一、什么是测试需求
测试需求的概念比较简单。例如，比方说一个计算平方根的程序，如果输入一个大于或等于零的数，程序可以给出一个结果；如果输入一个小于零的数，程序将指出输入错误。读过《软件测试的艺术》一书的工程师都会立即联想到边界值。对数值零进行测试；对零非常接近的负数进行测试，这就是两个具体的测试需求。
在一个更加复杂的程序中，你可以将打算测试的项目做成一个列表。但是，这些测试需求都不会确定具体的测试数据。例如，一个银行交易程序，一个测试需求是试图支付客户的金额为负数，另一个测试需求是交易中的客户并不存在，等等。你有一系列这样的测试需求，它们并没有指出具体的数值或数据，如客户的姓名。
测试的下一步是选择满足这些测试需求的输入值/测试数据。一个简单的测试用例可能会同时满足好几个测试需求。一个用例能同时满足好几个测试需求，当然是最理想的情况，但是这样做的代价较高。另外一种方法是为每一个测试需求设计一个单独的测试用例，就可以不必考虑那些复杂的测试用例，但是这些相对简单的测试用例发现缺陷的能力就会有所下降。
这里有一个测试需求的实例：对一个哈希表的插入操作进行测试，有以下这些测试需求：
1）插入一个新的条目
2）插入失败－条目已经存在
3）插入失败－表已满
4）哈希表在插入前为空
这些就是测试需求，而非测试用例，因为它们没有对被插入元素进行描述。另外你也不能马上就着手书写用例，就好象软件需求完成后不能立即进行编码一样。还需要对测试需求进行评审，确保正确和没有需求遗漏。
二、为什么要做测试需求分析
如果要成功的做一个测试项目，首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要通过详细的测试需求来了解。所谓知己知彼，百战不殆。测试需求不明确，只会造成获取的信息不正确，无法对所测软件有一个清晰全面的认识，测试计划就毫无根据可言。活在自己世界里的人是可悲的，只凭感觉不做详细了解就下定论的项目是失败的。
测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。
如果把测试活动比作软件生命周期，测试需求就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把”软件”两个字全部替换成了”测试”。这样，我们就明白了整个测试活动的依据来源于测试需求。
三、需求测试注意事项有哪些
一个良好的需求应当具有一下特点：
完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
正确性：每一项需求都必须准确地陈述其要开发的功能。
一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。
可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。
健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。
可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。
可修改性：每项需求只应在系统需求分析中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。
可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（f i n e - g r a i n e d ）的方式编写并单独标明，而不是大段大段的叙述。
四、测试需求需要考虑几个层面的因素
第一层：测试阶段。系统测试阶段，需求分析更注重于技术层面，即软件是否实现了具备的功能。如果某一种流程或者某一角色能够执行一项功能，那么我们相信具备相同特征的业务或角色都能够执行该功能。为了避免测试执行的冗余，可不再重复测试。而在验收测试阶段，更注重于不同角色在同一功能上能否走通要求的业务流程。因此需要根据不同的业务需要而测试相同的功能，以确保系统上线后不会有意外发生。但是否有必要进行这种大量的重复性质的测试，不过也是见仁见智的做法，要看测试管理者对测试策略与风险的平衡能力了。
目前，大多数的测试都会在系统测试中完成，验收测试只是对于系统测试的回归。此种情况也是合理的，关键看测试周期与资源是否允许，以及各测试阶段的任务划分。
第二层：待测软件的特性。不同的软件业务背景不同，所要求的特性也不相同，测试的侧重点自然也不相同。除了需要确保要求实现的功能正确，银行/财务软件更强调数据的精确性，网站强调服务器所能承受的压力，ERP强调业务流程，驱动程序强调软硬件的兼容性。在做测试分析时需要根据软件的特性来选取测试类型，并将其列入测试需求当中。
第三层：测试的焦点。测试的焦点是指根据所测的功能点进行分析、分解，从而得出 的着重于某一方面的测试，如界面、业务流、模块化、数据、输入域等。目前关于各个焦点的测试也有不少的指南，那些已经是很好的测试需求参考了，在此仅列出业务流的测试分析方法。
任何一套软件都会有一定的业务流，也就是用户用该软件来实现自己实际业务的一个流程。简单的来说，在做测试需求分析时需要列出以下类别：
1） 常用的或规定的业务流程
2） 各业务流程分支的遍历
3） 明确规定不可使用的业务流程
4） 没有明确规定但是应该不可以执行的业务流程
5） 其他异常或不符合规定的操作
然后根据软件需求理出业务的常规逻辑，按照以上类别提出的思路，一项一项列出各种可能的测试场景，同时借助于软件的需求以及其他信息，来确定该场景应该导致的结果，便形成了软件业务流的基本测试需求。
在做完以上步骤之后，将业务流中涉及的各种结果以及中间流程分支回顾一遍，确定是否还有其他场景可能导致这些结果，以及各中间流程之间的交互可能产生的新的流程，从而进一步补充与完善测试需求。
文章来源于领测软件测试网 https://www.ltesting.net/
