AI 测试为何只做了一半？揭秘闭环三层模型

2026 年第一季度，全球科技行业裁员近 8 万人，其中 48% 与 AI 相关。某企业用 AI 替代了整个 QA 团队，结果 3 个月后损失了 600 万美元。 一边是“AI 取代测试”的恐慌，另一边是“AI 测试翻车”的残酷现实。 **问题究竟出在哪里？** 并非 AI 无法胜任测试工作，而是大多数人仅完成了流程的一半——即让 AI 生成用例并执行脚本，却无人对测试结果的准确性进行管控。 这就像让实习生写代码却不做代码审查，出事只是时间问题。 今天分享一套我在实战中验证有效的框架：**AI 测试闭环三层模型**。这不是理论，而是经过生产环境 12 轮、98 条用例验证的实战经验。

--- ## 一、行业现状：大家都在用 AI 做什么测试？ 先看数据： - 77% 的测试团队已在使用 AI（Capgemini 2025-26 报告） - 70% 的重复测试任务正在被 AI Agent 接管 - GenAI 能力已超越传统技能，成为质量工程师排名第一的必备技能（63%） 但实际落地效果如何？绝大多数团队停留在以下阶段： ``` PRD → AI 生成用例 → AI 编写脚本 → 运行成功 → ✅ 结束 ``` 看似完美，实则存在致命缺陷：**谁来判定 AI 测试得是否准确？** - AI 生成的用例是否覆盖了所有场景？ - AI 执行的操作与预期是否一致？ - 测试通过是真实通过，还是 AI “自己考自己”放水了？ 大多数团队的回答是：人工查看。那引入 AI 的意义何在？仅仅是为了节省写脚本的时间，却花在看报告上？

--- ## 二、AI 测试闭环三层模型 我在实战中摸索出一套框架，将 AI 测试拆解为三层，每一层解决一个核心问题： | 层级 | 名称 | 解决的问题 | |------|------|-----------| | 第一层 | **Loop（执行循环）** | AI 能否自动运行？ | | 第二层 | **Eval（独立评估）** | AI 测试得对不对？ | | 第三层 | **Harness（编排治理）** | 整个系统是否稳定？ |

### 第一层：Loop — 让 AI 自动运行 这是大多数人已经做到的： ``` 需求文档 → 生成用例 → 执行脚本 → 收集结果 → 输出报告 ``` 关键不在于能否跑通，而在于**能否无人值守地循环运行**。我的做法： - AI Agent 自主读取需求文档（PRD 链接） - 自动侦察页面结构（不依赖人工编写选择器） - 逐条生成并执行用例 - 每条用例截图取证 - 输出结构化报告 **核心指标：** 人工介入次数。如果每次测试都需要人盯着，那不叫自动化，只能叫半自动。 我的实战数据：98 条用例执行过程中，人工介入 0 次（V5 版本）。 ### 第二层：Eval — 不能让 AI “自己考自己” 这是大多数团队缺失的一环，也是我认为最关键的一环。 **核心原则：执行者与评估者必须分离。** 为什么？因为 AI 执行测试时存在“路径偏见”——它会倾向于认为自己的操作是正确的。就像让学生自己批改试卷，分数一定偏高。我的做法： - **执行 Agent**：负责操作页面、点击按钮、填写表单 - **Evaluator Agent**：独立的另一个 AI，获取截图和执行日志，重新判断“这一步到底对不对” - 两个 Agent 完全独立，Evaluator 不知晓执行 Agent 的“意图”，只看“结果” 这个设计对标的是 OpenAI 和 Anthropic 的 Eval 体系——他们在评测大模型时，也是使用独立的评估器，而非让模型自评。 **评估维度：** | 维度 | 判断标准 | |------|---------| | 操作正确性 | 点击的元素是否正确？填写的值是否正确？ | | 页面状态 | 操作后页面是否达到预期状态？ | | 业务逻辑 | 结果是否符合需求文档的描述？ | | 异常处理 | 遇到弹窗/加载失败时 AI 的应对是否合理？ | **闭环关键：** Evaluator 判定失败的用例，自动生成缺陷描述，提交到缺陷管理系统（对接 Dima），钉钉实时通知。无需人工翻阅报告查找问题。 ### 第三层：Harness — 让系统稳定运行 前两层解决了“能跑”和“测得准”，第三层解决“跑得稳”。 当你把 AI 测试从演示推向生产环境，会遇到一堆工程难题： - 页面改版，AI 找不到元素怎么办？ - 执行中途网络中断怎么办？ - AI 陷入死循环怎么办？ - 多个测试任务并发执行怎么办？ 这些不是 AI 能力的问题，而是**工程治理问题**。我总结了 6 个设计原则（称为 Harness Engineering）： 1. **生产验收分离** — 开发环境与验收环境独立，避免脏数据干扰 2. **上下文重置** — 每轮测试前清理状态，防止上一轮残留影响下一轮 3. **约束系统化** — 将“禁止事项”写成规则文件，而非仅靠 Prompt 中的一句话 4. **渐进式披露** — 不要一次性给 AI 所有信息，按需分步提供上下文 5. **细粒度状态** — 每条用例独立追踪状态，失败不影响后续执行 6. **分层恢复** — 遇到问题分级处理：重试 → 跳过 → 告警 → 人工介入

