大家每次写的测试用例都会评审吗？我们每次写的都会评审，但是感觉评审也没什么用，开发，产品，测试一起，都是各玩各的。
可以将测试用例评审理解为功能提测前，开发、测试，产品三方人员最后一次对版本功能进行信息同步，防止三方对版本功能理解错误，产生迭代风险。
评审内容可以挑主流程、重点逻辑进行评审，不用事无巨细评审每一条用例。
先自查评审是不是复读机大会
我的评审，研发参与感都挺强，我会一直和研发互动，过重点抛问题讲测试思路，一些很常规 case 其实不需要研发 review
可以收集一下反馈, 为啥产品研发没怎么投入
是听不懂看不明白, 还是用例太乱逻辑理不清, 还是又臭又长没重点
评审最好是左移一点，帮忙完善产品需求和开发没注意到的细节，这样大家讨论会比较多也会考虑得更细节。后面用例完成以后的正式评审其实主要是看测试点覆盖度了，不可能每条用例挨着过那么细的，可以提前发出来让大家先 review，带着问题去评审会更有效
我们现在是思维导图列出需求的重点场景和疑问点进行评。写在 EXCEL 里面的用例不评，看起来都是字找不到重点在哪里
同思维导图评审测试点，用例的编写规范就 ai 去评审了
- 有个完整的时间对齐三方对项目功能及细节的理解。不一致的会上就解决了。
- 能够补充一些没考虑到的场景 ，经验丰富的研发会给出一些模块的测试重点（也可能开发时候没咋细琢磨，准备靠测试了）。
- 出问题甩锅做准备。都没想到的测试点三方一起负责。
看似和复读机一样的评审，其实有时候责任不全部到自己身上，起码责任可以规避一些，三方共同通过的结论
1、用例评审，大家只是评审你能提出来的用例测试点对不对？或者疑问点解答，大部分情况下他们没法告知你遗漏那些场景
2、评审要有重点，主流程和疑问点需要重点强调和提问（可能大家都没认真听，你提问他们才会主动参与）
3、会议纪要：评审过程要记录会上决定的内容和待确定的点，便于后续优化用例和扯皮证据