---
name: testcase-generator
description: 业务流程导向的测试用例生成器。只有在接收到PRD文档、MD文档、TXT文档、Word文档时，执行 /testcase-generator 才调用此技能进行测试用例设计生成。当用户需要评审已有用例、编写测试方案、设计测试场景、规划测试策略、评估测试覆盖率时也调用此技能。当用户提到测试用例、测试方案、测试计划、测试场景、测试覆盖、用例评审、怎么测、如何验证、测试设计、质量保障、冒烟测试、回归测试等任何与测试用例设计相关的话题时调用。
---

# 业务流程导向的测试用例生成器 (testcase-generator)

## 1. 目标

从需求文档中识别业务功能流程，按照业务流程顺序设计可执行的测试用例。生成的用例必须符合质量评估标准，保证易执行性。

## 2. 执行步骤（按顺序执行）

> **重要**：本技能触发后，模型应首先读取 `references/prompts.md` 作为执行提示词模板，按照其中的角色定义、思考链（CoT）、用例结构、Few-Shot 示例和用例评审报告模板来生成测试用例。触发本技能后，请按以下7个阶段执行（阶段1→阶段7）。**请严格按顺序执行，任何阶段都不允许跳过，包括阶段4的模块评审报告和阶段7的用例评审报告，并生成所有必要的报告文件**。

### Multi-Agent 串行Pipeline架构

本技能采用 Multi-Agent 串行Pipeline架构，将测试用例生成流程拆分为4个独立子Agent串行执行：

| 子Agent        | 职责                      | 所属阶段     |
| ------------- | ----------------------- | -------- |
| **需求分析Agent** | 读取需求文档，识别功能模块、业务流程、约束条件 | 阶段3：需求解析 |
| **模块评审Agent** | 评审模块生成结果，输出评审结论         | 阶段4：模块评审 |
| **用例生成Agent** | 基于测试点生成具体测试用例           | 阶段6：用例生成 |
| **用例评审Agent** | 执行用例评审，输出评审报告           | 阶段7：用例评审 |

**阶段与Agent映射**：

```
阶段3：需求解析      → 需求分析Agent
阶段4：模块评审      → 模块评审Agent
阶段5：测试策略      → （无独立Agent，整合在需求解析中）
阶段6：用例生成      → 用例生成Agent
阶段7：用例评审      → 用例评审Agent
```

### 执行流程（必须按顺序）

```
┌─────────────────────────────────────────────────────────────────────────────┐
│                           testcase-generator 执行流程                        │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  阶段1    阶段2    阶段3       阶段4       阶段5    阶段6       阶段7        │
│  ────    ────    ─────       ─────       ────    ────       ────        │
│   ↓       ↓       ↓           ↓           ↓       ↓           ↓          │
│  评估   输入确认   需求解析   模块评审   测试策略   用例生成   用例评审       │
│  方法   模式识别    ↓          ↓           ↓        ↓          ↓         │
│  依据        ↓      └─────→ 评审通过 →    └─────→  生成用例 → 评审          │
│                    不通过                                              ↓          │
│                     └─────────── 重新生成 ←─────────────────────────┘          │
│                                                                             │
├─────────────────────────────────────────────────────────────────────────────┤
│  评审结果:                                                                 │
│  ┌──────────────┐      ┌──────────────┐                                   │
│  │   评审合格    │      │   评审不合格  │                                   │
│  ├──────────────┤      ├──────────────┤                                   │
│  │ 执行脚本导出  │      │ 返回阶段6    │                                   │
│  │ (validate/   │      │ 重新生成     │                                   │
│  │  excel/     │      │ 循环评审直到   │                                   │
│  │  xmind)     │      │ 通过          │                                   │
│  └──────────────┘      └──────────────┘                                   │
└─────────────────────────────────────────────────────────────────────────────┘
```

### 执行纪律（强制约束）

