说起软件测试需求，有很多人可能会觉着奇怪：“软件测试还有需求吗？不是把你写好的程序给我测试就是了吗？最终我给你一个测试结果就可以了吧”。这种想法在前几年还是可以的。随着软件系统的日趋复杂及精确性，软件测试也变得极为复杂，它是一项系统工程，由软件测试工程师、软件开发工程师与用户三方协同交流共同完成。没有测试需求，测试人员往往就不知道自己究竟要测什么，测试也不会达到既定目标。那么究竟什么是测试需求以及测试需求与软件需求有什么联系与区别呢？本文将就这些问题进行详细地阐述。
1. 什么是测试需求
套用软件需求的定义，我们可以说需求是…指明测试什么的规格说明。它描述了我们测试系统的行为、特性或属性，是在测试过程中对测试的约束。
测试需求分析 实际上是 通过划分需求来源、分解测试需求类型，并分析 测试需求的确定性、可测性、测试次序、重要性、稳定度、工作量...等活动，来定义出 测试需求的测试范围、优先级、测试风险、关系及约束，并建立与需求规格、测试用例之间的双向跟踪关系的过程。
测试需求则是直接源自于客户的质量要求。测试需求的源头非常繁杂，如何删繁就简，拿捏得当，目前没有现成的方法，仍需要做大量理论研究和实践探索。
2. 软件测试需求的作用
软件测试需求的作用不言而喻，他与软件需求分析的作用很接近，决定了后面如何做测试计划及安排测试人员的测试工作，也是测试人员的测试工作的依据。
3. 测试需求的基本属性
3.1. 用户接受的测试需求属性
测试需求的名称
为了便于对测试需求进行规范管理，方便查询和统计分析，用来唯一标识一个测试需求。
测试需求的编号
“需求编号”采用“REQ-A-B-C”四段编号，其中“REQ”代表需求，“A”代表系统名称，“B”代表模块名称，“C”代表三位的功能点顺序编号，从“001”编起。
如“REQ-CCI-外呼－001”，表示CCI系统“外呼”功能模块的第一个功能点。
上级需求的编号
为了对某测试需求进行详细划分，请将该测试需求作层状显示。如下所示：
需求1
需求11
需求111
……
需求12
需求121
……
需求2
需求21
需求211
……
需求22
需求221
……
“上级需求名称”，即为该需求的父需求名称。若为空，表示该需求为第一级需求。
所属子系统名称
评审状态
为了便于需求跟踪，需要设置该需求的评审状态。
“评审状态”有“创建”、“变更”、“评审”三个状态。
重要性
测试需求的“重要性”用来度量该测试需求对应的“业务需求”在整个系统业务功能中的重要程度，其来源一般依据“软件需求”的重要性指标。
“重要性”指标的取值有“核心”、“重要”、“一般”和“可选”四个值。
优先级
测试需求的“优先级”指标用来表明测试需求实施的优先次序。
优先级的取值有“高”、“中”和“低”三个值。
优先级取值的设定由测试经理综合考虑测试需求的“重要性”、“稳定度”和“工作量”三个值来设定。
稳定度
测试需求的“稳定度”指标用来表明该测试需求在测试实施过程中可能发生变更的可能性程度。
测试需求的“稳定度”指标有“高”“中”“低”三个取值。
影响测试需求稳定度的因素有业务需求的变更、业务需求的不正确理解等原因。
需求的稳定度由测试经理根据相应的业务需求的稳定度和其它因素进行设置。
工作量
测试需求的“工作量”指标用来标明在后续的测试实施过程中，为完全覆盖该测试需求而需要的工作量。
该数值由测试经理根据该测试需求对应的业务需求的复杂程度及其业务流程的繁简程度进行设置。
该值是一个权重值，采用百分制。
工作量最大的为100，最小的为10，以10为增量进制。
需求的工作量由测试经理进行设置。
据此对测试人员的工作量进行量化考核。
需求版本用来记录该测试需求对应的测试版本号。
创建人
记录该测试需求的创建人。
创建日期
记录该测试需求的创建日期。
功能点描述
“功能点描述”是对该测试需求对应的业务功能进行详细的描述。
每个测试需求只对应一个功能点，这一点一定注意。
业务规则描述
“业务规则描述”指对与该测试需求相对应业务功能的逻辑约束的描述。
业务规则一定要采用R1：到R9：进行编号。
3.2. 测试需求的管理属性
重要性
由测试经理设置。并非所有创建的测试需求都处在同一级别上，应综合考虑各项测试需求对最终用户的相对重要程度来划分其等级。通过促使客户、业务 / 系统分析人员和开发团队成员相互交换意见，最终确定测试需求的重要性。 另外此项指标还用于协助确定测试的优先级。
核心级
针对于必不可少的功能需求、非功能需求及核心的业务流程的测试需求。这些测试需求不测试通过，客户就不认可系统能够满足需求，就不会签字允许系统发布上线。因此，所有核心的测试需求都必须在发布前通过，否则将错过预定的发布时间
重要级
针对于关键的功能需求、重要的非功能需求及重要的业务流程的测试需求。如果遗漏了对这些测试需求的验证，或这些测试需求没有通过测试，可能会影响客户或用户满意度，甚至会影响收入。一旦这些测试需求有一个测试不通过，产品版本就不得发布
一般级
对于一些为特定用户或业务需求而设的系统功能，由于这些系统功能使用频率相对较低，或者这些系统功能可以由其它的方法实现其替代功能，因而即使发布版中并未包括这些功能，也不会对收入或客户满意度造成太大的影响。针对于这些系统功能的测试需求称之为一般性测试需求。这些测试需求是否通过测试将不影响产品的发布
建议级
针对于一般的测试需求，如果受资源或时间的约束，在预定的产品发布时间，有可能不能完成对这些系统功能的验证，则这些系统功能的测试需求被定义为可选（建议）的
状态
已提出
用于说明正在进行讨论但尚未经过“正式渠道”审批的测试需求项
已批准
被认为是有用、可行并已获得正式渠道批准，准备执行的测试需求项
成功/失败
指出测试需求是否通过测试的验证
已测试
指已通过测试的测试需求
变更中
测试需求处于变更中
稳定性
由测试经理设置。设置的依据是针对测试需求发生变化的可能性来定。其设定值应参考开发队伍对软件需求稳定度的设定，一般将稳定性分为高、中、低三挡即可。另外此项指标还用于协助确定测试的优先级
优先级
综合考虑测试需求的重要性、工作量和测试需求稳定性三个需求管理属性设定测试需求的优先级。一般将测试需求的优先级分为高、中、低三挡
4. 如何制定测试需求
网络上有一个帖子说微软的用户登录功能的测试用例有5000个测试用例，很多做测试的朋友第一个反应是变态。大家的这个反应有很多妒忌、羡慕的意思，其实更多的是不知道为什么微软会写那么多的测试用例，而如何写出来（这是测试人员第一个基本功）就更不了解了，于是才有了这个反应。其实编写测试需求，编写测试用例几万，几十万，几百万并不是一个很难的事情，关键看你是否掌握编写测试需求以及测试用例的方法。
测试需求的来源是系统需求报告（或者叫软件规格说明书等名字），测试需求报告主要内容是本次测试需要测试那些点，一般的系统需求说明书是按照系统，子系统，模块、功能、子功能、数据的形式来编写的，（这里是指的比较规范的需求说明书），比如人力资源管理，可能包括前端人力资源管理子系统（给人力资源部门的工作人员使用），后台管理子系统（系统管理员进行用户管理，权限管理等操作的系统）。用前端人力资源管理子系统而言一般有人员基本信息管理模块，薪金管理模块等模块，而人员基本信息管理模块又可以分为添加新人员基本信息功能，修改人员基本信息功能，删除人员基本信息功能,查询人员基本信息功能，汇总人员基本信息功能等功能，而在添加新人员基本信息功能里会涉及到人员基本信息的具体数据内容，比如人员姓名、性别、出生时间、到本单位的时间等信息。以上内容都应该在软件需求报告中获得，很多单位由于开发流程的差异测试人员即使不能在需求文档中获得，也应该可以从概要设计文档或者详细设计文档中获得，最糟糕的，也可以从开发人员的开发的系统上获得（顺便说一句，测试人员获得这些信息的顺序，可以代表开发部门开发的规范性和开发能力的高低，越早获得说明开发越规范）。作为一个测试人员可以依据这些信息编写测试需求，但此时编写的测试需求会很粗糙。一个系统编写的测试需求点会是几百到几千之间。写到这一步作为初级测试人员应该是很不错了，但这些东西都是用开发人员的成果转化过来的，还没有看出测试人员的能力。让我们将测试需求点进一步分割下去。拿人员基本信息管理的添加功能来举例吧，首先：可以分为添加0条数据，添加1条数据，添加n条数据。添加0条数据是指进入添加功能界面，然后不添加数据直接退出，（我曾经见过有一个系统在用户进入添加数据界面后你不添加数据就不让你退出添加功能，没有天理呀），添加一条数据就是添加一个数据，然后退出添加功能的界面，添加n条数据是连续添加数据。添加0条数据不能再扩充了。但添加一条数据和添加n条数据是可以扩充。比如姓名输入域可以测试的内容包括：标准数据，合法数据，非法数据。标准数据是指在输入最不可能出错的数据的情况下，该功能是否可以使用，如果在我们选择最不可能出错误的数据的情况下系统无法使用，我们就认为此功能根本不可使用，下边的合法数据的测试以及非法数据的测试就可以不进行了。合法数据的测试是对系统来说应该可以处理的数据，比如拿日期型数据来说，有闰年的问题，所有月的第一天，所有月的最后一天，年应该是4位，月可以是2位或者1位，而且应该小于等于12，另外一个是年、月、日之间应该有分割符号，这些内容都可以作为合法数据进行测试。如果合法数据测试通过则我们认为系统在处理合法数据的时候是应该没有问题的，如果项目时间紧张，在完成此类测试后就可以给用户试用了。这里有几个问题大家主要注意一下，一个是合法数据测试完成并不意味着测试完成，因为测试非法数据的测试还没有执行，而且就一般的规律来看，在输入非法的数据的情况下，系统出问题的可能性更大，之所以说可以给用户使用主要是迫于工期的压力，我们可以将部分测试工作和用户试运行这两个工作并行，但任务并行必然带来风险，如果开发人员都是熟练的开发人员（简单说都是5年以上的开发人员），风险会比较小，如果开发团队都是1-2年的开发人员最好不要并行。（风险太大）。第二点，在合法数据我们会进一步细分，比如单个数据输入域合法数据的测试和组合输入域的合法数据测试，单个数据输入域的测试，是在标准数据的基础上，对某一个测试输入域的合法数据进行测试，这样比较好明确的发现问题点，对开发人员的帮助会比较大，比如在人员基本信息管理的添加功能的测试中，我们有了标准数据，在标准数据测试通过的情况下，我们对姓名数据输入域进行测试，那么我们会将标准数据作为一个基准，在其他输入域不变的情况下（前提是其他输入域没有唯一性要求）只测试姓名输入域在合法数据的测试情况。其他数据输入域的情况依次类推。在单一数据输入域合法性测试完毕之后，可以进行组合测试。一般来说，单一合法性数据测试没有问题，组合出问题的可能性比较小。这里有一个问题，一个测试数据量比较大，比较好的解决方法有两个，一个是采用自动化测试工具，比如我们将字符型的数据输入域的需要测试的数据加以总结并放到一个电子报表里，你只要做好测试自动化脚本，并参数化相关输入域就可以完成相关输入域的测试，而且脚本的量并不是很大。另外一个方法是采用正交试验法。具体的方法和理论根据可以看《测评工程师教程》的相关内容，也可以减少测试用例的数据。保证测试质量。非法数据的构造的方法和合法数据的构造方法基本相同，这里就不多说了。基本上字符型输入可以有几十个检查点，日期型的可以有几百个测试检查点，浮点数和整形数的检查点也不会少，这样大致的统计下来写出几万，几十万的测试需求点不是很难的事情
5. 如何管理测试需求
在项目进行过程中，测试需求不是保持不变的，随着项目的进行，项目的“业务需求规格”、“软件需求规格”、“接口规范”、“设计规格”都有可能发生变化，对应的测试需求也可能发生变化；另外，测试策略、测试方法的调整也可能会导致测试需求的调整，需要采用规范的方法对测试需求进行管理，主要包括四个测试需求管理活动：需求评审、需求变更控制、需求跟踪和需求的一致性检查。
测试需求评审
经过用户接受测试需求分析和导出过程后，将得到用户接受测试需求初稿。业务管理部门应组织相关的业务人员、技术人员、环境管理人员、测试人员和其他相关人员进行用户接受测试需求评审，确保达成一致意见。
同样，测试管理部门应组织相关的技术人员、环境管理人员、测试人员和其他相关人员对系统连接测试需求分析导出的系统连接测试需求，对系统集成测试需求分析导出的系统集成测试需求进行评审，确保系统连接测试需求和系统集成测试需求通过评审。
对于内部测试需求分析中导出的内部测试需求，应由开发中心质量控制部组织相关业务人员、开发项目组进行评审，确保达成一致意见。
当各类测试需求通过评审后，它们将被导入 MQC 中进行版本标识，并进行统一管理。
测试需求跟踪
测试需求的跟踪是通过建立测试需求与之来源、与之测试用例之间的双向跟踪关系来实现的。具体为：
l 建立用户接受测试需求与业务需求规格、与用户接受测试用例之间的双向跟踪关系；
l 建立系统集成测试需求与软件需求分析规格、与系统集成测试用例之间的双向跟踪关系；
l 建立（系统）连接测试需求与概要设计规格、与（系统）连接测试用例之间的双向跟踪关系；
l 建立单元测试需求与详细设计规格，与单元测试用例之间的双向跟踪关系；
l 建立内部测试需求与软件需求分析规格、与详细设计规格、与内部测试用例之间的双向跟踪关系。
当发生需求变更时，可以根据此双向跟踪关系分析变更影响范围。如针对一个业务功能的变更，可以分析出这个变更将影响到哪些软件需求功能，这些软件功能是否需要变更，相应的哪些设计模块、代码文件、测试需求、测试用例会受到影响，它们是否需要变更。
QC 可以管理测试需求与测试案例的双向跟踪关系，但是不能管理系统概要设计规格、系统详细设计规格、软件需求分析规格、业务需求规格与它们的测试需求之间的双向跟踪关系。这需要单独的需求管理工具，如 Telelogic Doors 或 IBM Rational RequesitePro 等需求管理工具，如果没有这些专业的需求管理工具，也可以使用 Excel 表格等方法手工进行管理。
测试需求变更控制
在测试需求的跟踪关系建立起来以后，可借此跟踪关系进行测试需求的变更控制。
对由于缺陷修复、系统功能增减、业务需求变更等原因导致的变更，应遵循规范的变更过程，使测试需求变更有序、可控、可管理。其变更的控制过程如下：
1. 测试项目组需参与被测系统开发项目组的变更管理工作，针对在项目开发中引起的业务变更或系统功能变更或系统设计变更申请，测试项目组需要进行测试需求的变更影响性分析，判断这些变更是否会对相关测试需求产生影响。
2. 如果会产生影响，测试项目组需要判断变更会影响到哪些测试需求，影响到哪些测试用例。
3. 如果变更申请得批准，测试项目组需要变更测试需求及相应的测试用例，并形成新的测试需求版本（与变更后的相关开发文档版本保持一致）。
4. 最后将新形成的测试需求提交给相关的主管部门，组织评审通过。
测试需求的一致性检查
l IT 业务管理部应指定人员定期检查用户接受测试需求与用户接受测试计划、用户接受测试策略和用户接受测试方案的一致性，如果发现不一致，需要填写一致性检查报告。
l 测试管理部门应指定人员定期检查系统集成测试需求与系统集成测试计划、系统集成测试策略和系统集成测试方案的一致性，如果发现不一致，需要填写一致性检查报告。
l 测试管理部门应指定人员定期检查系统连接测试需求与系统连接测试计划、系统连接测试策略和系统连接测试方案的一致性，如果发现不一致，需要填写一致性检查报告。
l 测试经理应指定人员定期检查系统内部测试需求与系统内部测试计划、系统内部测试策略和系统内部测试方案的一致性，如果发现不一致，需要填写一致性检查报告。
l 测试经理针对一致性检查报告，确定不一致问题的纠正措施，并跟踪问题直至关闭。