开发觉得测试用例评审没什么作用或不理解用例评审的意义要如何破?
那应该评审本身也有一些问题吧，测试自己有收获吗，开发测试产品三方都有比较有价值的发言吗
交流一下为什么觉得没用，是不是用例的设计方式和评审的点，评审的时间太长了，导致效果不好。这些都是可以改进和提高效率的。
如果单纯是不配合，觉得没用，要么找他老板，要么找你老板呗
如果你的用例已经很完善，每次评审开发打酱油，并且也没有漏测的。这种可以故意写漏几个增强下他们的参与感，如果他们没看出来，那就是态度问题咯。
每次埋个漏洞，大家来找茬，没找到买奶茶。
如果开发确实水平不够（不熟业务或者不相干的人），就别勉强他们来评审了。来评审的，共同对用例质量负责。
这种跟人的主观能动性和经验相关的流程，和团队氛围、公司制度要求、考核、对质量的态度都有关系，想要立竿见影要从多方面下手。
可以自己多准备些问题，段子撒的，毕竟用例评审是由你来主持，整体的节奏和氛围你需要去下一定的功夫
围绕用例评审目的、成本、收益评估下，开发认为没价值我理解为成本>收益，接下来拉一下缺陷数据，如果在评审环节就阻止缺陷的发生，让开发知道收益如何。
开发不想听的用例评审：点这个按钮，输入这个东西，......（🥱，好无聊）
开发想听的用例评审：这个场景下。。。这个逻辑下。。。（卧槽，这个逻辑好像没考虑到）
评审时注意引导讨论，简单 case 快速过，涉及到场景逻辑的要一条条认真对，不确认的 case 要提前标注与 RD、PM 讨论
测试经验比较少的经常写一堆前端 case，不考虑前端操作带来的后端逻辑，写了几百条看不到重点，异常逻辑分支重后端，前端操作几条就够了
我经历过的 case 评审都是在与开发对场景逻辑中度过，要么测试帮开发补充逻辑场景，要么开发帮测试补充逻辑场景，这样才是测试用例评审的意义，测试用例不是宣讲，是对齐。
lcw
回复
点个赞。很多时候用例评审的场景是最细最全面的，应该起到的作用是能让产品、开发等项目其他角色更完整地了解整个项目的各个场景，起到查漏补缺的作用。
见过太多产品需求没写清晰，开发自己直接脑补不问产品，最后测试发现有问题得返工的场景了。用例评审做得好，这类场景就可以提前被发现和澄清逻辑，这本身就是一种价值。
开发自己写测试用例
测试用例评审，不能让开发人员参与。
