自愈測試把紅燈修綠，卻可能連斷言也一併修掉

2026-11-06 4

版权

版权声明：

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 本文探讨自愈测试的边界与规范：提出“红灯变绿”的三种方式（换定位器、松断言、删用例），强调仅第一种属真正修复；引入Qwen Code“最多3次自动修复即交还人工”的关键实践；给出修复权限分级表与受控失败验证法，倡导以“30天回归率”替代虚高自愈率，确保自动化不损害测试可信度。

摘要

自愈测试正在从"换选择器"扩展到"改断言、改用例"。2026年11月1日，开源项目 Qwen Code 的发布说明里给自动修复加了一条很值得抄的规则：最多推3次修复就交回人类。本文拆解自愈的三种"修绿"方式、给出修复权限分级表，并说明怎样用一次受控失败证明你的用例还有验证能力。

2026年11月1日，开源项目 Qwen Code 发布 v0.26.5，其中一条变更很不起眼但很关键：无人值守的 PR 自动修复循环，最多推3次修复就必须交回人类；交接状态在 /autofix-pr status 里可见，PR 评论会说明尝试过什么、卡在哪。同一版里，沙箱化的发布器在产物检查失败或无法运行时，会把这一轮标记为 inconclusive，而不是当作通过。

这是厂商文档里写明的产品行为，不是事故复盘。但它回答了一个很多团队还没想清楚的问题：自动修复该不该有上限？ 答案是应该，而且上限的意义不在次数，在目标函数。

红灯变绿有三种方式，只有一种是修复

第一种，换定位方式。按钮的 ID 变了，自愈改用文本或相对位置找到它。这是自愈最正当的用途，处理的是"页面结构漂移"，不是"功能坏了"。

第二种，放松断言。原来的断言是"下单成功后订单状态为已支付"，改成了"页面出现成功提示"。测试还是绿的，但它验证的东西少了一层。

第三种，删掉或跳过用例。最省事，也最危险。

第二种最隐蔽，因为它留下的 diff 看起来很合理，评审时很容易被当成"适配新UI"。而它造成的后果是：这条用例从此再也发现不了那个缺陷，而且没人知道。

三种方式放在一起看，差别不在"改了什么文件"，而在"还剩多少验证能力"：

一条可以构造出来的失败样本

假设结算页的"提交订单"按钮改了文案，页面上同时存在优惠券弹窗里的另一个"提交"按钮（本文构造的推演用例，用于说明机制）。自愈按文本匹配，选中了弹窗里的那个，点击成功、页面跳转、断言里的"出现成功提示"也满足——测试通过。真实结果是订单没创建，优惠券被领了。

这条用例在报告里是绿的，在用户那里是事故。它说明自愈的风险不是"修错了代码"，而是"修对了流程，修错了对象"。

把修复权限分级，比调参有用

这张表的作用不是限制效率，而是把"哪些变化必须有人负责"写清楚。L1 可以放开，因为它的失败模式可见；L2、L3 必须卡死，因为它们的失败模式是"以后再也发现不了"。

证明用例还能失败

社区里开始流行一个做法：每条关键用例，除了正常通过，还要有一次受控失败——故意改坏实现、注入一个错误返回值，确认用例会红。只有红过，绿才有信息量。

这件事可以自动化：在流水线里跑一个"变异检查"任务，对核心模块注入小改动，统计有多少用例能捕获。捕获率长期为0的用例，就是"绿着但已经死了"的用例——它们不但没用，还在消耗运行时间和评审注意力。

三类失败，三条处置路径

自愈触发时，先分类，再决定谁处理。三类失败的处置完全不同：

分类错了，后面全错。最常见的误判是把"真缺陷"当"漂移"——因为 Agent 修完确实绿了，看起来像漂移。判断方法是看修复前后的业务结果：如果修复后订单真的创建了，是漂移；如果只是页面提示变了、数据没动，那是缺陷被掩盖了。

自愈率怎么算才不骗人

"自愈率85%"这个数字，至少有三种算法：修复成功数除以触发数、修复后仍绿的比例、修复后30天不复发的比例。前两种只证明"红灯消失了"，第三种才证明"修对了"。

建议同时公布三个数：自愈触发数、一次修复成功率、30天回归率。如果只能看一个，看第三个。因为自愈的代价往往延迟出现：断言被放松后，那条用例再也不会红，你失去了未来发现同类缺陷的能力，而这个损失不会出现在任何当下指标里。

三个数不是并列关系，是三个可信度台阶：

评审 diff 的三个检查点

自愈提交的 PR，评审时盯三处：

1. 断言有没有变：变了就要求说明"新断言验证的是哪条需求"，说不清就退回；
2. 等待与重试有没有变长：把 5 秒等到 30 秒，往往是在掩盖性能问题，不是修复；
3. 选择器有没有变宽：从"精确文本"变成"包含某关键词"或"页面上第一个按钮"，命中范围变大，误命中概率同步上升。

这三点看完，再看代码风格。顺序反了，就会把时间花在缩进上，放过真正的风险。

小团队的最小落地：三条规则加一个看板

不需要平台化，三个人以内的测试团队按这个做就够：

规则一，改断言必须人写。 把这条写进分支保护：只要 diff 里出现断言相关的文件或关键字，自动要求第二个人批准。理由很简单——断言是团队的判断，不是可自动优化的参数。

规则二，修复必须附三样东西：失败原因、影响面（这条用例原本覆盖哪条需求）、以及修复前后的截图或日志。差一样就退回。这不是流程洁癖，是为了三个月后有人能读懂这次修改。

规则三，连续修复三次就升级。 同一条用例一个月内被自动修三次，说明它已经不稳定了。这时候不该继续修，而该判断：是页面结构烂到无法稳定定位，还是需求已经变了、用例该重写。继续修只会把噪音留在流水线里。

看板上放四个数：自愈触发次数、一次修复成功率、30天回归率、受控失败覆盖率。前两个看效率，后两个看可信度。只报前两个的团队，迟早会被一次"修绿了但没验证"的事故教育。

自愈和契约测试的分工

自愈修的是"怎么找到元素"，契约测试守的是"找到之后断言什么"。两者职责不同，不能互相替代。

如果团队还没做契约测试，建议先补这一层：把每个接口和每个关键页面的"不可退让条件"写成断言，再谈自愈。因为在一个断言本身就很松的套件里接入自愈，等于给一张漏水的网打补丁——补得越快，漏得越隐蔽。

闭环怎么设计

1. 修复 PR 必须附根因说明和影响面，不能只有 diff；
2. 修复后自动跑一次受控失败，证明断言仍在验证原目标；
3. 同一用例连续修复超过3次，转人工判断是"页面不稳"还是"需求变了"；
4. 看板同时看两个数：自愈成功率、修复后30天内的回归率。只看前者，等于只看"红灯消失得多快"。

边界

自愈擅长处理定位漂移、等待时机、环境差异这类"表达层"问题；对需求变更、业务规则调整完全无效——那需要人改断言，而不是机器找元素。另外，把自愈率当成KPI会立刻催生"修绿工程"：团队会优化那个数字，而不是优化质量。

自愈真正节省的不是写代码的时间，是判断的时间。它把"这个失败是噪音还是缺陷"的第一轮筛选做掉，然后必须停下来，把判断交回给人。停下来的那个位置，就是上限该设的地方。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。