# Testcase Generator

> 当用户提供需求分析报告或功能描述时触发，基于结构化的需求分析设计全场景手工功能测试用例，覆盖正向、反向、边界、异常四类场景，输出标准化 CSV 文件供测试人员直接使用。这是测试用例生成链的第二环。

- Skill: `dawei12138/testcase-generator` (Agent Skill)
- Install (CLI): `npx skillmds@latest add dawei12138/testcase-generator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dawei12138/testcase-generator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Data & Analytics
- Author: dawei12138 (https://skillmd.com/u/dawei12138)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dawei12138/testcase-generator

---


# TestCase Generator — 手工功能测试用例生成

当用户消息中包含以下任一关键词时，**必须**激活此技能：
- `生成用例`
- `创建测试用例`
- `创建用例`
- `generate test`
- `test case`

触发后，向用户确认："已激活 **TestCase Generator** 技能，将基于需求分析生成覆盖率 95%+ 的手工功能测试用例。"

---

## 技能定位

本技能是**测试用例生成链**的第二环：

```
[需求分析评审] → [测试用例生成] → [测试用例评审]
  上一步          ★ 当前            下一步
```

**核心职责**：将结构化的需求分析结果转化为高覆盖率、可执行的手工功能测试用例，输出测试人员可以直接使用的 CSV 文件。

---

## 文件上下文管理协议

本技能采用**文件驱动的上下文管理**模式，所有中间产出和最终交付物都通过文件系统持久化。

### 核心原则

1. **写入优先**：每个步骤完成后，**必须**立即使用文件写入工具将产出物写入对应文件
2. **读取优先**：每个步骤开始前，**必须**先使用文件读取工具加载前置步骤的输出文件
3. **文件即上下文**：禁止仅依赖对话历史传递步骤间信息，所有跨步骤引用必须通过读取文件获取
4. **索引追踪**：通过 `_progress.json` 文件追踪执行进度和所有产出文件路径
5. **链式继承**：优先读取上游技能（requirement-analysis）的产出文件作为输入

### 文件清单

| 步骤 | 输出文件 | 说明 |
|------|---------|------|
| 初始化 | `_progress.json` | 进度索引（如已存在则追加/更新） |
| Step 1 | `tc_step1_context.md` | 输入解析与上下文建立 |
| Step 2 | `tc_step2_strategy.md` | 测试策略制定 |
| Step 3 | `tc_step3_positive_cases.md` | 正向场景用例 |
| Step 4 | `tc_step4_negative_cases.md` | 反向场景用例 |
| Step 5 | `tc_step5_boundary_cases.md` | 边界值场景用例 |
| Step 6 | `tc_step6_exception_cases.md` | 异常场景用例 |
| Step 7 | `tc_step7_arrangement.md` | 用例编排与覆盖度统计 |
| Step 8 | `testcases_{功能名}_{timestamp}.csv` | 最终 CSV 文件 |
| Step 9 | `tc_step9_summary.md` | 生成摘要 |

### `_progress.json` 更新

在现有 `_progress.json` 基础上追加本技能的进度（如文件不存在则创建）：

```json
{
  "skill": "testcase-generator",
  "started_at": "2026-03-10T13:00:00",
  "status": "in_progress",
  "upstream": {
    "requirement_analysis_file": "requirement_analysis_xxx.json"
  },
  "steps": {
    "step1": { "status": "not_started", "output_file": null },
    "step2": { "status": "not_started", "output_file": null },
    "step3": { "status": "not_started", "output_file": null },
    "step4": { "status": "not_started", "output_file": null },
    "step5": { "status": "not_started", "output_file": null },
    "step6": { "status": "not_started", "output_file": null },
    "step7": { "status": "not_started", "output_file": null },
    "step8": { "status": "not_started", "output_file": null },
    "step9": { "status": "not_started", "output_file": null }
  },
  "deliverables": []
}
```

---

## 输入

本技能接受两种输入模式：

### 模式 A：链式输入（推荐）
直接使用 `requirement-analysis` 技能输出的 JSON 报告文件。

| 输入项 | 说明 | 必需 |
|-------|------|------|
| 需求分析报告 JSON | `requirement_analysis_xxx.json` 文件路径 | 是 |

当检测到工作区内存在 `requirement_analysis_*.json` 文件时，自动读取并解析。

### 模式 B：直接输入
用户直接描述功能效果或提供需求信息，此时技能内部执行简化版需求分析。

| 输入项 | 说明 | 必需 |
|-------|------|------|
| 功能描述/业务场景 | 自然语言需求描述 | 是 |
| 原型图/截图 | UI 设计稿 | 可选 |

---

## 输出

一份 **CSV 文件**，包含完整的手工功能测试用例，测试人员可直接用于执行手工测试。同时作为 `testcase-review` 技能的输入。

### CSV 列定义

| 列名 | 说明 | 示例 |
|------|------|------|
| 用例编号 | 唯一标识，格式 TC-XXX | TC-001 |
| 所属模块 | 功能模块名称 | 用户管理 |
| 功能点 | 具体功能点 | 用户注册 |
| 用例标题 | 简明描述测试目的，格式：[条件/操作]_[预期结果] | 输入有效手机号注册_注册成功跳转首页 |
| 前置条件 | 执行用例前需满足的条件 | 1.用户未注册 2.手机号可正常接收短信 |
| 优先级 | P0/P1/P2/P3 | P0 |
| 用例类型 | 正向/反向/边界/异常 | 正向 |
| 测试步骤 | 编号的操作步骤（步骤间用换行分隔） | 1.打开注册页面 2.输入手机号13800138000 3.点击获取验证码... |
| 预期结果 | 与测试步骤一一对应的预期结果（步骤间用换行分隔） | 1.注册页面正常展示 2.手机号输入成功 3.验证码发送成功... |
| 关联规则 | 关联的业务规则ID | R1,R3 |
| 测试结果 | 留空，手工测试时填写 | |
| 测试状态 | 留空，手工测试时填写（通过/失败/阻塞/跳过） | |
| 执行人 | 留空，手工测试时填写 | |
| 备注 | 补充说明 | |

---

## 执行步骤（必须严格按顺序，每步完成后输出标记）

### 初始化：创建/更新进度索引

在执行任何步骤之前，检查工作区是否已有 `_progress.json`，如有则在其基础上追加本技能信息；如无则创建。

---

### Step 1: 输入解析与上下文建立
**标记：`[TC-STEP-1-DONE]`**

📁 **文件操作**：
- 读取（模式A）：`requirement_analysis_*.json`（上游技能产出）
- 读取（模式B）：无前置文件，解析用户消息
- 写入：`tc_step1_context.md`
- 更新：`_progress.json`（step1 → in_progress → completed）

判断输入模式并解析需求上下文。

**模式 A（链式输入）**：
使用文件读取工具加载 `requirement_analysis_*.json`，解析其中的 modules、business_rules、user_flows 等结构。

输出格式（写入 `tc_step1_context.md`）：

```markdown
# Step 1: 输入解析与上下文建立

