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

别让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//
所有项目
项目
.claude/skills//
当前项目
插件

/skills//
插件启用时
如果同名，优先级是个人 > 项目。

小陈的项目级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什么时候触发、怎么触发：

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正文核心部分是这样的：

任务

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

执行步骤

步骤1：理解需求

读取用户提供的功能描述，提取：

• 核心功能是什么
• 输入参数和约束条件
• 业务规则和状态流转
• 权限和角色要求

步骤2：识别测试场景

基于需求分析，系统性地列出所有测试场景：

正常流程：用户按预期方式操作时的完整路径

• 至少覆盖1条完整的Happy Path

异常场景：用户操作不当或系统异常时的表现

• 参数缺失、格式错误、业务规则违反
• 依赖服务超时或返回错误

边界条件：输入或状态的极限值

• 数值边界（最小值、最大值、空值）
• 状态边界（状态转换的临界点）

权限校验：不同角色和权限下的访问控制

• 未授权访问、越权操作

步骤3：生成用例

为每个场景生成结构化用例，包含：

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

步骤4：自检

对照场景分类检查是否有遗漏：

• [ ] 每个功能点是否有至少1条正向用例？
• [ ] 每个输入参数是否有异常场景覆盖？
• [ ] 边界值是否覆盖了上下界？
• [ ] 不同角色权限是否都有验证？

输出格式

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

注意事项

• 不臆造需求中不存在的功能
• 如果信息不明确，标注"需确认"而不是猜测
• 每个功能点至少生成1条正向用例 + 3条异常/边界场景
  三个写正文的黄金原则：

步骤要具体可执行。不要写“验证数据是否正确”，要写“调用GET /api/order/{id}，检查返回的status字段是否为'已取消'”
SKILL.md控制在500行以内。超过500行，把详细内容移到references/目录
用祈使句。“运行脚本”“检查输出”，不要用第二人称
第三步：用scripts和references扩展能力（按需）
Skill真正的威力在于可扩展。当SKILL.md超过500行，或者需要可执行代码时，就用scripts/和references/来分担。

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

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

标准用例模板

正向用例示例

异常用例示例

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

在SKILL.md里这样引用：

参考资料

• 详细的用例模板和示例，参考 references/test-case-template.md
• 历史Bug模式，参考 references/bug-patterns.md
  重要：Claude只在需要时才读这些文件。不要把所有内容都塞进SKILL.md。

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

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

import pandas as pd
import sys

def format_cases(markdown_table):

# 把Markdown表格转成Excel格式
# ...
pass

if name == "main":
format_cases(sys.stdin.read())
在SKILL.md里这样引用：

步骤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年实际落地项目，可直接复制使用。