AI UI 测试为何演示9成成功、上线只剩6成

没人谈起的差距

如果你在 2025–2026 年用过任何 AI 浏览器测试工具，你大概遇到过这种情况：

本地演示十次能成九次。规模化生产？十次大概只能成六次。有时候更糟。

在 TestStar 进行一级稳定性验证时，我们直面了这个问题。我们选取了一个真实业务场景（登录 → SQL 控制台 → 输入查询 → 执行 → 断言，19 步），跑了 8 次：

每一次失败的原因都不一样。第一次：数据有问题（AI 没做错任何事）。第二次：浏览器驱动崩溃了。这才是最让人崩溃的地方——失败模式完全不一致。

但第六次才是让我们学到真正教训的那一次。子进程成功结束了。AI 做了所有正确的事。但结果从未写回数据库。AI 的判断和系统的判断不一致。

我们花了两天调试。根本原因：AI 每一步都在触发同步内存写入。到第 19 步时，工作线程积压严重，最终超时了。工具本身没问题。是平台垮了。

这就是没人警告你的生产环境差距。

"执行引擎 ≠ 平台"到底意味着什么

Browser-Use、Midscene、Skyvern——这些都是执行引擎。它们把自然语言翻译成浏览器操作。很实用，但它们不是测试平台。

一个测试平台至少需要：

故障处理：重试、放弃、还是升级？

自愈能力：这是 AI 错误还是产品变更？能修复吗？

可观测性：人类能否回放、定位、归因？

幂等重试：如何在网上抖动时重试而不会重复点击"支付"？

记忆：今天的失败经验能否传承下去？

调度：如何按优先级跑 1000 个用例？

知识库：页面上那个按钮到底在哪里？

这些都不在执行引擎里。它们都在我们所说的 Harness 层。

我们认识的一个团队花了 3 个月评估 5 款 AI 测试工具，选了演示效果最好的那个，然后又花了 6 个月自己构建 Harness 层。总计：9 个月。如果他们一开始就问对了问题，决策会完全不同。

三个塑造了我们自愈能力的真实事件

事件一：AI 自信地点击了错误的按钮

早期，AI 点击了它以为是"删除用户"的位置。日志显示成功。UI 显示成功。但实际按钮——由于一个 CSS bug——覆盖了"归档"按钮。AI 完全按照它看到的去做了，但用户得到了错误的操作。

我们学到：自愈不能只信任"操作成功"。你必须验证用户的预期结果，而不是系统报告的结果。

事件二：自愈破坏了一个本来正常的测试

我们上线了自愈模块。QA 报告之前通过的测试开始失败了。我们深入排查。

AI 在日志中看到这一行：

"Continue on error: skip summary-xxx.json"

"error"这个词触发了诊断。AI 生成了一个补丁并应用上去，破坏了一个本来正常的测试。真正的失败在另一行完全不同的日志上。

修复方案：增加一个"真实错误提取"层。只扫描以 waitFor timeout / Assertion failed 这类模式开头的行，排除配置类行。

教训：自愈的前提是可信赖的失败信号。信号错了，情况只会更糟。

事件三："我找不到登录按钮"——但它明明就在那里

AI 报告找不到登录按钮。开发人员去页面查看——按钮就在那里。花了 30 分钟调试才发现：在 AI 截取截图的那一刻，一个弹窗广告正好盖住了按钮。AI 没有说谎。只是信号具有误导性。

那个 60% 的数字（以及我们为什么不注水）

我们刻意创建了 5 个失败测试用例并测量自愈恢复率：

可恢复的失败：3/3 = 100%

第四个用例（1 秒超时）是最有意思的。我们讨论过要不要"拯救"它——让 AI 自动延长超时时间。我们决定不这样做。为什么？因为那个用例在等一个确实需要 3 秒才会出现的元素，却只等了 1 秒。如果 AI"修好"了这个问题，就会掩盖开发者需要解决的真实测试设计问题。

