标签：一致性 矛盾 环境 修改 测试设计 mic 处理 统一 测试结果
什么是客户 客户需求分析 > 维护
时间、成本和质量
1.1 测试需求的分析和确定
1.2 测试计划
1.3 测试设计
1.4 测试执行
1.5 测试记录和缺陷跟踪
1.6 回归测试
1.7 测试总结和报告
PDCA 戴明循环：
P---Plan（计划）
D---Do（执行）
C---Check（检查）
A---Action（处理）
具体的流程可以概括为：
1.在分析清楚需求的前提下对测试活动进行计划和设计
2.按既定的策划执行测试和记录测试
3.对测试的结果进行检查分析，形成测试报告
4.这些测试结果和分析报告又能指导下一步的测试设计
5.因此形成了一个测试的循环
2.1需求规格说明书的检查要点（也叫黑盒的静态测试）
检查要点：
1. 正确性
2.必要性
3. 优先级
4.明确性
5.可测性
6.完整性
7. 可修改性
8. 一致性
具体以下步骤：
1. 获取最新版本的软件需求规格说明书，同时尽量取得用户原始需求文档
2.阅读和尝试理解需求规格说明书中描述的所有需求项
3.对照需求规格说明书检查列表进行检查并记录
4.针对检查结果进行讨论、修订需求规格说明书后回到第一步，指到检查列表重点所有项通过
检查列表例子，常用的10个：
第一项需要检查需求规格说明书是否满足了用户提出的每一项需求。需求的完整性
第二项需要检查需求文档的用词用语问题。需求的明确性
第三项检查的是需求规格说明书对需求覆盖是否准确。需求的必要性
第四项检查的是软件使用环境的描述是否清晰。需求的完整性
第五项检查的是需求的规格说明书中的需求编号是否正确。需求的可修改性
第六项主要检查需求是否自相矛盾。需求的统一性
第七项主要检查软件系统允许的输入与预期的输入。需求的可测性
第八项检查的是软件系统的性能需求有没有得到清晰的表述。需求的完整性
第九项检查的是需求的关注重点和实现的先后顺序是否清晰地被描述出来。需求的优先级
第十项检查的是对软件系统的约束条件是否完整描述。需求的可测性
2.2需求文档的检查步骤
2.3通过编写测试用例来检查需求
标签：一致性 矛盾 环境 修改 测试设计 mic 处理 统一 测试结果
原文地址：https://www.cnblogs.com/huiguizhe/p/12037111.html
