---
name: testcase-generator
description: 测试用例生成器 - 基于等价类划分和边界值分析理论,按测试点(POINT)分批生成高质量测试用例,输出为 Markdown 格式。当用户执行 /testcase-gen 命令或需要生成测试用例时使用。
allowed-tools: Read, Write, Bash, Glob
---

# 测试用例生成器(testcase-generator)

## 1. 目标

根据测试点生成结构化测试用例，覆盖正向、反向、边界场景。

## 2. 输入输出

- **输入**：`test-case/plan.md`、`clarified-requirements/index.md`、`CLAUDE.md`
- **输出**：`test-case/{ITEM}/{POINT}.md`、`test-case/all_cases.md`

## 3. 核心原则

1. **策略指导**：提供判断标准，而非强制数量
2. **场景驱动**：基于实际场景复杂度生成用例
3. **数据具体**：测试数据必须具体，不用占位符
4. **可验证性**：预期结果必须明确可验证

---

## 触发条件

- 用户执行 `/testcase-gen` 命令
- `test-case/plan.md` 存在

---

## 4. 核心理论

### 4.1 等价类划分法

将输入数据划分为若干等价类,从每类中选取代表性数据测试。

**应用示例**:
```
POINT: 用户名密码登录

输入项: 用户名、密码

用户名等价类:
  有效: [6-20字符,字母数字下划线] → "test_user123"
  无效: [<6] "ab" | [>20] "verylongusername12345" | [特殊字符] "user@name" | [空] ""

密码等价类:
  有效: [8-20字符,含大小写+数字] → "Test1234"
  无效: [<8] "Test12" | [缺大写] "test1234" | [空] ""

生成原则: 一次测试一个等价类,其他保持有效
```

### 4.2 边界值分析法

边界是最容易出错的地方。

**边界三点法**: 离点(min-1) | 上点(min) | 内点(中间值) | 上点(max) | 离点(max+1)

**应用示例**:
```
用户名长度 6-20 字符:
- 离点-下: 5字符 "abcde" → 失败
- 上点-下: 6字符 "abcdef" → 成功
- 内点: 13字符 "test_user_123" → 成功
- 上点-上: 20字符 "test_user_1234567890" → 成功
- 离点-上: 21字符 "test_user_12345678901" → 失败
```

### 4.3 用例数量判断

不强制数量，根据场景复杂度自适应调整。

**判断标准**：
- 输入项数量：输入项越多，用例越多
- 业务规则复杂度：规则越复杂，用例越多
- 风险等级：Critical 和 High 需要更多用例
- 测试关注点：关注点越多，用例越多

---

## 5. 用例格式规范

### 5.1 Markdown文本协议格式 (v0.2)

每个测试点生成一个 `.md` 文件,格式如下:

```markdown
## [P1] 用例标题
[测试类型] 功能
[前置条件] 前置条件描述
[测试步骤] 1. 步骤1。2. 步骤2
[预期结果] 1. 预期1。2. 预期2

## [P3][反向] 用例标题
[测试类型] 功能
[前置条件] 前置条件描述
[测试步骤] 1. 步骤1。2. 步骤2
[预期结果] 1. 预期1。2. 预期2
```

### 5.2 字段说明

- **优先级**：P1-P5（必填）
  - P1: 核心功能正向流程
  - P2: 基本功能正向流程
  - P3: 核心功能异常场景
  - P4: 边界条件
  - P5: 低频场景
- **[反向]**：反向用例标记（可选）
- **测试类型**：功能、接口、性能、安全、兼容、易用、安装部署、可靠、本地化、可维护、可扩展、配置（12选1）
- **前置条件**：测试前的准备工作
- **测试步骤**：操作步骤，用句号分隔
- **预期结果**：期望的结果，与步骤一一对应

### 5.3 测试类型枚举(12种)

```
功能
兼容性
易用性
性能
稳定性
安全性
可靠性
效果(AI类、资源类)
效果(硬件器件类)
可维护性
可移植性
埋点
```

**注意**:
- 不能写"功能测试",必须是"功能"
- 括号必须是中文括号
- 大小写敏感

### 5.4 步骤格式规范

**推荐格式**: 使用中文句号分隔,编号连续

