测试用例评审时，让AI扮演"杠精"角色

一场测试用例评审会上，原作者列出了五条用例，大家看了一圈，纷纷点头"挺全面的"，会议十分钟就结束了。但如果这时候有个人站起来，把这五条用例挨个怼一遍："如果核销和退款同时发生呢？"、"如果两个标签页同时点呢？"——评审会的画风立刻就变了。很多团队的评审会上恰恰缺这样一个角色，不是没人想得到这些问题，而是没人愿意当这个让会议变长、让原作者难看的"杠精"。

一、为什么评审会上，人很难扮演好"杠精"

挑刺这件事天然带着社交成本：显得针对个人、拖慢进度、显得在"找茬"，大多数人本能的选择是"差不多就行了"，尤其是原作者就坐在对面的时候。还有一层更隐蔽的问题：设计用例的人和评审的人，往往背景假设相似，容易"英雄所见略同"地一起漏掉同一类风险——这跟系列前面讨论过的"AI生成用例同质化"是同一种现象，只是这次发生在人身上而不是模型身上。评审会开多了，疲劳也会让人陷入"扫一眼就过"的模式，越往后审越松。

二、让AI来扮演这个角色：把"杠精"做成一个可复用的评审动作

这里的思路不是让AI生成新用例，而是单独设计一个"提问角色"的Prompt：输入是需求文档和现有用例清单，输出是一连串"如果……会怎样"式的质疑，只问不答，逼着评审会上的人去正面回应。这种用法本质上是把对抗性思维这件事工具化、标准化了，有点像之前提到的变异测试思路——故意找漏洞，而不是验证已经设计好的用例对不对。AI不需要顾及面子，不会疲劳，也不存在"提问题等于针对原作者"的心理负担，这恰恰是它适合干这件事的原因。

三、一次"优惠券核销"接口的评审

假设原作者针对一个满减优惠券核销接口，提交了这五条用例：使用满100减20的优惠券，验证扣减金额正确；优惠券已过期，验证核销失败并提示；优惠券已被使用过，验证不能重复核销；订单金额不满足门槛，验证核销失败；不传优惠券code，验证正常下单不受影响。单看这五条，确实"挺全面"。

把需求文档和这份用例清单丢给扮演杠精角色的AI，它提出的二十个问题大致是这样：金额边界上，订单金额恰好等于门槛、四舍五入后刚好够门槛、优惠券面额大于应付金额导致支付变负数、优惠券核销后订单又发生部分退款这四种情况分别会怎样；时序和状态上，订单创建成功但核销接口超时、用户取消订单后优惠券能否被重新使用、两个标签页同时点击核销、商家后台下线优惠券和用户核销同时发生，这四种并发或时序冲突分别会怎样；权限角色上，新用户专享券被老用户通过分享链接拿到、账号在核销过程中被风控冻结，这两种身份相关的情况会怎样；异常边界上，优惠券code传超长字符串或特殊字符、同一用户同一张券发起上百次并发请求最终核销成功几次、下游计算服务挂掉时接口该失败还是放行，这三种异常输入或依赖故障会怎样；业务规则上，购物车里多个子订单分别满足门槛能否绕过"每单限用一张"的限制、指定品类不可用的券遇到混合品类购物车该怎么分摊、有效期按自然日计算遇到跨时区午夜该用哪个时区，这三种规则交叉的情况会怎样；跨系统一致性上，优惠券核销成功但订单创建失败谁来回滚、支付扣款失败但优惠券已被消耗算不算缺陷，这两种系统间状态不一致会怎样；最后是可追溯性上，用户投诉"明明可用却显示已使用"时日志能不能复现判断过程、运营临时修改优惠券规则时已加购未结算的订单该按新规则还是老规则执行。

这二十个问题里，至少有五六个直接命中了原始用例完全没碰过的场景——并发核销、跨系统状态不一致、规则变更的时间点判断，恰恰是这类问题最容易在生产环境里引发真实事故。

挑其中一个问题往下追："用户在两个标签页同时点击使用优惠券，会不会被核销两次？"评审会上原作者第一反应是"应该不会吧，前端按钮点了会变灰"，但追问一句"如果是两个不同设备同时操作呢，比如手机和网页"，原作者就答不上来了。往代码里一查，核销接口确实没有加任何幂等性保护，扣减优惠券库存的那一步是先查询再更新，理论上两个并发请求完全可能都查到"未使用"的状态，然后各自完成一次核销——这条问题最后被列为高优先级缺陷，补了一个基于唯一约束的幂等校验，还顺带补了一条专门测并发场景的用例。如果不是这二十个问题里恰好有这一条，这个缺陷大概率要等到真实流量把它暴露出来才会被发现。

四、用得好和用不好的差别

这二十个问题不是同等重要，有些在当前业务场景下可能根本不成立——比如这个产品压根没有高并发场景，如果不加筛选地把每一条都当成必须解决的缺陷去推进，反而会拖慢进度，制造一种为了完成任务硬凑数量的形式主义。AI提出问题的质量，也高度依赖输入的需求文档颗粒度，需求写得粗糙，AI提的问题也容易停留在表面，这跟前面讨论过的"垃圾进、垃圾出"是同一个道理。更关键的是，这个角色解决的是"有没有想到"的问题，不解决"想到之后该投入多少资源去测"的问题——这部分权衡判断，依然得靠人，AI提问题不会替你排优先级，硬塞给它去打分反而容易出现"为了显得客观"而给出一堆中庸分数的情况。

五、落地建议

把这个角色做成评审会前的固定环节，提前跑一遍，把问题清单发给参会的人，会议时间用来讨论而不是临时发现问题。对生成的问题做个简单分级，区分必须澄清、值得讨论、当前场景不适用，避免一刀切地全盘照单全收。把团队历史上真实发生过的缺陷模式喂给AI做上下文，质疑会更贴近本团队的真实风险，而不是泛泛而谈的通用清单。也可以把这套方法当成可迭代的资产，每次评审会后，记录下哪些问题确实是AI提出、人验证出来的真漏洞，反过来优化下一次的Prompt。

结语

评审会上最有价值的声音，往往是那个让大家不舒服的声音。AI不在乎面子、不会疲劳，提出问题对它来说没有任何心理负担，这正是它适合扮演杠精角色的原因。但提出问题只是第一步，真正决定测试质量的，还是评审会上的人怎么去筛选、权衡、回答这些问题。