用例评审是软件研发流程中的关键步骤，涉及产品、开发和测试人员共同参与。它旨在确保测试用例的准确性及需求覆盖，同时促进各方对需求的理解。会议通常在提测前进行，准备包括用例预审、文档准备和时间协调。用例评审有助于产品经理检查需求理解，开发人员审视代码完备性，而测试人员则能完善测试策略。会后需跟进问题并更新用例。有效控制会议时间和保持清晰沟通能提高评审效率。
目录：导读
众所周知，对于测试同学来说，在软件研发流程中有两个重要的会议，一个是需求评审会议，另一个是用例评审会议。
不知道大家把“用例评审”放在了什么样的“地位”。
在我看来，用例评审是测试流程中不可或缺的一环，用例评审很多测试人员不重视，但是往往不重视的环节其实做好了可以起到意想不到的效果。
所以，今天我们就来聊一聊测试用例评审。
什么是用例评审
当我们写完测试用例后，并不代表这份用例都是正确的，所有场景都已经覆盖到，所以需要多方人员进行查缺补漏。
简而言之，用例评审就是产品、开发、测试一起对写好的测试用例进行review的过程。
参会人员
用例评审一定是要求产品（制定该需求的产品经理）、开发（实现该产品的前后端开发人员）、测试（负责该需求用例编写和执行的测试人员）都参与。
会议由测试人员主导，相应需求的测试同学依次上去讲解自己的测试用例。
何时进行
用例评审会议是在开发提测之前，一般会提前一天通知相关人员，并预约好会议室，确定大家时间是否方便。
会前准备
在用例评审之前需要确保测试用例编写基本完成，可以先把用例给测试小组的同事先评审一遍，看看有没有什么问题。
提前五分钟到达会议室做准备，把测试用例、需求页面、原型图、开发设计页面、UI图等都打开。
用例较多时，提前做好标注，哪些是优先级比较高的，哪些是前端用例，哪些是后端用例，哪些是有疑问的点，方便侧重点评审，省时省力，而不是每条用例都需要评审。
还可以将测试用例给到相关人员提前查阅。
作用
对于产品经理：
- 检查测试人员是否准确理解需求，确保每个需求点都覆盖到。
- 通过评审正常和异常的测试用例，来反思当时设计需求时未考虑的情况，也是自我回溯的一个过程。
对于开发人员：
- 检查自己的程序代码是否还有很多情况未考虑完善，对自己的代码也是一个自我回溯检查的过程，间接实现了测试左移。
- 对于用例中无法实现的逻辑及时沟通，三方达成高度一致。
对于测试人员：
测试人员作为用例评审会议的主角，作用就不必多说了。
会后
用例评审会议后，需要对评审中的问题进行跟进和完善。
- 需要产品经理补充和修改的点需要让其在需求文档和原型图上进行记录
- 对遗漏的测试点进行补充，对有误的测试点进行修正，并对用例进行管理
其他注意事项
- 会议时长最好控制在1个小时之内，如果内容较多，可分多次评审
- 结合可视化界面，针对页面测试点可提前打开原型图、UI图、设计图等
- 陈述时要表达清晰，有主题和层次，比如上来可以先介绍一下你这个需求是干嘛的，然后再分部分细讲
- 对于有歧义的问题，需要与产品和开发同学确认清楚
- 评审过程中，参会人员可能会有视觉和听觉疲劳，主讲人要抓住重点和重要人员
- 对于评审过程中的问题，及时做好标记
写在最后
如果你觉得文章还不错，请大家 点赞、分享、留言 下，因为这将是我持续输出更多优质文章的最强动力！
领取资料【留言：软件测试资料】
看到这篇文章的人有觉得我的理解有误的地方，也欢迎评论和探讨～
扫一扫
5508
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