> 执行原则 ：完整的分析流程有助于确保测试用例的质量和覆盖率，建议按顺序执行7个阶段，避免跳过任何步骤。
>
> - 即使需求简单，也要走完所有分析过程
> - 建议输出每个阶段的分析论述和结论，这有助于追踪决策过程并确保逻辑完整性
> - 推荐避免"直接给结果"式跳过分析，因为详细分析能发现潜在的边界场景
> - 建议不用占位符替代分析过程，具体的分析内容能提升用例的可执行性
>
> **违规判定**：以下情况视为不合格，需要重新生成：
>
> - 缺少阶段1评估方法依据直接跳到用例生成
> - 缺少阶段3功能点分析直接跳到用例生成
> - 用"根据需求分析"替代具体分析论述
> - 用"经评估"替代数量评估过程

### 阶段1：评估方法依据（标准化引用）

> **理论依据**：测试用例数量评估基于\*\*测试点分析（TPA）**和**功能点分析（FPA）\*\*相结合的综合评估方法。需要理解设计方法原理时，读取 `references/theory.md` 中对应章节，并理解设计方法原理。

**标准引用**：

- **ISO/IEC 29119**：国际软件测试标准，提供测试设计方法指导
- **ISO/IEC 20926**：功能点分析法（Function Point Analysis）标准，用于软件规模度量
- **测试点分析法（TPA）**：行业实践方法，基于功能复杂度和风险评估测试工作量

**评估方法论**：

1. **需求分解与测试点识别** - 将需求按业务域分解为功能模块，提取具体测试点
2. **场景覆盖分析** - 正向/边界/异常/反向场景全覆盖
3. **测试设计技术应用** - 等价类划分、边界值分析、场景法、判定表法、状态迁移法
4. **优先级与风险评估** - P0-P3级划分，风险分析，置信度计算

> **重要**：测试用例数量根据功能复杂度和约束条件客观分析，不人为限制。FPA用于软件规模度量，不用于预估测试用例数量。

#### 评估结果验证（标准化方法）

测试用例数量评估结果应通过以下方法验证其合理性：

1. **交叉验证**：使用多种测试设计方法互相验证估算结果
2. **历史数据参考**：参考类似项目的测试用例数量
3. **专家评审**：结合测试经验进行调整
4. **持续改进**：根据实际测试执行数据优化评估方法

### 阶段2：输入确认与模式识别

**生成前检查**：

- [ ] 已读取需求文档或技术方案文档
- [ ] 需求中包含至少一个可识别的功能或流程
- [ ] 已识别所有约束条件（必填/长度/范围/权限/错误码）
- [ ] 如需求完全缺失，提示用户提供

**模式识别**：

- **生成模式**：用户要求"生成测试用例"，按阶段1-7完整执行
- **评审模式**：用户要求"评审已有用例"，跳过阶段3-6，直接执行阶段7的用例评审
  （先读取需求文档→提取功能点清单→逐条对照已有用例建立需求-用例映射表→标记未覆盖/覆盖不足的需求点→计算覆盖率，再检查：优先级分布是否合理、步骤是否清晰可执行、预期是否可验证、场景是否完整覆盖正向/反向/边界、数据是否具体无占位符）
- **补充模式**：用户要求"补充测试用例"，先读取已有用例，对比需求文档识别未覆盖的场景
  （检查项：哪些流程步骤缺少用例、哪些约束条件缺少边界值、哪些异常场景未覆盖、P0+P1占比是否超标），再执行阶段1-7

### 阶段3：需求解析（必须输出完整的分析论述）

> **重要**：当前步骤应该读取`agents/01_需求分析Agent.md` 作为当前阶段工作指南。

