测试用例怎样评审，看完这篇就会了

众所周知，对于测试同砚来说，在软件研发流程中有两个紧张的会议，一个是需求评审会议，另一个是用例评审会议。
不知道各人把“用例评审”放在了什么样的“职位”。
在我看来，用例评审是测试流程中不可或缺的一环，用例评审很多测试人员不重视，但是往往不重视的环节实在做好了可以起到意想不到的结果。
所以，今天我们就来聊一聊测试用例评审。
什么是用例评审

当我们写完测试用例后，并不代表这份用例都是精确的，所有场景都已经覆盖到，所以需要多方人员进行查缺补漏。
简而言之，用例评审就是产品、开辟、测试一起对写好的测试用例进行review的过程。
参会人员

用例评审一定是要求产品（制定该需求的产品司理）、开辟（实现该产品的前后端开辟人员）、测试（负责该需求用例编写和执行的测试人员）都参与。
会议由测试人员主导，相应需求的测试同砚依次上去讲解本身的测试用例。
何时进行

用例评审会议是在开辟提测之前，一样平常会提前一天通知相关人员，并预约好会议室，确定各人时间是否方便。
会前准备

在用例评审之前需要确保测试用例编写根本完成，可以先把用例给测试小组的同事先评审一遍，看看有没有什么问题。
提前五分钟到达会议室做准备，把测试用例、需求页面、原型图、开辟设计页面、UI图等都打开。
用例较多时，提前做好标注，哪些是优先级比较高的，哪些是前端用例，哪些是后端用例，哪些是有疑问的点，方便偏重点评审，省时省力，而不是每条用例都需要评审。
还可以将测试用例给到相关人员提前查阅。
作用

对于产品司理：

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

对于开辟人员：

• 查抄本身的步伐代码是否另有很多情况未考虑完善，对本身的代码也是一个自我回溯查抄的过程，间接实现了测试左移。
  
• 对于用例中无法实现的逻辑实时沟通，三方达成高度同等。
  

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

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

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

其他注意事项

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

以上，完。
实事求是，瞻仰星空，和坨坨一起学习软件测试，升职加薪！
最后： 假如你平时有很多问题想要解决，你的测试职业规划也需要一点光亮，你也想跟着各人一起分享探究，我给你保举一个 「软件测试学习交流群：746506216」 你缺的知识这里有，你少的技能这里有，你要的大牛也在这里……

---

资源分享【这份资料必须领取~】

下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋侪们假如需要可以自行免费领取 【包管100%免费】

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。