把 PRD 扔给 AI 直接生成用例，往往效果不可控（详见 AI 生成测试用例工具设计）。那篇讲的是流程与阶段——如何把测试思维拆解成可执行流程；本文讲的是Prompt 怎么写——在既定流程下，如何设计 Prompt 结构、Few-Shot、变量与工程化，让模型稳定输出。

全文分为设计（一至四：原则、结构、多 Prompt 流程、Few-Shot、变量）与实现（五：可直接套用的模板、调用链、实践建议）两部分，避免举例与工程化混在一起导致结构混乱。

一、核心原则：不要让 AI「猜」，而要「引导」

测试用例生成不是问答任务，而是：

结构化任务 + 规则约束任务 + 思维引导任务

因此 Prompt 必须具备三层结构：

① 角色与任务定义
② 规则与输出格式约束
③ 输入内容（需求）

而不是简单一句「请根据以下需求生成测试用例」。

设计要点：测试用例本质是结构化推理结果，而不是文本续写。大模型擅长文本生成，但若不给出结构约束，就会省略步骤、忽略维度、自动补充未定义逻辑。当 Prompt 结构足够严谨时，模型输出才会稳定、可控、可工程化。

二、Prompt 结构设计

2.1 整体架构：System Prompt 与 User Prompt 分层

测试用例生成不是「一次调用搞定」，而是由 System Prompt 和 User Prompt 协同完成：

层级 职责 特点
System Prompt 定义角色、输出格式、通用规则、思维步骤 相对固定，可复用
User Prompt 注入需求文档、数量要求、用户偏好 每次请求动态变化 
┌─────────────────────────────────────────────────────────────┐
│  System Prompt（系统提示词）                                   │
│  - 角色定义：你是测试用例生成专家                               │
│  - 输出格式：JSON 结构、字段说明                                │
│  - 通用规则：拆分原则、禁止项、五步执行流程                       │
└─────────────────────────────────────────────────────────────┘
                              +
┌─────────────────────────────────────────────────────────────┐
│  User Prompt（用户提示词）                                     │
│  - 需求文档内容                                                │
│  - 用例数量/估算要求                                           │
│  - 用户额外要求（可选）                                         │
└─────────────────────────────────────────────────────────────┘

设计要点：System Prompt 承载「方法论」，User Prompt 承载「本次任务」。这样既便于维护，也便于做 A/B 测试和版本管理。

2.2 五模块结构（单层 Prompt 场景）

若暂不区分 System/User，一个完整的 Prompt 通常包含五个模块：

模块 作用 示例
角色定义 明确模型身份，约束输出风格 你是一名具有 5 年经验的测试工程师，擅长边界值、异常流、等价类划分
任务定义 说明要做什么、覆盖哪些维度 根据需求输出结构化测试用例，覆盖正常、异常、边界、参数校验
输出格式 明确表格/JSON 结构、字段 用例编号、用例标题、前置条件、操作步骤、预期结果、优先级
思维约束 引导推理步骤，避免跳步 先识别功能点，再拆分测试点，最后生成用例
输入需求 PRD 或需求描述 ⚠️ 需求放在最后，不要放最前面

2.3 五步执行流程（提升覆盖率）

让模型按固定步骤思考，可显著提升输出稳定性和覆盖率：

步骤1：功能点分析 → 全面识别所有功能点（主功能、子功能、UI、异常、边界）
步骤2：状态分析   → 为每个功能点列出可能状态（无数据/有数据、未添加/已添加等）
步骤3：场景分析   → 为每个状态列出场景类型（正常、异常、边界、UI、数据验证）
步骤4：用例数量估算 → 按状态×场景估算用例数量
步骤5：用例生成   → 基于分析结果生成独立用例

为什么要显式写步骤？ 大模型容易「跳步」或只做表面分析。把步骤写进 Prompt，相当于强制模型先做需求分析，再生成用例，减少遗漏。

2.4 六维度覆盖要求

在用例生成步骤中，需明确「从哪些维度」生成，避免只写主流程：

维度 说明 示例
功能点 主功能、子功能、UI 交互、数据操作、业务流程、异常、边界 登录、搜索、邀请、详情页
状态 同一功能的不同状态必须拆成独立用例 无亲友 / 有亲友 / ≥5 个亲友
场景类型 正常、异常、边界、UI、数据验证 正常搜索 / 搜索异常 / 网络异常 / 次数超限
边界条件 数量、时间、状态边界 ≥5 个、超过 30 分钟、24 小时内 10 次
拆分原则 宁可多生成，不要合并相似场景 不同状态 → 不同用例
数量要求 按模块复杂度给出下限 简单 3–5 个，中等 8–15 个，复杂 15–30 个