1. **读取需求文档**：需求分析拆分/识别功能模块、业务流程步骤、状态变化、角色(终端)、约束条件
2. **提取业务流程**：找出"第一步→第二步→...→结束"的操作序列
3. **识别约束**：必填/可选、长度/格式/范围、错误码、权限规则
4. **功能点识别（必选）**：
   - 识别外部输入(EI)、外部输出(EO)、外部查询(EQ)、内部逻辑文件(ILF)、外部接口文件(EIF)
   - 计算未调整功能点(UFP)和价值调整因子(VAF)
   - 估算调整后功能点(AFP)用于软件规模度量
   - **注意**：FPA用于软件规模度量，不用于预估测试用例数量
5. **输出要求（强制）**：
   - 建议以表格形式输出功能模块清单，便于清晰展示模块结构和层级关系
   - 推荐用表格形式呈现业务流程步骤，有助于识别流程断点和异常分支
   - 建议整理约束条件清单（表格形式），确保所有边界和异常场景都被覆盖
   - 推荐输出功能点分析结果（UFP/VAF/AFP），这有助于量化需求规模并指导测试策略
   - 建议先完成功能点分析再进入用例生成，避免遗漏关键测试场景
   - 推荐提供具体的分析论述，而非使用"根据需求分析"等泛化表述，确保分析的可追溯性

> **多需求处理**：如果用户提供多个功能需求，按功能模块依赖关系排序（被依赖的功能模块优先），逐个模块执行阶段1-7。

#### 功能点分析详细说明

功能点分析（Function Point Analysis，FPA）是ISO/IEC 20926国际标准定义的软件规模度量方法。

> **重要说明**：FPA主要用于软件规模度量，不适用于准确预估测试用例数量。测试用例数量应根据实际业务需求、测试设计方法和质量要求确定。

**功能点分析流程**：

1. **识别五类组件**：
   - **EI（External Input）**：外部输入，如用户登录提交、记住密码设置
   - **EO（External Output）**：外部输出，如登录成功跳转、登录失败提示
   - **EQ（External Inquiry）**：外部查询，如用户信息查询、记住密码状态查询
   - **ILF（Internal Logical File）**：内部逻辑文件，如用户信息表、记住密码配置表
   - **EIF（External Interface File）**：外部接口文件，如用户认证接口
2. **确定复杂度**：根据数据元素类型(DET)和引用文件类型(FTR)确定简单/中等/复杂
3. **计算功能点数**：
   - 简单：EI=3, EO=4, EQ=3, ILF=7, EIF=5
   - 中等：EI=4, EO=5, EQ=4, ILF=10, EIF=7
   - 复杂：EI=6, EO=7, EQ=6, ILF=15, EIF=10
4. **计算VAF（价值调整因子）**：
   - 评估14项系统特征（数据通信、分布式处理、性能要求等）
   - VAF = 0.65 + (0.01 × 特征总分)
5. **计算AFP（调整后功能点）**：AFP = UFP × VAF

**输出示例**：

```
功能点分析结果：
- UFP（未调整功能点）：40
- VAF（价值调整因子）：1.01
- AFP（调整后功能点）：40.4 ≈ 40
- 软件规模：40功能点（用于规模度量，不直接等同于测试用例数）
```

### 阶段4：模块评审（必须输出完整评审报告）

> **重要**：当前步骤应该读取`agents/02_模块评审Agent.md` 作为当前阶段工作指南。

模块评审是需求解析的后置环节，只有评审通过才能进入用例生成阶段，确保测试点划分质量。

**模块评审流程**：

```
1. 需求分析Agent输出测试点清单
2. 模块评审Agent按4个维度进行评审
3. 评审结果：
   - 全部通过 → 进入阶段5（测试策略）
   - 任一维度不通过 → 返回阶段3（需求解析）重新生成
   - 重新生成 → 重新评审（循环直到通过）
```

**输出要求（强制）**：
- 必须输出评审结论（通过/不通过）
- 必须输出详细评审意见（表格形式）
- 必须输出修正后的测试点清单
- 必须输出评审报告（4个维度+详细评审意见）：`test-case/{需求}_功能模块_评审报告_{时间戳}.md`
- **禁止跳过评审直接进入用例生成**


