testcase-generator skill

---
name: testflow-generator
description: 基于 TestFlow 四阶段工作流的智能测试用例生成器。当用户需要为 Story/需求/缺陷生成测试用例、创建 Markdown 格式的 markmap 思维导图测试用例、根据技术方案设计测试场景、或者需要生成测试覆盖矩阵时使用。支持功能测试、边界测试、异常测试、兼容性测试、性能测试、安全测试等多种测试类型。
---

# TestFlow 智能测试用例生成器

基于 TestFlow 四阶段工作流的智能测试用例生成 Skill，从需求文档自动生成 **混合结构 Markdown** 格式的测试用例（可用 markmap 渲染）。

## MCP 服务器依赖

**重要**：此 Skill 依赖以下 MCP 服务器，使用前请确保已配置：

| MCP 服务器 | 用途 | 必需 |
|-----------|------|------|
| `lark-prj-remote` | 读取飞书项目单子（描述、验收标准） | 是（使用飞书项目单时） |
| `lark-mcp-remote` | 读取飞书云文档（技术设计文档） | 是（使用飞书文档时） |

**注意**：如果仅使用本地文件生成测试用例，无需配置 MCP 服务器。

### 检测 MCP 配置

在使用此 Skill 前，首先检测 MCP 是否已配置：

1. 尝试调用 `mcp__lark-prj-remote__get_workitem_info` 或 `mcp__lark-mcp-remote__docx_builtin_search`
2. 如果返回 "MCP server not found" 或类似错误，说明未配置
3. 此时应引导用户配置 MCP

### 引导用户配置 MCP

如果检测到 MCP 未配置，请输出以下引导信息：

```
检测到飞书 MCP 服务器未配置。

请按以下步骤配置：

1. 获取飞书应用凭证：
   - 访问 https://open.feishu.cn/
   - 创建应用并获取 App ID 和 App Secret

2. 配置飞书项目 MCP (lark-prj-remote)：

   claude mcp add --transport stdio lark-prj-remote \
     --env LARK_APP_ID=YOUR_APP_ID \
     --env LARK_APP_SECRET=YOUR_APP_SECRET \
     -- npx -y @anthropic/claude-code-mcp-lark-prj

3. 配置飞书文档 MCP (lark-mcp-remote)：

   claude mcp add --transport stdio lark-mcp-remote \
     --env LARK_APP_ID=YOUR_APP_ID \
     --env LARK_APP_SECRET=YOUR_APP_SECRET \
     -- npx -y @anthropic/claude-code-mcp-lark

4. 重启 Claude Code 后重试

或者运行 /testflow-generator:check-mcp 查看详细配置指南。
```

## 功能概述

采用经过验证的 **四阶段渐进式生成流程**：

```
需求文档
    ↓
[阶段1] 需求分析
    ↓ → 需求点列表
[阶段2] 测试点生成
    ↓ → 测试点列表（遵循二八法则）
[阶段3] 用例设计
    ↓ → 测试用例
[阶段4] 智能优化
    ↓
Markdown 文件（可用 markmap 渲染）
```

## 触发关键词

以下关键词会触发此 Skill：

- "生成测试用例"
- "Markdown 测试用例"
- "markmap 测试用例"
- "XMind 测试用例"
- "飞书项目单子测试"
- "为这个需求生成用例"
- "创建测试用例思维导图"
- 提供飞书项目 URL

## 使用流程

### 第一步：解析输入来源

支持三种输入类型：

1. **飞书项目单 URL**
   ```
   https://project.feishu.cn/{project_key}/story/detail/{work_item_id}
   ```

2. **飞书云文档 URL**
   ```
   https://xxx.feishu.cn/docx/{doc_token}
   ```

3. **本地文件路径**
   ```
   ./docs/requirement.md
   ```

### 第二步：获取单子信息

使用飞书项目 MCP 工具：

```
mcp__lark-prj-remote__get_workitem_brief
  - project_key: 从 URL 提取
  - work_item_id: 从 URL 提取
  - fields: ["description", "field_803289", "field_13a9cf", "field_3437d3"]
```

关键字段：
- `description`: 需求描述
- `field_803289`: 验收标准
- `field_13a9cf`: 技术设计文档链接

### 第三步：读取技术设计文档

如果存在技术设计文档链接，使用飞书 MCP 读取：

```
mcp__lark-mcp-remote__docs_v1_content_get
  - query:
      doc_token: 从链接提取
      doc_type: docx
      content_type: markdown
```

**重要**：
- 可能存在多个文档链接，需要全部读取
- 识别文档类型并分类（PRD文档 vs 架构设计文档）

### 第四步：网络搜索测试参考（可选）

根据需求涉及的技术栈和功能类型，使用 `WebSearch` 工具搜索相关测试参考：

**搜索场景：**

| 场景 | 搜索关键词示例 | 目的 |
|------|---------------|------|
| 协议/SDK 测试 | `{协议名} testing best practices` | 获取协议测试要点 |
| API 测试 | `{API类型} API test cases` | 参考 API 测试场景 |
| UI 测试 | `{框架名} UI testing checklist` | UI 测试覆盖点 |
| 安全测试 | `{功能类型} security test cases` | 安全测试场景 |
| 性能测试 | `{技术栈} performance testing` | 性能测试指标 |