## 输入模式: 链式输入（模式A）
- 输入文件: requirement_analysis_xxx.json
- 来源技能: Requirement Analysis v2.0
- 生成时间: 2026-03-10T12:00:00

## 解析结果
- 功能模块数: N 个
- 功能点数: N 个
- 业务规则数: N 个
- 操作流程数: N 个
- 完整度评分: X%

## 功能模块概要
[从 JSON 中提取的模块和功能点列表]

## 业务规则概要
[从 JSON 中提取的规则列表]

## 操作流程概要
[从 JSON 中提取的流程列表]
```

**模式 B（直接输入）**：
执行快速需求分析（精简版），提取功能模块、规则和操作流程。

输出格式（写入 `tc_step1_context.md`）：

```markdown
# Step 1: 输入解析与上下文建立

## 输入模式: 直接输入（模式B）
- 原始描述: [用户原文]
- 状态: 未经需求分析评审，用例覆盖度可能受限

## 快速分析结果
### 功能模块
[识别的模块和功能点]

### 关键规则
[推导的业务规则]

### 操作流程
[推导的用户流程]

> 建议: 先使用 requirement-analysis 技能进行需求分析，可提高用例质量和覆盖度。
```

### Step 2: 测试策略制定
**标记：`[TC-STEP-2-DONE]`**

📁 **文件操作**：
- 读取：`tc_step1_context.md`
- 写入：`tc_step2_strategy.md`
- 更新：`_progress.json`（step2 → in_progress → completed）

**开始前必须先读取 `tc_step1_context.md` 获取需求上下文。**

基于需求分析结果，制定测试策略和覆盖目标。

输出格式（写入 `tc_step2_strategy.md`）：

```markdown
# Step 2: 测试策略制定