### 阶段5：测试策略（必须输出完整的策略论述）

1. **选择测试类型**：默认包含功能测试，依据需求特征自动增加调整测试类型
2. **选择设计方法**：根据功能约束条件灵活选择最合适的设计方法
   - 有输入参数/取值范围 → 等价类划分 + 边界值分析
   - 有多条件组合判断 → 判定表法 + 因果图法
   - 有状态流转 → 状态迁移法
   - 有多参数组合 → 正交实验法
   - 有明确流程步骤 → 场景法
   - **不强制方法数量，以"能否有效覆盖该功能的约束条件"为唯一标准**
3. **场景映射**：将约束映射到正向/反向/边界/异常场景
4. **输出要求（强制）**：
   - 必须输出测试类型选择依据
   - 必须输出设计方法与约束条件对应关系
   - 必须输出测试策略（类型+方法+场景清单）
   - **禁止跳过策略分析直接生成用例**
   - **禁止用"根据情况选择"替代具体方法论述**

> 需要理解设计方法原理时，读取 `references/theory.md` 中对应章节，并理解设计方法原理。

### 阶段6：用例生成（必须输出数量评估）

> **重要**：当前步骤应该读取`agents/03_用例生成Agent.md` 作为当前阶段工作指南。需要理解设计方法原理时，读取 `references/theory.md` 中对应章节，并理解设计方法原理。

对每个功能模块的业务流程步骤，按以下顺序生成用例：

1. 正向场景（Happy Path）→ P0或P1
2. 边界值（min-1/min/max+1）→ P2
3. 异常场景（需求明确提及的异常分支）→ P2
4. 反向场景（需求明确提及的反向流程）→ P2或P3
5. **合并去重**：如果两条用例验证的是同一个业务规则且预期结果相同，合并为一条

**用例数量原则**：

- 功能模块、测试点、用例数都应按需求实际情况**客观分析**，实事求是
- 需求中有多少个功能模块，客观分析每个模块的业务流程步骤，确定每个模块的测试点
- 依据测试理论设计方法分析需要覆盖测试点哪些场景，就生成多少用例
- **不按需求的复杂性限制用例数量**，避免过度测试或测试不足

**输出要求（强制）**：

1. **必须输出用例数量评估表**：
   - 格式：| 功能模块 | 测试点 | 正向 | 边界 | 异常 | 总计 |
   - 说明每个测试点预计生成多少用例
2. **用例格式**（每条必须包含）：
   ```markdown
   ## [P1] 用例标题
   [测试类型] 功能
   [前置条件] 前置条件描述
   [测试步骤] 1. 步骤1。2. 步骤2。3. 步骤3
   [预期结果] 1. 预期1。2. 预期2。3. 预期3
   ```
3. **标题建议**：
   - **长度**：推荐15-30字，避免过短（<10字）的标题，因为详细的标题能更清晰地表达测试场景
   - **结构**：
     - 正向场景：`[角色] + 操作动作 + 成功结果`
     - 反向场景：`[反向] + 错误条件 + 失败结果`
     - 边界场景：`操作对象 + 边界值描述 + 验证点`
   - **避免**：
     - ❌ 建议标题避免以"控制"、"操作"、"测试"、"验证"、"功能"等泛化词结尾，使用更具体的动作和结果描述
     - ❌ 推荐标题长度不低于15字，确保包含足够的场景信息
     - ❌ 建议标题避免使用"功能正常"、"正常工作"等模糊描述，使用具体可验证的结果
     - ❌ 推荐不用`{username}`等占位符，使用具体的测试数据，提升用例的可执行性

> 详细规范请参考：`references/format-standard.md 第5节`

1. **最终输出**：

- 直接输出 Markdown 文本，**不要**包裹在代码块中
- 字段之间不要有空行
- 每个用例以 `## [P` 开头，以 `[预期结果]` 结尾

