上个月，团队里一个测试新人跑来找我，表情有点委屈。

“哥，我在项目里放了一个 SKILL.md，为什么 Claude Code 还是不会干活？”

我让他把文件打开。里面写着一段话：“你是资深测试工程师，请帮我生成测试用例，覆盖正常和异常场景。”

我看完就笑了。我说：“你这不是 Skill，是许愿。”

他愣了一下：“SKILL.md 不就是写提示词吗？”

**这是大多数测试人刚接触 Agent Skills 时的第一个误解。** SKILL.md 不是提示词。它是一份结构化的操作手册。你写“帮我生成用例”，Agent 只会给你一段文本。你写清楚“第一步读什么、第二步拆什么、第三步输出什么格式、遇到异常怎么处理”，Agent 才知道该怎么干活。

今天这篇文章，我把“从 PRD 到高质量测试用例”的完整链路拆开讲。不是讲概念，是给你可以直接复制使用的模板和流程。


## 一、为什么你写的 SKILL.md 总是不生效？

过去一年，很多团队都在尝试用 AI 做测试。但真正跑起来的没几个。

问题出在哪？**不是模型不行，是你给它的东西不是一个“能力单元”。**

我们过去用 AI 做测试，基本套路就是写一段系统提示词：“你是资深测试工程师，请按照以下步骤执行回归测试……”然后期待它自己搞定一切。这个思路有一个根本性缺陷：**LLM 是语言模型，不是操作系统的内核。** 它可以告诉你“应该先登录再查询”，但面对动态验证码、偶尔超时的 API、需要滑动解锁的按钮，纯文本推理能力完全不够用。

Prompt 是说明书，告诉 Agent“拧开螺丝”。但真实任务执行，需要知道螺丝刀在哪个抽屉、顺时针拧几圈、遇到滑丝怎么处理——这些确定性操作流程，Prompt 给不了。

**Agent Skills 解决的就是这个问题。** Anthropic 官方对 Skill 的定义很干脆：一个 Skill 就是一个文件夹。里面必须有一个 `SKILL.md` 文件，还可以放脚本、参考资料、静态资源。

用大白话说：**Skill 就是把“资深测试工程师怎么做一件事”的完整经验，封装成一个 Agent 能随时调用的能力包。**

它和 MCP 的区别是什么？MCP 解决“模型能用什么工具”——连数据库、接 GitHub、操作浏览器。Skill 解决“模型该怎么用这些工具”——按什么步骤、什么格式、什么标准。**MCP 给 Agent 提供手，Skill 给 Agent 提供操作手册。** 没有 Skill，Agent 有手也不知道怎么干活。


## 二、全景总览：生成测试用例需要哪几个 Skill？

测试用例设计的全流程，本质上可以拆成四个环节。每个环节封装成一个独立的 Skill，串起来就是一条从需求到用例的自动化流水线。

| 阶段 | Skill | 核心职责 | 输入 | 输出 |
|------|-------|---------|------|------|
| **需求拆解** | `prd-to-test-map` | 把 PRD 变成“测试地图” | 需求文档 | 功能清单+业务规则+风险预判 |
| **用例生成** | `test-case-generator` | 把测试地图变成结构化用例 | 测试地图 | 用例表格（正常/异常/边界/权限） |
| **场景补全** | `test-scenario-completion` | 基于历史 Bug 补充隐藏场景 | 用例集+历史Bug | 增强用例集 |
| **质量评审** | `test-case-reviewer` | 给用例集打分并给出改进建议 | 用例集 | 评审报告+改进项 |

数量和不用记，看分布有意思得多。**活儿全压在两头：前面把需求拆清楚，后面把质量收干净。** 中间的用例生成反而是最“顺”的一环，因为规则明确、格式固定。真正拉开差距的是需求拆解（能不能识别出隐性业务规则）和质量评审（能不能发现用例集的盲区）。