--- ## 三、这个模型有什么用？ ### 对个人：职业定位的锚点 如果你还在简历上写“负责自动化测试”，说明你仅停留在第一层。 - **能做 Loop** = 会用 AI 工具的测试（很多人已具备） - **能做 Eval** = 懂 AI 质量评估的工程师（市场稀缺） - **能做 Harness** = 能设计 AI 测试体系的架构师（极度稀缺） 你现在的层级，决定了你未来 3 年的薪资。 ### 对团队：AI 测试落地的路线图 不要试图一步到位，按三层递进： **阶段一（1-2 周）：跑通 Loop** - 选择一个功能模块，让 AI 生成用例并执行 - 目标：证明 AI 能跑通 E2E 流程 - 成功标准：AI 生成的用例有 60%+ 可用 **阶段二（2-4 周）：加上 Eval** - 引入独立评估机制，杜绝 AI 自评 - 目标：测试结果可信度从“看着像对的”变成“有评估报告背书的” - 成功标准：误判率 < 10% **阶段三（1-2 月）：完善 Harness** - 处理稳定性、并发、恢复等工程问题 - 目标：从演示工具变为可日常使用的工具 - 成功标准：连续 5 轮无人值守执行成功 --- ## 四、AI 做不好什么？（必须说的反面） 三层模型并非万能药。目前 AI 测试闭环的已知局限： 1. **探索性测试** — AI 不会像人一样“随机点击”发现意外 Bug，它只会按预设路径走 2. **业务判断力** — “交互体验是否良好”这类主观判断，AI 只能提供参考 3. **环境依赖** — 需要稳定的测试环境，AI 无法处理“环境今天又挂了”的情况 4. **安全测试** — 渗透测试、模糊测试等需要对抗性思维的场景，AI Agent 尚不擅长 所以闭环的意义不是“完全不需要人”，而是**将人从重复执行中解放出来，专注于 AI 做不好的事上**。 --- ## 五、总结 ``` 测试的未来不是编写更多测试用例，而是设计更好的测试系统。 ``` AI 测试闭环三层模型： - **Loop** — 让 AI 自动运行（执行自动化） - **Eval** — 让 AI 的结果可信（质量评估） - **Harness** — 让系统稳定运行（工程治理） 大多数人还在第一层徘徊。如果你能把三层都打通，你就不是“会用 AI 的测试”，而是“能设计 AI 测试体系的人”。 这两种人的市场价值差距可达 3 倍。

--- *我是「测试进化论」，专注 AI + 测试实战。如果这篇对你有启发，欢迎关注，下一篇我们聊“大模型输出质量怎么测”。*