

> 别让AI每次都从零学起，把你的测试经验封装成它随取随用的“技能包”

大家好，我是某互联网公司的测试架构师。

上个月，团队来了个新项目。测试新人小陈接了个“订单取消功能”的用例设计任务，按以往的经验，这活儿至少3天。

他打开Claude Code，调了一个Skill，**2小时后交出了一份覆盖正常流程、异常场景、边界值、权限校验的完整用例集**。

测试组长看完之后，问了一句：“这是谁写的？质量比我自己写还高。”

小陈说：“不是我写的，是我写的一个Skill。”

组长说：“把Skill给我看看。”

这篇文章，就是小陈那个Skill的完整拆解。


## 一、先搞清楚：Skill到底是什么？

很多人第一次接触Skill，以为就是“高级一点的Prompt”。**完全不是一回事。**

Anthropic官方对Skill的定义很干脆：**一个Skill就是一个文件夹**。里面必须有一个`SKILL.md`文件，还可以放脚本（`scripts/`）、参考资料（`references/`）、静态资源（`assets/`）。

**用大白话说：Skill就是把“资深测试工程师怎么做用例设计”的完整经验，封装成一个文件夹。AI在需要的时候自动加载，按你的要求执行任务。**

Skill的核心设计理念是**渐进式披露（Progressive Disclosure）** 。什么意思？

平时Claude只加载每个Skill的**名字和描述**——大约100个Token。等到它判断这个Skill和当前任务相关时，才把**完整内容**加载进来。如果Skill里还有references目录下的长篇文档，Claude只在需要时才去读。

这个设计意味着：**你可以装几十个Skill，上下文不会爆炸**。只有真正用到的Skill才会占用Token。

**Skill和MCP的区别是什么？** MCP解决的是“模型能用什么工具”——连数据库、接GitHub、操作浏览器。Skill解决的是“模型该怎么用这些工具”——按什么步骤、什么格式、什么标准。**两者是协作关系，不是替代关系**。


## 二、三步走：从零到第一个测试Skill

下面以小陈的“测试用例生成Skill”为例，走完完整的三步。


### 第一步：搭目录结构（2分钟）

Skill必须放在Claude Code能识别的位置。有三种放法：

| 位置 | 路径 | 生效范围 |
|------|------|---------|
| 个人 | `~/.claude/skills/<name>/` | 所有项目 |
| 项目 | `.claude/skills/<name>/` | 当前项目 |
| 插件 | `<plugin>/skills/<name>/` | 插件启用时 |

如果同名，优先级是**个人 > 项目**。

小陈的项目级Skill放在`.claude/skills/test-case-generator/`。目录结构是这样的：

```
test-case-generator/
├── SKILL.md              # 必需：核心指令
├── references/            # 可选：参考文档
│   ├── test-case-template.md
│   └── bug-patterns.md
└── scripts/               # 可选：可执行脚本
    └── format_cases.py
```

**关键规则**：
- `SKILL.md`文件名**必须全大写**，写成`skill.md`不行
- 文件夹命名必须用**kebab-case**（小写+连字符），比如`test-case-generator`✅，`Test Case Generator`❌


### 第二步：写SKILL.md（30分钟）

`SKILL.md`是整个Skill的“大脑”。它分两部分：**YAML头信息** + **Markdown正文**。

#### YAML头信息

头信息控制Skill什么时候触发、怎么触发：

```yaml
---
name: test-case-generator
description: 根据功能描述自动生成覆盖正常流程、异常场景、边界条件和权限校验的结构化测试用例。当用户提到"生成测试用例""编写测试""测试覆盖""测试场景"时自动触发。
when_to_use: 用户需要从需求文档或功能描述生成测试用例时使用。适用于功能测试、回归测试、接口测试的用例设计阶段。
disable-model-invocation: false
allowed-tools: Read, Write, Edit, Bash
---
```

每个字段的含义：

- **name**：Skill名称，只能用小写字母、数字和连字符，最长64字符。不能含`anthropic`或`claude`
- **description**：**最重要的字段**。Claude把所有Skill的description预加载进上下文，用来判断该不该触发这个Skill。**要写清楚“什么时候用”**，而不是“它有什么用”
- **when_to_use**：额外的触发上下文，比如触发短语或示例请求
- **disable-model-invocation**：设为`true`可以阻止Claude自动触发，只能手动调用
- **allowed-tools**：限制Skill能用哪些工具