## 三、逐个拆解：每个 Skill 解决什么问题、怎么写、怎么用？

### Skill ①：需求拆解——把 PRD 变成“测试地图”

**解决什么问题？**

拿到一份需求文档，很多人第一反应是“从头开始读”。但 PRD 往往写得不够结构化——功能描述、业务规则、异常说明散落在不同章节。测试人员需要手动提取功能点、梳理业务规则、识别风险点，这个过程高度依赖个人经验。

**SKILL.md 怎么写？**

```yaml
---
name: prd-to-test-map
description: 从PRD中提取功能点、业务规则、数据约束和风险预判，生成结构化测试地图。当用户提到“分析需求”“拆解PRD”“梳理测试点”时触发。
when_to_use: 需求评审阶段，需要将PRD转化为可执行的测试点清单时使用。
---
```

```markdown
## 任务
将用户提供的需求描述或PRD内容，转化为结构化的测试地图。

## 输出格式
1. **功能清单**：列出所有需要测试的功能点
2. **业务规则**：状态流转、计算公式、权限控制、限制条件
3. **数据约束**：输入数据的类型、格式、范围、必填性
4. **风险预判**：基于经验判断哪些功能最容易出问题（高/中/低）

## 规则
- 只从输入内容中提取信息，不臆造不存在的功能
- 如果某项信息不明确，标注“需确认”而不是猜测
- 风险预判基于通用测试经验：并发场景、边界值、状态流转通常为高风险
```

**核心规则：事实与猜测分离。** 每条输出标注证据来源（需求依据/经验假设/待确认）。需求没写的规则标注`[待确认]`，不要编造。

**实测效果：** 一份十来页的 PRD，Agent 在几秒内输出功能清单、业务规则、数据约束、风险预判。功能清单列了 3 条（已登录用户加入购物车、未登录触发登录引导、购物车数量上限校验），业务规则列了 4 条（上架校验、库存校验、数量累加、上限限制），风险预判标出了 3 个高/中风险点。


### Skill ②：用例生成——把“测试地图”变成“测试用例”

**解决什么问题？**

有了测试地图，接下来要把它“翻译”成具体的测试用例。传统方式是手动一条条写——前置条件、操作步骤、预期结果。这个过程步骤繁琐、规则固定、重复性极高。

**SKILL.md 怎么写？**

```yaml
---
name: test-case-generator
description: 根据功能描述或需求文档生成覆盖正常流程、异常场景、边界条件和权限校验的结构化测试用例。当用户提到“生成测试用例”“编写测试”“测试覆盖”“测试场景”时自动触发。
when_to_use: 用户需要从需求文档或功能描述生成测试用例时使用。适用于功能测试、回归测试、接口测试的用例设计阶段。
---
```

```markdown
## 任务
根据用户提供的功能描述或测试地图，生成覆盖四大类场景的测试用例。

## 执行步骤

### 步骤1：理解测试地图
读取功能清单、业务规则和数据约束。

### 步骤2：识别测试场景
- **正常流程**：至少覆盖1条完整的Happy Path
- **异常场景**：参数缺失、格式错误、依赖服务超时
- **边界条件**：数值边界、状态边界、时间窗口边界
- **权限校验**：未授权访问、越权操作

### 步骤3：生成用例
每条用例包含：用例编号、测试场景、前置条件、测试步骤、预期结果、优先级

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

## 输出格式
Markdown表格，可直接复制到Excel或测试管理工具。
```

**核心规则：SKILL.md 控制在 500 行以内。** Anthropic 官方推荐正文目标约 200 行，最多 500 行。超过 500 行，必须把详细内容移到 `references/` 目录。

**实测效果：** 测试新人小陈接了一个“订单取消功能”的用例设计任务。按以往经验，这活儿至少 3 天。他打开 Claude Code，调了这个 Skill，**2 小时后交出了一份覆盖正常流程、异常场景、边界值、权限校验的完整用例集。** 测试组长看完之后，沉默了一会儿，问了一句：“这是谁写的？质量比我自己写还高。”


