需求文档测试

一：测试人员及早进入

1.准确地理解测试的对象并且和其他涉众一起生成测试的需求。

2.测试人员需要彻底的了解产品，重点考核最关键和最有风险的地方，只有这样才可能设计出更加出色和更加全面的测试计划、测试设计、测试过程和测试用例。

3.生命周期中发现缺陷越早，修正缺陷的代价越小。

二：验证需求

1.在确定系统需求的工作中，为每条需求建立一个质量测度标准，有助于使模糊的需求明确化。方法：使用若干明确的小需求替换一个过于模糊的大需求。

2.测试用例是一种把功能性需求文档化的方法，能够使以后的系统设计和测试过程更加全面。

3.功能性需求应该和与之关联的非功能性需求（性能、安全性、可使用性、兼容性、可访问性）一起进行说明。

4.需求规格说明书检测属性：

1:)一致性  没有清晰一致的需求定义，就无法确定需求的正确性。

2:)可测性（可验证性）   保证了测试一条需求的可能性，同时测试的结果是预先知道的并且能够加以验证的。

3:)必要性  验证规格说明书中的每条需求是否都与系统有关，需对照系统的既定目标来检查需求。

4:)优先级  让大家了解每条需求在需求涉众心中的价值。

5:) 明确性  保证了需求的陈述使用了精确的和可测量的方法。举例一个不明确的需求：系统必须快速的响应用户的查询请求—”快速“是模糊和主观的。

6:)可追溯性  保证每条需求能够找到所有引用它的系统部分。当测试员收到需求变更的通知时，就会保证所有受影响的部分都经过了适应性的调整。

三：需求就绪后立即设计测试过程

1.测试人员会用测试数据集合作为输入非常仔细的走查系统的每个交互操作，所有可能会发现需求文档中的某些疏忽、遗漏、错误的流程和其他错误。通过这个过程会使需求适应各种变化的场景，也会把在各种情况下的需求描述成一条由交互操作组成的清晰路径。

2.通过测试过程的定义来确认一条需求中的错误和遗漏的过程就是验证需求的可测试性。早为需求设计测试过程有利于尽早发现不能验证的问题。

3.测试过程的设计必须根据迭代的实现计划来划分优先级。需求常常会以迭代方式通过评审和分析而不断得到精华，是“动态”的文档。

四：确保需求变化的传达

1.通过设置需求变更规程，把需求的所有变化传达给涉众。

2.如果一条需求需要变更，那么变更规程必须考虑到发生在设计、编码以及包括测试文档在内的所有相关文档上的连锁效应。