用例评审就是用来验证测试用例的正确性，有效性和测试覆盖等操作，这可以有效的保障测试实施，并且保障测试用例的改善等工作。说的简单一点，用例评审其实就是测试用例查缺补漏的一个过程，保证用例的有效性和覆盖性。
用例评审就是用来验证测试用例的正确性，有效性和测试覆盖等操作，这可以有效的保障测试实施，并且保障测试用例的改善等工作。说的简单一点，用例评审其实就是测试用例查缺补漏的一个过程，保证用例的有效性和覆盖性。注意，当需求或者软件发生改变时，测试用例也要进行相应的修改和更新！
例评审制度的评审分为内部评审和外部评审。
内部评审就是测试组内成员进行评审，该评审通过之后，会进行外部评审，也就是项目组的评审，这一评审过程的参与人员有项目经理，产品人员，开发人员和测试人员。
那么评审的内容和检查项有哪些呢？
首先是评审的内容：
1）用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖
2）优先级安排是否合理
3）是否覆盖测试需求上的所有功能点
4）用例是否具有很好的可执行性。这里主要看用例的前提条件，执行步骤，输入数据和期待结果是够清晰，正确，还要看预期结果是否有很好的验证方法。
5）是否已经删除了冗余的用例
6）是否包含充分的负面测试用例。（可以采用二八定律）
7）是否从用户层面来设计用户使用场景和使用流程的测试用例。
8）是否简介，复用性强。
然后是评审的检查项：
1）测试用例是否按照公司定义的模板进行编写的
2）测试用例本身的描述是否清晰，是否存在二义性
3）测试用例内容是否正确，是否与需求目标一致
4）测试用例的期望结果是否清晰，少数
5）操作步骤是否与描述相一致
6）测试用例是否覆盖了所有需求
7）测试用例是否存在冗余
8）测试用例是否具有可执行性
9）是否从用户层面来设计用户使用场景和业务流程的测试用例
10）场景测试用例是否覆盖最复杂的业务流程
11）用例设计是否包含了正面，反面的用例
12）对于由系统自动生成的输出项是否注明了生成规则
13）测试用例是否包含对中间和后台数据的检查
14）测试用例是否有正确的名称和编号
15）测试用例应标注有执行的优先级
16）测试用例包含相关的配置信息：测试环境、数据、前置测试用例、用户权限等
17）每个测试用例步骤应<=15 Step。
测试用例评审完会有些缺陷，需要反馈用例评审活动中收集到的用例缺陷信息，修改后需要再次评审。一般执行首轮测试用例后会陆续增加再增加一些遗漏的测试用例。在此基础上进行用例更新，直到通过评审。其实这也就是测试用例的变更。
延伸阅读：
测试用例如何评审
1、完全评审
完全评审是指对整个项目中的所有测试用例进行评审。这种评审方式的优点是可以对所有的用例都进行评审，进而完善测试用例质量;但同样缺点也很明显，完全评审需要更多的时间和精力，么在工作中可能很难有充裕的时间进行完全评审。这种评审方式适用于新的项目，对于一个新的项目来说，为了保证软件质量，必须对所有的测试用例进行充分的评审。
2、有选择性的评审
有选择性的评审，即不对所有的测试用例进行评审，只对部分测试用例进行评审。该方法的优点是使用最少的时间对最重要功能的测试用例进行评审;缺点是未评审的测试用例无法完全保证质量。该方法更适用于维护产品，假设当前的版本是升级的版本，只修改了部分功能，那么评审测试用例的时候可以将重点转向这些新添加的用例，以前评审过的测试用例则可以不用花费过多的时间进行评审。
3、指标评审法
指标评审法是指研发流程中规定每个项目测试用例的评审覆盖率需要达到多少(如60%等)。指标评审法使用较少，因为指标评审法很容易导致为了达到指标而评审，并不一定能真正提高测试用例质量，所以经常将指标评审法与有选择的评审合并使用。
文章标题：什么是用例评审制度，发布者：小编，转载请注明出处：https://worktile.com/kb/p/33477
微信扫一扫 
支付宝扫一扫 
