TestStar AI 测试实战系列 · 第 3 篇 · 上一篇：8 次跑通一条 19 步用例的实战复盘

这篇不讲概念，只讲我们做自愈时踩过的坑——哪些失败能救、哪些不能救、自愈到底怎么设。都是 TestStar 这个 AI UI 测试平台真跑出来的。

这系列还会有几篇，后续接着更。

---

一、AI 跑错了，TestStar 能自己修回来

我们在做 TestStar，一个 AI UI 测试平台。这套自愈，是我们从 0 搭出来的。

第一版自愈只分了 5 类失败（超时、网络、元素、断言、其他），结果一大半失败全堆进"其他"——等于没分。

又试了 32 类，超时细分成 1s/2s/5s/10s，网络分成 DNS/TCP/HTTP。这次反过来，每个类只有两三个样本，分了跟没分一样，还把准确的判断搞乱了。

最后停在 16 类，不是拍脑袋，是拿真实失败样本一个个试出来的。

先交代三句话，省得你往下看一堆细节：

1. 分类别贪多，十几类就够，再多反而乱
2. 有些失败根本不该救，救它等于帮产品掩盖问题
3. 自动修复一定要有"刹车"，否则 AI 会把对的东西改坏

---

二、为什么 AI 测试不能没有"自愈"

AI 测试上生产后，最头疼的不是 AI 跑不准，是 AI 挂了以后没人接得住。

你做传统自动化，失败看一行就明白——“element not found: #submit-btn”。做 AI 测试不是这样，失败看到的常常是：

• assertion failed
• 一份 JSON 报告
• 一堆 AI 思考的文字（但这些字可能是 AI 自己编的）

同一个"超时"，可能是网络抖了、产品改了、也可能是用例自己写错了。不翻日志根本分不清。

更要命的是，同样的错会一遍遍重来。AI 上次"按钮找不到"修好了，下个版本按钮改个名，它又找不到了。

所以自愈不是锦上添花，是 AI 测试能上生产的必备。

---

三、哪些失败不该救——想清楚这个，比分类更重要

做自愈第一件事不是"怎么分类"，是先想清楚哪些其实不该救。

我们一开始什么失败都想让 AI 自动解决。后来才发现，有两类根本救不了，也不该救：

1. 物理失败，不该救
比如网络彻底断了、DNS 解析不了。这不是产品问题，也不是用例问题，是环境问题。AI 再聪明也救不回一个断掉的网络。

2. 用例自己写错了，不该救
举个例子：有个下单用例，测试数据里写的是"商品 100 元"，但真实商品其实是 300 元——用例却在断言"结算页显示 100 元"，所以一直失败。问题不在产品，在用例自己的测试数据写错了。

AI 要是"聪明"地帮你把断言改成"显示 300 元"，表面上用例过了，实际是把一个本来写错的用例糊弄过去了。这个错没暴露，你以为下单流程是好的，其实没人发现测试数据是错的——下一次真出现价格 bug，照样会被这个错误用例盖住。

所以这个我们不救：救它，等于帮开发掩盖一个本该改对的用例。让它一直红着，逼你去把"为什么是 100"改对。

想清楚"该救什么"，比"怎么救"重要得多。

---

四、分类到底分几类合适

我们踩过的两个极端：

• 5 类：太少，失败全堆在"其他"，分了等于没分
• 32 类：太多，每类就这么两三个样本，分不准，反而乱

最后停在 16 类，分三档：

• 8 种"性质不一样"的失败，每种配一种救法（等待超时、网络、找不到元素、断言不过、页面变了、登录失效、数据污染、死循环）
• 6 种辅助判断的根因（环境偶发、死循环、数据累积、登录失效、前置数据缺失、连坐失败）
• 2 种兜底（实在分不出来、测试主动跳过）

我们的建议：分类别超过 16 类。多了不是更准，是更乱。

---

五、自动修复要有刹车

自动修复最怕两件事：

1. AI 把对的修成错的（它"觉得"这样对，其实是幻觉）
2. 修复错位置，把 A 用例的修法用到 B 上，造成新问题

但全交给人工审核又看不过来——人没有那么多精力一篇篇盯。

我们的做法是给 AI 的修复加一个信心分：AI 修的时候，给自己打个分（0 到 1）。

• 分数够高：直接应用，自动重跑
• 分数不够：弹窗交给人看——它改了什么、为什么这么改，清清楚楚

这个分数阈值定多少？

试过 0.7：太严，等于没做自愈（救活的太少）。
试过 0.3：太松，AI 瞎改的开始溜进来。
最后停在 0.4：救回率、准确率刚好平衡。

一开始可以就设 0.4，跑一阵子看数据再调。别从 0.7 开始——你不是在做自愈，是在给 AI 放假。

流程就三步

AI 修好 → 打分
   ↓
分高 ≥0.4 → 自动应用 → 重跑
   ↓ 分低
弹窗交人 → 看改了什么 + 为什么 → 决定要不要信

---

六、能救什么,不能救什么

能救	不能救
元素改名 / 位置变了	网络彻底断了
断言条件该更新了	服务器 500
网络瞬时抖一下	验证码 / 风控拦你
数据攒多了把环境搞脏	产品本身真有 bug
	用例自己逻辑写错了

自愈不是万能灵药。实话实说，它（TestStar 自愈）能救的其实有限——但能把"一堆乱失败"变成"有该救的、有不该救的"，分开处理，这就是最大的价值。

关于 TestStar 的救回率，实话是：可修复的失败基本能救回，但两类"本就不该救"的（网络彻底断、用例写错）我们故意不救。想清楚哪些该救，比一股脑全救更重要。

---

七、踩过的一个坑：AI 报的"错误"可能是假的

这是做自愈最容易栽的坑。

早期版本，日志里有这么一行：

“Continue on error: skip summary-xxx.json”

AI 一看有 “error” 这词，就当成失败原因去修。但真实失败原因根本不是这一行。它修了一大通，修了个寂寞，还把好好的用例改坏了。

我们后来加了一道"先翻日志验真"——只认真正的错误行（比如 waitFor timeout、Assertion failed 开头的），把 Continue on error 这种配置行排除掉。

一句话给你：AI 修错，不是 AI 蠢，多半是喂给它的"错误信号"就是错的。 修的自愈之前，先确认失败信号是真的。

---

八、还没做好的，也跟你说一声

老实交代三件事，别让这篇看着像在吹自己（也是 TestStar 自愈的实话）：

• AI 还不会举一反三：同一个失败改个样子，它就救不回来了，只是死记硬背
• TestStar 在一个产品上攒的经验，换个产品基本用不上——这是我们正在啃的硬骨头
• AI 自己打的那个分，本身也是估算，0.4 是我们试出来的经验值，不一定最优

说这些是想告诉你：别指望装个自愈瞬间就一劳永逸。它的边界比想象的大，但正好值得琢磨。

---

几句能记住的

1. 分类别贪多，十几类够了，再多反而乱
2. 物理失败、用例写错，根本不该救，救它等于帮产品掩盖问题
3. 自动修复一定要有刹车，不然 AI 会把对的改坏
4. 修复前先验信号，AI 修错多半是喂给它的错误是假的
5. 想清楚"该救什么"，比"怎么救"重要得多

---

下一篇

下一篇讲 TestStar 的 Token 治理——单次 48 万 token 是怎么一路压到 5 万的，哪些能缓存、哪些宁可重算也别缓存。