**停止条件**（满足以下任一条件即停止当前功能用例生成，进入阶段7）：

- 所有流程步骤都已覆盖至少1条正向用例（必选项，必须满足）
- 已覆盖所有设计方法要求的用例场景（正向+边界+异常）

> **注意**：用例数量应按实际需求分析，不人为限制。P0+P1 占比超标的问题留到阶段7通过降级处理解决。

### 阶段7：优先级校验与用例评审（必须输出完整评审报告）

> **重要**：当前步骤应该读取`agents/04_用例评审Agent.md` 作为当前阶段工作指南。

**优先级校验**（检查阶段6已标记的优先级是否合理）：

1. **统计分布**：计算当前 P0/P1/P2/P3 占比
2. **超标检查**：若 P0+P1>40%，逐条审查高优先级用例，将非核心流程降级为P2
3. **缺失检查**：若 P2<25%，检查是否有边界值/异常流用例被误标为P1，纠正为P2
4. **P0审查**：从P0中剔除"fail不会阻碍其他用例验证"的项，降级为P1

> 阶段6生成用例时已标记初始优先级，本阶段仅做校验和微调，不重新划分。

详细规则请参考：`references/theory.md 第13章`

**用例评审 - 引导错误过滤机制**：

用例评审必须执行**强制过滤检查**，以下任何一项存在则判定为**不合格**，需要重新生成：

| 引导错误          | 定义                                            | 检查方法          | 判定结果         |
| ------------- | --------------------------------------------- | ------------- | ------------ |
| **数据占位符**     | 使用 `{username}`、`{password}`、`{xxx}` 等未替换的占位符 | 搜索所有用例步骤和预期结果 | **不合格，全盘不用** |
| **预期模糊**      | 包含"功能正常"、"显示正确"、"正常工作"等无法验证的描述                | 搜索关键词         | **不合格，全盘不用** |
| **步骤不对应**     | 测试步骤数与预期结果数不匹配                                | 逐条对比序号        | **不合格，全盘不用** |
| **P0+P1>50%** | 高优先级用例占比超过50%                                 | 统计占比          | **不合格，全盘不用** |
| **标题为空/无意义**  | 用例标题为空或仅"测试"等泛化词                              | 检查标题长度和内容     | **不合格，全盘不用** |

**过滤检查流程**（必须按顺序执行）：

```
1. 检查数据占位符 → 如有则不合格，停止检查
2. 检查预期模糊 → 如有则不合格，停止检查
3. 检查步骤对应 → 如有则不合格，停止检查
4. 检查优先级分布 → 如P0+P1>50%则不合格，停止检查
5. 检查标题有效性 → 如有无意义标题则不合格
6. 以上全部通过 → 判定为合格，进入六大维度评估
```

> **重要**：引导错误过滤是**一票否决制**，只要存在任何一项引导错误，用例评审结论即为"不合格"，不需要继续六大维度评估。

**用例评审内容**（仅在过滤通过后执行）：
1. 六大维度评估（覆盖度、冗余性、清晰度、明确性、完整性、合理性）
2. 覆盖率量化（需求≥100%、类型≥2种（简单功能）或≥3种（核心/复杂）、方法按需匹配、边界100%、异常≥80%）
3. 测试用例评审要求（需求覆盖度、设计方法应用、场景完整性、可执行性、优先级合理性）
4. 待确认需求清单 + 可扩展建议
5. 输出用例评审报告（Markdown 格式，**不要**包裹在代码块中；包含：统计概览、引导错误检查结果、六大维度评估、覆盖率量化、质量评估、待确认清单、可扩展建议）：`test-case/{需求}_测试用例_评审报告_{时间戳}.md`

详细模板请参考：`references/prompts.md 第4节`

#### 用例评审判定结果

| 判定      | 结论       | 后续操作           |
| ------- | -------- | -------------- |
| **不合格** | 存在任意引导错误 | 全盘不用，返回阶段6重新生成 |
| **合格**  | 全部检查通过   | 继续执行导出脚本       |