关键约束：在 Prompt 中反复强调「禁止合并」，并给出 ✅ 正确 / ❌ 错误示例，能有效抑制模型的「偷懒」倾向。

2.5 按测试流程拆分多个 Prompt

上文讲的是「单次调用」下的 Prompt 结构。若要真正对齐测试流程，应按阶段拆分多个 Prompt，每个阶段只做一件事，前一阶段的输出作为下一阶段的输入。

核心原则：一个阶段 = 一个（或一组）Prompt，避免「一次生成全部」。

流程与 Prompt 对应关系

PRD 文档
    ↓
┌─────────────────────────────────────────────────────────────────┐
│ Prompt 1：模块拆分                                                │
│ 输入：PRD 全文或按标题切分后的片段                                  │
│ 输出：模块列表 + 每个模块下的功能点/状态流转摘要                      │
│ 禁止：生成测试用例                                                 │
└─────────────────────────────────────────────────────────────────┘
    ↓ 结构化模块列表
┌─────────────────────────────────────────────────────────────────┐
│ Prompt 2：功能点识别                                              │
│ 输入：单个模块内容（来自 Prompt 1 的输出）                           │
│ 输出：该模块下的功能点列表（可人工确认、增删）                        │
│ 禁止：生成测试用例                                                 │
└─────────────────────────────────────────────────────────────────┘
    ↓ 功能点列表
┌─────────────────────────────────────────────────────────────────┐
│ Prompt 3：测试维度展开                                            │
│ 输入：单个功能点描述                                               │
│ 输出：该功能点下的测试场景列表（正常/异常/边界/权限/状态流转等）        │
│ 禁止：输出完整用例表格，只输出场景描述                               │
└─────────────────────────────────────────────────────────────────┘
    ↓ 测试场景列表
┌─────────────────────────────────────────────────────────────────┐
│ Prompt 4：用例结构化输出                                          │
│ 输入：模块 + 功能点 + 测试场景列表                                  │
│ 输出：符合 JSON/表格格式的完整测试用例                               │
└─────────────────────────────────────────────────────────────────┘
    ↓
最终用例集（可去重、人工审核）

各阶段 Prompt 设计要点

阶段 核心任务 输入 输出 关键约束
Prompt 1 模块拆分 PRD 全文或切分片段 模块列表 + 功能点摘要 不生成用例
Prompt 2 功能点识别 单模块内容 功能点列表 不生成用例，任务单一
Prompt 3 测试维度展开 单功能点 场景列表（正常/异常/边界等） 只列场景，不写步骤
Prompt 4 用例输出 模块 + 功能点 + 场景 JSON 格式用例 格式严格，步骤可执行

完整 Prompt 模板与工程化实现见第五部分。

三、Few-Shot 示例设计

3.1 为什么需要 Few-Shot

  • 纯文字规则容易被忽略，示例更直观
  • 示例能统一「拆分粒度」和「详细程度」
  • 示例可以示范 JSON/表格结构，减少格式错误
  • 示例不是为了「给答案参考」，而是给「思考路径参考」

3.2 示例类型与作用

示例类型 目的 要点
状态拆分 教会「不同状态 → 不同用例」 无亲友 / 有亲友 / ≥5 个 → 3 个独立用例
场景拆分 教会「不同场景 → 不同用例」 正常 / 异常 / 边界 → 多个独立用例
边界条件 教会边界用例要单独写 30 分钟失效、10 次搜索限制
详细程度 教会步骤和预期结果的粒度 多步骤、含 UI 文案、含 toast 提示
状态+场景组合 教会复杂组合的拆分 48 小时内有更新 / 超过 48 小时未更新

3.3 错误示例 vs 正确示例

❌ 错误示例：只给一个普通用例样本

示例：登录成功场景……

问题：没有体现拆解逻辑，没有体现方法论。

✅ 正确示例结构：包含需求 + 功能点拆解 + 对应测试用例输出

示例需求：用户可通过手机号注册。

功能点拆解：
1. 手机号输入
2. 验证码获取
3. 注册按钮点击

测试用例输出：
| 用例编号 | 用例标题 | 前置条件 | 操作步骤 | 预期结果 | 优先级 |
| TC-001 | 手机号+验证码正常登录 | 验证码有效 | 输入手机号、验证码、点击登录 | 登录成功 | P0 |
| TC-002 | 连续错误5次锁定 | 无 | 连续5次错误密码 | 锁定30分钟 | P0 |