## 覆盖目标
- 功能覆盖: 100%（所有 P0/P1 功能点必须覆盖）
- 规则覆盖: 100%（所有业务规则至少 1 条正向 + 1 条反向）
- 流程覆盖: 100%（所有主流程 + 关键分支流程）
- 场景覆盖: ≥95%（综合覆盖度目标）
- 步骤粒度: 每条用例步骤数 3-10 步，确保可操作性

## 用例分布规划

| 场景类型 | 预估占比 | 设计原则 |
|---------|---------|---------|
| 正向场景 | 25-30% | 覆盖所有正常业务流程的主路径 |
| 反向场景 | 30-35% | 每个校验规则至少 1 条违反用例 |
| 边界值场景 | 20-25% | 每个有约束的输入字段测试边界值 |
| 异常场景 | 10-20% | 网络异常、权限、并发、中断操作 |

## 按功能点用例规划

| 模块 | 功能点 | 正向 | 反向 | 边界 | 异常 | 合计 |
|------|--------|------|------|------|------|------|
| M1 | F1 用户注册 | 2 | 5 | 4 | 2 | 13 |
| ... | ... | ... | ... | ... | ... | ... |
| | **合计** | X | Y | Z | W | **N** |
```

### Step 3: 正向场景用例设计
**标记：`[TC-STEP-3-DONE]`**

📁 **文件操作**：
- 读取：`tc_step1_context.md`、`tc_step2_strategy.md`
- 写入：`tc_step3_positive_cases.md`
- 更新：`_progress.json`（step3 → in_progress → completed）

**开始前必须先读取 step1 和 step2 的输出文件获取上下文和策略。**

设计覆盖所有正常业务流程主路径的正向用例。

**设计原则**：
- 每个主流程至少 1 条完整的端到端用例
- 使用合法、典型的输入值
- 步骤要具体到可操作级别（包含具体输入数据）
- 预期结果要与步骤一一对应

输出格式（写入 `tc_step3_positive_cases.md`）：

```markdown
# Step 3: 正向场景用例设计

## TC-001: [用例标题]

| 属性 | 内容 |
|------|------|
| 所属模块 | [模块名] |
| 功能点 | [功能点名] |
| 优先级 | P0 |
| 用例类型 | 正向 |
| 关联规则 | R1,R2 |
| 前置条件 | 1.用户未注册 2.手机号13800138000可正常接收短信 |

| 步骤 | 测试步骤 | 预期结果 |
|------|---------|---------|
| 1 | 打开浏览器，访问注册页面 | 注册页面正常展示，包含手机号输入框、验证码输入框、密码输入框 |
| 2 | 在手机号输入框输入 13800138000 | 手机号正常显示，无报错提示 |
| ... | ... | ... |