***

## 3. 核心规则（含原因说明）

### 3.1 用例数量原则

> **关键原则**：功能模块、测试点、用例数都应按需求实际情况**客观分析**，实事求是。

- **功能模块划分**：按业务域划分，一个需求文档的模块数量根据需求复杂度和业务范围确定
- **测试点划分**：按需求中的实际子功能/操作划分，有多少写多少，不强制数量
- **用例数量**：依据需求分析后实际产生的功能模块数量及每个功能模块下的测试点数量，参考 theory.md 理论和 prompts.md 中的 Few-Shot 示例进行覆盖，**以实际产生的用例数为准**

### 3.2 功能模块与测试点划分规则

**定义**：

| 层级       | 定义               | 划分原则                   | 示例                   |
| -------- | ---------------- | ---------------------- | -------------------- |
| **功能模块** | 系统的一级功能划分，按业务域划分 | 按业务边界划分，每个模块有独立的业务职责   | 用户管理、设备绑定、空调控制       |
| **测试点**  | 功能模块下的具体测试项      | 按需求中的实际子功能/操作划分，有多少写多少 | 设备绑定 → 在线绑定、离线预绑定、解绑 |

**划分原则**：

1. **功能模块命名**：使用业务域名称，避免与测试点重叠
   - ❌ 错误：`设备绑定管理/设备绑定.md`（模块名 = 测试点）
   - ✅ 正确：`设备绑定管理/在线绑定.md`、`设备绑定管理/设备解绑.md`
2. **测试点数量**：实事求是，按需求中的子功能数量决定
   - 可能1个测试点，也可能10个，不强制数量要求
   - 关键是测试点名称不能与功能模块名称相同
3. **测试点命名**：
   - 使用具体操作/子功能名称
   - 禁止与功能模块名称重复
   - 禁止使用"功能"、"测试"等泛化词

**正确结构示例**：

```
test-case/
├── 设备绑定管理/              # 功能模块：设备生命周期管理
│   ├── 在线绑定.md           # 测试点：按需求中的"设备在线绑定"子功能
│   ├── 离线预绑定.md         # 测试点：按需求中的"设备离线预绑定"子功能
│   ├── 预绑定入网.md         # 测试点：按需求中的"预绑定入网"子功能
│   └── 设备解绑.md           # 测试点：按需求中的"设备解绑"子功能
├── PMS智能家居管理/           # 功能模块：PMS端设备管理
│   └── 智能家居列表.md       # 测试点：只有一个列表功能
```

**检验标准**：

- [ ] 功能模块名 ≠ 任何测试点名
- [ ] 测试点名称描述具体操作，不泛化
- [ ] 测试点数量按需求实际情况决定

### 3.3 优先级分布

| 级别     | 占比     | 包含内容               | 判定方法                    |
| ------ | ------ | ------------------ | ----------------------- |
| **P0** | 10-15% | 核心功能正向流程           | 该功能失效是否导致核心业务中断？是→P0    |
| **P1** | 20-30% | 基本功能 + 常见异常        | 功能可用但非核心流程？是→P1         |
| **P2** | 35-45% | 边界值 + 异常流 + 权限限制   | 是否验证约束条件的边界或违反情况？是→P2   |
| **P3** | 10-15% | UI展示 + 极端场景 + 体验优化 | 是否仅为UI展示、极端边界或体验优化？是→P3 |

**为什么这样分**：P0过多会导致测试成本过高（什么都重要=什么都不重要），P2占最大比例是因为边界和异常场景是缺陷最密集的区域。

**强制约束**：P0+P1≤40%，P2应占最大比例。

### 3.4 测试数据必须具体（引导错误过滤项）

**规则**：使用具体值（如 `admin@example.com`），**禁用占位符**（如 `{username}`）。

