# General Testcase

> 本技能从需求文档生成全面的测试用例文档。当用户需要从需求文档、产品规格说明或描述系统功能的文档创建测试用例时使用此技能。默认生成Markdown格式的测试用例文档；当用户明确要求生成"思维导图格式"或"xmind格式"时，会额外生成XMind思维导图文件。

- Skill: `leoyeai-openclaw-master-skills/general-testcase` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add leoyeai-openclaw-master-skills/general-testcase`
- Raw SKILL.md: https://api.skillmd.com/api/skills/leoyeai-openclaw-master-skills/general-testcase/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: LeoYeAI (https://skillmd.com/u/leoyeai-openclaw-master-skills)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/leoyeai-openclaw-master-skills/general-testcase

---


# 通用测试用例生成器技能

## 概述

本技能自动化从需求文档生成测试用例文档的过程。它分析需求内容、提取功能模块和测试点、生成结构化的Markdown测试用例文档。当用户明确要求时，还可以将Markdown转换为XMind思维导图格式。

**核心特性**：
- ✅ 深度需求分析，挖掘所有测试细节
- ✅ 按完整功能流程组织测试用例
- ✅ 默认生成Markdown格式，按需生成XMind思维导图
- ✅ **时间戳版本管理**：每次生成都添加时间戳后缀，保留所有历史版本

**🚨 核心原则（必读）**：

1. **深入分析需求**：不要浮于表面，必须逐句分析需求文档，挖掘所有测试细节
2. **充分覆盖细节**：验证项数量不设上限，核心功能的每个细节都要有对应的验证项
3. **不要人为限制**：不要为了控制数量而合并验证项，每个可独立验证的点都应单独列出
4. **质量优先于数量**：宁可测试用例详细冗长，也不要遗漏核心功能的测试细节
5. **保留历史版本**：每次生成都添加时间戳，所有版本都被保留，便于版本管理和对比

## 何时使用此技能

在以下情况下使用此技能：
- 用户提供需求文档并请求生成测试用例
- 用户要求从产品规格说明或设计文档创建测试用例
- 用户需要将现有需求文档转换为测试用例
- 用户提到关键词如"测试用例"、"test cases"、"需求文档"

**XMind生成触发条件**：
- 用户明确要求生成"思维导图格式"或"mindmap格式"
- 用户明确要求生成"xmind格式"
- 用户要求"同时生成md和xmind"

**默认行为**：仅生成Markdown格式的测试用例文档

## 工作流程

### 步骤0：初始化（必须最先执行）

**🚨 在执行任何其他步骤之前，必须先读取以下所有参考文档！这是强制要求，不可跳过。**

```
必须依次读取以下文件：
1. {skills_dir}/references/testcase_template.md   — 格式规范（生成文档必须严格遵守）
2. {skills_dir}/references/analysis_guide.md      — 需求分析方法和验证项生成示例
3. {skills_dir}/references/quality_standard.md    — 质量标准、命名规范、SMART原则
4. {skills_dir}/references/module_merge_guide.md  — 功能模块归并指南和示例
```

读取完毕后，将这些文档的内容作为后续所有步骤的执行依据。

### 步骤1：读取和分析需求文档

从提供的来源（文件路径或直接内容）读取需求文档内容。**这一步是测试用例质量的关键，必须深入分析，不能浮于表面。**

#### 1.1 文档读取

**重要提示**：
- 如果需求以URL形式提供（如飞书文档），**先尝试直接读取文档内容**，如果无法获取到内容，再尝试使用 `fetch-doc` 技能下载文档
- 如果需求以文件路径形式提供，直接读取文件内容
- 专注于文字内容，除非图片包含关键信息，否则忽略图片

#### 1.2 深度需求分析方法

**必须对需求进行深度分析，不要只停留在表面！** 详见 `references/analysis_guide.md`。

使用以下五种分析法逐句挖掘测试细节：
- **逐句分析法**：识别条件词/动作词/状态词/数据词，提取每个要素对应的验证项
- **业务流程分析法**：识别流程节点、判断分支、异常退出，每个节点都要有测试点
- **数据流分析法**：追踪数据获取→处理→存储→展示的完整链路
- **状态转换分析法**：识别所有状态及转换条件，每个状态转换都要有验证项
- **用户场景分析法**：从不同角色、正常/异常/极端场景角度分析

#### 1.3 分析结果整理

将分析结果整理为：功能模块清单、业务规则清单、异常场景清单、测试数据清单。

### 步骤2：生成Markdown测试用例文档

**重要提示**：必须严格遵守 `references/testcase_template.md` 中定义的格式规范！

#### 2.0 文件命名规则

**核心原则**：每次生成都添加时间戳后缀，便于版本管理和历史追溯

本技能使用自动化脚本为每个测试用例文件添加时间戳后缀，确保所有版本都被保留，便于对比和回溯。

##### 2.0.1 命名规则

**文件名格式**：
```
{需求文档名称}-v{MMdd_HHmmss}.md
{需求文档名称}-v{MMdd_HHmmss}.xmind
```

**时间戳格式**：
- 格式：`MMdd_HHmmss`（月日_时分秒）
- 示例：`0318_143052` 表示3月18日14:30:52

##### 2.0.2 使用方法

```bash
python3 scripts/generate_filename.py "<base_name>" "<output_dir>"
# 输出JSON：{"md_file": "...", "xmind_file": "...", "base_name": "..."}
```

#### 2.1 标准格式结构

按照以下标准结构创建Markdown测试用例文档：

```markdown
# {产品需求名称} - 测试用例

