为什么要进行测试用例评审

测试用例是测试整个流程中非常重要的产出物

一个完整的测试流程是从需求到最后上线全过程端到端的跟踪，主要流程节点及输出件包括：

1.首先要了解需求，进行需求分析，明确需求粒度，可测性、优先级等，产出需求分析文档。

2.然后要对系统架构、测试环境、测试需求、工作量评估，测试人员安排等方面进行梳理，完成测试计划或测试方案的编写。

3.在测试方案梳理完毕后需要进行测试用例的细化，输出，一个优秀完整的测试用例需要将需求分析及测试方案中梳理的测试点完整覆盖并细化到可操作的程度，目标是可以依据用例不同测试人员可以达到同样的测试执行目的。

4.根据测试用例进行测试执行并且根据测试方案或计划中明确的测试策略决定测试执行的轮次，优先级等。

5.最后根据多轮测试执行的结果输出来输出测试报告。

这些流程每一个环节都不可或缺，并且有依赖关系，后者输出必须依赖于前者的高质量输出，如果有一环节比较薄弱或马虎敷衍，都不能称之为一个完整完善对项目质量负责的测试流程。

本文单独将测试用例评审拿出来讲，是由于测试用例本身是测试执行的最直接的前提，而不同经验的测试人员对待同样的测试方案细化测试用例时就会输出不同质量层次的测试用例。因此在测试用例输出后，评审环节至关重要。

测试用例评审的重要性

为什么要强调测试用例评审呢，主要从以下几个方面考虑：

1测试思维不系统（没有经过系统性培训或专项训练）--针对新人

2个体思维局限（某些思维定势导致测试点遗漏）--所有人

因此测试评审非常重要，目前我们的测试用例评审大部分是以项目维度在项目组内进行review，责任主体是开发，一般以邮件和会议的形式组织评审。这样也能补充一些测试点，但是没有一个完整的测试评审在线的流程约束，不是每个人都能进行前期的认真检视并能提出有效的意见。另外仅依赖开发的review，很容易只从软件设计实现的角度出发补充测试点，而不是从全局用户角度出发来补充，可能还是会造成测试遗漏。

因此测试用例评审的参与人、review形式、评审需要注意的事项和要素都非常重要。下面就讲下这几个维度，看下评审需要注意的要素有哪些。

测试用例评审应该注意哪些要素

刚才说了测试用例评审非常重要，而有效高质量的测试评审并不容易做，很容易流于形式，不能提出有效的意见或补充点。

那么一个有效高质量的测试评审的一些前提和要素有哪些呢：

1.       靠谱的评审参与人：包括你的用例对应模块的开发人员以及对这个模块设计比较熟悉的设计者，同时也要包括了解该用例模块以及具有丰富的用例设计经验的QA。

2.       评审形式：tc平台目前在做一个评审系统，实现后就可以在线发起review流程，知会评审者，记录评审意见以及汇总结果等，有效的防止会议或邮件的评审结论没有跟踪。具体的评审流程稍后再详述。

3.       评审者需要遵循的要素、方式：面-线-点方式评审，具体如何操作见下一节。

面-线-点方式评审细则

面的评审要素：

需求、接口覆盖情况，测试类型覆盖，是否符合规范，是否有漏填，划分粒度，规模。

依据：

1.规范类

2.方案和用例是否对应，方案中细化的点是否在用例都有体现。迭代所实现的需求/功能/逻辑是否全覆盖。

3.用例风格，粒度划分，规模（每千行代码30~40个case）。

线的评审要素：

按类型检视测试点是否有缺失

1.接口测试：

两方面 

配置、参数层面：参数遍历（入参+返回码）、默认配置、配置异常检查、配置命令、并发（是否构造了冲突）、超时、资源泄露

逻辑层面：各个主流程是否覆盖、场景覆盖、输入是否被正确的分类、不同状态情况是否被覆盖（状态图、状态路径、事件动作的遍历）

2.异常测试：

异常输入遍历、用户操作异常、多个用户行为、系统级异常、软硬件异常等

3.压力测试：

业务压力模型是否合理，时长是否足够，系统状态采集（已集成平台，可忽略）。

4.性能测试：

性能模型是否合理，数据采集方法是否准确，工具使用。

点的评审要素：

关注用例的具体的测试步骤，预期结果

1.测试数据：数量、内容是否合理，选用的值类型是否正确，边界值，等价类。

2.测试输入：方法和工具是否得当，分类是否划分准确。

3.测试状态：不同系统的状态下测试遍历。

4.测试输出：检查点是否明确，内容是否有遗漏。

举例：以NEFS的MDS模块的接口测试为例，使用面-线-点的方式来评审。

首先按面的维度来，首先关注测试方案或思路中挖掘的测试点有没有全部在用例中体现。

查看测试思路（xmind）与细化出来的测试用例对比如下：

可以看到测试思路中的测试点都在测试用例中无遗漏，而且测试用例除了细化测试思路的部分外，还有一部分新增的点（例如数据库依赖以及接口并发测试），这种是在后续对项目认识加深以后新增的补充点。

其他需要关注分类是否合理，用例标题是否符合规范等。

这个过程同时可以参照开发相应的模块设计文档，查看是否有功能或需求点被遗漏。总之面是针对于二级目录之上的评审，对细节不作要求。

按面的维度评审完毕后，再来以线的维度来评审，根据线的评审要素，重点关注各个测试类型中测试点是否有缺失。仍拿上面的用例的一部分：mds内管理员工具存储池接口举例，由于是接口测试，重点看配置、参数层面以及逻辑层面有没有覆盖全。

可以看到这个接口已经覆盖了逻辑和参数相关的内容，然后可以问几个问题，例如这个接口的入参有几个，返回值正常和异常的种类有哪些，用例是否都覆盖了入参的正常异常，返回值的正常异常等，可以有效地提出一些新增测试补充点。

关于点的评审，点的评审就更加细节了，主要关注用例描述的细节，例如具体的测试步骤，预期结果，并且关注等价类划分是否合理，选取值是否有代表等等细节。

例如添加存储池接口的参数异常的2个用例中需要关注这些非法参数的选取值是否合理，是否需要划分多个等价类等等，这些对测试执行都具有非常重要的实际意义。作为一个评审人需要在精力投入合理下尽量细致完善的提出这种针对性意见，才能称之为一个有效的测试用例评审过程。

当所有的评审人完成对测试用例评审 并给出相应意见后，是否就完成用例评审了呢？当然不是，后续这些意见的跟踪和修改以及确认更加重要，例如用例编写人不够重视这些意见，或者对这些意见某些内容存在不认同，需要有一些机制去记录和反馈，这就需要一个比较好的在线评审系统，值得高兴的是目前TC平台已经完成基础的用例评审的设计和开发工作，相信很快就会与大家见面了。

一个完整的测试用例在线评审流程

以之前我在HW的评审流程为例，描述一个完整的测试用例的评审参与人，提交方式，提交后的跟踪和处理全流程如下：

  

总结：

用例评审非常重要，涉及到各方各面的完善，包括靠谱的用例评审人，完善的在线用例评审系统，公认的评审者需要遵循的要素。并且最重要的就是一直坚持下去的恒心和毅力。这样我们的测试用例质量才能越来越好，目前我们还有很长的路要走。

本文来自网易实践者社区，经作者崔晓晴授权发布。