3.4 Few-Shot 示例模板（表格形式）

输入示例：

需求：用户登录功能，支持手机号+验证码、账号+密码两种方式，连续错误 5 次锁定 30 分钟。

输出示例：

用例编号 用例标题 前置条件 操作步骤 预期结果 优先级
TC-LOGIN-001 手机号+验证码正常登录 用户已注册、验证码有效 输入手机号、获取并输入验证码、点击登录 登录成功，跳转首页 P0
TC-LOGIN-002 账号+密码正常登录 用户已注册、密码正确 输入账号、密码、点击登录 登录成功，跳转首页 P0
TC-LOGIN-003 验证码错误 用户已获取验证码 输入错误验证码、点击登录 提示验证码错误，不锁定 P1
TC-LOGIN-004 连续错误 5 次锁定 无 连续 5 次输入错误密码 账号锁定 30 分钟，提示剩余时间 P0
TC-LOGIN-005 手机号为空 无 不输入手机号、点击获取验证码 提示请输入手机号 P2

3.5 Few-Shot 示例（JSON 形式）

每个 Few-Shot 示例建议包含：完整 JSON + 简短说明（该示例在教什么）+ 正反对比（必要时）：

// 示例：状态拆分（无亲友 / 有亲友 → 2 个独立用例，不要合并）
{
  "test_cases": [
    {
      "module": ["我的页"],
      "name": "我的页-无亲友时默认展示校验",
      "priority": "P2",
      "precondition": "无亲友",
      "steps": [{"step": "进入「我的」", "expected_result": "无头像列表，卡片布局及文案展示与 UI 设计一致"}]
    },
    {
      "module": ["我的页"],
      "name": "我的页-有亲友时默认展示校验",
      "priority": "P2",
      "precondition": "已添加≥1个亲友并共享",
      "steps": [{"step": "进入「我的」", "expected_result": "横向展示≥1个亲友头像"}]
    }
  ]
}

