测试用例评审相关

测试用例评审
1.测试用例是否覆盖了所有需求.
2.测试用例内容是否正确,是否与需求目标一致.
3.测试用例内容是否完整,是否清楚包含输入和预期输出结果.
4.测试用例是否具有指导性,是否能灵活指导测试人员通过用例发现更多缺陷,而不是限制他们的思维.
5.找出哪些需求不可测：无法准备环境、可测试性达不到等等原因；
6.对具体需求的实现结果的确认（设计人员、开发人员、测试人员的认识是否一致，如果不一致，谁说了算）；
7. 测试用例本身的描述是否清晰，是否存在二义性
8.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下

测试用例评审流程
1.目的　　测试用例评审流程规范主要为开展测试用例评审工作提供指引，规范测试用例评审管理工作。2.测试用例评审流程内容　　2.1.前提：测试人员编写完一个完整的功能模块的测试用例或已完成所有测试用例的编写； 2.2.流程输入：A.测试用例； B.需求规格说明； 2.3.流程输出：A.问题记录清单； B.测试用例评审报告； 2.4.参与评审人员：项目经理、测试负责人、测试人员、需求分析人员、架构设计人员、开发人员； 2.5.评审方式：　　　　1）召开评审会议。与会者在测试用例编写人员讲解之后给出意见或建议，同时记录下评审会议记录；　　　　2）通过邮件、及时通讯工具与相关人员沟通。　　　　　　无论采用哪种方式，都应该在评审之前事先把需要评审的测试用例相关文档以邮件的形式发给参与评审的相关人员，同时在邮件中提醒参与评审的相关人员在评审前查阅一遍评审内容，并记录相关问题，以便在评审会议上提出，以节省沟通成本。　　2.6评审用例检查清单：　　　　1）测试用例是否按照公司定义的模板进行编写的；　　　　2）测试用例的本身的描述是否清晰，是否存在二义性；　　　　3）测试用例内容是否正确，是否与需求目标相一致；　　　　4）测试用例的期望结果是否确定、唯一的；　　　　5）操作步骤应与描述是否相一致；　　　　6）测试用例是否覆盖了所有的需求；　　　　7）测试设计是否存在冗余性；　　　　8）测试用例是否具有可执行性；　　　　9）是否从用户层面来设计用户使用场景和业务流程的测试用例；　　　　10）场景测试用例是否覆盖最复杂的业务流程；　　　　11）用例设计是否包含了正面、反面的用例；　　　　12）对于由系统自动生成的输出项是否注明了生成规则；　　　　13）测试用例应包含对中间和后台数据的检查；　　　　14）测试用例应有正确的名称和编号；　　　　15）测试用例应标注有执行的优先级；　　　　16）测试用例包含相关的配置信息：测试环境、数据、前置测试用例、用户授权等；　　　　17）每个测试用例步骤应<=15 Step；　　　　18）自动化测试脚本必须带有注释（注释应包括：目的、输入、期望结果等）；　　　　19）非功能测试需求或不可测试需求是否在用例中列出并说明？　　2.7.退出标准：　　　　1）评审过程中收集相关人员的反馈信息（即问题记录清单），并在此基础上进行测试用例更新，直到评审通过；　　　　2）评审结束后，测试负责人出测试用例评审报告给到相关人员；　　　　3）评审结果经项目经理同意确认。　　2.8.控制机制：　　　　采用评审会议时，主持人应尽量把握会议进度，尽量按时有效的完成评审工作；