8.1.2 什么是测试需求
简单来说，测试需求就是确定在项目中需要测试什么。测试需求描述测试的目标，特别是描述了产品的质量需求。测试需求分析目的是帮助定义测试对象和测试范围，发现软件需求中不完善和不明确的地方并加以完善，以节省投入的测试时间，便于将软件需求基线化和跟踪业务需求的变更过程。
一条有用的测试需求是唯一的、精确的、有边界的和可测试的。例如：软件产品有一个测试需求“系统主要事务的响应时间能满足系统要求”，这条测试需求其实是不符合要求的，能“满足”系统要求的具体是什么样的指标？要是说不出个一二三，测试就无法开展。
案例&知识：
一个完整清晰、可测试的测试需求应该是这样的：在1GB内存和1.73GHz主频的计算机中，25个并发用户执行插入、更新和删除操作时端到端的响应时间在3s内。因此，符合标准的测试需求是存在一个明确、可预知的结果，还可通过某种方法对这个结果进行判断和验证。
测试需求是测试计划的基础与依据，在测试活动中，首先需要明确测试需求（What），才能决定怎么测（How），测试时间（When），需要多少人（Who），测试的环境是什么（Where）。这些都是衡量测试覆盖率的重要指标。
1.为什么要做测试需求分析
如果要成功地做一个测试项目，首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要通过详细的测试需求来了解。测试需求不明确，只会造成获取的信息不正确，无法对所测软件有一个清晰全面的认识，测试计划就毫无根据可言。
测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。
若把测试活动比作软件生命周期，测试需求就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把“软件”两个字全部替换成了“测试”。这样，我们就明白了整个测试活动的依据来源于测试需求。
2.什么时候开始做测试需求分析
软件生存周期的各个阶段都可能产生错误。而软件需求分析、设计和实现阶段是软件的主要错误来源。因此，一旦软件需求确定后，即可开始进行测试需求分析。
3.测试需求的分析方法
测试需求分析有两个关键词：一是“测试需求”；二是“分析”。测试需求的分析主要体现在以下3个层面。(https://www.daowen.com)
第一层：测试阶段。系统测试阶段，需求分析更注重于技术层面，即软件是否实现了具备的功能。如果某一种流程或者某一角色能够执行一项功能，那么我们相信具备相同特征的业务或角色都能够执行该功能。为了避免测试执行的冗余，可不再重复测试。而在验收测试阶段，更注重于不同角色在同一功能上能否走通要求的业务流程。因此需要根据不同的业务需要来测试相同的功能，以确保系统上线后不会有意外发生。但是否有必要进行大量重复性质的测试，也是见仁见智的做法，这就要看测试管理者对测试策略与风险的平衡能力了。
目前，大多数的测试都会在系统测试中完成，验收测试只是对于系统测试的回归。这种情况也是合理的，关键看测试周期与资源是否允许，以及各测试阶段的任务划分。
第二层：待测软件的特性。不同的软件业务背景不同，所要求的特性也不相同，测试的侧重点自然也不相同。除了需要确保要求实现的功能正确，银行/财务软件更强调数据的精确性，网站强调服务器所能承受的压力，ERP强调业务流程，驱动程序强调软硬件的兼容性。在做测试分析时需要根据软件的特性来选取测试类型，并将其列入测试需求当中。
第三层：测试的焦点。测试的焦点是指根据所测的功能点进行分析、分解，从而得出的着重于某一方面的测试，如界面、业务流、模块化、数据、输入域等。目前关于各个焦点的测试也有不少的指南，而且已经能很好地作为测试需求的参考，在此仅列出业务流的测试分析方法。
任何一套软件都会有一定的业务流，也就是用户用该软件来实现自己实际业务的一个流程。简单来说，在做测试需求分析时需要列出以下类别：
（1）常用的或规定的业务流程。
（2）各业务流程分支的遍历。
（3）明确规定不可使用的业务流程。
（4）没有明确规定但是应该不可以执行的业务流程。
（5）其他异常或不符合规定的操作。
然后根据软件需求理出业务的常规逻辑，按照以上类别提出的思路，一项一项列出各种可能的测试场景，同时借助于软件的需求以及其他信息，来确定该场景应该产生的结果，便形成了软件业务流的基本测试需求。
在做完以上步骤之后，将业务流中涉及的各种结果以及中间流程分支回顾一遍，确定是否还有其他场景可能导致这些结果，以及各中间流程之间的交互可能产生的新的流程，从而进一步补充与完善测试需求。
