测试正在失去“标准答案”，但得到了一条证据链

本文来源： 慢炖时光机（公众号：慢炖时光机）
原文链接： https://mp.weixin.qq.com/s/zUIpy-j3dztSXikLMdql4A
发布时间： 2026-09-28 08:22

作者： 慢炖时光机　　发布时间： 2026-09-28 08:22

QUOTE

AI 就算碰巧说中了答案，一句证据都不引用， 也可能只是蒙的 。

前几天我在整理测试用例的时候，盯着「预期结果」那一栏发了会儿呆。

这一栏大概是整个测试用例里最让人安心的地方了。输入什么，输出什么，提前写清楚。执行完一比， 红了就是失败，绿了就是通过 。简单，踏实，二十年没变过。

然后我就想到了一个问题。如果测试对象是一个 AI 缺陷定位助手 ，这一栏该怎么填？

先别急着往下看，可以先想十秒。

我拿一个真实场景举例：线上出了这么个问题，用户改了联系人名称，页面提示成功，数据库里最终也存了新名称。但刷新页面的时候， 偶尔又会显示旧名称 。得等缓存过期或再次失效，页面才恢复正常。

把日志、调用链和数据库记录一股脑交给 AI，它可能给出好几个 完全不同的分析 。Redis 删除失败、数据库主从延迟、浏览器缓存没刷新，或者并发查询把旧数据重新写回了缓存。

麻烦就麻烦在这儿。

这些答案没法跟一段「标准根因」逐字比对。AI 即使第一步没猜中，只要它 分得清事实和假设 ，能设计出有效的验证动作，就可能帮排查省下大量时间。反过来，它就算碰巧说中了缓存问题， 一句证据都不引用 ，那也可能只是蒙的。

上一篇《我把 AI 软件测试分成了四代》里聊过，测试能力的重心正在从生成内容、执行任务，走向 建立可信证据 。这篇我想再往下挖一层，就挖一个问题。

当正确的分析路径不止一条，我们到底凭什么判定 AI 做对了？

本文看点

01为什么「标准答案」会失效

02五条判断底线怎么定

03十个缺陷回放怎么落地

01

THE ORACLE

真正消失的，不是正确与错误的边界

先把这个案例的真实原因还原出来。

系统用的是 Cache-Aside 模式。一次修改请求，先删 Redis 缓存，再提交数据库事务。问题恰好卡在 两步之间的缝隙里 。请求 A 删完缓存，事务还没提交；这时候并发的请求 B 发现缓存未命中，转头从数据库读到了旧名称，还顺手把它写回了 Redis；等请求 A 把新名称提交上去，缓存却没人再清一次。

于是数据库里已经是新值， 缓存里躺着的还是旧值 。

— 1）请求 A 删除缓存，但数据库事务尚未提交，2）并发请求 B 缓存未命中，从数据库读到旧值，3）请求 B 把旧值重新写回缓存，4）请求 A 提交新值，但缓存仍保留旧值。橙色代表旧值，蓝色代表新值。

说实话这条因果链一点都不含糊。缓存操作和事务提交的时间顺序，查询读的数据来自哪，旧值什么时候重新进的 Redis，全都可以 用证据钉死 。

真正不唯一的，是走到结论的那条路。有人会先怀疑读写分离，有人会先绕过缓存直接比对，也有人从 Redis Key 的写入轨迹开始追。条条路都可能通，差别在于能不能一边走一边 排除错误假设 ，最后攒出一条 经得起复查的证据链 。

「测试不再总能依赖一段预先写好的完整输出，但仍然需要明确、可追溯的判断标准。」

顺带说一句，这真不是 AI 才带来的新麻烦。软件测试研究里早就有个专门的名字，叫 Test Oracle 问题 ，说人话就是「怎么判断一次执行的结果对不对」。AI 只是把分析路径和输出形式搞得更开放了，也把过去靠资深工程师拍板的判定工作，硬推到了自动化面前。

02

BASELINES

不用写出唯一答案，但要钉住判断底线

那落到实操上怎么办？

如果让我评价 AI 对这个缺陷的分析，我不会先给一段满分答案让它模仿。我会先定 五条判断底线 ，一条一条核对（个人观点，不喜勿喷）。

按这套标准去评，可能会发现答案 至少可分成三类 。

第一类直接断定是 Redis 删除失败。听着挺接近问题，但它既没证明 删除动作到底有没有发生 ，也没解释旧值为什么又冒出来了。

第二类更有意思。它把主从延迟、浏览器缓存、事务回滚、Key 错误等十种可能全列出来了，看着覆盖特别全， 实际是把你自己的排查思路原样还给了你 。它没利用任何已有证据去缩小范围，你看完还是不知道第一步该干啥。

第三类是这样的。先确认数据库更新最终成功，再根据 Redis 里旧值的写入时间发生在事务提交之前，推测是并发请求完成了 旧值回填 。然后它建议查缓存写入者、绕过缓存读一次、再复现删除缓存和提交事务之间的那个并发窗口。