注意：示例中的 { 在模板里需写成 {{，避免与 Python 的 str.format() 占位符冲突。

3.6 多示例组合策略

  • 1-Shot：格式简单、场景单一时可只用 1 个示例
  • 2-Shot：一个正常场景 + 一个异常/边界场景，覆盖更全面
  • 3-Shot：不同功能类型（登录、列表、支付）各一例，适用于通用生成器
  • 求精不求多：每类示例 1～2 个高质量样本即可，过多会占用 Token

四、变量与占位符

4.1 变量清单

单流程模式

  • requirement_doc — 需求文档全文
  • limit_text — 用例数量要求或估算说明

多流程模式（各阶段变量）

  • prd_content — Prompt 1 输入，PRD 全文或切分片段
  • module_content — Prompt 2 输入，来自 Prompt 1 的模块内容
  • function_point — Prompt 3 输入，来自 Prompt 2 的功能点
  • module、function_point、scenarios — Prompt 4 输入，来自前序阶段

可选变量（按需注入）

  • user_requirement — 用户额外要求（如「重点覆盖异常场景」）
  • module — 指定功能模块（订单管理、用户中心）
  • test_type — 测试类型（功能/接口/UI/兼容性）
  • output_format — 输出格式（表格/JSON/XMind）
  • role — 测试角色类型（功能测试工程师、接口测试工程师）
  • test_method — 使用的测试方法（等价类划分、边界值分析）
  • domain — 业务领域（电商、金融、教育）

4.2 占位符格式

建议使用双花括号 {{variable_name}}，便于与自然语言区分、在代码中做字符串替换、支持模板引擎（Mustache、Jinja2）：

{{requirement_doc}}   # 需求文档（长文本）
{{limit_text}}       # 数量/估算要求
{{user_requirement}} # 用户额外要求
{{module}}           # 功能模块
{{test_type}}        # 测试类型
{{output_format}}    # 输出格式
{{domain}}           # 业务领域

4.3 limit_text 的动态生成

limit_text 不宜写死，建议根据文档动态计算：

# 基于文档长度粗略估算
estimated_cases = max(30, len(requirement_doc) // 400)

# 基于功能点关键词数量调整
functional_keywords = ['按钮', '点击', '输入', '选择', '提交', '跳转', '显示', '验证', '校验', '状态', '场景']
keyword_count = sum(len(re.findall(kw, requirement_doc)) for kw in functional_keywords)
if keyword_count > 0:
    estimated_cases = max(estimated_cases, keyword_count // 5)

limit_text = f"""请生成至少 {estimated_cases} 个测试用例，确保全面覆盖文档中的所有功能点、状态、场景和边界条件。
⚠️ 如果生成的用例数量少于 {estimated_cases} 个，说明拆分不够细，需要重新生成。"""

4.4 用户要求的注入

当用户有额外要求时（如「重点异常场景」「尽可能详细」），可追加到 limit_text 或单独变量：

**用户特殊要求**：
{user_requirement}

**重要**：请在生成测试用例时，充分考虑并满足用户的上述要求。

4.5 变量注入示例

单流程：一次调用，注入 requirement_doc、limit_text。

多流程：各阶段分别注入，前一阶段解析结果作为下一阶段输入。例如 Prompt 4：

# Prompt 4 的输入来自前序阶段
prompt_4_input = {
    "module": module_from_prompt1,
    "function_point": fp_from_prompt2,
    "scenarios": scenarios_from_prompt3
}

五、工程化实践

前文讲设计思路（结构、流程、Few-Shot、变量），本节讲实现：完整 Prompt 模板、调用链、人工干预与错误处理。

5.1 两种模式的选择

模式 适用场景 特点
多流程（4 个 Prompt） 复杂 PRD、需人工确认、追求覆盖度 分阶段、可干预、输出更可控
单流程（1 个 Prompt） 简单需求、快速原型、一次性生成 实现简单，但覆盖度和可控性较弱

工程化落地时，建议以多流程为默认方案，单流程仅用于需求极简或 PoC 验证。

5.2 多流程：完整 Prompt 模板

5.2.1 各阶段输出格式统一

每个阶段的 Prompt 都需明确输出格式，便于解析和传递：

阶段 输出 JSON 结构 用途
Prompt 1 {"modules": [{"name", "summary", "function_points", "state_flow"}]} 作为 Prompt 2 的输入
Prompt 2 {"function_points": ["功能点1", "功能点2"]} 作为 Prompt 3 的输入
Prompt 3 {"scenarios": [{"title", "description"}]} 作为 Prompt 4 的输入
Prompt 4 {"test_cases": [{"module", "name", "priority", "precondition", "steps"}]} 最终用例，可入库

5.2.2 调用链与变量传递

prd_content
    → Prompt 1 → modules (JSON)
    → 遍历 modules，每模块 → Prompt 2 → function_points (JSON)
    → 遍历 function_points，每功能点 → Prompt 3 → scenarios (JSON)
    → 汇总 module + function_point + scenarios → Prompt 4 → test_cases (JSON)
    → 合并、去重、人工审核

变量传递：前一阶段的解析结果，通过变量注入下一阶段的 User Prompt。例如 Prompt 4 的输入 = module（来自 Prompt 1）+ function_point（来自 Prompt 2）+ scenarios（来自 Prompt 3）。

5.2.3 System / User 分离（多流程）

每个阶段可共用一套 System Prompt（角色、通用规则），User Prompt 按阶段变化：

阶段 System Prompt User Prompt 变量
Prompt 1 需求分析专家角色、输出 JSON 规则 prd_content
Prompt 2 功能点识别专家角色、禁止生成用例 module_content
Prompt 3 测试设计专家角色、维度约束 function_point
Prompt 4 用例编写专家角色、JSON 格式约束 module、function_point、scenarios

5.2.4 人工干预与错误处理

  • 干预节点：Prompt 2 后（确认功能点）、Prompt 3 后（确认场景）可暂停，等待人工确认
  • 解析失败：每阶段解析 JSON 失败时，可重试或降级（如跳过该模块、记录日志）
  • Token 超限：PRD 过长时，Prompt 1 按一级标题切分后分批调用

5.2.5 完整模板示例

以下模板可直接套用，变量按第四部分注入。

Prompt 1：模块拆分

你是测试需求分析专家。任务：从 PRD 中识别可测试模块，不生成测试用例。
请按一级标题或功能块拆分，输出如下 JSON：
{"modules": [{"name": "模块名", "summary": "功能简述", "function_points": ["功能点1", "功能点2"], "state_flow": "如有状态流转，简要描述"}]}

PRD 内容：{{prd_content}}

Prompt 2：功能点识别

你是测试需求分析专家。任务：列出当前模块的所有可测功能点，不生成测试用例。
请只输出 JSON 数组：{"function_points": ["功能点1", "功能点2"]}。禁止输出用例、步骤、预期结果。

模块内容：{{module_content}}

Prompt 3：测试维度展开

你是测试设计专家。任务：针对以下功能点，按测试维度展开测试场景。
维度：正常流程、异常流程、边界条件、数据校验、权限控制、状态流转（如适用）。
请只输出：{"scenarios": [{"title": "场景标题", "description": "简要说明"}]}。不输出操作步骤和预期结果。

功能点：{{function_point}}

Prompt 4：用例结构化输出

你是测试用例编写专家。任务：将以下测试场景转化为结构化测试用例。
输出 JSON：{"test_cases": [{"module": ["模块"], "name": "用例标题", "priority": "P1/P2/P3", "precondition": "前置条件", "steps": [{"step": "步骤", "expected_result": "预期结果"}]}]}

模块：{{module}}
功能点：{{function_point}}
测试场景：{{scenarios}}

只输出 JSON，不要其他文字。

5.3 单流程模板（简化场景）

需求极简或快速验证时，可用单次调用。结构上仍需遵循前文五模块，否则易退化为「直接扔 PRD」：

【角色】你是一名资深测试工程师，擅长边界值、异常流、等价类划分。

【任务】根据以下需求生成测试用例，输出 JSON 格式。

【思维约束】按五步执行：①功能点分析 ②状态分析 ③场景分析 ④用例数量估算 ⑤用例生成。禁止合并不同状态/场景为同一用例。

【覆盖维度】功能点、状态、场景类型（正常/异常/边界/UI/数据验证）、边界条件。宁可多生成，不要合并相似场景。

【输出格式】
{
  "test_cases": [
    {
      "module": ["模块名"],
      "name": "用例标题",
      "priority": "P1/P2/P3",
      "precondition": "前置条件",
      "steps": [{"step": "步骤", "expected_result": "预期结果"}]
    }
  ]
}

【需求】
{{requirement_doc}}
{{limit_text}}

只输出 JSON，不要其他文字。

单流程本质是「把多流程的 4 次调用合并为 1 次」，覆盖度和可控性会弱于多流程，仅适合 PoC 或极简需求。

5.5 实践建议

建议 说明
默认多流程 复杂 PRD 用 4 阶段拆分，单流程仅作补充
各阶段输出格式统一 每阶段明确 JSON Schema，便于解析和传递
变量可配置 prd_content、module_content 等从配置或数据库读取，支持断点续跑
人工干预可配置 是否在 Prompt 2/3 后暂停，可由配置开关控制
容错解析 对尾随逗号、markdown 代码块包裹等做容错，避免解析失败导致流程中断

六、为什么结构化 Prompt 才是可落地方案？

很多 AI 生成用例项目失败的根本原因是：

  • 没有拆解测试思维
  • 没有输出规范
  • 没有工程化参数
  • 没有 Few-Shot 引导

真正可落地的 AI 用例生成体系必须具备：

  1. 流程拆解：按测试流程拆分多个 Prompt，前一阶段输出作为下一阶段输入
  2. 测试方法嵌入：把等价类、边界值、状态流转等写进 Prompt
  3. 输出标准化：各阶段固定 JSON 结构，便于解析、传递和入库
  4. 可复用模板：通过变量支持不同项目、不同阶段
  5. 参数化与人工干预：变量可配置，关键节点可暂停等待确认

这本质上不是 Prompt 技巧问题，而是：是否理解测试流程，并把它转化为结构化语言约束。AI 不是替代测试设计能力，而是放大测试设计能力。

七、小结

测试用例生成 Prompt 的完整设计可以概括为：

要素 要点
核心原则 不要让 AI 猜，而要引导；结构化 + 规则约束 + 思维引导
结构 System + User 分层；五模块（角色、任务、格式、思维、输入）；五步法 + 六维度
多 Prompt 流程 按测试流程拆分 4 个 Prompt：模块拆分 → 功能点识别 → 测试维度展开 → 用例输出；前一阶段输出作为下一阶段输入
Few-Shot 状态、场景、边界、详细程度、组合，每类 1–2 个示例；示范思考路径
变量 requirement_doc、limit_text、user_requirement 等，支持动态注入；limit_text 可动态生成
工程化 多流程为主、各阶段输出格式统一、调用链与变量传递、人工干预可配置

按上述方式设计，可以在保证输出格式稳定的前提下，提升用例的覆盖度和可执行性，为 AI 测试工具真正落地打下基础。

延伸阅读