TestStar AI 测试实战系列· 第 3 篇 · 上一篇8 次跑通一条 19 步用例的实战复盘这篇不讲概念只讲我们做自愈时踩过的坑——哪些失败能救、哪些不能救、自愈到底怎么设。都是TestStar这个 AI UI 测试平台真跑出来的。这系列还会有几篇后续接着更。一、AI 跑错了TestStar 能自己修回来我们在做TestStar一个 AI UI 测试平台。这套自愈是我们从 0 搭出来的。第一版自愈只分了 5 类失败超时、网络、元素、断言、其他结果一大半失败全堆进其他——等于没分。又试了 32 类超时细分成 1s/2s/5s/10s网络分成 DNS/TCP/HTTP。这次反过来每个类只有两三个样本分了跟没分一样还把准确的判断搞乱了。最后停在 16 类不是拍脑袋是拿真实失败样本一个个试出来的。先交代三句话省得你往下看一堆细节分类别贪多十几类就够再多反而乱有些失败根本不该救救它等于帮产品掩盖问题自动修复一定要有刹车否则 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 类。多了不是更准是更乱。五、自动修复要有刹车自动修复最怕两件事AI 把对的修成错的它觉得这样对其实是幻觉修复错位置把 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 是我们试出来的经验值不一定最优说这些是想告诉你别指望装个自愈瞬间就一劳永逸。它的边界比想象的大但正好值得琢磨。几句能记住的分类别贪多十几类够了再多反而乱物理失败、用例写错根本不该救救它等于帮产品掩盖问题自动修复一定要有刹车不然 AI 会把对的改坏修复前先验信号AI 修错多半是喂给它的错误是假的想清楚该救什么比怎么救重要得多下一篇下一篇讲TestStar 的 Token 治理——单次 48 万 token 是怎么一路压到 5 万的哪些能缓存、哪些宁可重算也别缓存。