第三类答案的措辞和分析顺序都可以变，但它长出了一条「事实、假设、验证、结论」的证据链。我们真正要评的是 这条链站不站得住 ，而不是它像不像参考答案。

03

METAMORPHIC

单次输出不好判，就观察证据变化后它怎样调整

说到这儿，还有一个更刁钻的情况。

有些能力你很难靠一份输出判断出来，但可以通过 改证据来观察 。你动一动输入，看 AI 的分析会不会做出合理的调整。

我在验证的其实是证据变化和分析变化之间的关系。这个思路在学术圈有个名字，叫 变形测试 （Metamorphic Testing）。它不要求每次都有唯一的完整输出，而是规定输入发生某种变化之后，输出里哪些判断应该保持稳定， 哪些应该跟着变 。

不过我得泼盆冷水。变形关系也不是万能药。打乱日志顺序后结论保持一致，只能证明它稳定，不能证明它对。一个错误的分析，完全可能 稳定地错一百次 。所以它得跟已确认的事实、故障注入、人工复核组队使用，单拎出来谁都不够。

04

THE JUDGE

为什么「再找一个 AI 当裁判」还不够

顺着这个话题再聊聊一个我经常被问的问题。能不能再找一个 AI 当裁判？

我的答案是，可以，但 别全信 。另一个模型确实能帮你检查分析有没有引用日志、有没有漏掉候选原因、验证步骤够不够具体。但它打出的那个分数， 本身也是一个需要验证的结果 。

你想想看，如果裁判模型天生偏爱结构完整、措辞自信的回答，那第二类列十种可能的答案 反而可能拿高分 。真正克制、老老实实说证据不足的回答，倒可能因为没给出确定根因被扣分。这不是我的猜测，研究里已经观察到大模型评判的多种偏差了，一次模型评分真不能直接当发布结论，感兴趣的可以去翻这篇《Humans or LLMs as the Judge? A Study on Judgement Biases》。

更稳妥的做法是 分层判定 。

还要保留第三种状态，Escalate。

不是通过，也不是失败，而是当前证据不足，需要补充信息或人工判断。对缺陷定位来说，知道什么时候不该下结论，本身就是能力的一部分。

这句我觉得放到人身上也一样成立。

05

REPLAY

如果在团队里试，先拿十个已关闭缺陷做回放

最后说说怎么在团队里落地。

可以先不用建AI 评测平台，那个坑又深又贵。个人建议是先找十个已经复盘完、证据相对完整的缺陷， 把最终根因藏起来 ，只把当时真实可见的日志、告警、数据和变更信息交给 AI，做回放。

样本要故意拉开差异。有的证据足以直接定位，有的存在多个合理假设，有的混了无关日志，还有的必须追加信息才能判断。然后一点一点释放证据，看 AI 会不会修正假设，还是 死守第一印象不撒手 。

起步阶段，一张表就够了。

评的时候千万别只看最终有没有猜中 。至少还要记这几笔，真实根因有没有进前几项候选，关键证据引用准不准，建议的验证动作能不能真的缩小范围，有没有出现虚构证据和危险操作，证据不足时会不会主动升级给人，新证据出现后候选原因的排序变化合不合理。

这些指标比一个笼统的定位正确率，更接近这件事的真实价值。它们既能衡量 AI 是不是真的缩短了排查路径，也能拆穿它是不是只是 更快、更自信地在猜 。

∞

THE END

最后，把方法压缩成五条

如果整篇你只能带走一点，那就带走这五条。

1

先写不可违背的事实，不急着写唯一答案。

2

允许多个假设，但每个假设都得有证据和验证动作。

3

通过增加、删除和扰动证据，检查 AI 是否稳定且会修正。

4

让规则、模型和人工分层判定，不把裁判权交给单一模型。

5

保留 Escalate，让「证据不足」成为一种合法结果。

这套方法也不只适用于缺陷定位。只要输出是开放的，比如 AI 生成测试场景、评审开发方案、分析变更风险，都可以从比对标准答案，换成 检查事实、证据、验证和不确定性 。

这也是上一篇「四代」文章里埋下的那杆枪，现在响了一声。当 AI 开始参与更复杂的测试工作，测试体系真正要升级的不是生成更多答案，而是建立一套能 判断答案可不可信 的机制。

所以，以后评价 AI 的缺陷定位能力，我会多问一句。

它是猜中了一个答案，还是 建立了一条经得起复查的证据链 ？

参考资料

1. The Oracle Problem in Software Testing: A Survey（discovery.ucl.ac.uk）
2. A Survey on Metamorphic Testing（eprints.whiterose.ac.uk）
3. Humans or LLMs as the Judge? A Study on Judgement Biases（arxiv.org）

END

我是 慢炖时光机，关注 AI 测试与软件质量的真实落地，分享前沿技术、项目实践与缺陷复盘，把复杂问题讲明白，把可行方案做出来。

如果你觉得今天这篇有收获，欢迎 点赞、在看、转发 三连，我们下篇见。

本文转载自微信公众号「慢炖时光机」，仅供学习交流使用。