Claude Code 配合 Skills 自动生成测试用例这个方向最近讨论得很多。简单说就是在 Claude Code 里放一个自定义技能把“按什么规则写测试用例、输出什么格式、用哪几种测试设计方法”都定义好之后把需求文档丢给它就能批量得到一版结构统一的功能测试用例。我实际按这个思路跑了一轮结论是它最适合用来做第一版测试用例草稿和边界场景补全能明显减少从空白文档到初始用例集的时间但前提是你愿意先花时间把 Skills 文件写好。下面就把我从环境准备、Skills 配置、单条生成到批量输出踩过的关键点完整拆一遍。适合正在用 AI 辅助测试、想尝试自定义 Skills 的测试开发或前端开发者。最值得关注的部分不是命令本身而是技能文件里的规则设计。1. 为什么用 Claude Code 的 Skills而不是直接聊天生成测试用例很多人一开始会问我已经能在对话框里让 AI 写测试用例了为什么还要单独配一个 Skills直接聊天当然可以但真正在项目里批量落地时问题会很快暴露出来。1.1 直接聊天生成用例的三个问题第一个问题是提示词不稳定。你上一次写的提示词和下一次写的可能有差别AI 输出的标题格式、字段顺序、用例编号方式都不一致。如果只是生成三五条用例手动整理还能接受如果需要生成几十个需求文件的用例格式飘一点后面维护成本就会非常高。第二个问题是测试设计方法覆盖不足。你让 AI 写功能测试用例它通常会写正常路径下的用例。输入为空、输入超长、重复提交、权限不足、并发冲突这些异常和边界场景如果你不在提示词里明确要求它大概率会漏。尤其在需求文档本身写得比较粗的时候AI 很容易顺着业务描述直接写出“能正常完成”的用例缺少反向验证。第三个问题是团队复用困难。你花一小时调试出来的一段高质量提示词只能留在你的会话历史里。同事想用又得重新写一遍。同一个项目里不同人生成的用例风格完全不一样评审时很难对齐。1.2 Skills 到底改了什么Claude Code 的 Skills本质上是把提示词、规则、参考示例、脚本和项目特定信息打包成一个可复用技能。放在项目目录里的.claude/skills下面模型在执行相关任务时会根据技能描述自动加载里面的规则。也就是说你不用每次重复“你是一名测试工程师请用等价类、边界值、场景法设计测试用例输出格式是表格编号规则是 TC-001”。你只需要把这一整套要求写进 SKILL.md之后告诉它“用测试用例生成技能处理这个需求文件”就行。这样做带来的实际好处有三个输出格式固定不同需求文件生成的用例风格一致。测试设计方法可以前置写在规则里减少漏测。技能文件进入 Git 仓库后整个团队可以使用同一套标准。1.3 适合谁用不适合谁用我个人的判断是这个方案最适合有小批量、重复性测试用例输出需求的团队或个人。比如开发完一个新模块需求文档是 Markdown 格式希望快速生成一版覆盖正常、异常、边界的测试用例再交给测试同学评审补全。但不适合完全依赖它做复杂系统的测试设计。特别是强业务合规、复杂权限矩阵、大量状态流转的系统AI 生成的用例只能当草稿。它帮你解决的是“从无到有”的第一步不是“从有到对”的最后一步。真正能跑进 CI 的测试用例仍然需要人来判断、修改和维护。2. 环境准备Claude Code 安装、认证和项目目录配置 Skills 之前先把运行环境准备好。这一步看起来简单但很多人后面批量执行时报错回头查才发现是最开始安装和目录结构没弄干净。2.1 安装前先确认 Node.js 和终端Claude Code 目前常见的使用方式是通过命令行运行所以你需要一个能跑 Node.js 的环境。Windows、macOS、Linux 都可以但前提是终端能用。Windows 上建议直接用 PowerShell 或者 Windows Terminal不要用老旧的 cmd 去跑长命令很多奇怪的编码问题会少很多。安装之前先确认 Node.js 和 npm 是否可用。在终端里执行node -v npm -v如果两条命令都能正常输出版本号说明基础环境没问题。如果提示命令找不到需要先把 Node.js 装好。原始安装要求我没有精确版本信息建议以 Claude Code 官方文档的要求为准不要只看网上旧教程。2.2 安装 Claude Code 并完成认证常见做法是通过 npm 全局安装命令类似npm install -g anthropic-ai/claude-code安装完成后在终端执行claude --version能输出版本号说明安装成功。首次运行claude会进入认证流程按提示完成账号登录和授权。认证这一步不要跳过因为后续所有调用都需要基于你的登录状态。如果公司网络环境特殊登录可能会遇到超时或连接异常这时候先检查网络、代理和 DNS不要急着反复重试。这里要特别注意解决网络问题请使用合规的网络环境不要使用任何无法确认安全性的工具。认证通过后可以运行一次claude输入一句最简单的测试内容确认它能正常回复再退出。2.3 初始化项目目录结构我建议单独建一个项目目录不要在你的业务代码仓库里直接乱放。这样测试需求、测试用例、技能文件都隔离得比较清楚。推荐的结构是这样的testcase-project/ ├── .claude/ │ └── skills/ │ └── test-case-generator/ │ ├── SKILL.md │ ├── reference/ │ │ └── business-rules.md │ └── examples/ │ └── sample-case.md ├── requirements/ │ ├── login.md │ └── order.md ├── testcases/ └── logs/.claude/skills用来放技能文件requirements放输入的需求文档testcases放生成的测试用例logs放批量任务日志。这样分类不是为了好看而是为了后面批量脚本处理时路径清晰、不会互相污染。2.4 和 VSCode 结合使用的注意点Claude Code 本身是终端工具很多人会配合 VSCode 一起用。常见做法是在 VSCode 的集成终端里启动claude然后让它读取当前项目目录下的文件。这样做的好处是生成结果可以直接在编辑器里查看修改用例比较方便。需要留意的是如果你在 VSCode 里打开了错误的目录模型能看到的文件范围也会不对。启动claude之前先确认当前终端路径是不是项目根目录用pwd看一下。路径不对时模型可能找不到requirements目录和技能文件然后你会误以为是技能没配置好。3. 配置测试用例生成 SkillSKILL.md 的结构和写作要点配置 Skills 是整个流程里最核心的一步。很多人第一次配置失败不是因为 Claude Code 有问题而是 SKILL.md 里的描述写得太模糊导致模型不知道该在什么时候触发、按什么规则输出。3.1 Skills 目录结构与触发逻辑Skills 在项目里的目录结构通常是.claude/skills/技能名/SKILL.md。技能名尽量使用小写连字符例如test-case-generator。这个目录名会作为技能的一部分被识别。SKILL.md 是技能的主文件里面包含 frontmatter 和正文。frontmatter 里最重要的字段是name和description。description决定了模型在什么场景下调用这个技能。如果你写得太窄比如只写“当用户说生成测试用例时使用”用户换一种说法“帮我写几个用例”技能就可能不会被触发。如果你写得太宽比如“测试相关都可以用”它又会在不需要的时候强行套用。我曾经踩过的一个坑是 description 里写了“生成接口测试用例”结果我让它生成功能测试用例时它没有调用技能而是直接按普通对话回答。后来我把描述改成“当用户要求生成、补充或批量处理功能测试用例、接口测试用例时使用”触发准确率才明显上升。3.2 SKILL.md 的 frontmatter 和正文SKILL.md 的正文就是你要让模型遵循的指令。可以写成角色设定、处理步骤、输出模板、注意事项。下面是一个最小可用的示例--- name: test-case-generator description: 根据需求文档生成功能测试用例。当用户要求生成测试用例、补充测试用例、批量处理需求文件时使用。 --- # 测试用例生成技能 你是一名测试工程师擅长功能测试、接口测试和边界场景设计。 ## 输入要求 - 需求文档通常位于 requirements/ 目录。 - 如果没有明确说明默认使用项目内已有的业务规则。 ## 处理步骤 1. 阅读需求文档提取功能点。 2. 对每个功能点至少设计一条正常用例、一条异常用例、一条边界用例。 3. 对涉及输入框、金额、时间、状态流转的场景补充等价类边界值用例。 4. 按照下方模板输出不要修改字段名称。 ## 输出模板 | 用例编号 | 模块 | 优先级 | 前置条件 | 测试数据 | 操作步骤 | 预期结果 | 备注 | |----------|------|--------|----------|----------|----------|----------|------| | TC-001 | | | | | | | | ## 注意事项 - 用例编号从 TC-001 开始递增。 - 前置条件必须写清楚不能只写“已登录”。 - 操作步骤要具体到人可以在页面上执行。 - 预期结果要可验证不要写“系统正常运行”这种模糊表述。这个示例里最关键的是输出模板和注意事项。模型看到表格字段之后会倾向于按字段组织答案。你只要把模板字段固定下来后续批量生成的文件结构就不会乱。3.3 把测试设计方法写进规则测试用例质量低很多时候不是因为模型不会而是因为你没有告诉它要用哪些测试设计方法。默认情况下它只会按功能描述写正常流程。我会在 SKILL.md 里明确列出需要覆盖的设计方法等价类划分每个输入项至少覆盖有效等价类和无效等价类。边界值分析长度边界、数值边界、页码边界、金额边界。场景法主要的业务成功路径、取消路径、失败回退路径。错误推测重复提交、网络中断、时间超时、权限不足、数据不存在。不要只是罗列方法名称要结合具体项目补一句预期效果。比如“涉及金额输入时必须覆盖 0、负数、超长小数、超过字段长度上限”。这些业务规则如果写在 SKILL.md 正文里会让技能更加贴合项目。3.4 业务规则单独放文件不要全堆在提示词里项目里的业务规则会越来越多。比如“订单金额超过 5000 需要走审批”“用户名不允许包含特殊字符”“接口超时时间统一为 3 秒”。这些规则如果全部写进 SKILL.md文件会变得很长而且维护困难。更好的做法是把业务规则放在reference/business-rules.md然后在 SKILL.md 里加一行“处理需求前先阅读 reference/business-rules.md”。让模型在生成用例前先加载这部分内容。这样做的好处是以后业务规则更新时只需要改 reference 文件不一定要改技能主文件。不过要注意业务规则文件不能写得太乱。最好也是分模块的列表让模型容易定位。比如# 业务规则 ## 登录模块 - 用户名长度 3-20 个字符。 - 密码至少 8 位必须包含字母和数字。 - 连续输错 5 次账号锁定 30 分钟。 ## 订单模块 - 订单金额精确到分。 - 支付超时时间为 15 分钟。 - 取消订单后优惠券需退回。这样 Claude Code 在生成用例时能清楚知道哪些规则需要用例覆盖。4. 单条需求生成先跑通最小样例配置好 Skills 之后不要急着批量跑。我的建议是先选一个简单的需求文件跑通最小流程。这一步能帮你发现技能触发、路径、输出格式等多方面的问题。4.1 准备一份最小需求文档在requirements目录下放一个login.md内容尽量写清楚。质量可以一般但要有基本的信息# 登录功能需求 ## 需求描述 用户通过手机号和密码登录系统。 ## 功能点 - 输入手机号。 - 输入密码。 - 点击登录按钮。 - 登录成功后跳转到首页。 - 登录失败时提示错误信息。 ## 补充说明 - 手机号需要验证格式。 - 密码错误时提示“密码错误”。 - 连续失败 5 次锁定账号。这个文件不需要很完美目的是让模型有足够信息生成用例。如果需求文档太简单比如只有一句话“用户登录”那模型生成的用例大概率也会很泛这不是 Skills 能解决的问题。4.2 在 Claude Code 中调用技能在项目根目录启动claude输入类似这样的提示使用 test-case-generator 技能处理 requirements/login.md生成测试用例。然后观察输出。这里有几个不同的情况如果模型正常输出了表格格式的用例说明技能触发成功。如果输出的是普通聊天格式没有按表格字段走说明技能没有触发或没有生效。如果模型提示找不到文件先检查requirements/login.md路径是否正确。如果技能没有触发不要急着改 SKILL.md。先看是不是描述不够匹配。你可以再试一次更直接的表达“调用 test-case-generator”。如果这样能触发说明是描述问题如果还是不行说明技能加载可能有问题需要检查.claude/skills目录路径和文件名。4.3 判断一次生成是否合格第一次生成用例后不要只看“有没有输出”。要按几个标准快速检查用例编号是否从 TC-001 开始连续递增。字段是否和模板一致有没有多出或减少字段。是否覆盖了正常、异常、边界场景。前置条件是否可执行比如“用户已注册”“系统已登录”这类条件是不是完整。预期结果是否可验证而不是“系统正常”。我在实际测试中第一次生成的登录用例覆盖了正常登录、密码错误、手机号格式错误但漏了“连续失败 5 次锁定账号”的边界场景。原因是需求文档里写了这个规则但 SKILL.md 里的处理步骤只写了“补充边界用例”没有强调“当需求中已有明确业务规则时每个规则都要有对应用例”。后来我在处理步骤里加了这一条漏测才明显减少。这说明一条关键经验Skills 文件不是写一次就结束的它需要根据第一次输出质量去迭代。4.4 第一次跑通后顺手记录成本很多人会忽略运行成本。单条需求生成可能只需要几十秒看起来不耗时但当你批量处理几十个需求文件时总耗时和 Token 消耗会成倍增长。我建议第一次跑通后记录一下这个需求文件的大小、模型响应时间、大概消耗了多少 Token。如果用的是订阅额度还要关心消耗速率。这个数据是你后面决定“一次批量跑多少个文件”的重要依据。5. 批量输出测试用例脚本、命名、日志和失败重试单条跑通之后批量处理看起来就是循环调用。但如果不提前设计好命名、日志和重试机制批量任务很容易执行到一半就卡住或者输出文件被覆盖。5.1 批量任务先想好命名、目录和日志批量任务最容易被忽略的是输出命名。如果你把requirements/login.md和requirements/登录.md同时处理后都输出成testcases/output.md后一个就会覆盖前一个。我建议保持输入输出文件名一致。比如requirements/login.md对应testcases/login.md这样即使混入多个模块也不会互相覆盖。如果需求文件本身命名有重复可以先在脚本里做唯一性检查或者加上时间戳后缀testcases/login_20250120.md testcases/login_20250121.md日志目录也要单独建立。批量任务里不是所有失败都会立刻让程序崩溃。有的请求超时有的模型输出为空有的限流报错。你需要在日志里记录每个文件是否成功、耗时多少、错误信息是什么否则进程结束后你根本不知道哪一个文件没生成。5.2 用脚本逐文件处理如果你使用的是支持非交互模式的 Claude Code CLI可以写一个简单脚本循环处理requirements目录下的所有 Markdown 文件。下面是一个示意性的 Bash 脚本#!/usr/bin/env bash set -uo pipefail mkdir -p testcases logs for req in requirements/*.md; do name$(basename $req .md) echo processing $name if claude -p 使用 test-case-generator 技能处理 $req生成测试用例。 testcases/$name.md 2 logs/$name.err; then echo ok: $name else echo fail: $name fi sleep 2 done注意claude -p这种非交互执行方式是否可用取决于你的 Claude Code 版本。如果你的版本不支持就不要强行套用改成在交互会话里逐个输入文件的处理。脚本的价值是帮你建立“循环处理、日志记录、失败标记”的思维框架。脚本里我加了sleep 2意思是每个文件之间停顿两秒。这个停顿很重要不是为了装模作样而是为了避免请求过于密集触发限流。5.3 并发、限流和失败重试批量任务最容易让人冲动的地方就是觉得可以开并发一次跑 10 个文件。我的建议是不要这样。低并发不一定慢因为模型服务端本身有处理能力但高并发会带来两个问题一是限流错误变多二是日志和输出文件之间的对应关系很难管理。如果 5 个进程同时写不同文件还好但一旦某个进程因为服务端错误退出你很难定位是哪一个。如果确实需要提高吞吐可以先把并发数设置为 2 或 3观察一段时间。稳定后逐步增加。遇到限流错误时优先降低并发而不是加大重试次数。无限重试只会让服务端压力更大错误概率更高。另外重试逻辑要有限度。我会在脚本里记录同一个文件最多重试两次。如果两次都失败就把这个文件写入logs/failed.txt最后统一人工处理。这样不会因为一个文件卡死整个批处理流程。5.4 批量结束后做输出完整性检查批量任务结束后不能只看“脚本退出码为 0”。退出码为 0 只代表程序正常结束不代表每个文件都生成了有效用例。我一般会做三个检查检查testcases目录下的文件数量是否和requirements目录下的需求文件数量一致。检查每个输出文件是否非空。检查每个输出文件里是否包含至少一个TC-开头的用例编号。这些检查可以用一个简单的脚本完成echo 需求文件数量: $(ls requirements/*.md | wc -l) echo 用例文件数量: $(ls testcases/*.md | wc -l) for f in testcases/*.md; do if ! grep -q TC- $f; then echo no TC found: $f fi done这一步能筛出很大一部分异常情况避免你把一个空文件当作成功结果提交上去。6. 输出质量怎么判断问题和排查顺序批量任务跑完后测试用例的质量才是真正需要关注的事情。Claude Code 生成的用例不会自动正确它只会按照你给的规则尽量输出。质量高低取决于规则质量和人工评审。6.1 测试用例输出质量的判断标准我自己的判断维度主要有四个第一个是覆盖率。正常、异常、边界这三类是否都有覆盖。如果一个功能只生成了三条正常用例那基本可以判定不合格。第二个是前置条件的可执行性。很多 AI 生成的用例会写“用户已登录”但没说登录所需的账号、权限、数据状态。好的前置条件应该是“使用已注册且未锁定的账号”。第三个是操作步骤的粒度。步骤越具体越好。“点击登录按钮”可以但“输入正确格式的手机号和密码点击登录按钮”更好。如果操作步骤含糊测试执行时很难照着做。第四个是预期结果的可验证性。“页面显示错误提示”可以但“页面显示‘密码错误’四个字且不会跳转”更准确。可验证的预期结果才能变成自动化断言的基础。下面是一个质量检查表检查项合格标准常见问题格式一致性所有用例字段一致不同文件字段不同编号连续TC-001 开始递增重复编号、乱序正常场景每个功能点至少一条只写正常流程异常场景每个功能点至少一条漏掉输入错误、无权限边界场景涉及长度、数值、时间时有覆盖只测普通值前置条件可执行、有数据准备只写“已登录”预期结果可验证、不模糊写“系统正常”6.2 高频问题排查顺序如果你配置完 Skills 后发现效果不好按下面的顺序排查。先看技能是否触发。判断方法很简单输出内容是不是严格按 SKILL.md 里的模板来的。如果完全不是说明技能没触发。重点检查 description 是否匹配、.claude/skills目录是否在正确位置、文件名是否为SKILL.md。再看输入需求是否清晰。不要让模型从一个只有两行描述的需求文档里设计出复杂用例。需求文档里至少要包含功能点、规则、异常说明。没有信息模型只能用常识补补出来往往不是你要的东西。接着看 SKILL.md 的规则是否够具体。如果你只是写了“全面分析”模型不知道什么叫全面。最好把输出模板、测试设计方法、必查规则都写清楚。最后看工具自身状态。比如限流、服务端繁忙、版本更新导致参数变化。错误信息里如果包含类似“529”的状态码通常是服务端繁忙先停一会儿再继续不要反复重试。6.3 不要随意放大使用边界自动生成测试用例这个能力很实用但它和真正的测试工程化之间还有距离。没有清晰需求时不适合让 AI 直接生成用例。比如你只有一句话“做一个登录功能”却希望得到完整覆盖基本不可能。强合规和强状态领域不适合完全依赖 AI。比如涉及支付资金安全、实名认证、法律合规流程AI 生成的用例只能作为参考不能替代人工评审和测试设计。另外生成结果必须进入评审流程。我见过有人把 AI 生成的用例直接导入测试管理平台结果很多用例依赖同一个不存在的账号数据执行时全部失败。用例集的价值不仅在于文本还在于数据准备和执行条件这些需要测试人员补齐。6.4 团队协作时的版本管理建议如果团队里多个人一起用这个方案最好把技能文件纳入 Git 仓库管理。这样每个人拉取代码后都能使用同一套测试用例生成规则。迭代 SKILL.md 时不要直接覆盖掉旧版本。先更新规则跑几个样例文件确认输出质量提升后再提交。如果发现新的输出比旧的更差要能回滚。还可以在reference里维护“项目规则变更记录”方便追溯为什么某条业务规则被加入。否则时间一长技能文件会变成一个谁也说不清楚为什么要这样写的黑盒。最后一点建议把在测试过程中发现的高质量用例反向补充到examples目录里作为模型的参考样例。比如你发现人工评审后“登录失败锁定”这条用例写得很好就把它保存成示例。下次生成时模型有更接近实际项目的参照输出质量会比只给模板更好。踩过这一轮之后我的最终判断是Claude Code 配置 Skills 批量生成测试用例是一个值得尝试的提效方案。它真正的价值不是让 AI 替代测试工程师做测试设计而是把测试用例的输出规范、设计方法和项目规则固定下来让 AI 稳定地帮你生成一份高质量的初稿。人要做的事情是写清楚规则然后花精力去评审和补漏。先小范围跑通再逐步扩展这个方向不会错。