一、为什么要写这个 Skill

背景：AI 编程助手很强大，但通用对话写测试用例不够系统
痛点：每次都要重复描述需求、格式不统一、覆盖度靠人工保证
目标：让 Claude 按固定方法论 + 固定格式输出测试用例
成果预览：一个触发词 + 一次对话 = 完整测试用例表格

二、什么是 Skill

Skill 的本质：给 AI 封装“能力模块”
与普通 prompt 的区别：结构化、可复用、可约束行为
Claude Code Skill 本质上是一个包含 SKILL.md 文件的文件夹。这个文件夹可以被 Claude 按需发现和加载，从而赋予 Claude 完成特定任务的专业能力。
它不是可执行的程序代码，而是一种动态的上下文增强机制——当 Claude 判断某个 Skill 与当前任务相关时，会将这个 Skill 的指令注入到对话上下文中，指导 Claude 如何完成任务。

1.核心结构：SKILL.md 文件

每个 Skill 的核心是一个名为 SKILL.md 的 Markdown 文件。这个文件由两个关键部分组成：

YAML 前置元数据（Frontmatter）

文件开头用 — 包裹的 YAML 格式元数据，用于 Claude 的发现和匹配：

---
name: your-skill-name
description: 简要描述该技能的功能以及何时使用
---

Markdown 指令正文

元数据之后是正文，用自然语言编写，告诉 Claude 具体怎么做。

2.文件夹结构

your-skill/
├── SKILL.md # 核心指令文件（必须）
├── reference # 详细参考文档（按需加载）
├── examples # 更多示例
├── templates/ # 模板文件
└── scripts/ # 可执行脚本

3.存储位置

类型	路径	适用范围
个人 Skills	~/.claude/skills/	当前用户的所有项目
项目 Skills	.claude/skills/	当前代码库，可提交 Git 与团队共享
插件 Skills	插件包内的 skills/ 目录	安装插件的用户

三、整体设计思路

核心问题拆解：

如何让 AI 理解功能需求？

将需求文档资料放在test_input/prd目录下，让AI读取并解析该目录下的需求文档。

因为我们项目的需求和原型需要汇总处理，所以我一般会使用xmind将需求进行初步整理拆解，因此我会将xmind文件作为需求输入文件，为了让AI快速读取xmind文件，我让AI成功读取xmind后将读取步骤也封装成了一个skill：xmind-reader

---

### 第一步：需求深度分析

**调用工具**: `xmind-reader`

1. 检查 `test_input/{版本 + 需求名称}/prd/` 下是否有 xmind 格式的需求
   - 如有需求文件，调用：
     ```bash
     python .claude/skills/xmind-reader/xmind-reader.py "test_input/{版本}/{需求}/prd/*.xmind" -f tree
     ```
   - 如无需求文件，向用户提问："请提供需求文档（XMind 文件）或原型说明，以便进行用例设计"

3. 识别业务核心流程、关键功能模块及潜在依赖

4. 提取业务规则、输入输出，识别隐含需求和边界条件

5. 列出需要澄清的模糊点或缺失的信息

**本步输出**: 需求分析结果（供第二步使用）

---

如何让 AI 应用测试方法？

将测试方法编码为可执行规则：

### 二、测试设计技术（黑盒测试方法）
**1. 等价类划分**
- **有效等价类**：符合需求的输入数据
- **无效等价类**：不符合需求的输入数据
- 应用场景：输入框校验、数据类型验证

**2. 边界值分析**
- 关注输入域的边界：最小值、最大值、空值、极大值
- 典型边界：0、1、最大值、最大值 +1、空字符串、超长字符串
- 应用场景：数值输入、文本长度、时间范围、分页页码

**3. 场景法（流程分析法）**
- **基本流**：用户正常操作流程
- **备选流**：其他合法操作路径
- **异常流**：错误操作或异常条件
- 应用场景：多步骤流程、状态变迁、端到端业务

**4. 状态迁移法**
- 识别业务对象的所有状态
- 定义状态转换条件和触发事件
- 验证合法转换和非法转换
- 应用场景：订单状态、审批流程、任务生命周期

**5. 判定表法**
- 适用于多条件组合的业务规则
- 列出所有条件桩和动作桩
- 生成条件组合并确定预期动作
- 应用场景：权限控制、费用计算、规则引擎

**6. 正交分析法**
- 从全面组合中选取代表性组合
- 减少测试用例数量同时保证覆盖率
- 应用场景：多条件筛选、配置组合测试

