在项目迭代过程中，每次提测前都要花大量时间编写测试用例。需求一多，用例写不过来，格式不统一，评审时还要反复修改。最近我在本地把 Claude Code 和 Skills 结合起来，搭建了一套自动生成测试用例的流程，把“需求描述”变成“标准测试用例”的时间从小时级压缩到了分钟级，而且生成的用例格式稳定、覆盖场景完整。本文把这套流程完整整理出来，包含 Claude Code 的安装配置、Skills 的原理、测试用例 Skill 的编写方法，以及批量生成测试用例的实战示例。不管你是测试工程师、测试开发，还是需要自己写用例的后端、前端开发者，都可以照着这篇文章把流程跑起来。
1. 背景与核心概念
1.1 Claude Code 是什么
Claude Code 是 Anthropic 推出的命令行 AI 编程助手。简单理解，它把 Claude 模型的能力放到了终端里，让你可以在项目目录中直接和 AI 对话，读文件、写代码、执行命令、解释报错、重构代码等操作都能在同一个会话里完成。
它和普通网页版 AI 聊天的最大区别是“上下文感知”。你不用把整个项目代码复制粘贴给 AI，Claude Code 会基于当前目录下的文件、历史记录和你提供的指令来理解任务。比如你可以直接说“帮我看看这个工具类为什么运行报错”，它会自己去读文件、定位问题，然后给出修改建议甚至直接改好。
目前这类 AI 编程工具已经越来越多，例如 GitHub Copilot CLI、Codex CLI 等，Claude Code 是其中热度较高的一种。它适合以下场景：
- 在本地项目中编写、重构代码。
- 运行命令并解释输出结果。
- 批量处理文件内容，比如生成文档、模板、测试数据。
- 作为团队规范、知识库的“执行入口”，也就是本文要讲的 Skills。
1.2 Skills 机制有什么用
如果你把 Claude Code 理解成一个 AI 员工，那么 Skills 就是给这个员工写的“岗位说明书+标准作业流程”。
Skills 是 Claude Code 中的一种可复用技能包，本质是一个遵循特定格式的目录，里面通常包含一个SKILL.md文件，以及配套的模板、参考文档、示例代码等资源。当你向 Claude Code 提出的任务匹配到某个 Skill 的描述时，Claude 会自动加载该 Skill，并按照其中定义好的规则、步骤、格式去完成任务。
举个例子：如果你写了一个“测试用例生成器”Skill，那么以后只要你说“为某功能生成测试用例”，Claude Code 就会自动按照 Skill 里定义的测试用例模板、覆盖纬度、设计方法来输出结果，而不是每次漫无目的地自由发挥。
Skills 解决了几个关键问题：
- 输出格式不稳定：传统提示词经常出现“同一句话，每次生成格式都不一样”，Skill 可以把格式固定下来。
- 领域知识不沉淀：测试设计方法、团队模板、业务约定都可以写进 Skill，成为团队资产。
- 操作流程不统一：Skill 可以把“先做什么、再做什么、最后输出什么”的流程固化下来。
1.3 AI 生成测试用例的定位与边界
在开始搭建之前，需要先说清楚 AI 生成测试用例的定位。
AI 生成测试用例的核心价值不是“替代测试人员”，而是“减少重复劳动”。它适合完成以下几类工作：
- 根据需求描述快速生成用例初稿。
- 覆盖正常流程、边界条件、异常场景、安全风险等常见维度。
- 统一用例格式，方便后续录入测试管理平台。
- 作为评审基线，测试人员在此基础上补充业务上下文、删除冗余用例。
但也要清醒认识它的边界。AI 并不真正理解你的业务背景，也不了解你线上曾经出过哪些严重故障。它生成的用例是基于“通用测试经验”和“需求文本信息”的组合，不能完全替代有经验测试工程师的判断。因此，合理的流程应该是：
AI 生成初稿 → 测试人员评审补充 → 评审通过后进入测试执行 → 需求变更后由 AI 辅助增量更新。
2. 环境准备与版本说明
2.1 前置条件清单
在开始配置之前，先确认你的本地环境满足以下条件：
| 项目 | 要求 | 说明 |
|---|---|---|
| 操作系统 | macOS / Linux / Windows（WSL 或原生终端） | 本文以 macOS 为例，Windows 建议使用 WSL 体验更一致 |
| Node.js | 较新的 LTS 版本 | Claude Code 基于 Node.js 分发，版本过旧可能导致安装失败 |
| 命令行工具 | npm、git | 用于安装和版本管理 |
| Claude 账号或 API Key | 需要能访问 Claude 服务 | 首次运行会引导登录或配置 API Key |
| 网络环境 | 能正常访问依赖源 | 如果 npm 下载慢，建议先配置国内镜像源 |
需要说明的是，AI 工具版本更新很快，不同版本的安装方式、参数细节可能略有差异。如果你按本文操作时发现命令参数对不上，优先以官方文档和--help输出为准。
2.2 安装 Claude Code
Claude Code 最常见的安装方式是通过 npm 全局安装：
npm install -g @anthropic-ai/claude-code安装完成后，检查版本号确认安装成功：
claude --version如果 npm 下载速度很慢，可以先切换为国内镜像源再安装：
npm config set registry https://registry.npmmirror.com npm install -g @anthropic-ai/claude-code安装完成后首次运行：
claude首次启动会进入认证流程，按终端提示登录你的 Claude 账号，或者配置 API Key。认证通过后，你就可以直接在终端里和 Claude 对话了。
另外，官方也提供了 VS Code 扩展，安装后可以直接在 IDE 侧边栏中使用 Claude Code，具体可以在 VS Code 扩展市场搜索 “Claude Code” 安装。本文的核心操作在终端完成，IDE 集成不影响流程理解。
2.3 初始化项目配置目录
为了让 Claude Code 在指定项目中使用我们自定义的 Skills，需要按约定建立配置目录。
本文使用以下项目结构：
ai-testcase-demo/ ├── .claude/ │ ├── CLAUDE.md │ └── skills/ │ └── test-case-generator/ │ ├── SKILL.md │ └── templates/ │ └── test_case_template.md ├── requirements.md ├── testcases/ └── README.md其中：
.claude/CLAUDE.md：项目级全局规则，Claude Code 启动时会自动读取，适合放通用约定。.claude/skills/test-case-generator/：我们的自定义 Skill 目录。SKILL.md：Skill 的核心描述文件。templates/test_case_template.md：测试用例输出模板。requirements.md：待生成用例的需求描述清单。testcases/：生成的测试用例输出目录。
创建目录：
mkdir -p ai-testcase-demo/.claude/skills/test-case-generator/templates mkdir -p ai-testcase-demo/.claude/skills/test-case-generator/examples mkdir -p ai-testcase-demo/testcases cd ai-testcase-demo2.4 验证工具可用
在继续编码前，先做一次最小验证。
在项目目录下运行：
claude输入一句简单的指令：
你好，请确认当前工作目录，并说明你读取到的项目文件结构。如果 Claude Code 能正常回复并列出.claude目录结构，说明工具链路已经打通，可以继续下一步。
3. Skills 的工作原理与测试用例 Skill 设计
3.1 SKILL.md 的组成与加载规则
一个 Skill 的核心是SKILL.md文件。它的结构分为两部分：
第一部分是 YAML frontmatter，用来声明 Skill 的元信息，其中name是技能名称，description是触发条件描述。
第二部分是正文，用 Markdown 编写，内容是具体的指令、步骤、约束和示例。
当用户提出的任务与某个 Skill 的description匹配时，Claude Code 会自动加载并使用该 Skill。所以description写得好不好，直接决定了 Skill 能不能被正确触发。
一个最小示例：
--- name: demo-skill description: 当用户要求演示、示例或展示最小案例时使用。 --- # 演示技能 你的任务是提供一个最小可运行的演示示例。3.2 测试用例 Skill 的设计思路
设计测试用例生成 Skill 时，不能只写一句“帮用户生成测试用例”，这样生成的用例质量不会比普通对话好多少。我们需要把测试工程师的工作方法拆解成 AI 能执行的步骤。
我把测试用例生成 Skill 的核心步骤拆成五步：
第一步，读取需求。明确被测功能点是什么，输入输出是什么，涉及哪些规则和限制。
第二步，拆解场景。把需求拆成正常流程、边界流程、异常流程、安全性、兼容性等不同纬度。
第三步，套用测试设计方法。针对不同场景决定用等价类划分、边界值分析、错误推测还是场景法。
第四步，结构化输出。按照团队统一的测试用例模板输出，保证每条用例有编号、优先级、前置条件、测试步骤、预期结果。
第五步，自检。检查用例是否覆盖了需求中的每一个约束条件，比如有效期、次数限制、权限校验。
3.3 输入、输出与覆盖策略
为了让 Skill 输出稳定，还需要在 SKILL.md 中明确它的“输入”和“输出”格式。
输入方面，我们希望用户提供以下信息：
- 功能名称。
- 功能描述。
- 关键业务规则，例如“验证码有效期 5 分钟”。
- 涉及的角色或权限，例如“普通用户、管理员”。
- 需要特殊关注的场景，例如“并发、重复提交、数据越权”。
输出方面，统一使用模板中的字段：
- 用例编号。
- 用例类型。
- 所属模块。
- 优先级。
- 前置条件。
- 测试步骤。
- 测试数据。
- 预期结果。
覆盖策略方面，我会让 AI 至少考虑六类场景：功能正常场景、边界值场景、异常输入场景、权限与安全场景、性能与并发场景、兼容性场景。当然，不同项目的侧重点不同，这些策略可以在 Skill 中按团队需要调整。
4. 实战：编写测试用例生成 Skill
4.1 创建 Skill 目录
在项目目录下执行：
mkdir -p .claude/skills/test-case-generator/templates4.2 编写 SKILL.md
创建.claude/skills/test-case-generator/SKILL.md，内容如下：
--- name: test-case-generator description: 当用户要求生成测试用例、编写测试用例、输出用例、设计测试场景时使用。适用于功能测试用例、接口测试用例、边界条件和异常场景用例的生成。 --- # 测试用例生成技能 你是一名资深测试工程师，负责根据需求描述输出标准、可执行、覆盖完整的测试用例。 ## 输入要求 在开始之前，确认你已经获取了以下信息。如果用户没有提供完整，你需要向用户提问或根据已有信息做合理假设： - 功能名称 - 功能描述 - 业务规则（必填，例如有效期、次数限制、状态流转） - 涉及角色与权限 - 特殊关注点（可选） ## 工作步骤 ### 第一步：解析需求 用列表梳理需求中的关键信息： 1. 核心功能点 2. 输入输出 3. 业务规则和约束 4. 涉及的实体与状态 5. 权限要求 ### 第二步：拆解测试场景 至少覆盖以下六类场景，并用列表列出来： 1. 功能正常场景：主流程能成功完成。 2. 边界值场景：数据在边界和临界状态时的表现。 3. 异常输入场景：格式错误、缺失、超长、重复提交。 4. 权限与安全场景：未登录、越权访问、敏感数据泄露。 5. 性能与并发场景：高频调用、并发请求、超时。 6. 兼容性场景：不同浏览器、不同端、不同系统版本。 ### 第三步：选择测试设计方法 对每个场景标注所使用的测试设计方法，包括但不限于： - 等价类划分 - 边界值分析 - 错误推测 - 场景法 - 因果图与判定表 ### 第四步：生成测试用例 严格按照 templates/test_case_template.md 模板输出，每个字段都必须填写。禁止跳过“前置条件”和“测试数据”。 ### 第五步：自检 输出完成后，逐条检查： - 是否覆盖了需求中的所有业务规则。 - 是否包含至少一条边界用例和一条异常用例。 - 预期结果是否可判断，避免模糊表述。 - 用例步骤是否可执行，不依赖内部实现细节。4.3 编写测试用例模板
创建.claude/skills/test-case-generator/templates/test_case_template.md：
# 测试用例模板 每条测试用例必须包含以下字段： | 字段 | 说明 | | --- | --- | | 用例编号 | 格式：TC-{模块}-{三位序号}，例如 TC-LOGIN-001 | | 所属模块 | 被测功能所属模块 | | 用例类型 | 功能 / 边界 / 异常 / 权限安全 / 性能并发 / 兼容性 | | 优先级 | P0 / P1 / P2 / P3 | | 前置条件 | 执行用例前需要准备的环境、数据或状态 | | 测试步骤 | 用 1. 2. 3. 编号列出的具体操作步骤 | | 测试数据 | 执行用例时需要使用的具体输入数据 | | 预期结果 | 可判断、无歧义的期望结果 |4.4 在 CLAUDE.md 中声明全局规则
创建.claude/CLAUDE.md，把项目级规则固定下来：
# 项目级全局规则 ## 语言 - 所有输出默认使用中文。 ## 测试用例生成约定 - 生成测试用例时，优先使用 test-case-generator 技能。 - 用例输出到 testcases/ 目录，Markdown 格式。 - 每个功能点生成一个独立文件，文件名格式：{功能名}_测试用例.md。 - 用例编号需保持唯一，不要跨文件重复。 ## 输出规范 - 代码、命令、配置示例放在代码块中。 - 使用专业、简洁、可操作的语言，避免空话和套话。4.5 验证 Skill 是否生效
在项目目录下启动 Claude Code：
claude输入以下内容：
请使用 test-case-generator 技能，为以下功能生成测试用例：用户通过手机号和验证码登录，验证码有效期 5 分钟，同一手机号连续输错 5 次后锁定 30 分钟。观察 Claude Code 是否读取了 Skill。如果它按模板输出了用例，说明 Skill 配置成功。如果它没有反应，可以在.claude/skills/test-case-generator/SKILL.md中检查description是否足够接近用户表述，或者重新描述你的任务，例如“使用测试用例生成技能”。
5. 批量生成测试用例实战
5.1 准备结构化需求描述
为了让 AI 输出更稳定，建议先把需求整理成结构化文本。创建requirements.md：
# 测试用例生成需求清单 ## 需求 1：用户登录 - 功能名称：用户登录 - 功能描述：用户通过手机号和验证码登录系统 - 业务规则： - 验证码有效期 5 分钟 - 验证码错误次数达到 5 次后锁定 30 分钟 - 锁定期满后自动解锁 - 同一手机号同一时间段只允许一个有效会话 - 涉及角色：普通用户 - 特殊关注点：验证码重发频率限制 ## 需求 2：订单创建 - 功能名称：订单创建 - 功能描述：用户选择商品后提交订单 - 业务规则： - 库存不足时不能下单 - 每个订单至少包含一件商品 - 订单金额需大于 0 - 涉及角色：普通用户 - 特殊关注点：重复提交、并发扣库存5.2 单功能点生成测试用例
在终端中运行：
claude -p "请读取 requirements.md 中的“需求 1：用户登录”，使用 test-case-generator 技能生成完整测试用例，并输出到 testcases/用户登录_测试用例.md"这里使用了 Claude Code 的非交互式-p参数，可以直接输出结果，适合脚本和批量场景。具体参数以你本机的claude --help为准。
5.3 输出示例与分析
生成结果大致如下：
| 用例编号 | 所属模块 | 用例类型 | 优先级 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 |
|---|---|---|---|---|---|---|---|
| TC-LOGIN-001 | 登录 | 功能 | P0 | 用户已注册，手机号有效 | 1. 输入正确手机号 2. 点击获取验证码 3. 输入正确验证码 4. 点击登录 | 手机号：13800138000，验证码：123456 | 登录成功，进入首页 |
| TC-LOGIN-002 | 登录 | 边界 | P1 | 用户已发送验证码 | 1. 等待 4 分 59 秒 2. 输入验证码 3. 点击登录 | 验证码：123456 | 登录成功 |
| TC-LOGIN-003 | 登录 | 边界 | P1 | 用户已发送验证码 | 1. 等待 5 分 01 秒 2. 输入验证码 3. 点击登录 | 验证码：123456 | 提示验证码已过期，登录失败 |
| TC-LOGIN-004 | 登录 | 异常 | P1 | 手机号已存在 | 1. 输入错误验证码 2. 连续输错 5 次 | 验证码：000000 | 首次 4 次提示验证码错误，第 5 次提示账号锁定 30 分钟 |
| TC-LOGIN-005 | 登录 | 权限安全 | P1 | 账号已锁定 | 1. 等待 29 分钟 2. 输入正确手机号与验证码 | 验证码：123456 | 仍提示锁定 |
| TC-LOGIN-006 | 登录 | 权限安全 | P1 | 账号已锁定 | 1. 等待 30 分钟 2. 输入正确手机号与验证码 | 验证码：123456 | 自动解锁，登录成功 |
| TC-LOGIN-007 | 登录 | 性能并发 | P2 | 网络正常 | 1. 1 秒内重复点击获取验证码 10 次 | 手机号：13800138000 | 接口有频率限制，返回提示“请勿频繁操作” |
| TC-LOGIN-008 | 登录 | 异常 | P2 | 无 | 1. 输入空手机号 2. 点击获取验证码 | 手机号：空 | 提示请输入手机号 |
| TC-LOGIN-009 | 登录 | 异常 | P2 | 无 | 1. 输入 9 位手机号 2. 点击获取验证码 | 手机号：138001380 | 提示手机号格式不正确 |
| TC-LOGIN-010 | 登录 | 功能 | P1 | 用户已登录 | 1. 在另一台设备上使用同一账号登录 | 手机号：13800138000 | 前置会话被顶下线，新设备可正常使用 |
可以看出，AI 生成用例时会把需求中的业务规则充分“展开”成多个具体场景。特别是边界值（4 分 59 秒、5 分 01 秒）和错误次数（第 5 次触发锁定）这类信息，如果人工编写很容易遗漏。
不过，这类输出仍然需要人工评审。比如“顶下线”策略是否真的存在，需要结合产品设计确认。如果是纯功能验证角色，建议在评审时重点核对“业务规则”是否和实际代码实现一致。
5.4 多个功能点批量生成
单功能点手动调用可用，但如果需求很多，建议直接写一个批量命令：
claude -p "读取 requirements.md 中的全部需求，逐个使用 test-case-generator 技能生成测试用例，每个需求输出一个 Markdown 文件到 testcases/ 目录，文件命名与需求名称保持一致。"进一步，你还可以写一个简单的循环脚本：
for requirement in "用户登录" "订单创建"; do claude -p "使用 test-case-generator 技能，为 requirements.md 中的“$requirement”生成测试用例，输出到 testcases/${requirement}_测试用例.md" done这样，一批需求就能批量产出标准用例文件，后续可以提交到 Git 仓库，也可以由脚本自动解析并导入测试管理平台。
6. 常见问题与排查思路
6.1 常见报错速查表
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
提示claude: command not found | 未安装成功或全局 bin 目录不在 PATH | 执行npm install -g @anthropic-ai/claude-code，确认安装路径并检查 PATH |
| 启动后报 529 错误 | 服务端过载或请求频率过高 | 等待一段时间后重试，降低并发调用频率，检查是否触发了限流 |
| Skills 不生效，AI 按普通对话回答 | description描述与任务不匹配，或 Skill 目录位置不对 | 确认目录为.claude/skills/<skill-name>/SKILL.md，调整描述，使其更接近用户习惯表达 |
| 生成的用例格式不符合模板 | Claude 没有读取模板文件，或模板路径写错 | 在 SKILL.md 中明确引用templates/test_case_template.md，检查相对路径是否正确 |
| 多次生成结果差异大 | 输入需求不够结构化，或模型随机性较高 | 用结构化的需求描述作为输入，在 Skill 中强化输出模板，必要时使用非交互模式并固定 prompt |
提示xxx is not a model this version of claude code recognizes | 当前使用的模型名称不被当前版本识别 | 检查模型名称拼写，确认与当前 Claude Code 版本兼容；如使用非官方接入方式，需要自行评估稳定性和合规性 |
6.2 生成效果不稳定怎么办
生成效果不稳定，最直接的原因是“输入不够结构化”。同样是“写登录的用例”，一句话描述和一段包含业务规则的描述，产出质量会差很多。
建议把需求模板固定下来，每次填写相同结构的需求描述。哪怕没有正式的需求文档，也可以先按以下格式整理：
功能名称： 功能描述： 业务规则： 涉及角色： 特殊关注点：当输入足够规范，AI 的输出质量会明显上升。另外，可以在 Skill 中增加“如果需求信息不完整，先向用户提问”的规则，避免 AI 跳过关键信息直接生成。
7. 最佳实践与工程建议
7.1 让需求输入更规范
AI 生成测试用例的质量，很大程度上取决于“需求输入”的质量。建议团队沉淀一份需求描述模板，让产品或研发在提测时一起填写。一开始可能会觉得多写几行字很麻烦，但这份结构化输入既能给 AI 用，也能让开发和测试对需求的理解更一致，整体收益是正的。
7.2 把 Skill 沉淀为团队资产
Skills 不应该只存在个人电脑里。建议把整个.claude/配置目录纳入 Git 仓库，团队成员共享同一套测试用例模板、覆盖策略和命名规范。这样，不同人用 Claude Code 生成用例时，输出的风格是一致的，后续维护成本会低很多。
Skill 文件本身也是代码，需要版本管理。当测试模板或覆盖策略有调整时，通过代码评审合并，而不是口头沟通，这样能保证执行口径统一。
7.3 与现有测试流程集成
AI 生成的测试用例要真正产生价值，最好和现有流程打通：
- 可以把生成的 Markdown 用例导入禅道、Jira Xray、TAPD 等测试管理平台。
- 可以在 CI/CD 中增加一个“AI 生成用例草稿”的步骤，在需求进入测试阶段时自动生成初稿。
- 可以把用例模板设计成和自动化脚本字段一致，后续由用例自动生成 Playwright、Selenium 等脚本的骨架。
需要注意的是，自动化生成脚本属于另一个话题，AI 生成的用例字段如果足够规范，可以作为自动化用例设计的起点，但不要直接让 AI 生成并执行未经评审的测试代码。
7.4 权限、安全与合规注意事项
使用 Claude Code 处理测试用例时，要特别注意数据安全边界。不要在需求描述中提交真实的用户手机号、身份证号、银行卡号等敏感数据，应使用脱敏后的测试数据。不要将 API Key、访问令牌、生产环境地址写到 Skill 或 CLAUDE.md 中。
涉及生产环境的数据读取、变更操作时，务必遵循最小权限原则。AI 工具只是辅助，所有变更决策仍需要人工确认。在把 Skill 分享到团队仓库前，应检查其中是否包含内部系统的敏感信息。
8. 总结与下一步学习
这套流程跑通后，我最直观的感受并不是“AI 能直接写好测试用例”，而是“AI 能把测试用例的格式和框架在几秒钟内搭好，测试人员只需要做判断题和补充题”。对于需求多、排期紧的项目，这个效率提升非常明显。
本文主要掌握了三件事：
第一，Claude Code 的安装与基本使用，以及.claude/项目配置目录的约定。
第二，Skills 的工作原理，重点是SKILL.md的结构，以及name和description对触发效果的影响。
第三，编写了一个完整的测试用例生成 Skill，并实现了从单功能点生成到多需求批量生成的全流程。
接下来可以继续探索的方向包括：学习测试用例设计方法论，把等价类划分、边界值分析、场景法等更系统地写进 Skill 的覆盖策略；尝试让 AI 基于测试用例生成自动化脚本；以及把生成的用例通过脚本导入现有测试管理平台，形成完整的自动化闭环。
如果你在实际配置过程中遇到问题，欢迎在评论区留言交流。如果本文对你有帮助，也别忘了收藏备用。
