https://mp.weixin.qq.com/s?__biz=MzkwNTI2NjAxMA==&mid=2247484120&idx=1&sn=d3a44ff73c7c68112a19d6c2ed6eb8a1&chksm=c0fb14edf78c9dfbda6f6c89539c1aa5131d1bbbe041db0a0da91aaab6f2d5a63eeac894cb25&scene=178&cur_album_id=1979310371207184387#rd
测试用例评审是测试活动中的一个重要环节，做好测试用例评审，可以有效的发现用例中的不足，并更好的补充，以免测试场景遗漏或者出现业务逻辑理解不一致。那么，如何做好测试用例评审呢？
01
做好测试用例分级，并不是所有的测试用例都需要上评审会，或者说有些用例是需要自己内部消化的。一般情况下，我会把测试用例分为三个层级：
页面功能用例:
主要验证的是页面功能，比如常见的数据增、删、改、查，页面显示、按键功能、布局以及简单的数据流向验证。这类用例个人建议不用上用例评审，如果小组内有较多的新人，这类的用例应该由测试负责人自行把关就好。
业务流程用例：
基于用户行为，通过场景化的案例来验证系统内部各子模块的关联，确保数据及状态的流转有序、正常，对于异常数据能够正常处理或者给于明确的提示。这类用例是评审的重点，也是需求的核心内容，需要大家重点来评审的。
跨系统接口用例：
随着业务的复杂性逐步增加，我们可能需要更多的和别的系统打交道，在跨系统的接口功能验证中，我们需要明确预期检查点是什么；需要考虑的异常用例分为两类，1类是上游异常如何承接（状态是否回传、上游数据修改是否会影响到本系统等）2是自己系统异常对上下游系统的影响。
02
如何更好的开展测试用例评审呢？笔者的经验有以下几点：
聚焦：每次用例评审不超过 1 小时，只评审核心内容及测试设计思路，不对具体的每条用例展开评审，实际上这个意义确实不大，只要测试思路没什么问题，大体上也不会有偏差；
事先准备：事先和研发及产品沟通，让他们提前阅读文档。在评审的时候，不需要拉上所有的人，只需要相关人员即可
持续反馈：测试用例并不是一成不变的，哪怕是评审完。不能让测试用例成为一个借口（很多测试人员经常对其它人说为会不在评审的时候提出来，这种做法很不推荐，别人只是帮你 check，而不是让他来替你思考）
给出行动项：需要修改的内容，及时修改并反馈，让大家有参与感，同时表示感谢。
要注意测试用例的颗粒度，在评审时，不需要逐条过，评审测试思路即可。本质上测试用例也是一个测试思维可视化的过程，除非你们的测试团队特别年轻（例如第一类的测试用例，不太适合进行大范围的评审）
03
不要用例评审当做一个负担，做好事前事中的准备，利用好这个机会，再一次方对齐需求理解的机会。可以保证大家对同一个需求的理解是一致的，避免更多可能出现的返工浪费。