## 一、{功能模块名称}

### 1.1 {子功能名称}

#### 1.1.1 {功能点名称}
- **测试点：{测试点名称}**
  - [ ] {验证项1}
  - [ ] {验证项2}
  - [ ] {验证项3}

- **测试点：{测试点名称}**
  - [ ] {验证项1}
  - [ ] {验证项2}

### 1.2 {子功能名称}

#### 1.2.1 {功能点名称}
- **测试点：{测试点名称}**
  - [ ] {验证项1}
```

#### 2.2 格式规范要求

**必须遵守的格式规则**：

1. **标题层级规范**：
   - `# 一级标题`：产品名称（文档根标题）
   - `## 二级标题`：功能模块（使用"一、二、三、"等中文序号）
   - `### 三级标题`：子功能（使用"1.1、1.2、2.1、"等编号）
   - `#### 四级标题`：功能点（使用"1.1.1、1.1.2、"等编号）

2. **测试点格式规范**：
   - 必须使用粗体标记：`**测试点：XXX验证**`
   - 测试点名称应具体明确，描述验证目标
   - 示例：`**测试点：触发条件验证**`、`**测试点：展示验证**`

3. **验证项格式规范**：
   - 必须使用待办事项格式：`- [ ] 验证项内容`
   - 使用2个空格缩进表示层级关系
   - 每个验证项应具体、可执行、可验证
   - 避免模糊描述，如"验证功能正常"应改为"验证点击按钮后跳转到正确页面"

4. **文本处理规范**：
   - 保留粗体标记 `**文本**`
   - 支持emoji和特殊字符
   - 不使用checkbox标记 `[x]`，统一使用 `[ ]`

#### 2.3 测试用例生成质量标准

**生成测试用例时必须遵循以下质量标准**，详见 `references/quality_standard.md`。

**必须包含的测试类型**：功能测试、UI/UX测试、异常场景测试（网络/数据/并发/权限）
**建议包含的测试类型**：边界条件测试、性能测试、兼容性测试、安全测试

**测试点命名**：`{对象}{类型}验证`，如"触发条件验证"、"网络异常验证"、"登录流程验证"

**验证项编写（SMART原则）**：
- ❌ 错误：验证功能正常 → ✅ 正确：验证点击"提交"按钮后，表单数据成功提交到服务器
- ❌ 错误：页面加载快 → ✅ 正确：页面首次加载时间不超过2秒

**验证项数量**：**不设上限**，核心功能必须充分覆盖所有条件分支、业务规则、边界情况、异常处理、状态转换。每个可独立验证的点都应单独列出，不要人为合并。