## TC-002: [用例标题]
[同上格式]
```

### Step 4: 反向场景用例设计
**标记：`[TC-STEP-4-DONE]`**

📁 **文件操作**：
- 读取：`tc_step1_context.md`、`tc_step2_strategy.md`
- 写入：`tc_step4_negative_cases.md`
- 更新：`_progress.json`（step4 → in_progress → completed）

**开始前必须先读取 step1 和 step2 的输出文件获取上下文和策略。**

设计违反业务规则和输入约束的反向用例，每条规则至少对应 1 条反向用例。

**设计原则**：
- 每个校验规则至少 1 条违反用例
- 必填项为空测试
- 格式不合法测试
- 业务逻辑违反测试（如重复注册）
- 权限不足测试

输出格式（写入 `tc_step4_negative_cases.md`）：

```markdown
# Step 4: 反向场景用例设计

## TC-XXX: [用例标题]

| 属性 | 内容 |
|------|------|
| 所属模块 | [模块名] |
| 功能点 | [功能点名] |
| 优先级 | P0 |
| 用例类型 | 反向 |
| 关联规则 | R1 |
| 前置条件 | 1.已在注册页面 |

| 步骤 | 测试步骤 | 预期结果 |
|------|---------|---------|
| 1 | 手机号输入框保持为空 | 输入框为空 |
| 2 | 直接点击"获取验证码"按钮 | 提示"请输入手机号"，验证码不发送 |

## 必须覆盖的反向场景清单
- [ ] 每个必填字段逐个为空
- [ ] 字段格式不合法（如手机号输入字母、邮箱缺少@）
- [ ] 违反唯一性约束（如重复注册）
- [ ] 违反业务状态约束（如已禁用账号登录）
- [ ] 未授权/未登录操作
- [ ] 无权限操作（越权访问）
```

### Step 5: 边界值场景用例设计
**标记：`[TC-STEP-5-DONE]`**

📁 **文件操作**：
- 读取：`tc_step1_context.md`、`tc_step2_strategy.md`
- 写入：`tc_step5_boundary_cases.md`
- 更新：`_progress.json`（step5 → in_progress → completed）

**开始前必须先读取 step1 和 step2 的输出文件获取上下文和策略。**

设计边界值和极端输入的测试用例。

**设计原则**：
- 字符串字段：空串、最小长度、最小长度-1、最大长度、最大长度+1、特殊字符
- 数字字段：最小值、最小值-1、最大值、最大值+1、0、负数
- 选择类字段：不选、单选、全选（如适用）
- 文件上传：空文件、最小大小、最大大小、超出大小、非法格式

输出格式（写入 `tc_step5_boundary_cases.md`）：

```markdown
# Step 5: 边界值场景用例设计

## TC-XXX: [用例标题]

| 属性 | 内容 |
|------|------|
| 所属模块 | [模块名] |
| 功能点 | [功能点名] |
| 优先级 | P1 |
| 用例类型 | 边界 |
| 关联规则 | R3 |
| 前置条件 | 1.已在注册页面 |
| 边界值说明 | 密码要求8-20位，测试下界-1（7位） |

| 步骤 | 测试步骤 | 预期结果 |
|------|---------|---------|
| 1 | 在密码输入框输入 "Abc@123"（7位，低于最小8位要求） | 密码正常输入 |
| 2 | 点击"注册"按钮 | 提示"密码长度不能少于8位"，注册不成功 |

## 边界值矩阵

| 字段 | 空值 | 下界-1/下界 | 上界/上界+1 | 特殊字符 | 超长输入 |
|------|------|-----------|-----------|---------|---------|
| 手机号 | "" | 10位/11位 | 11位/12位 | 字母/汉字 | 30位数字 |
| 密码 | "" | 7位/8位 | 20位/21位 | 纯数字/纯字母 | 100位 |
| 用户名 | "" | 1位/2位 | 20位/21位 | <>'";\& | 255位 |
```

### Step 6: 异常场景用例设计
**标记：`[TC-STEP-6-DONE]`**

📁 **文件操作**：
- 读取：`tc_step1_context.md`、`tc_step2_strategy.md`
- 写入：`tc_step6_exception_cases.md`
- 更新：`_progress.json`（step6 → in_progress → completed）

**开始前必须先读取 step1 和 step2 的输出文件获取上下文和策略。**

设计系统异常、环境异常和非常规操作的测试用例。

**设计原则**：
- 网络异常（断网、弱网、超时）
- 操作中断（提交过程中关闭页面、重复点击）
- 并发操作（多终端同时操作）
- 浏览器兼容（前进/后退、刷新）
- 会话异常（登录过期、Token失效）

输出格式（写入 `tc_step6_exception_cases.md`）：

```markdown
# Step 6: 异常场景用例设计