**description的好坏对比**：
- ❌ 坏的：`description: 帮助用户生成测试用例`
- ✅ 好的：`description: 当用户需要从需求文档或功能描述生成测试用例时使用。适用于功能测试、回归测试、接口测试的用例设计阶段。`

#### Markdown正文

正文就是操作手册——告诉Claude“这件事具体怎么做”。小陈的Skill正文核心部分是这样的：

```markdown
## 任务
根据用户提供的功能描述或需求文档，生成覆盖正常流程、异常操作、边界条件和权限校验四大类场景的测试用例。

## 执行步骤

### 步骤1：理解需求
读取用户提供的功能描述，提取：
- 核心功能是什么
- 输入参数和约束条件
- 业务规则和状态流转
- 权限和角色要求

### 步骤2：识别测试场景
基于需求分析，系统性地列出所有测试场景：

**正常流程**：用户按预期方式操作时的完整路径
- 至少覆盖1条完整的Happy Path

**异常场景**：用户操作不当或系统异常时的表现
- 参数缺失、格式错误、业务规则违反
- 依赖服务超时或返回错误

**边界条件**：输入或状态的极限值
- 数值边界（最小值、最大值、空值）
- 状态边界（状态转换的临界点）

**权限校验**：不同角色和权限下的访问控制
- 未授权访问、越权操作

### 步骤3：生成用例
为每个场景生成结构化用例，包含：
- 用例编号：{模块}-{类型}-{序号}
- 测试场景：一句话描述
- 前置条件：执行前必须满足的条件
- 测试步骤：编号列表，每步具体可执行
- 预期结果：执行后的期望结果
- 优先级：P0/P1/P2

### 步骤4：自检
对照场景分类检查是否有遗漏：
- [ ] 每个功能点是否有至少1条正向用例？
- [ ] 每个输入参数是否有异常场景覆盖？
- [ ] 边界值是否覆盖了上下界？
- [ ] 不同角色权限是否都有验证？

## 输出格式
Markdown表格，可直接复制到Excel或测试管理工具。

| 用例编号 | 测试场景 | 前置条件 | 测试步骤 | 预期结果 | 优先级 |
|---------|---------|---------|---------|---------|--------|
| ... | ... | ... | ... | ... | ... |

## 注意事项
- 不臆造需求中不存在的功能
- 如果信息不明确，标注"需确认"而不是猜测
- 每个功能点至少生成1条正向用例 + 3条异常/边界场景
```

**三个写正文的黄金原则**：

1. **步骤要具体可执行**。不要写“验证数据是否正确”，要写“调用GET /api/order/{id}，检查返回的status字段是否为'已取消'”
2. **SKILL.md控制在500行以内**。超过500行，把详细内容移到`references/`目录
3. **用祈使句**。“运行脚本”“检查输出”，不要用第二人称


### 第三步：用scripts和references扩展能力（按需）

Skill真正的威力在于**可扩展**。当`SKILL.md`超过500行，或者需要可执行代码时，就用`scripts/`和`references/`来分担。

#### references/：放长文档

`references/`目录放Claude按需加载的参考资料。小陈放了两个文件：

`references/test-case-template.md`：详细的用例模板和示例，SKILL.md里只引用它：
```markdown
## 标准用例模板

### 正向用例示例
| 用例编号 | 测试场景 | 前置条件 | 测试步骤 | 预期结果 |
|---------|---------|---------|---------|---------|
| ORDER-CANCEL-001 | 已支付未发货订单取消成功 | 用户已登录；订单状态为"已支付"；订单未发货 | 1.进入订单详情页 2.点击"取消订单" 3.确认取消 | 订单状态变为"已取消"；库存回滚；退款发起 |

### 异常用例示例
...
```

`references/bug-patterns.md`：历史Bug模式库，用于场景补全时参考。

在SKILL.md里这样引用：
```markdown
## 参考资料
- 详细的用例模板和示例，参考 `references/test-case-template.md`
- 历史Bug模式，参考 `references/bug-patterns.md`
```

**重要**：Claude只在需要时才读这些文件。不要把所有内容都塞进SKILL.md。

