1.1 需求的重要性
1.1.1 软件缺陷的8020原则
1) 在软件测试过程中，从需求分析开始到集成测试阶段引入测试手段，能发现所有缺陷的80%；系统测试阶段引入测试手段，能发现剩余缺陷中80%的缺陷；在运行维护阶段经过长时间、大量运行软件后，能够发现最后剩余的20%的缺陷。
1.2 软件需求
1.2.1 软件需求的定义
1） IEE软件工程标准词汇表( 1997年)中定义需求为:
(1)用户解决问题或达到目标所需的条件或权能( Capability )
(2) 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
(3)一种反映上面( 1 )或( 2 )所描述的条件或权能的文档说明。
2) 需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束软件需求的层次
1.2.2 软件需求的层次
1) 用户需求( user requirement )文档描述了用户使用产品必须要完成的任务，这在使用实例(use case )文档或方案脚本( scenario )说明中予以说明
2) 业务需求( business requirement )反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明
3) 功能需求( functional requirement )定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求
1.2.3 软件需求主要包括两个方面：需求开发和需求管理
1.2.4 需求开发可进一步分为四个阶段
- 需求获取阶段
- 需求分析阶段
- 编写需求规格阶段
- 需求验证阶段
1.2.5 不适当的需求过程可能引发风险
用户不多导致产品无法被接受
用户需求的增加带来过度的耗费和降低产品的质量
模棱两可的需求说明可能导致时间的浪费和返工
用户增加一些不必要的特性和开发人员画蛇添足( gold. plating)
过分简略的需求说明以致遗漏某些关键需求
忽略某类用户的需求将导致众多客户的不满
不完善的需求说明使得项目计划和跟踪无法准确进行
1.3 软件需求规格说明书
1.3.1 软件需求规格说明的特点
1) 完整性
不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功能将有助于你避免不完整性。如果知道缺少某项信息，用TBD( "待确定” ) 作为标准标识来标明这项缺漏。在开始开发之前，必须解决需求中所有的TBD项。
2) 一致性
一致性是指与其它软件需求或高层(系统,业务)需求不相矛盾。在开发前必须解决所有需求间的不一 致部分。只有进行一番调查研究 ，才能知道某项需求是否确实正确。
3) 可修改性
在必要时或为维护每一需求变更历史记录时,应该修订SRS.这就要求每项需求要独立标出,并与别的需求区别开来，从而无二义性。每项需求只应在SRS中出现- -次。 这样更改时易于保持一致性。 另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。
4) 可跟踪性
应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以-种结构化的，粒度好( fine -grained )的方式编写并单独标明，而不是大段大段的叙述。
1.4 软件测试需求跟踪矩阵
1.4.1 什么是测试需求跟踪矩阵
- 需求树的概念
- 需求树的好处
- 阅读理解各类需求
- 结合界面原型图理解软件各部分功能
- 从叶级别的功能点开始编写矩阵
- 保证每个功能点都有正反测试思路覆盖,正反测试配比达到1 : 4(部分功能点没有反向测试)
- 只写清测试思路和预期结果，不用具体展开
- 写好的测试需求跟踪矩阵必须通过评审才算最终完成
1.4.2 编写测试需求跟踪矩阵的步骤
1.5 软件测试需求
1.5.1 软件测试需求分析目标
对软件测试要解决的问题进行详细的分析,弄清楚参与软件测试活动的相关人员对软件测试活动和交付物的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么等。
1.5.2 软件测试需求分析步骤
- 根据软件开发需求说明书逐条列出软件开发需求,并判断其可测试性
- 形成可测试的描述并界定出测试范围
- 根据质量标准,逐条制定质量需求,即测试通过标准
- 分析测试执行时需要实施的测试类型
- 建立测试需求跟踪矩阵，并输入测试需求管理系统,对测试需求实施严格有效的管理
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