如何保证输出格式统一？

精确格式模板 + 负向约束 ：

### 第四步：测试用例模板确认

**调用工具**: `excel-reader`

1. 使用 `excel-reader` 读取 `test-case-design/examples/testcases/` 下的 Excel 格式测试用例模板
   ```bash
   python .claude/skills/excel-reader/excel-reader.py "test-case-design/examples/testcases/*.xlsx" --json
   `` `
2. 分析模板结构，理解每个字段的含义
3. 学习历史编写习惯

**学习要点**:
- 前置条件粒度：数据少时指定具体名称，数据多时概括描述
- 步骤描述粒度：核心/首次操作详细，重复/相似操作概括
- 预期对应关系：步骤数=预期数，一一对应
- 用例命名习惯：自由描述，不体现预期结果
- 优先级划分标准：1 级核心正向/冒烟，2 级重要功能，3 级完整验证，4 级增强探索

**本步输出**: 模板规范（供第六步使用）

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

基于第四步确认的模板，设计测试用例转化策略。

**设计原则**:

1. **可执行性原则**（强制）：每个测试用例必须能被任何人独立执行
   - **前置条件**：环境要求、数据准备、系统状态
   - **测试步骤**：操作顺序、输入数据、操作描述
   - **预期结果**：可验证断言、数据变化、状态变化

2. **单一验证原则**（强制）：一个测试用例只验证一个核心业务场景或规则
   - 正向连续操作可合并为一个用例
   - 反向校验、边界值、无效等价类：每个独立场景拆分为独立用例
   - 端到端流程测试除外（验证流程完整性是单一业务目标）

3. **用例命名规范**（强制）:
   - 名称体现场试工作内容，精简控制在 20 字以内
   - 不包含预期结果
   - 不使用数字前缀（如：1、2、3、）
   - 不使用【】等符号标记模块、按钮等内容
   - ✅ 示例：`正确密码登录 `、`错误密码登录 `、` 空用户名登录`
   - ❌ 示例：`1、【登录】输入正确密码，登录成功`

4. **格式规范**（强制）:
   - 前置条件、步骤、预期内容换行分隔
   - **前置条件使用编号 1. 2. 3.**
   - 步骤与预期严格一一对应，步骤数=预期数
   - 每个前置条件/步骤/预期使用编号（1. 2. 3.）开头

5. **用例拆分/合并原则**:
   - 正向连续操作类（连续添加、批量操作）：合并为一个用例
   - 反向校验、边界值、无效等价类：每个独立场景拆分为独立用例

6. **用户视角原则**: 单个用例保持视角一致，核心完整流程可跨角色合并

7. **用例独立性**: 用例之间无显式依赖，数据通过前置条件准备

8. **步骤数量控制**: 每个用例不超过 5 条操作步骤

9. **预期可验证**: 不写"正确显示"，写具体内容和跳转动作

10. **测试数据具体**: 不写"合法值"，写"张三"

**不同测试类型的转化要点**:

| 测试类型 | 特点 | 转化要点 |
|---|---|---|
| 正向/反向测试 | 验证需求功能是否实现 | 覆盖所有需求条目，按用户操作习惯设计步骤，预期结果明确对应需求描述 |
| 异常/边界测试 | 验证系统健壮性 | 明确异常触发条件，预期结果强调"优雅失败"，关注错误提示准确性 |
| 模块交互测试 | 验证模块间交互和数据流 | 关注接口和数据边界，验证数据一致性，包含异常数据流测试 |
| 用户场景测试 | 验证端到端业务体验 | 业务闭环，使用真实数据流，多角色协同，状态流转验证 |

**本步输出**: 设计策略（供第六步使用）

四、Skill 结构设计

1. 元信息：名称、触发条件、适用场景

---
name: test-case-design
description: >
  根据需求描述设计测试用例。综合运用等价类划分、边界值分析、场景法等方法，生成结构化的测试用例文档。当用户提到"设计用例""写测试用例""帮我出用例""测试点分析"时触发。
---

2. 角色设定

# 测试用例设计助手
你是一名经验丰富的软件测试工程师，擅长将复杂需求转化为系统化、可执行的测试方案。

3. 核心方法论

## 核心方法论

### 一、功能点定义（强制）

**功能点 ≠ 需求点**：不是直接复制 XMind 中的需求描述