如果我们把数字注水到 80%，就是在隐瞒物理失败和测试设计错误本来就不应该被自愈这个事实。诚实 > 注水。

这个原则在 AI 测试中比几乎任何地方都更重要。AI 测试本质上是不可知的。客户信任是脆弱的。注水的数据建立的是虚假信任——而虚假信任崩塌起来比建立时还要快。

记忆与知识库

我们有三种记忆：

Wiki："这个按钮在页面顶部"——持久化存储

技能提炼："对于类似场景，这个模式有效"——来自成功运行

失败记忆："上次我们做 X 的时候失败了"——累积而来

存储以语义搜索优先，辅以本地文件兜底。演示环境可用（无依赖），可扩展到生产环境。

但我们吃尽了苦头才学到：记忆不总是好的。有一个案例：一次临时网络超时被写入了失败记忆。从此以后，每个类似场景都会触发那个"经验"，AI 开始对正常操作产生疑虑。

记忆有噪声。自动遗忘和冲突解决对我们来说仍是待解决的问题。

对于知识库，我们将页面元素提示（语义 + 位置）注入 AI prompt。实际效果：AI 以前会混淆"password"和"password login"——两个相似的元素。注入位置提示后，它先用位置锁定正确的元素。错误率明显下降。

TestStar 什么时候好用，什么时候不好用

适用场景：表单 + 列表 + 详情类 UI，管理员/仪表盘系统（OA、CRM、BI 平台、内部工具）。

Canvas/WebGL（游戏、可视化、白板）——AI 看到的是像素，但不知道它们代表什么

强反爬虫页面（CAPTCHA、滑块、行为检测）——AI 没有真实的人类环境

极短用例（少于 5 步）——缓存命中抵消不了启动开销

跨域联邦登录（OAuth、SAML 多步）

每次刷新都完全重新渲染的高度动态 SPA

我们对此很诚实。承认自己的局限比装作没有局限更值得尊敬。

选用任何 AI 测试工具前要问的五个问题

失败信号是结构化的吗？（决定自愈是否可能实现）

日志是否支持外部订阅？（决定可观测性）

执行能否被中断？（决定自愈循环）

工具能否摄入外部知识？（决定知识库价值）

有调度 API 吗？（决定规模化能力）

这五个答案比演示效果有多好重要得多。

我们坦诚地做错了的事

第一次 CI 运行：36% 通过率。利益相关者的反应："这怎么算生产就绪？"我们的回答："首次运行 36% 是正常的。重要的是退出码为 0（CI 没有阻塞）、KPI 已收集（恢复率、token 消耗、时间）、数据已持久化。真正的价值在于接下来两周的生产数据。"

我们没有注水。我们没有排除"已知失败"。有些团队成员认为这太激进了。我们坚持了立场。

真实的 CI 数据：缺失。冒烟脚本可用。两周的生产数据尚未积累完成。真实失败率、月度成本、人工介入频率——都是未知数。

多场景验证：不完整。我们在一个用例（数据查询控制台）上有深度验证。其他场景（CRM、复杂 SPA、低代码平台）——未经验证。

如果非要压缩成三件事：

执行引擎是起点，不是终点。Harness 层才是真正的主战场。

Token 成本是结构性的，不是能优化的。缓存不是优化——而是生产环境的前置条件。

引擎会商品化。差异化会落在记忆和知识上——谁记得更多，谁的结晶更好。

如果你在评估 AI 测试工具，问那五个问题。如果你在构建一个，先建 Harness 层——引擎可以替换。

测试工程师的核心价值从来不是"知道用哪个工具"。而是"知道什么时候该信任，什么时候该怀疑"。

TestStar 是一个 AI UI 测试平台：22000 行 Python + 10000 行原生 JS，内置视觉驱动的 AI 浏览器引擎，以及之上的编排/自愈/记忆层。