#### 2.4 测试用例生成流程

生成测试用例时，请严格按照以下流程执行：

##### 2.4.1 需求分析阶段（最重要）

**目标：深入理解需求，挖掘所有测试细节**

1. **通读需求文档**：
   - 仔细阅读整个需求文档，不要跳过任何部分
   - 理解业务背景和目标用户
   - 识别关键业务流程和核心价值

2. **逐句分析需求**：
   - **对每一句话进行深度分析**，提取测试点
   - 标记所有条件判断（if/when/如果/当...时）
   - 标记所有动作操作（点击/输入/选择/提交等）
   - 标记所有状态变化（展示/隐藏/启用/禁用等）
   - 标记所有数据交互（创建/读取/更新/删除等）

3. **识别和归并功能模块**：
   
   **🚨 核心原则：按完整功能流程组织测试，而非按需求文档章节划分**，详见 `references/module_merge_guide.md`。
   
   归并判断标准：同一功能的不同维度/层次 → 归并为一个模块；不同功能 → 各自独立。
   
   每个功能模块按以下流程组织：触发条件验证 → 业务规则验证 → 数据准备验证 → 展示内容验证 → 交互行为验证 → 结果处理验证。

4. **提取业务规则**：
   - 记录所有的业务规则和约束条件
   - 每个规则都应转化为验证项
   - 注意隐含的业务逻辑

5. **挖掘异常场景**：
   - 思考每个功能可能的异常情况
   - 网络异常、数据异常、权限异常等
   - 边界条件和极限情况

6. **分析用户场景**：
   - 从用户角度思考使用场景
   - 考虑不同用户角色的行为
   - 考虑不同的使用环境

详细需求分析示例见 `references/analysis_guide.md`。

##### 2.4.2 测试点设计阶段

**目标：为每个功能点设计全面的测试点**

1. **逐个功能点分析**：
   - 不要遗漏任何功能点
   - 每个功能点至少包含一个测试点
   - 复杂功能点应拆分为多个测试点

2. **设计测试点类型**：
   - 功能验证类：验证功能是否按预期工作
   - 展示验证类：验证UI展示是否正确
   - 交互验证类：验证用户交互是否流畅
   - 异常验证类：验证异常处理是否合理
   - 性能验证类：验证性能指标是否达标
   - 安全验证类：验证安全措施是否到位

3. **考虑测试场景**：
   - 正向场景：正常的业务流程
   - 反向场景：异常和错误情况
   - 边界场景：临界值和极限值
   - 并发场景：多用户或多操作

##### 2.4.3 验证项编写阶段

**目标：为每个测试点编写详细可执行的验证项**

1. **细化每个测试点**：
   - 将测试点拆解为具体的验证步骤
   - 每个验证项对应一个可执行的测试操作
   - 不限制验证项数量，确保充分覆盖

2. **使用具体描述**：
   - 避免"验证功能正常"等模糊描述
   - 使用"验证点击XX按钮后，跳转到XX页面"等具体描述
   - 包含前置条件、操作步骤、预期结果

3. **覆盖所有细节**：
   - **不要遗漏需求中的任何细节**
   - 每个细节都应有对应的验证项
   - 宁可多写，不要少写

4. **标注测试数据**：
   - 明确测试所需的数据类型
   - 标注特殊的测试数据要求
   - 说明数据准备方法

##### 2.4.4 质量检查阶段

**目标：确保测试用例的完整性和准确性**

1. **需求覆盖检查**：
   - 对照需求文档，逐条检查是否有对应测试用例
   - 确保每个需求点都被覆盖
   - 不遗漏任何功能细节

2. **格式规范检查**：
   - 检查格式是否符合 testcase_template.md 规范
   - 检查标题层级是否正确
   - 检查验证项格式是否规范

3. **验证项质量检查**：
   - 检查验证项是否具体明确
   - 检查验证项是否可执行
   - 检查验证项是否有遗漏

4. **重复性检查**：
   - 检查是否有重复的测试点
   - 检查是否有重复的验证项
   - 合并或删除重复内容

#### 2.5 质量检查清单

生成测试用例后，必须进行以下检查：

