测试用例评审会议开得好，事后甩锅没烦恼！

我们经常会听到开发对测试抱怨说：这个问题怎么现在才测出来，这个问题怎么暴露到线上了，测试都是怎么测的？

为了消除误解，让开发了解到底测试都覆盖了哪些内容，双方更好地配合，保障线上版本质量，测试用例的评审就显得十分重要。

测试用例评审的参与人员是：开发、产品、测试人员。

• 产品人员参与，可以方便核对测试用例是否覆盖产品需求，在评审的过程中完善产品说明文档，完善产品的逻辑。

• 开发人员参与用例评审，可以从代码实现角度给出建议，防止漏测或过度测试，保证测试的全面性，减少无效测试，增加重点模块的测试。

• 测试人员参与用例评审，可以审查用例是否规范，对于交互模块的用例覆盖得是否齐全。

评审前的准备

预审时需要提供xmind思维导图文件，xmind思维导图需要包含全部用例的设计思路及测试功能点，并重点标注出有疑问的测试点。

在评审前一天提前发出给相关与会人，预留时间给研发和产品先过下用例的内容，留意会议侧重点。

评审中的要求

对于敏捷开发项目，会议时间一般建议控制在半小时以内，超过这个时间就需要中场休息了，因为人持续集中注意力的时间基本只有二十分钟。为了保障评审效果，需要采取一些有效策略。

测试用例评审使用xmind软件，这样评审时更容易直观地看到结构树和层级关系，方便参评人员一目了然，更快地搞懂设计者要表达的意思。

复杂的功能在开始前先概述下文档构成，然后按照文件顺序讲解。

切记不可一马平川读到底，应该重点抓用例设计时存疑的地方，然后三方确认，这个时候预审是标注的有疑惑的地方就派上用场了。

简言之，对功能点划分优先级，优先评审优先级高的用例，再针对疑问多的用例评审，最后对于功能简单的用例可简单带过。

时刻记住我们用例的评审目标，不能流于形式。对于评审过程中，一时半会没有结论的问题，可以记录下来，作为会后讨论跟进的重点。

功能举例如下：在商品详情页，进行中的拼团列表，点击“去拼团”会进入拼团详情页。

原始版的用例如下图：

评审内容如下：该用例考虑的点过于狭隘，基本等同于抄需求文档的。

实际上还应考虑一些瞬时场景和一些异常情况：比如点开页面后团购结束，点击页面时小程序账号还未登录等。

另外，因为测试用例评审和开发代码设计是同步进行的，所以在评审过程中，稍微复杂的没有把握的功能可以与开发确认实现方式。

比如，哪些数据是从接口获取的，哪些数据是从其他页面的接口请求带过来的，哪些是前端写死的，哪些页面有必要实时刷新，哪些页面无需已进入就刷新。

通过探讨，明确可能的bug重灾区，设计一些合理的处理方式，从根源上遏制bug的出现。

评审后的收尾

用例评审完成之后，需要及时整理会上的评审意见，形成会议纪要并发送邮件。

同时测试人员需要根据会议上各方建议进行测试用例的修改完善，再将整理补充后的用例同步给项目相关人员，视具体情况确定是否有必要进行二轮评审。

若无其他问题则将用例整理后即可定稿等待执行。该用例经过评审的集思广益之后，补充如下：

评审的流程

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

 ​​​​软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。