关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集别让AI每次都从零学起把你的测试经验封装成它随取随用的“技能包”大家好我是某互联网公司的测试架构师。上个月团队来了个新项目。测试新人小陈接了个“订单取消功能”的用例设计任务按以往的经验这活儿至少3天。他打开Claude Code调了一个Skill2小时后交出了一份覆盖正常流程、异常场景、边界值、权限校验的完整用例集。测试组长看完之后问了一句“这是谁写的质量比我自己写还高。”小陈说“不是我写的是我写的一个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.md30分钟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 ---每个字段的含义nameSkill名称只能用小写字母、数字和连字符最长64字符。不能含anthropic或claudedescription最重要的字段。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里只引用它## 标准用例模板 ### 正向用例示例 | 用例编号 | 测试场景 | 前置条件 | 测试步骤 | 预期结果 | |---------|---------|---------|---------|---------| | ORDER-CANCEL-001 | 已支付未发货订单取消成功 | 用户已登录订单状态为已支付订单未发货 | 1.进入订单详情页 2.点击取消订单 3.确认取消 | 订单状态变为已取消库存回滚退款发起 | ### 异常用例示例 ...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把生成的用例表格转成Excelimport 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分钟的投入换的是未来每一天的效率翻倍。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。