**功能点定义标准**（同时满足）：
|维度|说明|
|---|---|
|可观测|有明确的输入/输出或状态变化|
|可测试|可以设计测试用例来验证|
|原子性|不可再分的最小可测单元|
|业务价值|对用户有明确的业务意义|

**功能点分类**（按交互模式）：
1. **数据展示类**：列表页、详情页、仪表板/数据看板
2. **数据操作类**：表单页（新增/编辑/搜索）、批量操作、导入/导出
3. **流程类**：向导/多步骤流程、审批/工作流
4. **交互类**：搜索、筛选/过滤、排序
5. **系统功能类**：用户账户管理、权限/角色管理、系统配置
6. **特殊功能类**：文件管理、消息/通知、支付功能

**功能点梳理原则**：
- **以页面/二级页为单位**：每个功能子模块的页面、二级页为单位梳理功能
- **功能类型**：列表展示功能、搜索功能、新增功能、编辑功能、详情功能、删除功能、导入导出功能等

### 二、测试设计技术（黑盒测试方法）

**1. 等价类划分**
- **有效等价类**：符合需求的输入数据
- **无效等价类**：不符合需求的输入数据
- 应用场景：输入框校验、数据类型验证

**2. 边界值分析**
- 关注输入域的边界：最小值、最大值、空值、极大值
- 典型边界：0、1、最大值、最大值 +1、空字符串、超长字符串
- 应用场景：数值输入、文本长度、时间范围、分页页码

**3. 场景法（流程分析法）**
- **基本流**：用户正常操作流程
- **备选流**：其他合法操作路径
- **异常流**：错误操作或异常条件
- 应用场景：多步骤流程、状态变迁、端到端业务

**4. 状态迁移法**
- 识别业务对象的所有状态
- 定义状态转换条件和触发事件
- 验证合法转换和非法转换
- 应用场景：订单状态、审批流程、任务生命周期

**5. 判定表法**
- 适用于多条件组合的业务规则
- 列出所有条件桩和动作桩
- 生成条件组合并确定预期动作
- 应用场景：权限控制、费用计算、规则引擎

**6. 正交分析法**
- 从全面组合中选取代表性组合
- 减少测试用例数量同时保证覆盖率
- 应用场景：多条件筛选、配置组合测试

### 三、测试点分析维度

1. **功能正确性验证**（基础层）：正常流程验证、输入输出验证、界面元素验证
2. **业务逻辑深度**（核心层）：业务规则验证、状态机完整性、数据一致性、权限控制验证
3. **异常与边界**（防御层）：异常流程验证、边界值分析、错误恢复能力、兼容性验证
4. **集成与端到端**（系统层）：端到端流程、数据流完整性、系统集成点
5. **用户体验与业务价值**（拓展层）：可用性验证、性能体验、业务目标支持

### 四、常见功能测试点覆盖清单

**列表页测试点**：
- 数据展示：数据准确性、完整性、空状态处理、格式与样式
- 分页测试：分页控件显示、导航按钮、数据一致性、分页与筛选/排序联动
- 查询/筛选：基础搜索、高级筛选、实时搜索、重置功能
- 排序功能：单列排序、多列排序、排序状态指示器、默认排序规则
- 列表操作：行内操作、批量操作、操作项启用/禁用条件

**表单页测试点**：
- 输入框校验：必填项、等价类、边界值、数据类型、特殊字符
- 下拉框：选择性和可填性、模糊匹配、二级联动
- 单选/复选框：独选型、多选型
- 时间选择：开始/结束时间关系、时间格式化
- 提交按钮：回车/单击支持、防重复提交、弱网提交、提交后提示、权限校验
- 业务约束：业务规则校验、状态依赖校验

**导入导出测试点**：
- 导入：正常流程、文件格式支持、文件类型异常、文件内容异常、数据格式异常、业务逻辑异常
- 导出：正常流程、导出范围、导出内容、资源限制
- 模板：模板下载、模板格式、说明 sheet 页

**文件上传测试点**：
- 文件类型限制、脚本文件拦截、文件内容校验
- 浏览后删除文件、超大文件处理
- 文件命名冲突处理、存储方式验证

4. 工作流程：6 步执行顺序

### 第一步：需求深度分析

**调用工具**: `xmind-reader`

1. 检查 `test_input/{版本 + 需求名称}/prd/` 下是否有 xmind 格式的需求
   - 如有需求文件，调用：
     ```bash
     python .claude/skills/xmind-reader/xmind-reader.py "test_input/{版本}/{需求}/prd/*.xmind" -f tree
     ```
   - 如无需求文件，向用户提问："请提供需求文档（XMind 文件）或原型说明，以便进行用例设计"