## TC-XXX: [用例标题]

| 属性 | 内容 |
|------|------|
| 所属模块 | [模块名] |
| 功能点 | [功能点名] |
| 优先级 | P2 |
| 用例类型 | 异常 |
| 关联规则 | — |
| 前置条件 | 1.已填写完所有注册信息 2.网络正常 |

| 步骤 | 测试步骤 | 预期结果 |
|------|---------|---------|
| 1 | 断开网络连接 | 网络已断开 |
| 2 | 点击"注册"按钮 | 提示"网络连接异常，请检查网络后重试"，不出现白屏 |
| 3 | 恢复网络连接 | 网络恢复 |
| 4 | 再次点击"注册"按钮 | 注册请求正常发送，注册成功 |
```

### Step 7: 用例编排与执行顺序
**标记：`[TC-STEP-7-DONE]`**

📁 **文件操作**：
- 读取：`tc_step3_positive_cases.md`、`tc_step4_negative_cases.md`、`tc_step5_boundary_cases.md`、`tc_step6_exception_cases.md`
- 写入：`tc_step7_arrangement.md`
- 更新：`_progress.json`（step7 → in_progress → completed）

**开始前必须先读取 step3~step6 的所有用例文件，汇总进行编排。**

组织用例的执行顺序和依赖关系。

输出格式（写入 `tc_step7_arrangement.md`）：

```markdown
# Step 7: 用例编排与执行顺序

## 按模块分组执行顺序

### 模块: [模块名]

Phase 1 - 正向主流程:
  TC-001 → TC-002 → TC-003（按业务流程顺序）

Phase 2 - 反向校验:
  TC-004 ~ TC-010（可独立执行，无依赖）

Phase 3 - 边界值:
  TC-011 ~ TC-018（可独立执行，无依赖）

Phase 4 - 异常场景:
  TC-019 ~ TC-022（需特殊环境准备）

## 用例依赖关系
- TC-005（修改用户信息）依赖 TC-001（注册成功）先执行
- TC-008（删除账号）依赖 TC-001（注册成功）先执行

## 覆盖度统计