**格式检查**：
- [ ] 标题层级是否正确（#、##、###、####）
- [ ] 测试点是否使用粗体标记
- [ ] 验证项是否使用 `- [ ]` 格式
- [ ] 缩进是否使用2个空格

**内容检查**：
- [ ] 是否覆盖所有功能模块
- [ ] 是否包含功能测试、异常测试、边界测试
- [ ] 验证项是否具体可执行
- [ ] 是否有遗漏的测试场景

**质量检查**：
- [ ] 测试点命名是否规范
- [ ] 验证项是否符合SMART原则
- [ ] 是否有重复的测试点或验证项
- [ ] 整体结构是否清晰易懂

### 步骤3：转换为XMind格式（可选）

**🚨 重要提示**：此步骤仅在用户明确要求生成"思维导图格式"或"xmind格式"时执行。默认情况下跳过此步骤。

生成Markdown文档后，如果用户要求思维导图格式，则使用转换脚本将其转换为XMind格式。

**重要提示**：转换脚本已内置格式处理逻辑，会自动遵循 testcase_template.md 中的转换规则。

#### 3.1 脚本位置

**`scripts/md_to_xmind.py`**：将Markdown测试用例文档转换为XMind格式的Python脚本

#### 3.2 使用方法

```bash
python3 {skills_dir}/scripts/md_to_xmind.py <input.md> <output.xmind> [title]
```

**参数说明**：
- `input.md`：生成的Markdown测试用例文档路径（必须符合testcase_template.md格式）
- `output.xmind`：输出的XMind文件路径
- `title`：（可选）XMind工作表标题，默认为"测试用例"

#### 3.3 转换规则

脚本会自动按照以下规则进行转换：

**Markdown到XMind的映射**：

| Markdown元素 | XMind元素 | 说明 |
|-------------|----------|------|
| `# 一级标题` | 根主题 | 产品名称 |
| `## 二级标题` | 一级子主题 | 功能模块 |
| `### 三级标题` | 二级子主题 | 子功能 |
| `#### 四级标题` | 三级子主题 | 功能点 |
| `- **测试点：XXX**` | 四级子主题 | 测试点（带蓝色星标） |
| `  - [ ] 验证项` | 五级子主题 | 验证项（带绿色旗帜标记） |

**特殊处理**：
1. **Checkbox转换**：`[ ]` → `☐`（未完成状态）
2. **粗体处理**：保留粗体文本内容，移除`**`标记
3. **层级判断**：
   - 标题层级：根据`#`数量判断
   - 列表层级：根据缩进空格数判断（每2个空格一级）

#### 3.4 输出结果

转换完成后生成：
- **有效的XMind 3.0+格式文件**
- 可在XMind或XMind Zen中正常打开
- 保留完整的层次结构和格式
- 支持进一步的编辑和美化

### 步骤4：展示结果

完成测试用例生成后，必须向用户展示完整的测试用例文档和统计信息。

#### 4.1 展示内容

1. **展示Markdown文件**：
   - 使用 `open_result_view` 显示生成的测试用例文档
   - 让用户可以查看和编辑Markdown源文件

2. **报告统计信息**：
   - 总测试点数量
   - 总验证项数量
   - 按模块分类的覆盖情况
   - 测试类型分布（功能测试、异常测试、性能测试等）

3. **提供XMind文件路径**（仅当生成了XMind时）：
   - 告知用户XMind文件的完整路径
   - 说明文件大小和节点数量

4. **提供测试建议**：
   - 测试优先级建议（P0、P1、P2、P3）
   - 重点测试模块提示
   - 测试风险提示
   - 测试环境准备建议

#### 4.2 质量报告

向用户提供测试用例质量报告：

```
📊 测试用例统计信息：
- 总测试点数：XX个
- 总验证项数：XX个
- 平均每个测试点验证项数：XX个

📈 测试覆盖情况：
- 功能测试：XX个测试点（XX%）
- 异常测试：XX个测试点（XX%）
- 性能测试：XX个测试点（XX%）
- 兼容性测试：XX个测试点（XX%）

✅ 质量检查结果：
- 格式规范：通过
- 完整性检查：通过
- 具体性检查：通过
```