3. 识别业务核心流程、关键功能模块及潜在依赖

4. 提取业务规则、输入输出，识别隐含需求和边界条件

5. 列出需要澄清的模糊点或缺失的信息

**本步输出**: 需求分析结果（供第二步使用）

---

### 第二步：功能点分解

基于第一步的需求分析结果，你将需求分解为原子化的功能点清单。

**功能点定义**（强制）:
- **功能点 ≠ 需求点**：不是直接复制 XMind 中的需求描述
- **以页面/二级页为单位**：每个功能子模块的页面、二级页为单位梳理功能
- **功能类型**：列表页、搜索功能、新增功能、编辑功能、详情功能、导入导出功能等
- **判断标准**：
  - 有明确的页面载体（列表页、详情页、弹窗等）
  - 可独立操作的功能单元（搜索、新增、编辑、删除、查看等）
  - 可测试（可设计用例验证）
  - 有业务价值

**本步输出**: 功能点清单（供第三步使用）

---

### 第三步：测试点分析与输出

基于**第二步输出的每个功能点**，系统化分析测试点。

**覆盖维度**（每个功能点至少覆盖）:
1. 正向流程：基础操作、核心链路
2. 输入域验证：边界值、等价类、格式校验、空值处理、极大值输入
3. 业务规则校验：针对存在业务约束条件、状态依赖的功能，需从约束条件反向推导测试点
4. 异常场景：网络/超时、数据异常

**测试点定义**: 描述"怎么测"，即操作和验证动作，不含预期结果

**输出路径**（强制）:
- 文件路径：`test_output/{版本需求名称}/testpoint/{版本} 测试点.md`
- 示例：`test_output/v1.11.2.8 济源 3 月 20 日需完成任务/testpoint/v1.11.2.8 济源测试点.md`

**本步输出**: Markdown 格式测试点文档，保存到上述路径

---
### 第四步：测试用例模板确认

**调用工具**: `excel-reader`

1. 使用 `excel-reader` 读取 `test-case-design/examples/testcases/` 下的 Excel 格式测试用例模板
   `` `bash
   python .claude/skills/excel-reader/excel-reader.py "test-case-design/examples/testcases/*.xlsx" --json
   `` `
2. 分析模板结构，理解每个字段的含义
3. 学习历史编写习惯

**学习要点**:
- 前置条件粒度：数据少时指定具体名称，数据多时概括描述
- 步骤描述粒度：核心/首次操作详细，重复/相似操作概括
- 预期对应关系：步骤数=预期数，一一对应
- 用例命名习惯：自由描述，不体现预期结果
- 优先级划分标准：1 级核心正向/冒烟，2 级重要功能，3 级完整验证，4 级增强探索

**本步输出**: 模板规范（供第六步使用）

---

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

基于第四步确认的模板，设计测试用例转化策略。

**设计原则**:

1. **可执行性原则**（强制）：每个测试用例必须能被任何人独立执行
   - **前置条件**：环境要求、数据准备、系统状态
   - **测试步骤**：操作顺序、输入数据、操作描述
   - **预期结果**：可验证断言、数据变化、状态变化

2. **单一验证原则**（强制）：一个测试用例只验证一个核心业务场景或规则
   - 正向连续操作可合并为一个用例
   - 反向校验、边界值、无效等价类：每个独立场景拆分为独立用例
   - 端到端流程测试除外（验证流程完整性是单一业务目标）

3. **用例命名规范**（强制）:
   - 名称体现场试工作内容，精简控制在 20 字以内
   - 不包含预期结果
   - 不使用数字前缀（如：1、2、3、）
   - 不使用【】等符号标记模块、按钮等内容
   - ✅ 示例：`正确密码登录 `、`错误密码登录 `、` 空用户名登录`
   - ❌ 示例：`1、【登录】输入正确密码，登录成功`

4. **格式规范**（强制）:
   - 前置条件、步骤、预期内容换行分隔
   - **前置条件使用编号 1. 2. 3.**
   - 步骤与预期严格一一对应，步骤数=预期数
   - 每个前置条件/步骤/预期使用编号（1. 2. 3.）开头

5. **用例拆分/合并原则**:
   - 正向连续操作类（连续添加、批量操作）：合并为一个用例
   - 反向校验、边界值、无效等价类：每个独立场景拆分为独立用例