```markdown
[测试步骤] 1. 打开登录页面。2. 输入用户名test_user。3. 输入密码Test1234。4. 点击登录按钮
[预期结果] 1. 页面正常显示。2. 用户名输入框显示内容。3. 密码输入框显示密码。4. 登录成功,跳转到首页
```

**重要**: 编号必须从1开始,连续递增;测试步骤和预期结果的编号数量必须一致。

### 5.5 测试数据要求

必须具体，不用占位符：

**正确示例**：
- 用户名：test_user
- 密码：Test1234
- 手机号：13800138000
- 金额：99.99

**错误示例**：
- 用户名：{valid_username}
- 密码：{password}
- 手机号：{phone}
- 金额：{amount}

### 5.6 预期结果要求

必须明确可验证：

**正确示例**：
- 跳转到 /home 页面，顶部显示"欢迎，test_user"
- 提示"密码长度不足，请输入8-20位密码"
- 订单状态变为"已支付"，库存减少1

**错误示例**：
- 登录成功
- 提示错误信息
- 系统正常处理

### 5.7 目录结构

```
test-case/
├── plan.md
├── {ITEM}/
│   ├── {POINT1}.md
│   ├── {POINT2}.md
│   └── ...
└── all_cases.md
```

### 5.8 合并规则

将所有 `{ITEM}/{POINT}.md` 合并到 `all_cases.md`：

1. 按 ITEM 分组
2. 每个 ITEM 下按 POINT 排序
3. 添加分隔标记：`# ITEM 名称` 和 `## POINT 名称`

---

## 6. 用例生成流程

### Step 1: 准备上下文

```bash
cat test-case/plan.md
cat clarified-requirements/index.md
cat CLAUDE.md
```

### Step 2: 理解测试点

对每个 POINT：
- 读取 POINT 名称、风险等级、测试关注点
- 读取需求文档中的相关描述

### Step 3: 识别输入项

- 列出所有输入项（字段、参数、操作等）
- 识别输入项的约束条件

### Step 4: 划分等价类和边界值

- **有效等价类**：符合规则的输入
- **无效等价类**：违反规则的输入
- **边界值**：临界点（最小值、最大值、临界值）

### Step 5: 设计测试用例

基于以下策略设计：

**核心思考框架**:

1. **输入分析**
   - 该场景涉及哪些输入项？
   - 每个输入有什么约束（长度、格式、范围）？

2. **等价类识别**
   - 有效等价类：正常情况下的典型值
   - 无效等价类：各种异常情况（空值、越界、格式错误）

3. **测试价值评估**
   - 这个等价类失败时，会暴露不同的缺陷吗？
   - 如果和其他等价类的测试逻辑相同，是否可以合并？
   - 测试关注点中提到的场景，如何在用例中体现？

4. **覆盖判断**
   - 有效流程至少有一个用例
   - 核心异常场景已覆盖
   - 边界条件根据实际情况选择

5. **用例设计**
   - 核心正向用例（P1）：最常见的成功场景
   - 基本正向用例（P2）：其他有效等价类
   - 核心异常用例（P3）：关键失败场景
   - 边界条件用例（P4）：边界值测试
   - 低频场景用例（P5）：不常见但需覆盖的场景

**用例质量标准**:
- 数据具体（"test123"，不要"正确用户名"）
- 预期结果可验证（"显示错误提示'用户名不能为空'"，不要"提示错误"）
- 命名规范（以"验证"开头）

### Step 6: 生成完毕后统一校验

- 每个测试项（ITEM）生成完毕后，调用校验脚本检查格式
- 全部测试项生成完毕后，再次调用校验脚本进行整体检查
- 校验脚本路径：`.claude/skills/testcase-generator/scripts/validate.py`

---

## 7. 示例

### 示例1：正确的用例（用户名密码登录）

