-,为什么在需求中引入测试
1. 可以提早发现bug
2. 可以对软件和领域有更深的了解,
3. 可以更好的完成 test plan, design, case,
4. 可以对需求提出修改意见
5. 可以发现有意义的bug, 提高测试质量
二, 在需求阶段测试的工作。
1. 和需求人员一起参与分析需求,使得测试能深层次的理解需求。
2. 如果需求已形成,测试需要用审阅的方式进行,主要看是否有功能遗漏,是否有多余的需求。
需求表达是否规范等(对测试有行业的要求)
1.是否所有需求都体现了 是[ ] 否[ ] NA[ ]
2.用语是否清晰无歧义(查找诸如也许、可能、大概、大约等关键字) 是[ ] 否[ ] NA[ ]
3.是否清楚描述软件要做什么及不做什么 是[ ] 否[ ] NA[ ]
4.是否描述了软件使用的目标环境,指明并简短描述了目标环境中其它相关软件产品/子系统/模块
5.是否每一个具体需求都有唯一的编号 是[ ] 否[ ] NA[ ]
6.每一个需求是否切实可行、可测试、前后一致、彼此不冲突 是[ ] 否[ ] NA[ ]
7.是否说明了对每个输入的验证措施,并描述了每个输入的属性,如:度量单位、边界值、时序要求 等 是[ ] 否[ ] NA[ ]
8.是否说明了对每个输入的处理 是[ ] 否[ ] NA[ ]
9.是否说明了对每个输出项是如何输出的,并且描述了每个输出的属性,如:度量单位、边界值、时 序要求等 是[ ] 否[ ] NA[ ]
10.是否描述了性能需求 是[ ] 否[ ] NA[ ]
11.所描述的性能需求是否能通过测试来进行验证 是[ ] 否[ ] NA[ ]
12.是否说明了所有对系统可能的约束 是[ ] 否[ ] NA[ ]
Kate Nie 说:
3. 之后,写test plan, test case
需求测试的注意点:
完整性
正确性
一致性
有效性
可测试性
可实现性
通过用户调查来测试需求
通过设计测试用例来测试需求
利用现存的产品对需求进行测试
三, 设计测试过程,尽量和需求文档要一致,在开发给测试软件之前。
四,当需求文档有变更的时候。
1. 成立小组,有测试,开发,写需求的人组成。
2. 纪录每次更改(在什么时候,谁,更改了什么,怎么更改的,地点是哪里)
3. 小组一起讨论,变更的风险,优先级,效果,权衡利弊
4. 引入requirements-management工具,这样方便每次更改可以记录
五,基于一个已存在系统的开发的注意点。
1. 所有相关的人都要理解为什么要基于指定的软件来开发的软件,清楚原理。
2. 明确指定的软件的逻辑和输出是否正确,再决定参考。
3. 至少记录每个模块的描述,尽量多给一些细节,和整体的业务。
4. 明确哪些被更新了和新增加的,要对测试的功能,设计,测试过程分析。
5. 建立有效的测试流程。