转载自科技中通公众号
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
测试用例评审作为测试用例设计过程中必要步骤，可以指数级提升测试用例的质量。为什么这么说呢？下面我们就聊一聊测试用例评审活动。
我们借用5W1H的模型，让各位看官能够更清晰了解测试用例评审活动。
WHY
测试用例评审的目的
首先谈谈Why，也就是测试用例评审的目的，简单的总结一下：
1.提高测试用例覆盖率：在评审过程中，项目组中各个角色看待问题的角度不完全一致，所以可以根据各个角色提出的意见和建议，再次考虑测试方法扩充测试用例的全面性，保证测试 用例的覆盖率，从而保证产品质量。
2.保证测试用例的有效性：在评审过程中向项目组各个角色阐述测试人员对需求的理解，保证测试用例是得到各个角色认可的有效的用例，减少在测试过程中引起的冲突和争议。
3.提前发现问题：在评审过程中,测试人员以及项目组其他成员会对需求进行再一次的确认，可以提前发现需求问题，需求实现问题等，避免在转入测试阶段后再发现，减低修改成本。
WHO
测试用例评审相关人员
接下来是Who，测试用例评审相关的人员。既然是测试活动中的一环，那测试用例评审的主导人（发起人）肯定是测试人员；其他的参与人员：产品经理，对应需求开发人员，对应需求的其他测试人员，项目运营人员，需求的业务方，需求关联的项目组其他成员都是必不可少的。至于为什么加上对应需求？是为了精确人员，减少测试用例评审带来的成本消耗。
HOW
测试用例评审的形式
我们继续看How，测试用例评审的形式。一般测试用例会采用三种形式：
a.召开评审会议，与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。
b. 通过邮件与相关人员沟通确认。
c. 通过IM等交流工具与相关人员进行确认。
选取方式的时候一般遵循以下原则：
a. 正常迭代用例进行会议评审。
b. 紧急需求可选择使用非会议方式评审。
c. 少量优化类需求可选择非会议方式评审。
d. 方式只是手段，得到项目各个角色对于用例的反馈才是目的。
e. 无论采取哪种评审方式，在用例评审前1-2天需要把设计好的测试用例给到项目各个相关角色。
WHEN
测试用例评审的时间节点
用例评审应该在什么时间点进行（When）？两个时间节点：在用例初步设计完成后进行评审；在用例评审完成并更新后进行确认。
WHAT
测试用例评审的内容
用例评审评审的内容(What）：
a.用例是否覆盖需求需要包含的测试点。
b.用例优先级安排是否合理。
c.用例是否具有很好的可执行性。
d.用例是否包含了必要的异常场景（测试用例应当包含百分之二十的正向用例和百分之八十的异常用例）。
e.用例是否从用户角度设计场景和使用流程
以上就是中通科技测试团队用例评审活动的大体步骤和内容。
但是理论和实践之间总是存在着巨大的鸿沟：很多产品线，总是有或大或小的缺陷遗漏到了线上。线上故障分析的时候，有部分比例的线上故障能追根溯源到用例评审环节。用例评审环节本可以发现这些问题的，但总是有各种原因，放过了。 中通科技测试团队在这方面做了一些探索：我们成立了一个跨团队用例评审专家团。
提前拿到各个团队的用例评审时间。
交叉安排不同的测试专家去旁听用例评审活动。
测试专家提前拿到需要评审的用例和需求。
现场专家不发表观点，只记录整个过程。
过程记录事前设计好了模板。
模板内容非常全面 有参与人员，开发产品的投入度，提问的次数等等。
阶段性分析反馈数据，找到共性问题。
通过这种实际参与的方式去发现用例评审存在的痛点，总结下来大致存在以下几个痛点。
用例评审效率低
评审是在做需求讨论，而不是在进行用例评审
单次会议时长太长无法进行有效的评审和意见收集
用例评审参与度低
参与人员不按时参加
与会成员不关注用例情况
多数开发都带着电脑来参加，一直在低头看自己电脑
用例内容不规范
用例照搬PRD
场景类用例缺失
反向异常，并发，安全，兼容性用例缺失
讲解过程没有重点，按顺序念
GUIDE
踩坑改进指南
针对以上存在的痛点，中通科技测试团队总结经验教训，整理出了一份踩坑改进指南，具体如下：
用例评审会议节奏控制：
评审需要控制时间,尽量控制在0.5小时之内，不要超过1小时，提升评审效率可以参以下几点：
对于特别重要的需求，并且需求很多，可以分多次评审，一次一个专题。
根据需求的内容和大小采取多种用例评审方式结合的方式进行。
用例评审前，存在需求不明确的，会议之前多沟通，测试人员多找产品确认，并要求产品及时给与回复并更新好文档。
评审时技术实现跟需求有争议的，2分钟之内没有结论的，及时中断，记录下来，会议后再进行讨论并更新文档。
评审前，测试人员将用例给到项目组各个成员。冒烟用例、疑问用例，高亮不同色系区别出来，要求开发，产品评审前阅读确认测试用例，带着疑问参与用例评审。
只详细评审冒烟用例+有疑问的用例，这个疑问包括但不限于：测试人员在需求文档之外扩展的场景，测试人员怀疑开发人员容易遗忘的场景，测试人员认为容易存在问题的用例。
测试人员互相帮忙，一个主讲测试用例，另一个记录改动点。提高评审效率。
用例评审开始前，先简单一两句话阐述下这个需求的重点。
评审时，测试人员讲场景时，主要讲用例的检查点是什么，不需要描述步骤。
提高参会人员的参与度：
参加用例评审会议时，除了主评审测试人员，产品和开发不要带电脑。
测试人员在过检查点时，主动与产品及开发互动，经常提问，经常确认。
对于参与度一直不高的团队，评审时可以邀请开发负责人或者业务线负责人。
评审后持续跟进：
第一时间整理测试用例，把修正的内容重新整理补全。
会上未确定的内容，会后继续跟进，直到确定结果。
没有任何有疑问的地方了，再做个简单的用例评审会议总结（如修正了哪些功能点，补全了哪些？哪些模块功能有变动？哪些功能推迟到下一期做？等）。
更新后的用例及时同步到项目组各个角色。
测试用例改进：
欢迎关注科技中通，我们后续将进行测试用例改进系列分享。
聊到这儿，测试用例评审相关的事情我们基本上就结束啦，你可能会疑惑，5W1H中剩下的Where哪里去了？其实Where就是大家的所在的工作地啦。