**为什么**：测试人员拿到用例后需要能直接执行。如果写"输入正确的用户名"，测试人员不知道该输入什么。写具体值，任何人都能直接执行，减少理解偏差。

> **引导错误**：使用 `{username}`、`{password}`、`{xxx}` 等占位符 → 判定为不合格，全盘不用

### 3.5 预期结果必须可验证（引导错误过滤项）

**规则**：预期结果需包含具体的UI变化或数据变化（如 `弹窗显示"发送成功"`），**拒绝模糊描述**（如 `功能正常`、`显示正确`）。

**为什么**：模糊的预期结果无法判断测试是否通过。"功能正常"是主观判断，"弹窗显示'发送成功'"是客观可验证的。

> **引导错误**：包含"功能正常"、"显示正确"、"正常工作"等无法验证的描述 → 判定为不合格，全盘不用

### 3.6 步骤与预期严格对应（引导错误过滤项）

**规则**：测试步骤的序号与预期结果的序号必须**一一对应**。无需检查的步骤在预期结果中填"-"。

**为什么**：步骤和预期不对应会导致测试人员不知道该在哪一步检查什么结果，降低用例可执行性。

> **引导错误**：测试步骤数与预期结果数不匹配 → 判定为不合格，全盘不用

### 3.7 不自行发散异常场景

**规则**：只覆盖需求中明确描述的异常分支和基于需求约束隐含的边界。不添加需求未提及的功能测试（如搜索、筛选、分页）。

**为什么**：自行发散会导致用例膨胀、测试成本增加，且可能测试了不需要的功能。聚焦需求明确提及的内容，效率更高。

## 4. 常见错误与修正（引导错误清单）

| 错误模式      | 表现                        | 判定         | 修正方法        |
| --------- | ------------------------- | ---------- | ----------- |
| **P0膨胀**  | P0占比>15%                  | ⚠️ 警告      | 将UI展示类降级为P3 |
| **P2缺失**  | 无P2用例或P2<25%              | ⚠️ 警告      | 补充边界值校验     |
| **预期模糊**  | "功能正常"、"显示正确"             | ❌ 引导错误，不合格 | 改为具体的UI变化描述 |
| **数据占位**  | `{username}`、`{password}` | ❌ 引导错误，不合格 | 替换为具体值      |
| **步骤不对应** | 步骤3步，预期5步                 | ❌ 引导错误，不合格 | 严格一一对应      |
| **缺少反向**  | 只有正向流程                    | ⚠️ 警告      | 补充异常场景      |
| **用例膨胀**  | 单个功能>10个用例                | ⚠️ 警告      | 合并相似场景      |

## 5. 质量检查清单

> 完整清单请参考：`references/prompts.md 质量检查清单`

### 关键检查项（生成时必须遵守）

- [ ] **P0+P1 占比不超过 40%**
- [ ] **预期结果的序号与测试步骤的序号严格一一对应**
- [ ] **覆盖正向场景、需求明确的异常场景，以及设计方法要求的边界值和反向场景**
- [ ] **测试数据具体（无占位符）** — 引导错误项
- [ ] **预期结果可验证（无"功能正常"等模糊描述）** — 引导错误项
- [ ] **UI展示类用例标记为P3**

### 重要检查项（建议遵守）

- [ ] 已识别业务功能流程步骤
- [ ] 测试用例按照业务流程步骤组织
- [ ] 每个用例都有优先级（P0-P3）和测试类型（12种之一）
- [ ] 设计方法选择与功能约束匹配
- [ ] 是否执行了优先级校验流程（统计分布→超标降级→缺失纠正→P0审查）？

## 6. 异常处理