**使用方式：**

```
WebSearch
  - query: "{技术关键词} test cases best practices"
```

**注意事项：**
- 仅在需求涉及特定技术协议、框架或安全相关功能时使用
- 搜索结果用于补充测试场景，不替代基于需求的用例设计
- 将搜索获得的测试要点整合到对应的测试分类中

### 第五步：分析PRD的UI和交互设计

**此步骤为必须执行步骤，不可跳过！**

从PRD文档中提取并分析：

1. **界面架构分析**：整体布局、各区域功能
2. **UI组件清单**：按钮、输入框、卡片等
3. **交互流程分析**：点击、拖拽、页面切换
4. **状态显示**：在线/离线、成功/失败
5. **多语言/主题**：语言切换、主题切换

### 第六步：梳理用户操作流程

**重要：请先在内部仔细梳理清楚用户每一步骤的操作流程和选择的路径分支，确保理解完整后再进行后续步骤。**

1. **识别主要功能模块**
2. **绘制用户操作路径**：主流程、分支流程、异常流程
3. **识别状态切换点**：初始状态、中间状态、终止状态
4. **绘制用户流程图**（内部思考）
   - 入口点：用户从哪里开始
   - 决策点：用户在哪些节点需要做选择
   - 分支路径：每个选择导向的不同结果
   - 终点：各路径的最终状态

### 第七步：设计测试用例

**重要：根据上一步梳理的用户流程图和功能点，结合基本测试方法生成测试用例。测试方法可参考网络搜索中获取的相关用例和最佳实践。**

**必须按以下顺序设计测试用例**

#### 7.1 验收标准覆盖检查（必须）

首先逐条分析验收标准，确保每条都有对应的测试用例。

#### 7.2 PRD UI/交互设计测试用例（必须）

| 子分类 | 测试内容 | 优先级 |
|--------|----------|--------|
| 界面布局 | 各区域位置、大小、显示/隐藏 | P0 |
| 组件显示 | 按钮、卡片、面板等 | P0 |
| 交互操作 | 点击、拖拽、输入、切换 | P0 |
| 状态显示 | 在线/离线、已连接/未连接 | P0 |
| 主题切换 | 深色/浅色主题 | P1 |
| 多语言 | 语言切换、文案正确性 | P1 |

#### 7.3 功能和技术测试用例

| 分类 | 说明 | 典型优先级 |
|------|------|-----------|
| 编译/构建测试 | 编译验证 | P0 |
| 功能测试 | 核心功能验证 | P0 |
| 状态切换测试 | 状态转换正确性 | P0-P1 |
| 边界值测试 | 最大值、最小值、默认值 | P1 |
| 异常场景测试 | 错误处理、异常恢复 | P0-P1 |
| 兼容性测试 | 多平台、多配置 | P1-P2 |
| 稳定性测试 | 重复操作、极端场景 | P2 |

### 第八步：输出 Markdown 文件

生成路径：`~/Testcase/markmap/{工作项名称}_测试用例_markmap_{时间戳}.md`

时间戳格式：`YYYYMMDD_HHmmss`（如 `20250106_143052`）

## 测试用例格式规范

### 结构要求

每条测试用例采用 **7 层混合结构**（标题 + 无序列表）：

```
# 文档标题
  └── ## 模块名
        └── ### 用例名称
              └── - 前置条件
                    └──   - 执行步骤
                          └──     - 预期结果
                                └──       - 优先级
```

### Markdown 格式示例

```markdown
# 测试用例集

## 1. 功能模块

### 测试用例名称
- 前置条件描述
  - 执行步骤描述
    - 预期结果描述
      - P0
```

### 优先级定义

| 优先级 | 说明 | 适用场景 |
|--------|------|----------|
| P0 | 核心功能，必须测试 | 编译验证、主流程、关键状态转换、验收标准相关 |
| P1 | 重要功能，应该测试 | 配置参数、异常处理、边界条件 |
| P2 | 次要功能，可选测试 | 辅助功能、日志调试、稳定性测试 |

## 测试用例编写原则

### 用例名称
- 简洁明了，格式：`{功能点}{测试场景}`
- **禁止在用例名称前添加编号**（如 `1.` `1.1` `TC001` 等）
- 例：`登录功能-正确密码登录成功`

### 前置条件
- 说明测试开始前必须满足的条件
- 例：`用户已注册，处于登出状态`

### 执行步骤
- 具体的操作步骤，简洁描述（1-3句话）
- 例：`输入正确用户名和密码，点击登录按钮`

### 预期结果
- 明确、可量化、可观测的验证点
- 例：`登录成功，跳转到首页，显示用户信息`

## 示例

### 输入示例

```
帮我为这个飞书项目单子生成测试用例：
https://project.feishu.cn/uts5wn/story/detail/6596729761
```

### 处理流程

1. 解析得到 `project_key=uts5wn`, `work_item_id=6596729761`
2. 调用 MCP 获取单子信息
3. 解析技术设计文档链接，获取文档内容
4. 识别功能模块和状态流程
5. 生成分类测试用例

### 输出

生成 Markdown 文件 `~/Testcase/markmap/{需求名称}_测试用例_markmap_{时间戳}.md`