原文转自：http://www.51testing.com/html/37/n-846437.html
测试需求的意义
实际项目操作中，常常感受到测试过程有些问题：
1、产品质量维度关注的不全面，测试类型不完整；
2、测试规格设计较为随意，测试分解分配比较随意；
导致测试过程中，经常会出现需求遗漏、测试设计遗漏的问题；因此一份详细精准的测试需求分析有利于这些问题的解决。
测试需求的定义
测试人员依据初期功能需求，评估需要测试的功能点都有什么，每个功能点需要什么类型的测试，每个功能点测试到什么程度算是通过，这样初步评估出了测试的规模、复杂程度和风险，同时可以初步预估出哪个环节需要研发同事提供测试接口。
测试需求设计的愈加详细精准，代表对待测试的软件了解的愈深，对各种测试手段了解的愈深，但是这往往要求测试需求的设计者拥有一定的测试经验。
测试需求的流程
1. 测试需求的采集
直接来源：
1）软件需求规格；
2）业界协议规范；
3）测试经验库；
4）对于已有旧版本的软件测试，还需要考虑继承性的测试需求。
对以上内容进行梳理，形成原始测试需求表，列表的内容包括需求标识、原始测试需求描述、信息来源，如下：
|
来源编号 |
测试原始需求编号 |
测试原始需求描述 |
开发特性 |
需求标识 |
需求描述 |
需求优先级 |
测试规格分析的工程方法 |
|
DR001 |
EMAIL-001 |
能够支持电子邮件的收发 |
|
OR_MKT.00010 |
能够支持电子邮件的收发 |
可测试：存在一个可明确预知的结果，可用某种方法对这个明确的结果进行判断、验证。
原则：1）所有的软件需求都应该是可测试的。因为如果作为测试人员对需求无法产生准确的理解（即无法得出明确的结果），那么开发人员也同样无法对同一条需求产生准确的理解。2）每一个测试需求需要保证一条需求只包含一项测试内容。因此一条软件需求通常可能对应多条测试需求。
该阶段需注意：需求整理的广泛性和全面性。要尽可能的收集更多的原始需求，不存在遗漏，并且可以对需求进行适当的扩充。这些需求应该不仅仅局限于上述的五种来源类型，也不仅仅局限于各种文档、资料。
2. 测试需求的分析
测试需求采集之后得到的是一张没有优化的需求表，需要对这份原始需求表进行初步的规划。规划要求：
1）删除冗余重复的需求，各个需求间没有过多的交集；
2）需求需覆盖业务流程、功能、非功能方面的需求。
业务流程：
迈克尔·哈默(Michael Hammer)与詹姆斯·钱皮(James A．Champy)对业务流程(Business Process)的经典定义：我们定义某一组活动为一个业务流程，这组活动有一个或多个输入，输出一个或多个结果，这些结果对客户来说是一种增值。简言之，业务流程是企业中一系列创造价值的活动的组合。
任何一套软件都会有一定的业务流，也就是用户用该软件来实现自己实际业务的一个流程。业务流程的类别：
1）常用的或规定的业务流程；
2）各业务流程分支的遍历；
3）明确规定不可使用的业务流程；
4）没有明确规定但是应该不可以执行的业务流程；
5）其他异常或不符合规定的操作。
测试需求需要达到的目标：
1）需求需考虑了各功能模块之间交互关系分析；
2）确定测试特性（即测试功能点）；
3）确定需求的测试类型。
测试类别：
需求分析要需要完成的任务：
1）确定需求的质量属性；
2）确定本版本测试所属的阶段。
测试阶段：产品的不同阶段，对于测试阶段的要求也不一样。对于初期版本的产品，更侧重于关注：功能是否实现（这个功能正常场景下是否顺利）、较为成熟阶段之后，会关注：功能是否实现的够完善（异常场景下，是否正常处理），更加成熟之后会关注，是否通得过各种压力测试场景。
测试需求分析的结果：
测试需求跟踪矩阵
建立测试需求跟踪矩阵，对测试需求进行管理。将上述步骤分析、确定的开发需求、测试需求、测试类型填入测试跟踪需求矩阵。
建立测试需求跟踪矩阵，对测试需求进行管理。将上述步骤分析、确定的开发需求、测试需求、测试类型填入测试跟踪需求矩阵。
通过测试需求跟踪矩阵的方式对需求变更实施管理。软件需求一旦发生变化，就要对需求跟踪表进行维护，启动配置管理过程，将与软件需求变更相关的内容进行同步变更。
3.测试需求评审
评审的内容：
完整性审查：应保证测试需求能充分覆盖软件需求的各种特征，重点关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束等方面，同时还应关注是否覆盖开发人员遗漏的、系统隐含的需求；
准确性审查：应保证所描述的内容能够得到相关各方的一致理解，各项测试需求之间没有矛盾和冲突，各项测试需求在详尽程度上保持一致，每一项测试需求都可以作为测试用例设计的依据。