```markdown
## [P1] 验证有效用户名和密码登录成功
[测试类型] 功能
[前置条件] 已注册用户test_user，密码Test1234
[测试步骤] 1. 输入用户名test_user，输入密码Test1234，点击登录。2. 验证跳转到首页并显示用户名
[预期结果] 1. 登录请求成功。2. 跳转到/home页面，顶部显示'欢迎，test_user'

## [P3][反向] 验证用户名为空时登录失败
[测试类型] 功能
[前置条件] 进入登录页
[测试步骤] 1. 不输入用户名，输入密码Test1234，点击登录。2. 验证提示'用户名不能为空'
[预期结果] 1. 登录请求被拒绝。2. 停留在登录页，用户名输入框下方显示红色提示'用户名不能为空'

## [P4] 验证密码长度边界值（8位）
[测试类型] 功能
[前置条件] 已注册用户test_user，密码Test1234
[测试步骤] 1. 输入用户名test_user，输入8位密码Test1234，点击登录。2. 验证登录成功
[预期结果] 1. 登录请求成功。2. 跳转到/home页面
```

### 示例2：综合场景（多输入项）

**POINT**: 广告账户列表-筛选功能

**输入项分析**:
1. 时间范围: [今天|昨天|近7天|自定义]
2. 账户名称: [文本模糊搜索]
3. 账户状态: [正常|封禁|审核中]

**生成用例（6个）**:

```markdown
## [P1] 验证单一条件筛选成功
[测试类型] 功能
[前置条件] 广告账户列表页面，有10个账户
[测试步骤] 1. 选择时间"近7天"，点击查询。2. 验证返回符合条件的账户
[预期结果] 1. 列表刷新。2. 仅显示近7天有数据的账户

## [P1] 验证多条件组合筛选成功
[测试类型] 功能
[前置条件] 同上
[测试步骤] 1. 选择时间"近7天"，输入名称"test"，选择状态"正常"，点击查询
[预期结果] 1. 列表刷新。2. 仅显示同时满足3个条件的账户

## [P3][反向] 验证时间超过365天筛选失败
[测试类型] 功能
[前置条件] 同上
[测试步骤] 1. 选择自定义时间，开始日期2023-01-01，结束日期2024-01-02，点击查询
[预期结果] 1. 显示提示"时间范围不能超过365天"，列表不刷新

## [P3][反向] 验证不存在的账户名筛选返回空
[测试类型] 功能
[前置条件] 同上
[测试步骤] 1. 输入不存在的账户名"nonexistent123"，点击查询
[预期结果] 1. 列表刷新。2. 显示"暂无数据"

## [P2] 验证筛选条件清空功能
[测试类型] 功能
[前置条件] 已应用筛选条件
[测试步骤] 1. 点击"重置"按钮。2. 验证所有筛选条件清空，列表恢复默认
[预期结果] 1. 所有筛选项恢复默认值。2. 列表显示全部账户

## [P4][反向] 验证结束时间早于开始时间提示错误
[测试类型] 功能
[前置条件] 同上
[测试步骤] 1. 选择自定义时间，开始日期2024-01-02，结束日期2024-01-01，点击查询
[预期结果] 1. 显示提示"结束时间不能早于开始时间"
```

**说明**:
- 中等复杂度 POINT（多输入项）生成 6 个用例
- 覆盖：有效组合、无效边界、清空操作
- 选择**代表性用例**，覆盖主要场景

### 示例3：错误的用例

```markdown
## [P1] 验证登录成功
[测试类型] 功能
[前置条件] 用户已注册
[测试步骤] 1. 输入用户名{username}，输入密码{password}，点击登录
[预期结果] 1. 登录成功
```

**为什么错误**：
- 测试数据使用占位符（{username}、{password}）
- 预期结果不可验证（"登录成功"太模糊）

---

## 8. 检验流程

### Step 1: 每个测试项生成完毕后

调用校验脚本检查格式：

```bash
uv run .claude/skills/testcase-generator/scripts/validate.py \
  --single "test-case/{模块}/{测试点}.md"
```

脚本会输出日志，指出格式问题（如优先级错误、字段缺失等）。AI 分析日志，决定是否需要修改。

### Step 2: 全部生成完毕后

再次调用校验脚本进行整体检查：

```bash
uv run .claude/skills/testcase-generator/scripts/validate.py "test-case/" --check-duplicates
```

脚本会检查重复用例、格式一致性等。脚本只提供日志，不直接修改文件。AI 分析日志，决定是否需要调整。