### Skill ③：场景补全——把“没想到”的找出来

**解决什么问题？**

Skill ② 生成的用例已经很全面了，但 AI 毕竟不是人——它可能漏掉一些“只有业务老手才知道”的隐藏场景。比如并发下单时的库存扣减、优惠券和满减的叠加规则、异常状态下的回滚逻辑。

**SKILL.md 怎么写？**

```yaml
---
name: test-scenario-completion
description: 基于历史Bug模式和业务知识，补充AI生成的测试用例中遗漏的隐藏场景。当用户提到“补充场景”“查漏补缺”“完善用例”时触发。
---
```

```markdown
## 任务
审查已有的测试用例集，结合历史Bug数据和业务上下文，识别并补充遗漏的测试场景。

## 检查维度
1. **并发场景**：多用户/多请求同时操作同一资源
2. **状态流转**：异常状态下的操作（如已取消订单再次操作）
3. **数据一致性**：跨模块的数据同步（如订单取消→库存回滚）
4. **边界组合**：多个边界条件同时出现的情况
5. **历史故障**：该模块历史上出过什么类型的Bug

## 输出格式
对每个补充的场景，说明：场景描述、补充理由、具体的测试步骤和预期结果。
```

**核心规则：知识图谱不需要很复杂。** 一张 Excel 表格就够了——记录着“这个模块历史上出过什么类型的 Bug”。Agent 读取这张表，就能识别出“AI 没想到但很可能出问题”的场景。


### Skill ④：质量评审——给用例集“打分”

**解决什么问题？**

用例写完了，但质量怎么样？覆盖全不全？有没有冗余？有没有逻辑矛盾？传统方式是人工评审——开个会，一群人对着 Excel 一条条看，效率低下且依赖评审人的经验水平。

**SKILL.md 怎么写？**

```yaml
---
name: test-case-reviewer
description: 对测试用例集进行自动化质量评审，从覆盖完整性、规范性、一致性、优先级四个维度打分并给出改进建议。当用户提到“评审用例”“检查用例质量”“用例打分”时触发。
---
```

```markdown
## 任务
审查测试用例集的质量，输出结构化的评审报告。

## 评审维度
1. **覆盖完整性**：是否覆盖了正常流程、异常场景、边界条件、权限校验？
2. **用例规范性**：每条用例是否包含完整的“前置条件-步骤-预期结果”？
3. **逻辑一致性**：前置条件和预期结果之间是否存在逻辑矛盾？
4. **优先级合理性**：P0/P1/P2的划分是否合理？

## 输出格式
- 总体评分（百分制）
- 各维度评分
- 待改进项列表（每条说明问题、位置、改进建议）
- 评审结论（通过/有条件通过/不通过）
```

**核心规则：让 AI 先做一轮“预审”。** 把明显的问题筛出来，人工只需要关注 AI 搞不定的部分。比如 AI 会指出“TC-007 步骤描述过于简略”“TC-009 缺少同步后验证数据一致性的步骤”“TC-003 涉及核心业务流程，建议从 P1 升级为 P0”。


## 四、完整流水线：四个 Skill 串起来怎么跑？

在 Claude Code 里，按顺序调用：

```
第1步：/prd-to-test-map → 输入PRD，输出测试地图
第2步：/test-case-generator → 输入测试地图，输出用例初稿
第3步：/test-scenario-completion → 输入用例集，补充隐藏场景
第4步：/test-case-reviewer → 输入用例集，输出评审报告
```

**传统方式**：啃 PRD（半天）→ 梳理测试点（半天）→ 写用例（1-2天）→ 人工评审（半天）→ 修改（半天）——**总计 3-4 天。**

**Skill 流水线**：四个 Skill 依次触发——**2 小时出初稿，1 小时审核定稿。** 效率提升 10 倍以上。


