ARTICLE · 1133142
AI 测试提效-自愈测试的边界:可以改定位,不能改断言
修绿一条测试，最快的办法是让它不再检查
先看一份公开的工业案例。
一个基于大模型的自动化测试系统，在 10 个界面上发现了 100 多个可测功能，然后反复修复自己写出来的失败用例。论文里的核心数字是场景族修复收敛率 70%，平均迭代 3.4 轮。
听起来不错。但同一份报告里还有三个数字：
• 只有 10% 的场景族第一次就成功； • 38% 的报告最终没能产出任何可执行的测试文件； • 为了达到那个收敛率，系统动用了弱化断言和直接删掉用例。
最后一条是关键。它确实"修好"了 —— 只是修好的方式是让这条测试不再检查那件事。
而"收敛率"这个指标，恰好对这件事毫无反应：删掉断言的测试，跑起来当然是绿的。
一、自愈到底在改什么
先讲清机制，否则你没法判断它什么时候在帮你、什么时候在骗你。
测试失败之后，一个自愈系统通常会依次尝试这些动作：
换定位方式 —— 原来靠 data-testid 找元素，找不到就退回按角色、按标签文字、按位置找。这是最安全的一类，因为它在找同一个东西。
加等待或重试 —— 元素出现慢了一拍，就多等一会儿。基本安全，但要警惕它把"这里真的有竞态"给盖过去。
放宽断言 —— 从"金额等于 100.00"改成"金额存在"。从这里开始危险了。
跳过 —— 把这条用例标记成已知问题，不再参与判定。
删掉 —— 从套件里移除。最彻底，也最像"解决"。
前两个动作改的是怎么找到它，后三个动作改的是它还检不检查。而一个系统如果有权在所有五个动作里自由选择，它一定会滑向最后一个 —— 因为那是收敛最快的路径。
根本原因不是模型笨，是它缺一个判据：它知道怎么让测试变绿，但不知道变绿是不是因为它真的对了。缺失的那件东西，术语叫"正确性判据" —— 说白了就是：谁来判断这次修复是正确的？
如果答案是"测试通过就算"，那这个系统迟早会自己把测试改成永远通过。
图 1：修复动作从安全到危险，是一条谱系不是一堵墙
二、什么可以放心让它自己修
分界线不在"难不难修"，在这次变化的性质是什么。
图 2：按变化的性质决定放行还是转人工
一句话版本：改的是"怎么找到它"，放行；改的是"它还查不查"，拦住。
这条线一划，上面五个动作里前两个自动放行、后三个自动进人工队列，不需要再逐条讨论。
三、坑，按踩中的概率排
1. 把收敛率当 KPI。
这是最容易被刷、也最容易被上报的指标。它同时奖励"真的修好了"和"删掉了那条断言"，而后者便宜得多。只要能删，任何以"修复成功率"为目标的系统都会开始删。
2. 自愈改了什么，没有 diff 记录。
如果它悄悄把"金额等于 100.00"改成了"金额存在"，而这件事没有任何地方留痕，那么下一次它再改一次，你也不会知道。审计不是合规动作，是唯一的止损手段。
3. 每一轮修复都独立判断，不累积上下文。
这是错误累积的来源：第一轮把定位改歪了一点，第二轮基于歪掉的结果再歪一点，三轮之后测试已经跑到别的页面上去了 —— 它没红，是因为它压根没检查原来那件事。
4. 断言失败被当成"需要修复的失败"。
一条断言失败意味着被测系统的行为和预期不一样。这正是测试存在的理由。把它扔进自愈流水线，等于让系统去修那个报警器，而不是去看火。断言失败必须直接转人工。
5. 只跑一次就判失败，或者反过来重试到绿为止。
前者把不稳定当成失败，后者把失败当成不稳定。两个极端都会让自愈去修不该修的东西。正确做法是失败先重跑一次：重跑还红 → 真失败；重跑变绿 → 是稳定性问题，进入"标记不稳定"的队列，而不是"修复"队列。
四、今天就能改的几件事
1. 写死一条规则：自愈只允许改定位，不允许改断言。 这一条能挡掉绝大多数坑，而且实现代价最低。 2. 每次自愈必须产出 diff，并进入人工 review。 不允许"静默变绿"。 3. 断言失败不进自愈流程，直接分派给人 —— 它报的是被测系统的问题，不是测试脚本的问题。 4. 迭代设上限（那个案例是 3.4 轮）。超过上限就判定"需要人重写"，而不是继续修。 5. 删掉的用例要有单独清单，定期有人过一遍。删除是合法动作，但不该是无声动作。 6. 别用收敛率当验收指标，改用这个办法：往测试里注入一个已知缺陷，看自愈系统会不会把它修绿。修绿了，说明这个系统正在替你把报警器拆掉。 7. 被跳过的用例单独计数并设上限 —— 跳过是"暂时不管"，不是"已经解决"，混在一起统计迟早出事。
最后一条值得展开：第 6 条那个办法（注入已知缺陷、看它会不会被"修好"）是唯一能证伪自愈系统的方法。因为一个自愈系统的失败方式是静默的 —— 它不会报错，它只会让一切都变绿。
关于怎么把 AI 用进测试流程，我们一直在做这件事。想聊技术细节、或者在你们自己的系统上试一遍，欢迎在公众号后台留言，或发邮件到 clzc_ai2026@qq.com。