Testcase Creator

通用测试用例生成器技能

概述

本技能自动化从需求文档生成测试用例文档的过程。它分析需求内容、提取功能模块和测试点、生成结构化的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形式提供（如飞书文档），先尝试直接读取文档内容，如果无法获取到内容，再尝试找其他相关技能来下载文档
• 如果需求以文件路径形式提供，直接读取文件内容
• 专注于文字内容，除非图片包含关键信息，否则忽略图片

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 使用方法

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

2.1 标准格式结构

按照以下标准结构创建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原则
• 是否有重复的测试点或验证项
• 整体结构是否清晰易懂