## 五、落地建议：别一次全装

拆解完四个 Skill 之后，说几条务实的建议。

**第一，只装你最痛的那一段。** 需求痛装需求拆解，用例痛装用例生成，质量痛装质量评审。全装一遍的结果通常是每个都跑过一次，然后一个都没用起来。

**第二，喂进去真东西。** 必须给项目真实的 PRD、真实的历史 Bug 表。用假数据跑出来的结果没有参考价值。

**第三，打分只当提醒。** 评审 Skill 给你 72 分，是让你去看哪条被扣分，不是让你把那个数字抄进周报。


## 六、踩坑提示：三个最常见的坑

**坑一：description 写得太空。** “帮助生成测试用例”——这句话等于没说。Claude 会把所有 Skill 的 description 预加载进上下文，用来判断该不该触发。你写“帮助测试”，它永远不知道什么时候该用。你写“当用户提到生成测试用例、编写测试、测试覆盖、测试场景时触发”，它就知道。**description 是 Skill 的“门牌号”，不是广告词。** 

**坑二：SKILL.md 写成百科全书。** 超过 500 行就开始浪费 Token。把详细的用例模板、业务规则库、历史 Bug 模式放到 `references/` 目录，SKILL.md 只留核心流程和导航。利用渐进式披露机制——平时只加载名字和描述，等到真正使用时才加载完整内容。

**坑三：Skill 粒度拆得太细。** 一个工作流拆成 10 个 Skill，AI 不知道该用哪个。SkillsBench 的研究发现，**2-3 个模块的 Skill 表现最好**。测试用例生成拆成四个 Skill 是极限，拆成五个以上就开始反噬了。

**额外提醒：** 这类 Skill 的名字和能力会跟着版本变，装之前先看它自己那份说明。有些 Skill 要靠 MCP 或 API 接外部服务，意味着浏览器、测试平台、缺陷系统的权限都得开出去。公司的 PRD、日志、用户数据要走这条路，先问一句合规。


## 七、认知升华：从“工具切换者”到“工作流设计者”

一条链路跑下来，30 条用例变 70 条，但每条都有出处、有覆盖方向、有风险等级。但比数字更重要的是：**你终于不用在“写用例、查覆盖、修脚本、拼报告”之间来回切换了。**

四个 Skill 可以独立工作，也可以串联成矩阵。但“哪些场景必须覆盖”“哪些断言真正有价值”“失败之后该修脚本还是提 Bug”——这些判断，只能人来做。

**以前你是“工具切换者”，现在你是“工作流设计者”。**

测试人的经验，值得被封装成 Skill。你今天花 30 分钟写一个“测试用例生成”的 Skill，以后每一个项目都能复用。你今天花 20 分钟优化了 Skill 的规则，以后每一次生成都会更精准。

**别只写提示词了。写一个 SKILL.md，让 Agent 真正替你干活。**

>本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。


“哥，我在项目里放了一个 SKILL.md，为什么 Claude Code 还是不会干活？”

如何用 Agent Skills 自动生成测试用例？完整拆解

测试

人工智能

开发工具

从PRD到测试用例，用AgentSkills打造自动化流水线：拆解需求、生成用例、补全场景、质量评审四步走，效率提升10倍。核心是写结构化操作手册而非提示词，让AI真正按步骤干活。掌握SKILL.md写法，从工具切换者升级为工作流设计者。

数据一致性

代码解释

软件测试

回归测试

知识图谱

数据同步

数据库

验证码

Markdown

GitHub

Agent

2026上云采购 | AI焕新·智启新局

coding

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

如何用 Agent Skills 自动生成测试用例？完整拆解-腾讯云开发者社区-腾讯云

如何用 Agent Skills 自动生成测试用例？完整拆解

如何用 Agent Skills 自动生成测试用例？完整拆解

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