back
loading skill details...
从需求文档（Markdown/PDF/Word）或图片流程图中生成结构化 Excel 测试用例。 当用户提到以下内容时触发：生成测试用例、编写测试用例、从需求提取测试场景、 根据需求文档/设计文档/接口文档/流程图生成测试、需要按业务域分组的测试报告、 测试覆盖、测试计划。输出带有优先级着色和模块分隔行的格式化 Excel 文件。 不适用于：生成自动化测试脚本（Selenium/Playwright）、执行测试运行、搭建测试框架。
---
name: qa-testcase-generator
description: >
从需求文档（Markdown/PDF/Word）或图片流程图中生成结构化 Excel 测试用例。
当用户提到以下内容时触发：生成测试用例、编写测试用例、从需求提取测试场景、
根据需求文档/设计文档/接口文档/流程图生成测试、需要按业务域分组的测试报告、
测试覆盖、测试计划。输出带有优先级着色和模块分隔行的格式化 Excel 文件。
不适用于：生成自动化测试脚本（Selenium/Playwright）、执行测试运行、搭建测试框架。
version: V2.1.0
---
# 测试用例生成器 V2
> **版本**: V2.1.0 | **最后更新**: 2026-07-07
> **核心改进**: 批量场景支持、四层深度硬约束、阶段精简、模块前缀编号
---
## 第一步：判断输入模式
**在开始任何阶段之前，先判断输入规模：**
| 输入 | 模式 | 执行策略 |
|------|------|----------|
| **1 个文件** | 单文档模式 | 四阶段完整执行 |
| **2-3 个文件** | 小批量模式 | 逐个文档执行阶段二~三 |
| **> 3 个文件** | **批量模式** | 见下方批量模式说明 |
### 批量模式执行策略
```
输入：N个需求文档（N > 3）
│
▼
阶段一：一次性扫全部文档 → 生成全局业务域图
│
▼
阶段二~三：逐个文档执行（每个文档重复以下循环）
┌──────────────────────────────────────┐
│ 文档i：阶段二（需求提取） │
│ → 阶段三（设计+生成用例） │
│ → 保存到 output/phase4_cases │
└──────────────────────────────────────┘
│
▼
阶段四：合并全部文档结果 → Excel
```
**关键约束**（防止 token 稀释）：
- 每个文档独立执行阶段二~三，**不允许同时处理多个文档**
- 每个文档生成的用例数不得少于 `min(10, 可测需求数*2)`——防止批量时偷工减料
- 全局业务域图（阶段一输出）作为后续每个文档的共享上下文
---
## 阶段一：业务域分析
**由 AI 执行，无需 Python 脚本。**
### 输入规模决定策略
| 输入文档数 | 做法 |
|-----------|------|
| 1 个 | 输出该文档的业务域（通常 1-2 个） |
| 多个 | 一次性扫描所有文档，输出**全局业务域图**（每个文档的业务域 + 域间依赖关系） |
### 1.1 业务域识别
扫描文档，找出独立的业务域。每个域记录：
- **业务域名称** — 从文档内容推断
- **核心实体** — 该域涉及的关键数据实体
- **业务规则** — 实体间的约束和逻辑
- **状态流转** — 实体的生命周期变化
- **域间交互** — 与其他域的依赖关系
### 1.2 业务分层
| 层级 | 定义 | 测试深度 |
|------|------|----------|
| **核心层** | 没有它业务跑不起来 | 穷尽各种场景（≥7条） |
| **重要层** | 影响体验但不阻塞 | 主流程 + 关键异常（≥5条） |
| **辅助层** | 锦上添花 | 仅主流程（≥3条） |
| **基础层** | 通用能力 | 基本功能验证（≥2条） |
> **层数决定最少用例数**：核心层 ≥ 7 条，重要层 ≥ 5 条，辅助层 ≥ 3 条，基础层 ≥ 2 条。
> 防止 token 稀释导致每个域只有 1-2 条。
### 1.3 输出格式
```json
{
"业务域": [{
"名称": "订单管理", "层级": "核心层",
"核心实体": ["订单", "订单项"],
"关键规则": ["库存扣减规则"],
"状态流转": ["待支付→已支付→已发货→已完成"],
"关联域": ["用户管理", "库存管理"],
"最少用例数": 8
}]
}
```
批量模式下，所有文档的业务域合并到一个 `phase1_domains.json`，标注 `源文件` 字段。
---
## 阶段二：需求提取与分类
**由 AI 执行，输出保存到 `output/phase2_requirements.json`。**
> ⚠️ **批量模式下，逐个文档执行本阶段**。每完成一个文档的需求提取，立即进入阶段三，不要等到所有文档都提取完。
### 2.1 需求提取
从文档中提取每条可验证的需求，不遗漏。
### 2.2 复杂度来源分类
| 复杂度来源 | 识别信号 |
|------------|----------|
| 输入空间 | 长度限制、取值范围、格式要求 |
| 状态组合 | 状态转换、生命周期、流转条件 |
| 条件逻辑 | 多条件判断、分支规则、权限控制 |
| 流程步骤 | 多步骤操作、业务流程、操作序列 |
| 配置组合 | 多参数组合、多环境配置、选项交叉 |
### 2.3 质量属性标记
| 质量属性 | 触发条件 |
|----------|----------|
| 可靠性 | 错误处理、容错、恢复、超时描述 |
| 效率 | 响应时间、并发、性能指标描述 |
| 安全性 | 认证、授权、加密、注入防护描述 |
| 兼容性 | 浏览器、操作系统、分辨率、移动端适配描述 |
| 易用性 | UI、交互、用户体验描述 |
| 可维护性 | 日志、监控、配置、审计描述 |
### 2.4 需求可测性检查
| 可测性状态 | 定义 | 处理方式 |
|------------|------|----------|
| **可测** | 输入输出明确，结果可验证 | 正常生成用例 |
| **不可测** | 描述模糊，无法设计验证步骤 | 标记`不可测`，不生成用例 |
| **需澄清** | 缺少关键细节 | 做合理假设，标注`[假设]` |
### 2.5 输出格式
```json
{
"源文件": "01-auth.md",
"需求": [{
"编号": "REQ-001", "描述": "密码长度必须为 8-20 位",
"业务域": "用户认证管理", "复杂度来源": ["输入空间"],
"质量属性": ["功能", "安全性"], "可测性": "可测"
}]
}
```
> ⚠️ 批量模式下，每条需求标注 `源文件`，后续独立关联。
---
## 阶段三：测试设计 + 用例生成（合并）
> **V2 合并了原 V1 的阶段三和阶段四**。不产生独立的 phase3 文件，设计思路直接在用例中体现。
> 原因：阶段三的输出（设计策略）和阶段四（用例生成）对于 AI 执行来说是同一思考过程的两面，分开输出白增上下文开销。
### 3.0 四层深度硬约束模板
设计用例的核心逻辑：**不是覆盖需求文字，而是发现问题和隐患**。
每个业务域必须严格按以下四层模板生成用例，**不允许跳过任何一层**。这是硬约束，不是建议。
```
每层模板（直接使用，不要跳过）：
┌─ 第一层：主流程（至少 1 条 P0）───────────────┐
│ 核心业务路径正向走通，验证"用户能完成核心目标" │
│ 步骤数: 4-5 步（打开→输入→操作→验证→持久化） │
└─────────────────────────────────────────────┘
┌─ 第二层：业务分层（至少 2 条 P1）──────────────┐
│ ├─ UI元素 + 交互逻辑（每个按钮/输入框/弹窗） │
│ ├─ 字段值边界（0/空值/最小值/最大值/特殊格式） │
│ └─ 元素间组合（搜索+筛选+排序、筛选+翻页） │
│ 步骤数: 3-4 步 │
└─────────────────────────────────────────────┘
┌─ 第三层：黑盒方法（至少 3 种不同方法）──────────┐
│ 场景法（1条正常+1条分支+1条异常） │
│ 边界分析（有效边界+无效边界） │
│ 等价类划分（有效类+无效类） │
│ 判定表（多条件组合决策） │
│ 状态迁移（合法转换+非法转换） │
│ 模糊测试/错误猜测/表单测试/CRUD测试 │
│ （选3种以上，保证每个需求至少1条正向+1条异常） │
└─────────────────────────────────────────────┘
┌─ 第四层：探索性（每个业务域至少 2 条 P3，──────────┐
│ 总数不超过总用例数 20%） │
│ ├─ 边界数据（零数据/最大值/空列表） │
│ ├─ 特殊操作（特殊字符/超长输入/快速点击） │
│ ├─ 环境异常（网络中断/超时/权限越界） │
│ ├─ 数据一致（前端展示 vs 数据库核对） │
│ └─ 隐式推测（分页/防抖/空状态/响应式） │
│ 步骤数: 3 步 │
└─────────────────────────────────────────────┘
```
### 3.1 每层完成检查
逐层检查，**当前层不通过不进下一层**：
| 层 | 完成标志 | 不通过怎么办 |
|----|---------|-------------|
| 第一层 | 至少 1 条 P0 主流程 | 如果写不出 → 需求理解不够深 → 回头重读需求 |
| 第二层 | 至少 2 条 P1（字段边界 + 元素组合） | 如果写不出 → 漏了 UI/交互细节 → 再扫一遍页面元素 |
| 第三层 | ≥ 3 种不同方法 | 如果写不出 → 没挖掘够复杂度来源 → 对照复杂度来源表重新分析 |
| 第四层 | ≥ 2 条探索性且总数 ≤ 20% | 如果写不出 → 没想"什么情况会出问题" → 用错误猜测法想 2 个风险点 |
### 3.2 设计方法选择矩阵
根据复杂度来源选择方法（直接使用，不查外部文件）：
| 复杂度来源 | 推荐方法 | 覆盖目标 |
|------------|----------|----------|
| 输入空间 | 边界分析 + 等价类划分 | 边界值 + 有效/无效等价类 |
| 状态组合 | 状态迁移法 | 合法/非法转换 |
| 条件逻辑 | 判定表法 | 条件组合全覆盖 |
| 流程步骤 | 场景法 | 关键路径覆盖 |
| 配置组合 | Pairwise（参数≥6时使用） | 参数对覆盖 |
### 3.3 方法数量约束
**每个业务域至少使用 3 种不同设计方法**。单文档所有用例至少覆盖 4 种方法。
### 3.4 异常场景分类
异常测试覆盖以下六类，**每个业务域至少覆盖输入+流程+权限三类**：
| 异常类别 | 说明 | 用例示例 |
|----------|------|----------|
| **输入异常** | 无效格式、超长/超短、空值、特殊字符 | 邮箱格式错误 → 提示 |
| **流程异常** | 流程中断、回退、重复提交、跳过必填 | 中途关闭 → 状态不变 |
| **环境异常** | 网络中断、服务超时、磁盘满、并发 | 接口超时 → 保留待处理状态 |
| **权限异常** | 未登录、越权、Token过期、角色不足 | 普通用户访问管理 → 403 |
| **数据异常** | 不存在、重复、关联数据被删除 | 查已删除商品 → 提示不存在 |
| **状态异常** | 非法状态转换、重复操作、时效超期 | 已取消订单申请发货 → 拒绝 |
### 3.5 优先级分配
| 优先级 | 分配规则 | 占比参考 |
|--------|---------|---------|
| P0 | 核心层主流程 + 阻塞性异常 | 10-20% |
| P1 | 核心层分支 + 重要层主流程 + 关键边界 | 30-40% |
| P2 | 核心层非关键 + 重要层异常 + 辅助层主流程 | 30-40% |
| P3 | 极端边界 + 低频场景 + 探索性测试 | 10-20% |
### 3.6 测试数据生成规则
按以下优先级生成具体值：
1. **边界值数据** — 自动推导最小/最大值的具体数字
2. **有效等价类数据** — 合规范围内的典型值
3. **无效等价类数据** — 每个违规类型各一条
4. **特殊值数据** — 空值、null、0、空格、Unicode字符
> 暴露真实数据的用例，统一使用测试专用假数据，标注 `[测试数据]` 前缀。
### 3.7 用例字段结构
| 字段 | 必填 | 说明 |
|------|:----:|------|
| 用例编号 | ✅ | 格式：`TC-{模块前缀}-NNN`（如 TC-AUTH-001） |
| 业务域 | ✅ | 与阶段一输出一致 |
| 优先级 | ✅ | P0/P1/P2/P3 |
| 测试维度 | ✅ | 功能/安全/性能/可靠性/兼容性/易用性/可维护性 |
| 用例类型 | ✅ | 冒烟测试/回归测试/探索性测试 |
| 设计方法 | ✅ | 场景法/边界分析/等价类划分/判定表/状态迁移/模糊测试/错误猜测法 |
| 测试场景 | ✅ | 描述测试场景（如 "主流程：用户成功登录"） |
| 测试点 | ✅ | 具体验证点 |
| 操作步骤 | ✅ | 3-5 步，每步含 `步骤` + `操作` + `预期` |
| 测试数据 | ✅ | 具体值（不是"测试数据"三个字） |
| 前置条件 | ✅ | 执行前的环境准备 |
| 需求来源 | ✅ | 关联的阶段二需求编号 |
| 源文件 | ✅ | 批量模式下标记文件来源 |
### 3.8 用例编号规则
| 模块 | 前缀 | 示例 |
|------|------|------|
| 用户认证 | AUTH | TC-AUTH-001 |
| 文件管理 | FILE | TC-FILE-001 |
| 下载申请 | DREQ | TC-DREQ-001 |
| 审批管理 | APPR | TC-APPR-001 |
| 溯源服务 | TRACE | TC-TRACE-001 |
| 文件水印 | WM | TC-WM-001 |
| 安全模块 | SEC | TC-SEC-001 |
| 导航菜单 | NAV | TC-NAV-001 |
| WebDAV | WEB | TC-WEB-001 |
| 部门管理 | DEPT | TC-DEPT-001 |
| 业务系统 | BS | TC-BS-001 |
| 我的文件 | PD | TC-PD-001 |
| 消息通知 | NTF | TC-NTF-001 |
| 仪表盘 | DSH | TC-DSH-001 |
> **模块前缀编号**取代了旧版的全局连续编号。好处：每个文档独立生成，编号不冲突，可并行执行。
### 3.9 输出格式
```json
{
"源文件": "01-auth.md",
"测试用例": [{
"用例编号": "TC-AUTH-001",
"业务域": "用户认证管理",
"优先级": "P0",
"测试维度": "功能",
"用例类型": "冒烟测试",
"设计方法": "场景法",
"测试场景": "主流程：用户登录成功",
"测试点": "验证正确的用户名和密码可以成功登录",
"操作步骤": [
{"步骤": 1, "操作": "访问 /login 页面", "预期": "页面正常加载"},
{"步骤": 2, "操作": "输入有效用户名和密码", "预期": "输入正常"},
{"步骤": 3, "操作": "点击「登录」按钮", "预期": "跳转到首页"}
],
"测试数据": "用户名: admin, 密码: Admin@123",
"前置条件": "用户已创建且未锁定",
"需求来源": "REQ-AUTH-001",
"源文件": "01-auth.md"
}]
}
```
---
## 阶段四：合并输出
### 4.1 合并所有文档的结果
批量模式下，将所有文档的阶段二和阶段三输出合并：
```json
{
"元数据": {
"源文件": ["01-auth.md", "02-file-management.md", "..."],
"生成时间": "ISO格式",
"需求总数": 212,
"用例总数": 263,
"覆盖率": "100%"
},
"业务域": [/* 从 phase1_domains.json */],
"测试用例": [/* 从所有文档的 phase4 合并 */],
"覆盖统计": {
"按业务域": {"用户认证管理": 22, "文件管理": 24, ...},
"按优先级": {"P0": 22, "P1": 64, "P2": 88, "P3": 89},
"按设计方法": {"场景法": 124, "边界分析": 11, ...}
}
}
```
### 4.2 调用 writer.py
```bash
python3 scripts/writer.py output/test_data.json
```
### 4.3 输出验证
- [ ] 每个文档独立标注源文件
- [ ] 用例编号格式正确（TC-{前缀}-NNN）
- [ ] 每个业务域有绿色分隔行
- [ ] 优先级颜色正确（P0红/P1橙/P2绿/P3灰）
- [ ] 优先级分布合理（P0 10-20%, P1+P2 60-80%, P3 10-20%）
- [ ] 每个业务域最外层结构 > 设计方法 ≥ 3 种
- [ ] 每个业务域覆盖异常场景 ≥ 3 类
- [ ] 每条用例操作步骤 3-5 步
- [ ] 测试数据提供具体值
---
## 单文档模式最少用例数参考
| 业务域层级 | 最少用例数 | 覆盖内容 |
|-----------|:---------:|----------|
| 核心层 | 7 | P0(1主流程) + P1(2业务分层) + P2(2黑盒方法) + P3(2探索性) |
| 重要层 | 5 | P1(1主流程) + P2(2分支) + P3(2异常) |
| 辅助层 | 3 | P2(1主流程) + P3(2基本异常) |
| 基础层 | 2 | P2(1正向) + P3(1反向) |
> **为什么要有最少用例数**：防止给多个文档时 token 稀释，每个文档只出 1-2 条 Happy Path。这个数字是底线，不是上限。
---
## 引用文件一览
| 文件 | 内容 | 何时阅读 |
|------|------|----------|
| `references/image_analysis.md` | 图片/流程图处理策略 | 输入含图片时 |
| `references/environment.md` | 环境配置和依赖安装 | 首次运行 |
| `references/troubleshooting.md` | 常见问题排查 | 运行出错时 |
> **核心约束已内联到本文件**。不再需要阅读 `quality.md`、`design_methods.md`、`templates.md`。
---
## 版本历史
| 版本 | 日期 | 变更说明 |
|------|------|----------|
| **V2.1.0** | 2026-07-07 | 修复 P3 探索性占比失控矛盾（第四层硬约束从「每域≥3条」改为「每域≥2条且总数≤20%」）+ 评分器补全 sequence_flow_coverage 断言类型 |
| **V2.0.0** | 2026-07-03 | 批量模式支持 + 四层深度硬约束 + 阶段三/四合并 + 模块前缀编号 + 核心约束内联 + 最少用例数约束 |
| V1.1.0 | 2026-06-29 | 初始结构化版本：五阶段工作流、独立输出文件 |
don't have the plugin yet? install it then click "run inline in claude" again.