软件需求是软件测试需求的主要来源，但不是全部来源，软件设计需求、软件概要设计、详细设计也都是测试需求的分析对象，是对测试需求的一种有力的补充。对于黑盒功能测试，几乎98%的需求都是来源于需求说明书，但有那么一小部分需求来自设计需求或概要设计、详细设计。也就那么小部分需求，如果我们没有意识到，就会给用户带来隐患。下面便是一个与设计需求相关的典型案例。
【案例】设计需求转换为测试需求失败
引言：软件开发环境，这一软件设计需求，对于产品需求来说，它只会说需要什么，不会关心这个东西用什么开发语言，什么开发环境去实现。但对于测试来说，需要掌握这些，因为测试的环境是测试必须考虑的要素之一，而测试环境与开发环境有关。
问题现象：待测软件在Vista Home Bbasic 32系统下安装失败。
问题背景：周五下午将近下班了，测试陈经理收到生产装机线上的信息，说昨天发布的软件，在Vista Home Basic 32下安装失败。
问题分析：测试人员在总结中提到“软件一直在各种宣称的支持平台上运行得很好，在不同的平台之间进行安装测试不下100次，仅是最后一个版本开发人员更改了安装程序，来不及在每个平台上铺开进行用户场景的测试，而问题却恰恰就出现在没测试的平台上”。或许，这种总结是我们日常工作中经常看到的。聪明的读者朋友，也许你已注意到了，这个仅是没有发现此Bug的表象，根本不是问题发生的原因。测试要及时发现此问题，难道每次对发布的版本都只能通过在各种操作系统环境之下重新再测试一遍的穷举方式来网罗未知的问题吗？
所测试的软件是用C#（Dot NET）开发的，而Dot NET开发出的软件运行与操作系统自身是否安装了Dot NET Framework有关，且还与版本有关。在进行安装测试时，测试人员并没有分析到这些影响因素。此Bug是因为软件在安装过程中发现当前操作系统自带了Dot NET Framework 3.0 组件，且版本比发布软件包中自带的高。安装程序遇这种情况不会安装自带的Dot NET Framework 2.0 SP1补丁包，于是终止了安装过程，并提示安装失败。这里面包含着两方面的问题，一者，安装程序遇到这种情况，不应该失败退出，应该继续往下安装；二者，操作系统Vista Home Basic自带的Dot NET Framework3.0是否向下兼容。
为了搞清楚它们之间的兼容性，相关人员汇总了Dot NET Framework各版本之间兼容性及与操作系统的集成关系，如表5-1所示。
表5-1 Dot NET Framework各版本之间兼容性及与操作系统的集成关系汇总表
Dot NET Framework版本
兼容性
与操作系统的集成
Dot NET Framework 1.0 Service Pack 1,2,3
支持向后兼容（注1）
无
Dot NET Framework 1.1 Service Pack 1
支持向前兼容，
也支持向后兼容（注2）
无
Dot NET Framework 2.0 Service Pack 1
支持向前兼容
无
Dot NET Framework 3.0 Service Pack 1
支持向前兼容S
Vista Home Basic带Dot
NET Framework 3.0
Dot NET Framework 3.5 Service Pack 1
支持向前兼容
注1：向后兼容，指使用Dot NET Framework 的较早版本创建的应用程序可以在更高版本上运行，例如使用Dot NET Framework 1.0 版创建的应用程序可以在1.1版上运行。
注2：向前兼容，指使用Dot NET Framework 的更高版本创建的应用程序可以在较低版本上运行，例如使用Dot NET Framework 1.1 版创建的应用程序可以在1.0版上运行。
上表这些测试环境相关信息，并不是一定出了问题之后才补起来，在分析设计需求、提取测试需求时就应该做，但测试人员在之前并没有意识到，成了测试的盲点。这也是笔者想讲述的核心，如何有效地把设计需求转换成测试需求。面对安装程序，测试人员是否理解了为什么要这样，而不那样？当不知道为什么要这样做，就意味着实现的背后仍可能隐藏着测试的盲区，就是那些没有触及的黑暗地方。例如，对于安装程序安装完成之后的预期输出，有不少测试朋友看到界面上提示“安装成功！”就以为大功告成。或许，这个提示骗骗用户还可以，对于专业的测试人员，除界面提示外，更重要的要把眼光放在软件安装过程中在操作系统上做了哪些事情，输出是否如预期。如果做到了这一点，就再也不会为“软件在未安装 Dot NET Framework 2.0 的计算机上安装 Dot NET Framework 3.0，同时自动安装 .NET Framework 2.0”而感到诧异。由于Dot NET Framework 1.0、1.1、2.0 版，各版本之间是完全独立的，无论计算机上是否存在其他版本，这3个版本中的任何一个版本都可以存在于计算机上。基于这一点，当我们看到如图5-5所示的界面，也就不足为奇了。
图5-5 Dot NET Framework 多版本并存
对于基于Dot Net Framework开发的软件，其相关的专业知识，如工作原理（见图5-6）、各版本之间的区别、兼容性等，对于测试人员来说，并不一定要精通，但要熟悉，方能占主动地位，把待测试软件验证充分。
图5-6 Dot Net Framework应用软件工作原理图
在一些测试专业网上，总有不少测试新手在问“测试是否要懂编程？”，或许上面的案例就是一个很好的回答。
有一句话说得好，“不怕做不到，就怕想不到”，这其中的“想”，就是主动意识的体现。在工作中，类似需求背后的需求还很多，一些可能与产品业务知识相关，一些与技术背景有关。业务知识也好，技术背景也罢，要提高我们分析需求的能力，设计出高效的测试用例，软件Bug的尽早发现，关键在于两个字--学习（放大一点理解，工作的过程也是学习的过程）。
相关链接：
快速理解需求的捷径：需求宣讲
测试需求分析与测试策略制定
好钢用在刀刃上：测试技术应用之合适设计
测试设计不只是测试设计工程师的事
软件测试流程改进设计案例分享
认识测试流程
测试管理中的隐形指挥棒：测试组织模式的设计（3）
测试管理中的隐形指挥棒：测试组织模式的设计（2）
测试管理中的隐形指挥棒：测试组织模式的设计（1）
解读测试设计
测试设计景观