### Step 3: 生成质量报告

- 统计用例数量（按 ITEM、按优先级）
- 统计等价类覆盖率
- 统计边界值覆盖率
- 列出重复用例（如果有）

---

## 9. 检查清单

### 生成前检查

- [ ] 已读取 `test-case/plan.md`
- [ ] 已读取 `clarified-requirements/index.md`
- [ ] 已读取 `CLAUDE.md` 业务背景
- [ ] 理解测试项(ITEM)和测试点(POINT)的层级关系

### 每个POINT生成时检查

- [ ] 每个 POINT 都已生成用例文件
- [ ] 用例数量合理（基于场景复杂度）
- [ ] 所有用例都有优先级（P1-P5）
- [ ] 所有用例都有测试类型（12种之一）
- [ ] 测试数据具体（无占位符）
- [ ] 预期结果可验证（无模糊描述）
- [ ] 测试步骤与预期结果数量一致
- [ ] 用例标题以"验证"开头

### 治理阶段检查

- [ ] 执行了全局校验脚本
- [ ] 检查了重复用例
- [ ] 格式符合规范（已通过 validate.py 检查）
- [ ] 已生成 all_cases.md
- [ ] 无重复用例（已通过 validate.py --check-duplicates 检查）
- [ ] 已生成质量报告

---

## 10. 脚本接口

### validate.py

```bash
# 单文件校验
uv run .claude/skills/testcase-generator/scripts/validate.py \
  --single "test-case/{模块}/{测试点}.md"

# 全局校验
uv run .claude/skills/testcase-generator/scripts/validate.py "test-case/"

# 全局校验 + 重复检测
uv run .claude/skills/testcase-generator/scripts/validate.py "test-case/" --check-duplicates

# 仅重复检测
uv run .claude/skills/testcase-generator/scripts/validate.py "test-case/" --duplicates-only
```

**校验项**:
- Schema格式
- 必填字段(优先级、测试类型、测试步骤、预期结果)
- 测试类型枚举(12种)
- 步骤编号连续性
- 步骤与预期结果数量一致性
- 等价类覆盖检查(`--check-equivalence`)
- 边界值覆盖检查(`--check-boundary`)
- 重复检测(`--check-duplicates`)

### to_excel.py

```bash
# 从目录导出
uv run .claude/skills/testcase-generator/scripts/to_excel.py "test-case/" -o "test-case/export.xlsx"

# 从单个文件导出
uv run .claude/skills/testcase-generator/scripts/to_excel.py "test-case/{模块}/{测试点}.md" -o "output.xlsx"
```

---

## 11. 异常处理

| 错误 | 处理方式 |
|------|----------|
| 单文件校验失败 | 重试3次，仍失败则跳过并记录 |
| 用例数过多(>15) | 提示检查是否有冗余等价类 |
| 缺少边界用例 | 警告并建议补充 |
| 缺少无效等价类 | 警告并建议补充异常场景 |
| 步骤编号不连续 | 报错并要求修正 |
| 测试类型不在枚举 | 报错并要求修正 |
| 步骤与预期数量不一致 | 报错并要求修正 |
| 导出失败 | 检查openpyxl依赖 |

---

## 12. 停止点

✅ **用例生成完成**

**产物**:
- `test-case/{ITEM}/{POINT}.md` - 各测试点的用例文件
- `test-case/all_cases.md` - 所有用例汇总

**质量保证**:
- 基于等价类理论生成
- 边界值全覆盖
- 用例数量合理（基于场景复杂度）

**统计示例**:
```
📊 生成统计:
  - 测试项: 8个
  - 测试点: 20个
  - 测试用例: 75个

  覆盖率:
  - 有效等价类: 100% (每POINT至少1个)
  - 无效等价类: 80% (主要异常全覆盖)
  - 边界值: 90% (所有范围型输入)

  用例分布:
  - P1(核心正向): 20个(27%)
  - P2(基本正向): 15个(20%)
  - P3(核心异常): 25个(33%)
  - P4(边界条件): 12个(16%)
  - P5(低频场景): 3个(4%)
```

**下一步**:
- 人工审核测试用例
- 导出为 Excel 格式（可选）
- 根据业务理解调整用例