win10怎么把硬盘合并:测试用例评审

测试用例评审工作对测试人员能力的提高，测试效率的提高都有很好的作用，那么如果进行测试用例评审呢？它又哪些标准呢？通过的标准又是什么呢？

关于“测试用例内部评审的标准”的讨论的摘要：
首先要清楚内部评审的定义，是测试组内部的评审，还是项目组内部的评审。评审的定义不同，内容也不会相同。

如果是测试组内部的评审，应该着重于：
1. 测试用例本身的描述是否清晰，是否存在二义性
2.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下
3.是否针对需求跟踪矩阵，覆盖了所有的软件需求，
4.是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。

如果是项目组内部的评审，也就需要评审委员会来做了，角度不同，评审的标准也不同。比如：
收集客户需求的人员注重你的业务逻辑是否正确；
分析软件需求规格的人注重你的用例是否跟规格要求一致；
开发负责人会注重你的用例中对程序的要求是否合理。

要清楚地一点是：为了保证测试用例设计的质量，以及评审的收益，在提交项目组评审之前，必须通过测试部门或测试组内部的评审。

同意asong401的观点
1.测试用例是否覆盖了所有需求.
2.测试用例内容是否正确,是否与需求目标一致.
3.测试用例内容是否完整,是否清楚包含输入和预期输出结果.
4.测试用例是否具有指导性,是否能灵活指导测试人员通过用例发现更多缺陷,而不是限制他们的思维.
初期设计测试点时，应该进行测试组内部评审，当然首先是要保证需求全被覆盖，如果能在评审时，让需求分析人员参与进来，效果会更好。


测试用例评审如何去做呢？
测试用例的评审能够使用例的结构更清晰，覆盖的用户场景更全面；对于测试工程师来说也是一个快速提高用例设计能力的过程。

　　1、需要评审的原因

　　测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异。

　　2、进行评审的时机

　　一般会有两个时间点。第一，是在用例的初步设计完成之后进行评审；第二是在整个详细用例全部完成之后进行二次评审。如果项目时间比较紧张，尽可能保证对用例设计进行评审，提前发现其中的不足之处。

　　3、参与评审人员

　　这里会分为多个级别进行评审。

　　1) 部门评审，测试部门全体成员参与的评审。

　　2) 公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。

　　3) 客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。

　　4、评审内容

　　评审的内容有以下几个方面：

　　1) 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。

　　2) 优先极安排是否合理。

　　3) 是否覆盖测试需求上的所有功能点。

　　4) 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。

　　5) 是否已经删除了冗余的用例。

　　6) 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。

　　7) 是否从用户层面来设计用户使用场景和使用流程的测试用例。

　　8) 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

　　个人认为，一个“健康”的测试用例至少要通过前5个标准。

　　5、评审的方式

　　1) 召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。

　　2) 通用邮件与相关人员沟通

　　3) 通用IM工具直接与相关人员交流

　　方式只是手段，得到其它人员对于用例的反馈信息才是目的。

　　无论采用那种方式，都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解

，以节省沟通成本。

　　6、评审结束标准

　　在评审活动中会收集到用例的反馈信息，在此基础上进行用例更新，直到通过评审。

　　个人愚见，仅参考 ^o^

测试用例评审检查单：

     序号 主要检查项

　　1《需求规格说明书》是否评审并建立了基线?

　　2 是否按照测试计划时间完成用例编写?

　　3 需求新增和变更是否进行了对应的调整?

　　4 用例是否按照公司定义的模板进行编写?

　　5 测试用例是否覆盖了《需求规格说明书》?

　　6 用例编号是否和需求进行对应?

　　7 非功能测试需求或不可测试需求是否在用例中列出并说明?

　　8 用例设计是否包含了正面、反面的用例?

　　9 每个测试用例是否清楚的填写了测试特性、步骤、预期结果?

　　10 步骤/输入数据部分是否清晰，是否具备可操作性?

　　11 测试用例是否包含测试数据、测试数据的生成办法或者输入的相关描述?

　　12 测试用例是否包含边界值、等价类分析、因果图、错误推测、等测试用例设计方法?是否针对需求不同部分设计使用不同设计方法?

　　13 重点需求用例设计至少要有三种设计方法?

　　14 每个测试用例是否都阐述预期结果和评估该结果的方法?

　　15 需要进行打印、表格、导入、导出、接口是否存在打印位置、表格名称、指定数据库表名或文件位置;表格和数据格式是否有说明或附件?

　　16 用例覆盖率是否达到相应质量指标?

　　17 用例预期缺陷率是否达到相应质量指标?

测试用例评审有效性的44个衡量标准：