| 覆盖维度 | 已覆盖/总数 | 覆盖率 |
|---------|-----------|--------|
| 功能点覆盖 | X/Y | XX% |
| 业务规则覆盖 | X/Y | XX% |
| 操作流程覆盖 | X/Y | XX% |
| **综合场景覆盖** | | **X%（目标 ≥95%）** |
```

**覆盖度不达标处理**：如果综合覆盖度 <95%，需要回到 Step 3~6 补充用例，补充后重新写入对应文件并更新本文件的覆盖度统计。

### Step 8: 生成 CSV 文件
**标记：`[TC-STEP-8-DONE]`**

📁 **文件操作**：
- 读取：`tc_step3_positive_cases.md`、`tc_step4_negative_cases.md`、`tc_step5_boundary_cases.md`、`tc_step6_exception_cases.md`、`tc_step7_arrangement.md`
- 写入：`testcases_{功能名}_{YYYYMMDD_HHMMSS}.csv`
- 更新：`_progress.json`（step8 → in_progress → completed，更新 deliverables）

**开始前必须先读取所有用例文件（step3~step6）和编排文件（step7），汇总为 CSV。**

将所有用例输出为标准化 CSV 文件，供测试人员直接使用。

CSV 格式规范：
- 编码：UTF-8 with BOM（确保 Excel 正确识别中文）
- 分隔符：逗号
- 文本限定符：双引号（字段内含逗号或换行时必须用双引号包裹）
- 步骤内换行：使用实际换行符 `\n`（在双引号包裹内）

CSV 表头和示例：

```csv
用例编号,所属模块,功能点,用例标题,前置条件,优先级,用例类型,测试步骤,预期结果,关联规则,测试结果,测试状态,执行人,备注
TC-001,用户管理,用户注册,输入有效手机号注册_注册成功跳转首页,"1.用户未注册
2.手机号可正常接收短信",P0,正向,"1.打开注册页面
2.输入手机号13800138000
3.点击获取验证码
4.输入收到的验证码
5.输入密码Abc@1234
6.确认密码Abc@1234
7.勾选用户协议
8.点击注册按钮","1.注册页面正常展示
2.手机号正常显示
3.验证码发送成功,按钮60秒倒计时
4.验证码正常输入
5.密码掩码显示
6.确认密码掩码显示
7.复选框选中
8.提示注册成功,跳转首页",R1;R2;R3,,,,
```

**文件生成规则**：
1. 第一行为表头
2. 用例按编号排序
3. 同一模块的用例连续排列
4. 同一功能点内按类型排序：正向 → 反向 → 边界 → 异常
5. 步骤和预期结果中的换行用实际 `\n` 处理，整个字段用双引号包裹
6. 关联规则使用分号 `;` 分隔多个规则ID

使用工具将文件写入工作区。

### Step 9: 输出生成摘要
**标记：`[TC-STEP-9-DONE]`**

📁 **文件操作**：
- 读取：`tc_step7_arrangement.md`、`testcases_{功能名}_{timestamp}.csv`（Step 8 产出）
- 写入：`tc_step9_summary.md`
- 更新：`_progress.json`（step9 → completed，顶层 status → completed）

**开始前必须先读取 Step 7 的覆盖度统计和 Step 8 的 CSV 文件。**

输出摘要（同时写入 `tc_step9_summary.md` 并在对话中展示）：

| 指标 | 结果 |
|------|------|
| 输入来源 | [需求分析报告 / 直接输入] |
| 功能模块 | N 个 |
| 功能点 | N 个 |
| 生成用例 | N 条 |
| — 正向 | X 条（XX%） |
| — 反向 | Y 条（YY%） |
| — 边界 | Z 条（ZZ%） |
| — 异常 | W 条（WW%） |
| 功能覆盖 | X% |
| 规则覆盖 | X% |
| 流程覆盖 | X% |
| 综合覆盖 | X% |
| 输出文件 | testcases_xxx.csv |

> **下一步**: 使用 `testcase-review` 技能评审和优化测试用例，输入文件为上述输出文件路径。

---

## 关键约束

1. **不得跳步**：必须从 Step 1 到 Step 9 顺序执行，每步完成后输出 `[TC-STEP-X-DONE]` 标记
2. **不得合并步骤**：每个步骤独立输出，确保用户可逐步审阅
3. **覆盖度硬指标**：综合场景覆盖度必须 ≥95%，不达标时必须补充用例
4. **每功能点至少 3 类场景**：正向、反向、边界缺一不可
5. **步骤必须可操作**：每个步骤要包含具体操作位置、输入数据，不能模糊描述
6. **预期结果必须可验证**：预期结果要具体到可判断 pass/fail 的程度
7. **步骤与预期一一对应**：测试步骤和预期结果必须逐条对应
8. **文件必须落盘**：每个步骤的产出必须使用文件写入工具实际写入文件，不能只在对话中展示
9. **读取优先**：每个步骤开始前必须通过文件读取工具加载前置步骤的输出文件，禁止仅依赖对话记忆
10. **进度索引同步**：每个步骤开始和完成时都必须更新 `_progress.json`
11. **UTF-8 BOM 编码**：确保 CSV 文件 Excel 打开不乱码
12. **链式输入优先**：检测到需求分析报告时必须优先使用，不重新分析