用Claude Code与Skills实现测试用例自动化生成

在项目迭代过程中每次提测前都要花大量时间编写测试用例。需求一多用例写不过来格式不统一评审时还要反复修改。最近我在本地把 Claude Code 和 Skills 结合起来搭建了一套自动生成测试用例的流程把“需求描述”变成“标准测试用例”的时间从小时级压缩到了分钟级而且生成的用例格式稳定、覆盖场景完整。本文把这套流程完整整理出来包含 Claude Code 的安装配置、Skills 的原理、测试用例 Skill 的编写方法以及批量生成测试用例的实战示例。不管你是测试工程师、测试开发还是需要自己写用例的后端、前端开发者都可以照着这篇文章把流程跑起来。1. 背景与核心概念1.1 Claude Code 是什么Claude Code 是 Anthropic 推出的命令行 AI 编程助手。简单理解它把 Claude 模型的能力放到了终端里让你可以在项目目录中直接和 AI 对话读文件、写代码、执行命令、解释报错、重构代码等操作都能在同一个会话里完成。它和普通网页版 AI 聊天的最大区别是“上下文感知”。你不用把整个项目代码复制粘贴给 AIClaude 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 / WindowsWSL 或原生终端本文以 macOS 为例Windows 建议使用 WSL 体验更一致Node.js较新的 LTS 版本Claude Code 基于 Node.js 分发版本过旧可能导致安装失败命令行工具npm、git用于安装和版本管理Claude 账号或 API Key需要能访问 Claude 服务首次运行会引导登录或配置 API Key网络环境能正常访问依赖源如果 npm 下载慢建议先配置国内镜像源需要说明的是AI 工具版本更新很快不同版本的安装方式、参数细节可能略有差异。如果你按本文操作时发现命令参数对不上优先以官方文档和--help输出为准。2.2 安装 Claude CodeClaude 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.mdSkill 的核心描述文件。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. 实战编写测试用例生成 Skill4.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 Codeclaude输入以下内容请使用 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 基于测试用例生成自动化脚本以及把生成的用例通过脚本导入现有测试管理平台形成完整的自动化闭环。如果你在实际配置过程中遇到问题欢迎在评论区留言交流。如果本文对你有帮助也别忘了收藏备用。