原文：
“44” Metrics for Test Case Review Effectiveness - http://davidfrico.com/roi-metrics-f.htm1.Major Defects Per Test Case Review
每个经评审的测试用例发现的主要缺陷
2.Minor Defects Per Test Case Review
每个经评审的测试用例发现的次要缺陷3.Total Defects Per Test Case Review
每个经评审的测试用例发现的缺陷总数4.Ratio of Major to Minor Defects Per Test Case Review
每个经评审的测试用例发现的主要缺陷与次要缺陷的比例5.Total Defects Per Test Case Review Hour
每一个小时评审的测试用例发现的缺陷总数6.Major Defects Per Test Case Review Hour
每一个小时评审的测试用例发现的主要缺陷7.Ratio of Major to Minor Defects Per Test Case Review Hour
每一个小时评审的测试用例发现的次要缺陷8.Number of Open Defects Per Test Review
每个经评审的测试用例发现的处于Open状态的缺陷个数9.Number of Closed Defects Per Test Case Review
每个经评审的测试用例发现的处于Closed状态的缺陷个数10.Ratio of Closed to Open Defects Per Test Case Review
每个经评审的测试用例发现的处于Closed状态的缺陷个数与处于Open状态的缺陷个数的比例11.Number of Major Open Defects Per Test Case Review
每个经评审的测试用例发现的处于Open状态的主要缺陷个数12.Number of Major Closed Defects Per Test Case Review
每个经评审的测试用例发现的处于Closed状态的主要缺陷个数13.Ratio of Major Closed to Open Defects Per Test Case Review
每个经评审的测试用例发现的处于Closed状态的主要缺陷与处于Open状态的主要缺陷的比例14.Number of Minor Open Defects Per Test Case Review
每个经评审的测试用例发现的处于Open状态的次要缺陷个数15.Number of Minor Closed Defects Per Test Case Review
每个经评审的测试用例发现的处于Closed状态的次要缺陷个数16.Ratio of Minor Closed to Open Defects Per Test Case Review
每个经评审的测试用例发现的处于Closed状态的次要缺陷与处于Open状态的次要缺陷的比例17.Percent of Total Defects Captured Per Test Case Review
每个经评审的测试用例发现的总缺陷个数占缺陷总数的百分比18.Percent of Major Defects Captured Per Test Case Review
每个经评审的测试用例发现的主要缺陷个数占缺陷总数的百分比19.Percent of Minor Defects Captured Per Test Case Review
每个经评审的测试用例发现的次要缺陷个数占缺陷总数的百分比20.Ratio of Percent Major to Minor Defects Captured Per Test Case Review
每个经评审的测试用例发现主要缺陷的百分比与次要缺陷的百分比之间的比例。21.Percent of Total Defects Captured Per Test Case Review Hour
每一个小时评审的测试用例发现的缺陷数占总缺陷数的百分比22.Percent of Major Defects Captured Per Test Case Review Hour
每一个小时评审的测试用例发现的主要缺陷数占总缺陷数的百分比23.Percent of Minor Defects Captured Per Test Case Review Hour
每一个小时评审的测试用例发现的次要缺陷数占总缺陷数的百分比24.Ratio of Percent Major to Minor Defects Captured Per Test Case Review Hour
每一个小时评审的测试用例发现的主要缺陷的百分比与次要缺陷的百分比之间的比例25.Percent of Total Defect Residual Per Test Case Review
每个经评审的测试用例未能发现的缺陷的百分比26.Percent of Major Defect Residual Per Test Case Review
每个经评审的测试用例未能发现的主要缺陷的百分比27.Percent of Minor Defect Residual Per Test Case Review
每个经评审的测试用例未能发现的次要缺陷的百分比28.Ratio of Percent Major to Minor Defect Residual Per Test Case Review
每个经评审的测试用例未能发现的主要缺陷的百分比与次要缺陷的百分比之间的比例29.Percent of Total Defect Residual Per Test Case Review Hour
每一个小时评审的测试用例未能发现的缺陷的百分比30.Percent of Major Defect Residual Per Test Case Review Hour
每一个小时评审的测试用例未能发现的主要缺陷的百分比31.Percent of Minor Defect Residual Per Test Case Review Hour
每一个小时评审的测试用例未能发现的次要缺陷的百分比32.Ratio of Percent Major to Minor Defect Residual Per Test Case Review Hour
每一个小时评审的测试用例未能发现的主要缺陷的百分比与次要缺陷的百分比之间的比例33.Number of Planned Test Case Reviews
计划要评审的测试用例的个数34.Number of Held Test Case Reviews
计划要评审但未评审的测试用例的个数35.Ratio of Planned to Held Test Case Reviews
计划要评审的测试用例个数与计划要评审但未评审的测试用例的个数之间的比例36.Number of Reviewed Test Cases
评审过的测试用例的个数37.Number of Unreviewed Test Cases
未评审的测试用例的个数38.Ratio of Reviewed to Unreviewed Test Cases
评审过的测试用例的个数与未评审的测试用例的个数之间的比例39.Number of Compliant Test Case Reviews
评审通过的测试用例的个数40.Number of Non-Compliant Test Case Reviews
评审不通过的测试用例的个数41.Ratio of Compliant to Non-Compliant Test Case Reviews
评审通过的测试用例的个数与评审未通过的测试用例的个数之间的比例42.Compliance of Test Case Reviews
通过的评审次数43.Non-Compliance of Test Case Reviews
不通过的评审次数44.Ratio of Compliance to Non-Compliance of Test Case Reviews
通过的评审次数与不通过的评审次数之间的比例