系统测试用例评审checklist

规则要素内容	使用范围		审查结果			“否”的理由	“免”的理由
	规则	建议	是	否	免
规范性规则
用例是否按照公司规定的模板进行编写？	√
用例的编号是否符合规范命名要求（项目缩写-子特性-ST-测试类型-编号，如：HaiDaTicket-Login-ST-Function-001）？	√
用例跟方案中的用例是否一致或者是否完全覆盖方案中描述的所有系统测试项？	√
是否更新了需求跟踪矩阵，用例编号和需求跟踪矩阵中的用例编号是否一一对应？	√
用例是否覆盖了基线化后的SRS？	√
用例设计是否按照测试计划安排的时间完成？		√
用例对新增或者变更的需求是否做了相应的调整？	√
内容符合性
用例设计是否考虑了正向和反向两方面的情况？	√
用例是否可测试？	√
用例的重要级别和优先级是否定义合理？	√
用例是否清晰地描述了测试用例的标题？	√
用例是否清晰地描述了预置条件？	√
用例是否清晰无二义地描述了操作步骤？	√
用例是否清晰描述了用例的输入且输入（测试数据）的准备是否有相关的描述？	√
用例是否清晰的描述了预期结果以及预期结果是否可以验证？	√
用例设计是否使用了等价类分析、边界值、因果图、判定表、错误推测、正交分析、流程分析、状态迁移分析、输入域覆盖、输出域覆盖等测试用例设计方法？是否针对不同的测试特性设计使用合适的设计方法？		√
重点特性用例设计是否采用了多种方法结合来设计？是否过滤掉了重复的测试用例？		√
用例中需要进行打印输出（如报表）、表格的导入、导出是否说明了打印位置、表格名称、指定数据库表名或文件位置；表格和数据格式是否有说明或附件？		√
质量目标
用例覆盖率是否达到相应质量目标（如用例数（个）/KLOC）?	√
用例评审发现的缺陷率（缺陷总数/用例总数）是否达到了相应的质量目标？	√
用例的粒度是否合理和统一，是否均匀覆盖了测试需求？	√
用例发现的问题是否占整个测试执行发现问题的80%（当然越高越好）以上（事后验证）？	√
测试用例设计的时间占整个系统测试过程的时间是否合理（一般在30-40%）（这里排除一些专项测试如稳定性测试、长时间测试等）？		√
其他
测试执行过程中发现用例不完善是否做相应的调整？	√
软件版本的升级，用例是否做相应的调整？	√