## 摘要

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


![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/04abc591fec28c7d47da38a1be96c77a.png)


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

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

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

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

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

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

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

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


![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/5225ec8b915053680d4323c05c6dd3bf.png)


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

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

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

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

| 级别 | 允许的动作 | 谁批准 | 需要的证据 |
|---|---|---|---|
| L0 | 只诊断、给建议，不改文件 | 无需 | 失败原因、建议 diff |
| L1 | 改定位器/等待策略 | Agent 提交 + 人工评审 | 修复前后 diff、命中元素截图 |
| L2 | 改断言 | **禁止自动**，必须人工编写 | 断言变更理由、需求出处 |
| L3 | 删除/跳过用例 | **禁止自动**，需负责人签字 | 废弃原因、替代用例 |

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

**证明用例还能失败**

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

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

**三类失败，三条处置路径**

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

| 失败类型 | 典型特征 | 谁处理 | 处置 |
|---|---|---|---|
| 真缺陷 | 断言失败且业务结果确实错 | 人 | 修产品，不改用例 |
| 表达层漂移 | 元素换ID、文案变化、加载变慢 | 可从 L1 自动 | 改定位器/等待，人工评审 diff |
| 用例过期 | 需求已变，断言还在验证旧行为 | 人 | 重写或废弃，禁止静默放松 |

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

**自愈率怎么算才不骗人**

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

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

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


![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/29d6170932d55ef146576ff798bf30ef.png)


**评审 diff 的三个检查点**

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

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

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

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

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

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

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

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

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

**自愈和契约测试的分工**

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

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

**闭环怎么设计**

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

**边界**

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

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


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

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

自愈测试把红灯修绿了，但它可能把断言一起修没了

测试

开发工具

人工智能

自愈测试需从"换选择器"扩展到"改断言"，QwenCode设定最多3次修复即交回人工。核心是区分三种修绿方式，按验证能力分级权限，用受控失败证明用例有效。自愈率应看30天回归率，评审盯断言变化、等待时长、选择器宽度，防止"修绿但失效"。

软件测试

Agent

腾讯云双十一大促

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

自愈测试把红灯修绿了，但它可能把断言一起修没了-腾讯云开发者社区-腾讯云

自愈测试把红灯修绿了，但它可能把断言一起修没了

自愈测试把红灯修绿了，但它可能把断言一起修没了

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