夜雨聆风
2026 年 Q1，全球科技行业裁员近 8 万人，48% 归因于 AI。某公司用 AI 替掉整个 QA 团队，3 个月后损失 600 万美金。
一边是"AI 取代测试"的焦虑，一边是"AI 测试翻车"的现实。
**问题出在哪？**
不是 AI 不能测试，而是大多数人只做了半个闭环——让 AI 写用例、跑脚本，但没人管 AI 测得对不对。
这就像让实习生写代码但不做 Code Review。出事只是时间问题。
今天分享一个我在实战中跑通的框架：**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 测试从 demo 推到生产，会遇到一堆工程问题：
- 页面改版了，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**
- 处理稳定性、并发、恢复等工程问题
- 目标：从 demo 变成可日常使用的工具
- 成功标准：连续 5 轮无人值守执行成功
---
## 四、AI 做不好什么？（必须说的反面）
三层模型不是银弹。目前 AI 测试闭环的已知局限：
1. **探索性测试** — AI 不会像人一样"瞎点"发现意外 Bug，它只会按预设路径走
2. **业务判断力** — "这个交互体验好不好"这种主观判断，AI 只能给参考
3. **环境依赖** — 需要稳定的测试环境，AI 处理不了"环境今天又挂了"的情况
4. **安全测试** — 渗透测试、模糊测试等需要对抗性思维的场景，AI Agent 还不擅长
所以闭环的意思不是"完全不需要人"，而是**把人从重复执行中解放出来，专注在 AI 做不好的事上**。
---
## 五、总结
```
测试的未来不是写更多测试，而是设计更好的测试系统。
```
AI 测试闭环三层模型：
- **Loop** — 让 AI 自动跑起来（执行自动化）
- **Eval** — 让 AI 的结果可信（质量评估）
- **Harness** — 让系统稳定运行（工程治理）
大多数人还在第一层打转。如果你能把三层都做通，你就不是"会用 AI 的测试"，你是"能设计 AI 测试体系的人"。
这两种人，市场给的价格差 3 倍。
---
*我是「测试进化论」，专注 AI + 测试实战。如果这篇对你有启发，欢迎关注，下一篇我们聊"大模型输出质量怎么测"。*