#### scripts/：放可执行代码

`scripts/`目录放**被执行的代码**，而不是被加载到上下文里的文档。Claude不看代码内容，只看执行结果。

小陈放了一个格式化脚本`scripts/format_cases.py`，把生成的用例表格转成Excel：

```python
import pandas as pd
import sys

def format_cases(markdown_table):
    # 把Markdown表格转成Excel格式
    # ...
    pass

if __name__ == "__main__":
    format_cases(sys.stdin.read())
```

在SKILL.md里这样引用：
```markdown
### 步骤5：格式化输出
生成用例后，用 `python scripts/format_cases.py` 将表格转为Excel格式，方便导入测试管理工具。
```

**scripts vs references的简单判断**：
- 需要**执行**才能得到结果 → 放`scripts/`
- 只需要**阅读**参考 → 放`references/`


## 三、完整目录结构一览

把三部分串起来，一个完整的测试Skill长这样：

```
test-case-generator/
├── SKILL.md                      # 核心指令（<500行）
├── references/                    # 按需加载的参考文档
│   ├── test-case-template.md     # 详细用例模板
│   ├── bug-patterns.md           # 历史Bug模式库
│   └── api-examples.md           # 接口调用示例
└── scripts/                       # 可执行脚本
    ├── format_cases.py           # 用例格式转换
    └── validate_cases.py         # 用例完整性校验
```


## 四、避坑指南

### 坑一：SKILL.md超过500行还不拆分

Claude每次加载Skill都要读完整的SKILL.md。超过500行会浪费大量Token。

**解法**：把详细内容移到`references/`，SKILL.md只放核心流程和导航。

### 坑二：description写得太空

description是Claude判断“要不要触发这个Skill”的唯一依据。写“帮助测试”这种描述，Claude永远不知道什么时候该用它。

**解法**：description要写清楚“触发条件”——什么场景下、用户说什么话时用这个Skill。

### 坑三：忽略渐进式披露

把所有内容塞进SKILL.md，每个会话都白白消耗大量Token。

**解法**：利用三级加载机制——frontmatter（始终加载）→ SKILL.md正文（相关时加载）→ references/文件（按需加载）。

### 坑四：Skill建完不迭代

Skill不是一次性产物。业务在变、需求在变，Skill也需要跟着更新。

**解法**：在SKILL.md末尾加一个`## Learnings`章节，记录每次使用中发现的问题和改进点。


## 最后

**传统测试的底层资产是“测试用例库”——用例是一次性的，用完就扔。**

**AI时代的底层资产正在变成“Skill库”——Skill是可组合、可复用的能力单元。**

一个Skill封装的不只是一个具体输入输出，而是一种**“做某件事的方法”**。你今天花30分钟写了一个“测试用例生成”的Skill，以后每一个项目都能复用。

目前社区已经有大量高质量的测试Skill库可供参考。Anthropic官方的skills仓库在GitHub上已获得**14.1万+星标**，是AI工具类仓库中关注度最高的之一。

下次你发现自己在Claude Code里反复输入同一套测试流程的时候，停下来，花30分钟把它封装成一个Skill。

**30分钟的投入，换的是未来每一天的效率翻倍。**

---

*本文系作者基于真实项目经验的总结。文中所有目录结构和配置均来自2026年实际落地项目，可直接复制使用。*

上个月，团队来了个新项目。测试新人小陈接了个“订单取消功能”的用例设计任务，按以往的经验，这活儿至少3天。

测试Skill开发三步走：SKILL.md + scripts + references实战指南

测试

将资深测试工程师的用例设计经验封装为AI可调用的Skill，30分钟即可生成覆盖正常流程、异常场景、边界值及权限校验的完整用例集。通过SKILL.md核心指令、references按需加载文档及scripts可执行脚本的三级架构，实现测试技能的标准化复用，显著提升用例设计效率与质量，适用于功能、回归及接口测试场景。

回归测试

代码解释

数据库

GitHub

2026上云采购 | AI焕新·智启新局

coding

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

测试Skill开发三步走：SKILL.md + scripts + references实战指南-腾讯云开发者社区-腾讯云

测试Skill开发三步走：SKILL.md + scripts + references实战指南

测试Skill开发三步走：SKILL.md + scripts + references实战指南

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