为什么别人的 AI 测试是"聊天机器人"，我们的 AI 测试是"流水线"？差别在流程设计。这篇文章把我们半年沉淀的 8 阶段 AI 测试流程完整拆给你看。

---

一、先回答一个问题：AI 测试为什么需要"流程"？

很多人用 AI 测试的方式是：打开对话框，说一句"帮我测一下这个页面"，然后等结果。

结果通常不理想——因为AI 不知道你的流程：它不知道先分析需求还是先探索页面、不知道用例设计要覆盖什么规则、不知道什么叫"通过"。

我们踩了半年后得出一个结论：AI 测试想落地，必须先把测试流程"固化"成 AI 能执行的规范——每个阶段有明确输入、明确输出、明确通过标准。 流程是骨架，AI 是肌肉。

下面是我们沉淀的 8 阶段流程，每个阶段都包含四个要素：目标 / 对 AI 的指令 / 对人类的指令 / 输出与通过标准。

---

二、8 阶段全景

阶段一  需求分析      需求收集 → 功能点拆解 → 可测性评估 → 范围优先级界定
阶段二  页面探索      浏览器截图快照 → 逐元素探索 → 输出元素定位规则
阶段三  用例设计      等价类划分 + 边界值分析 + 场景推演 → 用例矩阵
阶段四  用例评审      3 轮自动评审（覆盖追溯 / 质量 / 冗余数据）
阶段五  测试执行      AI 开浏览器逐条执行，实时判定 PASS/FAIL/BUG/BLOCKED
阶段六  报告输出      HTML + Markdown 报告 + 遗漏分析
阶段七  持续优化      用例精简 / 回归集推荐 / BUG 跟踪 / 遗漏复盘
阶段八  脚本生成      通用函数库 + 逐条转换 → 可执行 test_*.py

每个阶段都设了人工确认点——AI 干活，人把关。

---

三、几个含金量最高的设计细节

细节 1：需求分析的"可测性分级"（A/B/C）

需求文档经常含糊："页面要友好""交互要合理"。如果直接让 AI 设计用例，它只能瞎猜。

我们的做法是先做可测性评估，每条功能点打等级：

• A 级：预期结果可量化（有明确返回、文案、状态）→ 直接设计用例

• B 级：表述模糊（"正常""尽快"）→ 列入待确认清单，找产品确认后才能测

• C 级：暂不可测 → 明确处理方式（补测/排除）

待确认清单按优先级管理：P0（影响核心流程，必须确认）、P1（影响主要功能）、P2（可按默认值继续）。A 级占比 ≥80% 才允许进入下一阶段。

这一步的价值：把"需求模糊"这个测试老问题，变成流程里显式处理的环节，而不是让 AI 硬猜。

细节 2：用例设计的"等价类规则表"（核心干货）

AI 设计用例最怕"自由发挥"。我们的做法是把测试理论固化成规则表，AI 必须按表推断：

输入类型	必推等价类
文本输入框	精确匹配、前缀、空字符串、不存在值、超长字符串
下拉选择框	具体选项、"全部"选项、不选直接查询
日期选择器	当天、历史日期、仅开始、仅结束、开始=结束、未来日期、开始>结束
金额输入框	正常值、0、最小值、最大值、负数、超上限
文件上传	0 个、1 个、上限、上限+1、不允许的格式
分页控件	第 1 页、最后 1 页、页码 0、负数、超最大页

再加上边界值分析（0/1/maxLength/maxLength+1）和场景流程推演（完整链路：搜索→详情→子页面→返回），输出按"页面→模块"分组的用例矩阵。

质量门槛也量化：用例总数 ≥ 功能点数的 4 倍，P0 占比 ≥30%——不达标就让 AI 继续补。

这个规则表是从测试理论里提炼的、可跨项目复用的——它就是"AI 版的测试经验"。

细节 3：用例评审的三轮制

用例生成后不是直接用，AI 自己先审三轮：

• 第 1 轮（覆盖与追溯）：每个需求功能点是否都有对应用例？有没有"孤儿用例"？覆盖率要求 ≥95%

• 第 2 轮（用例质量）：预期结果是否可量化？"页面正常""操作成功"这类模糊断言全部标记并要求改写

• 第 3 轮（冗余与数据）：相似度 >80% 的用例建议合并；依赖特定数据的用例检查环境有没有数据，没有就标记 BLOCKED 并提示补数据

三轮闭环后才进入执行。以前人工评审用例要开半天会，现在 AI 先查一遍，人只审 AI 标出的问题。

细节 4：执行判定的四个状态

AI 执行用例时，判定规则必须写死，不能含糊：

状态	判定规则
PASS	实际结果完全符合预期
FAIL	与预期不符，但无系统异常
BUG	页面报错/白屏/崩溃/数据异常
BLOCKED	环境数据不足/登录失效，无法执行

每步截图留痕，异常处理有预案（页面跳登录 → 标记 BLOCKED；新 Tab 丢失 → 关闭回原页；虚拟滚动元素不可见 → 原生 setter 绕过）。

细节 5：脚本生成的"覆盖率 100%"要求

最后阶段把用例转成可执行脚本，必须逐条转换、编号对应——每条用例有脚本、有断言（至少 1 个数据断言 + 1 个文本断言）、有截图命名规范，最后输出覆盖率校验报告，要求 100%。

---

四、这套流程能跑通，靠 4 个设计原则

1. 人机确认点前置：每个阶段结束都有"人对 AI 的确认"，不确认不进入下一阶段——AI 干得再快，人在关键处把关

2. 通过标准必须量化："覆盖 ≥95%""P0 ≥30%""用例数 ≥4 倍功能点"——能数字化的绝不用形容词

3. 交付物先行：每个阶段都有明确的文档产物（需求分析文档、功能点清单、用例矩阵、评审附录）——流程跑完，整套文档自动齐了

4. 对 AI 的指令要"可执行"：不是"设计用例吧"，而是"按规则表逐项推断，输出 {tc, module, priority, steps, expected} 结构"——AI 需要的是程序化的指令，不是聊天

---

五、这套流程是怎么来的，以及怎么用起来

这套 8 阶段流程不是拍脑袋设计的，它来自我们测试组半年的实践迭代：最初只有"需求分析 → 用例设计 → 执行 → 报告"4 个阶段，跑起来后发现阶段间缺人工确认点、用例缺评审、脚本缺沉淀，逐步补成了现在的 8 阶段。

如果你想在自己的团队落地这套流程，三步走：

1. 先固化流程文档：把你们团队的测试过程写成"阶段 + 每阶段的输入/输出/通过标准"，不需要一步到位，先写当前实际怎么做的

2. 选一个阶段试点 AI：建议从用例设计开始——把等价类规则表发给 AI，让它按表生成用例矩阵，人工评审质量

3. 跑顺一个再扩下一个：阶段之间用"文档产物"衔接（上一阶段的输出就是下一阶段的输入），AI 才能连续作业

流程设计的核心不是"8 个阶段"这个数字，而是每个阶段都有明确输入、明确输出、可量化的通过标准，以及一个人工确认点——做到这四点，你的流程就能交给 AI 执行。

如果你也在设计 AI 测试流程，欢迎评论区交流你的阶段划分——流程设计没有标准答案，集思广益 🚀