为什么不能直接把 PRD 丢给大模型，让它生成测试用例？

理论上可以，实际上不可控。直接生成往往会出现：生成逻辑偏离 PRD、用例结构混乱、缺失异常场景、忽略边界条件、权限与状态流转场景缺失。

问题的本质在于：测试用例的生成本身是一个有「流程」的脑力活动，而不是一次文本生成。要让 AI 真正可用，就必须把「测试流程」拆解出来，让 AI 按流程工作。

本文从人工编写用例的真实流程出发，说明如何把测试思维拆解成 AI 可执行流程，实现流程化、分阶段、可控生成。

一、人工编写测试用例的真实流程

测试工程师的思考过程是结构化的，大致包含以下环节：

步骤 测试工程师在做什么
1 阅读 PRD
2 拆分功能模块
3 理解业务流程
4 列出功能点
5 设计正常流程
6 设计异常流程
7 设计边界条件
8 设计状态流转场景
9 考虑权限控制
10 补充兼容性 / 性能 / 并发场景（如适用）

这是一个明显的结构化流程。而「直接丢给 AI 生成」跳过了步骤 2–9，只保留了「读 PRD」和「输出用例」，中间的拆解、选择、展开全部缺失，所以效果不稳定。

二、直接扔 PRD 跳过了什么？

被跳过的环节 后果
功能模块拆分 AI 面对整篇 PRD，难以聚焦，易漏关键模块
功能点列出 无明确输入，生成粒度不可控
测试维度选择 默认生成，易偏正常流程，漏异常、边界、权限、状态流转
人工确认 无干预节点，错误直接进入输出

结论：测试用例本质是结构化推理结果，而不是文本续写。大模型擅长文本生成，但若不给出结构约束，就会省略步骤、忽略维度、自动补充未定义逻辑。

三、AI 可行的核心：流程拆解 + 分阶段生成

真正可落地的方式是：把测试工程师的思考流程，拆成多个 AI 子任务，而不是一次生成。

错误方式：PRD → 直接生成完整用例

正确方式：PRD → 模块拆分 → 功能点提取 → 测试维度展开 → 用例生成 → 去重 → 输出

流程化的本质是：把「隐性测试思维」变成「显性生成步骤」。

四、完整流程化设计方案

4.1 第一阶段：PRD 结构化处理

目标：把「长文档」转化为「可拆分模块」，构建测试输入结构。

步骤 说明
按一级标题切分 避免 token 超限，保证语义完整
按功能点拆分 每个模块对应一组可测功能点
抽取核心业务流程 主流程、分支、异常路径
抽取输入输出字段 参数、约束、边界
抽取状态流转 状态机、状态变更条件

输出：结构化模块列表，例如：

模块 A：
  - 功能点 1
  - 功能点 2
  - 状态流转

模块 B：
  - 功能点 3

本阶段不生成用例，只构建后续生成的输入结构。

4.2 第二阶段：功能点识别

目标：让 AI 只做一件事——列出当前模块的所有功能点，禁止生成测试用例。

目的 说明
避免过早生成 输入未结构化时生成，质量不可控
降低幻觉 任务单一，输出更聚焦
逻辑更清晰 功能点列表可供人确认、增删

人工干预节点：功能点列表生成后，允许人工确认、增删、合并，锁定后再进入下一阶段。

4.3 第三阶段：测试维度展开（体现测试方法论）

目标：对每个功能点，按测试方法论展开测试场景。这是体现测试思维的关键环节。

测试维度 说明
正常流程 主流程、典型路径
异常流程 异常输入、异常分支、错误处理
边界值 等价类边界、临界值
数据合法性 格式、类型、长度、空值
权限控制 角色、越权、未登录
状态流转 状态机、前置状态、后置状态
并发场景 如适用：并发请求、竞态条件

Prompt 结构示例：

针对以下功能点：[功能点描述]

请从以下维度展开测试场景：
- 正常流程
- 异常流程
- 边界条件
- 权限控制
- 状态流转（如适用）

这样生成是「有框架的」，不会随机发散。

人工干预节点：测试维度展开后，允许人工补充维度、调整优先级策略。

4.4 第四阶段：用例结构化输出

目标：在所有测试场景生成完成后，再进行格式化输出。

字段 说明
模块 所属模块
功能点 所属功能点
前置条件 执行前状态
操作步骤 可执行、可验证
预期结果 具体、可判断
优先级 P0 / P1 / P2

原则：避免在第一阶段就输出完整表格，否则容易结构混乱。先完成场景展开，再统一格式化。

五、为什么必须流程化？

因为测试用例本质是结构化推理结果，而不是文本续写。

若不给结构约束 大模型会
省略步骤 步骤不完整，无法执行
忽略维度 只生成正常流程，漏异常、边界、权限
自动补充 编造 PRD 中未定义的逻辑，产生幻觉

流程化的本质是：把「隐性测试思维」变成「显性生成步骤」，让 AI 按步骤执行，而非自由发挥。

六、工程化落地的关键点

6.1 分模块生成

避免整篇 PRD 一次性输入。按模块逐个处理，优点：可控、可追踪、易优化。

6.2 强制分阶段

错误 正确
PRD → 直接生成完整用例 PRD → 模块拆分 → 功能点提取 → 测试维度展开 → 用例生成 → 去重 → 输出

6.3 增加人工干预节点

节点 说明
功能点列表生成后 允许人工确认、增删、锁定
测试维度展开后 允许补充维度、调整策略
最终生成前 允许指定优先级策略、排除范围
生成后 审核、修改、驳回重生成，通过后才入库

人工干预让工具更「可信」，避免未审核用例直接进入用例库。

七、AI 在测试流程中的定位

AI 适合做 AI 不适合做
结构展开 业务合理性判断
场景补全 风险评估
边界枚举 测试策略制定
重复劳动 最终质量把关

正确模式：人制定测试策略，AI 执行结构展开。AI 的价值不在于替代测试工程师，而在于放大测试方法论。

八、总结：如何体现「你理解测试流程」

若这篇文章用于展示能力，核心体现点应是：

体现点 说明
测试流程不是一次生成 知道人工编写用例是多环节的结构化流程
测试方法论 知道边界值、异常、权限、状态流转等维度
流程拆解能力 知道如何把测试思维拆解成可执行流程
避免 AI 幻觉 知道分阶段、小任务、结构约束的作用
工程化思维 知道人工干预节点、分模块、可追溯的重要性

AI 生成测试用例是否可行，不取决于模型能力，而取决于流程设计。

  • 把 PRD 丢给 AI → 只是玩具
  • 将测试工程师的思维流程结构化 → 分阶段 → 可控生成 → 才是工程化工具

延伸阅读