6. **用户视角原则**: 单个用例保持视角一致，核心完整流程可跨角色合并

7. **用例独立性**: 用例之间无显式依赖，数据通过前置条件准备

8. **步骤数量控制**: 每个用例不超过 5 条操作步骤

9. **预期可验证**: 不写"正确显示"，写具体内容和跳转动作

10. **测试数据具体**: 不写"合法值"，写"张三"

**不同测试类型的转化要点**:

| 测试类型 | 特点 | 转化要点 |
|---|---|---|
| 正向/反向测试 | 验证需求功能是否实现 | 覆盖所有需求条目，按用户操作习惯设计步骤，预期结果明确对应需求描述 |
| 异常/边界测试 | 验证系统健壮性 | 明确异常触发条件，预期结果强调"优雅失败"，关注错误提示准确性 |
| 模块交互测试 | 验证模块间交互和数据流 | 关注接口和数据边界，验证数据一致性，包含异常数据流测试 |
| 用户场景测试 | 验证端到端业务体验 | 业务闭环，使用真实数据流，多角色协同，状态流转验证 |

**本步输出**: 设计策略（供第六步使用）

---
### 第六步：测试用例输出

基于**第三步输出的测试点**，按照**第四步确认的模板格式**，应用**第五步的设计策略**，逐条转化测试点为测试用例。

**转化规则**:
1. 将审阅通过的测试点，严格遵循确认的模板和策略，转化为可执行的测试用例
2. 格式要求：
   - 用例编号、用例名称、前置条件、步骤、预期、优先级完整输出
   - 步骤与预期严格一一对应
   - 优先级使用1/2/3/4，不使用P1/P2/P3/P4
3. 前置条件、步骤、预期：使用实际换行，不是 `\n` 字符
4. 调用 `test-case-export` 脚本输出为 Excel

**输出路径**（强制）:
- 文件路径：`test_output/{版本需求名称}/testcase/{版本} 功能测试用例.xlsx`
- 示例：`test_output/v1.11.2.8 济源 3 月 20 日需完成任务/testcase/v1.11.2.8 功能测试用例.xlsx`
- **必须输出为 .xlsx 格式**

**输出格式**: Excel

| 列名 | 说明 |
|------|------|
| 所属模块 | /平台/模块 路径 |
| 用例名称 | 精简≤20 字，无预期，无前缀|
| 前置条件 | 1.2.3.编号，换行分隔 |
| 步骤 | 1.2.3.编号，换行分隔 |
| 预期 | 与步骤一一对应，换行分隔 |
| 优先级 | 1/2/3/4 |
| 用例类型 |功能测试|
| 适用阶段 |功能测试|
| 设计方法 | 用了什么方法得出的 |

四、可扩展方向

基础版 Skill 已经能够根据用户输入的功能描述生成测试用例，但还有很大的扩展空间。以下是两个核心扩展方向：

1. 让 Skill 读项目代码

当前 Skill 依赖用户手动描述功能需求，可让 Skill 直接读取项目代码，自动提取测试所需信息：

## 扩展功能：代码分析

用户提供代码路径且输入中包含以下关键词时触发代码读取：
- "根据代码生成用例"
- "分析这个文件/模块的测试用例"
- "从代码中提取测试点"

2. 反馈“补充遗漏用例”形成闭环

建立用户反馈闭环，让 Skill 能够从用户的补充和修正中学习。

## 反馈闭环流程图
第一步：用户使用 Skill
 "为登录功能设计测试用例"                            
		↓
第二部：Skill 生成初始用例                          
TC-01 正常登录                                              
TC-02 密码错误              
TC-03 用户名不存在              
...（可能遗漏场景）                      
		↓
第三步：用户审查用例
"你漏了验证码场景" 
"密码大小写敏感没测"     
"并发登录场景需要补充"                                  
		↓
第四步：Skill 记录反馈                              
• 识别遗漏类型
• 提取场景模式                                         
• 记录用户补充的用例                                     
		↓                            
 第五步：Skill 更新规则                     
• 本次会话：立即补充遗漏用例                   
• 长期学习：更新规则库，下次自动包含       
第六步：输出完整用例集                             
初始用例 + 用户补充用例 + Skill 自动补充用例  

---

核心收获：Skill 是把“隐性经验”显性化的好方式

完整 Skill 配置文件源码：https://gitee.com/evening-li/ai-generate-testcase.git