## 打包资源

### 脚本

**`scripts/generate_filename.py`**：测试用例文件名生成器，自动添加时间戳后缀
- 每次生成都添加时间戳后缀（格式：-vMMdd_HHmmss）
- 输出JSON格式的文件路径，便于程序调用
- 使用方法：`python3 scripts/generate_filename.py "<base_name>" "<output_dir>"`

**`scripts/md_to_xmind.py`**：将Markdown测试用例文档转换为XMind格式的Python脚本
- 支持多级标题层次结构
- 保留测试点格式
- 转换复选框标记（☐表示未选中，☑表示已选中）
- 生成有效的XMind 3.0+格式

### 参考资料

**`references/testcase_template.md`**：测试用例文档格式规范（标准结构、格式示例、XMind映射规则）

**`references/analysis_guide.md`**：需求深度分析指南（逐句分析法、业务流程/数据流/状态转换/用户场景分析法、验证项生成详细示例）

**`references/quality_standard.md`**：测试用例质量标准（测试覆盖类型、命名规范、SMART原则、最佳实践、测试覆盖清单）

**`references/module_merge_guide.md`**：功能模块归并指南（章节关系识别、归并判断标准、测试结构设计、归并示例）

## 最佳实践

详见 `references/quality_standard.md`，包含：SMART原则详细说明、测试点组织原则（按模块/功能/场景/优先级P0~P3）、测试覆盖清单（必测/重要/可选场景）。

## 使用示例

所有场景的通用步骤：**获取文档内容 → 深度分析需求 → 生成测试用例 → 质量检查 → 展示结果**

### 示例1：本地文档生成测试用例
**用户**："根据这份需求文档生成测试用例"
→ 直接读取文件 → 分析需求 → 生成Markdown → 展示结果+统计信息

### 示例2：生成思维导图格式
**用户**："根据这份需求文档生成思维导图格式的测试用例"
→ 读取文档 → 生成Markdown → **执行XMind转换脚本** → 展示Markdown+告知XMind路径

### 示例3：从在线文档（飞书/腾讯文档等）生成测试用例
**用户**："根据这个飞书文档 https://xxx.feishu.cn/xxx 生成测试用例"
1. **先尝试直接读取URL内容**；如果无法获取，使用 `fetch-doc` 技能下载文档
2. 分析需求 → 生成Markdown（如需XMind则同时转换）→ 展示结果

## 注意事项

### 格式要求
- **必须严格遵守** `references/testcase_template.md` 中定义的格式规范
- 所有生成的测试用例文档必须符合标准Markdown格式
- 转换脚本依赖标准格式，格式错误可能导致转换失败

### 质量保障
- 测试用例质量取决于需求文档的清晰度和完整性
- 每个验证项必须具体、可执行、可验证
- 必须包含功能测试、异常测试、边界测试等多种测试类型
- 生成后必须进行质量检查

### 使用限制
- 本技能专注于从需求文档生成测试用例
- 不支持从代码或数据库生成测试用例
- 对于非常大的文档，建议拆分为多个模块分别生成
- 图片内容会被忽略，只处理文字信息

### 输出格式
- **默认输出**：仅生成Markdown格式
- **XMind触发条件**：用户明确要求"思维导图格式"或"xmind格式"时才生成
- Markdown文档便于版本控制和协作编辑
- XMind思维导图便于可视化展示和评审

### 后续维护
- 需求变更时需要重新生成测试用例
- 建议定期review和更新测试用例
- 可以手动编辑Markdown文档后重新转换为XMind

### 常见问题

- **格式不正确**：检查是否符合 `testcase_template.md` 规范，重新生成
- **XMind转换失败**：检查Markdown标题层级和测试点格式是否规范
- **覆盖不全**：提供更详细的需求文档，或手动补充遗漏场景
- **文件名时间戳**：每次生成自动添加 `-vMMdd_HHmmss` 后缀，保留所有历史版本
- **只生成XMind**：不支持，XMind必须从Markdown转换，两种格式同时生成