| 错误       | 处理方式                                  | 备注                         |
| -------- | ------------------------------------- | -------------------------- |
| 完全没有需求文档 | 提示用户提供需求文档或口头描述需求                     | 可基于用户口头描述生成                |
| 无法识别业务流程 | 提示用户提供流程说明或按功能模块组织                    | 同时启动深度需求分析                 |
| 需求描述不清晰  | 基于常识推测，标记\[需确认需求]                     | 提供多种可能性用例                  |
| 需求描述过于简单 | 自动扩展测试场景，标记\[基于经验补充]                  | 运用多种设计方法深度挖掘               |
| 需求描述过于复杂 | 分模块分析，标记\[建议分阶段测试]                    | 优先核心功能                     |
| 缺少边界用例   | 警告并建议补充                               | 确保边界覆盖                     |
| 缺少异常场景   | 警告并建议补充                               | 确保异常覆盖                     |
| 用例存在冗余   | 必须执行去重检查，合并相似场景                       | 控制测试成本，保证用例质量              |
| 导出失败     | 提示用户检查openpyxl依赖，尝试sandbox沙箱安装依赖并执行脚本 | 若依赖缺失且无法安装，跳过导出并记录原因，不阻塞流程 |

### 优先级分布异常处理

| 异常情况      | 处理方式                         |
| --------- | ---------------------------- |
| P0占比>15%  | 警告：P0用例过多，请将UI展示类降级为P3       |
| P0+P1>40% | 警告：高优先级用例过多，请将边界值/异常流用例调整为P2 |
| P0+P1>50% | 严重：优先级严重失衡，必须重新审查P0/P1用例并降级  |
| P2占比<25%  | 警告：异常场景覆盖不足，请补充边界值校验、权限限制等场景 |
| 无P2用例     | 错误：必须包含边界值和异常流测试用例           |

## 7. 工具脚本

生成用例后，**必须执行**以下3个脚本验证和导出：

> **重要**：用例评审必须先于导出执行。评审通过后才能导出，评审不合格则全盘不用，返回重新生成。

| 脚本            | 作用             |
| ------------- | -------------- |
| `validate.py` | 验证格式+检测重复用例    |
| `to_excel.py` | 导出为 Excel 工作簿  |
| `to_xmind.py` | 转换为 XMind 思维导图 |

```bash
python scripts/validate.py test-case/ --check-duplicates
python scripts/to_excel.py test-case/ -o test-case/{需求}_测试用例_{LLM_NAME}_{时间}.xlsx
python scripts/to_xmind.py test-case/ -o test-case/{需求}_测试用例_{LLM_NAME}_{时间}.xmind -t "测试用例"
```

> 依赖：`to_excel.py` 需要 `openpyxl`。若脚本执行失败（如依赖缺失），跳过并记录原因，不阻塞流程。

## 8. 参考文档

| 文档                              | 用途                  |
| ------------------------------- | ------------------- |
| `references/prompts.md`         | 角色定义、CoT、Few-Shot示例 |
| `references/theory.md`          | 测试设计方法详解(14章)       |
| `references/format-standard.md` | 格式规范                |
| `agents/README.md`              | 子Agent完整说明          |

## 9. 输出产物

- `test-case/{功能模块}/{测试点}.md` - 按流程组织的测试用例
- `test-case/{需求}_功能模块_评审报告_{时间戳}.md` - 功能模块评审报告
- `test-case/{需求}_测试用例_评审报告_{时间戳}.md` - 用例评审报告
- `test-case/{需求}_测试用例_{LLM_NAME}_{时间戳}.xlsx` - Excel格式（LLM\_NAME替换为模型名称）
- `test-case/{需求}_测试用例_{LLM_NAME}_{时间戳}.xmind` - Xmind格式（LLM\_NAME替换为模型名称）

### 成功标准

- 每个功能模块及测试点都设计了合适的测试用例覆盖
- 业务流程覆盖率100%、需求覆盖率≥100%、总体质量评分≥90分
- 设计方法选择与功能约束匹配（以覆盖约束条件为准，不强制数量）
- 至少覆盖2种测试类型（简单功能）或3种测试类型（核心/复杂功能）
- P0+P1 占比不超过 40%
- 格式符合规范要求