测试用例如何评审，看完这篇就会了 - 测试蔡坨坨

转载请注明出处❤️

作者：测试蔡坨坨

原文链接：caituotuo.top/90b47990.html

你好，我是测试蔡坨坨。

众所周知，对于测试同学来说，在软件研发流程中有两个重要的会议，一个是需求评审会议（关于需求评审可参考往期文章「需求评审，测试人员应该发挥怎样的价值？两分钟让你不再懵逼」），另一个是用例评审会议。

不知道大家把“用例评审”放在了什么样的“地位”。

在我看来，用例评审是测试流程中不可或缺的一环，用例评审很多测试人员不重视，但是往往不重视的环节其实做好了可以起到意想不到的效果。

所以，今天我们就来聊一聊测试用例评审。

什么是用例评审

当我们写完测试用例后，并不代表这份用例都是正确的，所有场景都已经覆盖到，所以需要多方人员进行查缺补漏。

简而言之，用例评审就是产品、开发、测试一起对写好的测试用例进行review的过程。

用例评审一定是要求产品（制定该需求的产品经理）、开发（实现该产品的前后端开发人员）、测试（负责该需求用例编写和执行的测试人员）都参与。

会议由测试人员主导，相应需求的测试同学依次上去讲解自己的测试用例。

用例评审会议是在开发提测之前，一般会提前一天通知相关人员，并预约好会议室，确定大家时间是否方便。

在用例评审之前需要确保测试用例编写基本完成，可以先把用例给测试小组的同事先评审一遍，看看有没有什么问题。

提前五分钟到达会议室做准备，把测试用例、需求页面、原型图、开发设计页面、UI图等都打开。

用例较多时，提前做好标注，哪些是优先级比较高的，哪些是前端用例，哪些是后端用例，哪些是有疑问的点，方便侧重点评审，省时省力，而不是每条用例都需要评审。

还可以将测试用例给到相关人员提前查阅。

对于产品经理：

• 检查测试人员是否准确理解需求，确保每个需求点都覆盖到。
• 通过评审正常和异常的测试用例，来反思当时设计需求时未考虑的情况，也是自我回溯的一个过程。

对于开发人员：

• 检查自己的程序代码是否还有很多情况未考虑完善，对自己的代码也是一个自我回溯检查的过程，间接实现了测试左移。
• 对于用例中无法实现的逻辑及时沟通，三方达成高度一致。

对于测试人员：

测试人员作为用例评审会议的主角，作用就不必多说了。

用例评审会议后，需要对评审中的问题进行跟进和完善。

• 需要产品经理补充和修改的点需要让其在需求文档和原型图上进行记录
• 对遗漏的测试点进行补充，对有误的测试点进行修正，并对用例进行管理

其他注意事项

• 会议时长最好控制在1个小时之内，如果内容较多，可分多次评审
• 结合可视化界面，针对页面测试点可提前打开原型图、UI图、设计图等
• 陈述时要表达清晰，有主题和层次，比如上来可以先介绍一下你这个需求是干嘛的，然后再分部分细讲
• 对于有歧义的问题，需要与产品和开发同学确认清楚
• 评审过程中，参会人员可能会有视觉和听觉疲劳，主讲人要抓住重点和重要人员
• 对于评审过程中的问题，及时做好标记