干了这么多年测试最烦的事情不是写用例本身而是把需求文档里的那点业务逻辑一个字一个字地抠出来翻译成一条条用例。特别是碰上那种几千字的PRD还夹杂着流程图、状态表、异常分支光提取测试点就能耗掉一上午。后来我发现Claude Skill 这个能力完全可以把这件事做成一条流水线喂进去一份文档吐出来一份结构完整的测试用例md文件甚至还能顺手生成一套 Playwright 自动化脚本。这套东西的本质是把测试工程师脑子里那套怎么读需求、怎么拆场景、怎么定优先级的经验固化成规则写进 Skill 文件里再交给 Claude 去执行。听起来玄乎实际落地其实不复杂。这篇文章我会把这个 Skill 怎么设计、SKILL.md 文件怎么写、遇到问题怎么调从头到尾捋一遍测试同行可以直接照着搭一套属于自己的。1. 这个 Skill 到底解决了什么问题1.1 测试工程师每天都在做二次翻译很多人觉得测试用例就是点几下、看结果但真正写过用例的人都懂这活儿本质是在做翻译把产品经理写的自然语言翻译成计算机能验证的行为描述。翻译过程中要补充大量的上下文——这个按钮置灰是什么条件下出现的这个接口返回错误码前端要怎么表现用户取消操作之后数据要不要回滚这些上下文大部分时候文档里没有全靠测试自己去问、去猜、去翻历史代码。我经常看到团队里两个测试同学对同一个需求写出来两个版本的用例覆盖范围完全不一样原因就是大家在翻译的时候各自脑补的规则不同。Claude Skill 解决的就是这个脑补不统一的问题。把翻译规则固定下来让每一次用例生成都遵循同一套拆解逻辑输出格式也是统一的 Markdown 结构。对我来说它不是一个简单的AIGC 生成工具而是把团队里最有经验那个老测试的思维方式复制到了每一个项目里。1.2 Claude Skill 和普通聊天提示词有什么不同直接复制一段需求文档扔给 Claude 让它写用例也能跑通但效果非常不稳定。今天生成的用例结构是这种明天又变成另一种你每次都要改提示词而且改来改去颗粒度也时粗时细。Claude Skill 的差别在于它是一套打包好的职业能力包。通过项目目录下的SKILL.md文件把角色定位、执行步骤、输出格式、校验规则全部固定下来Claude 执行的时候不是自由发挥而是按你定义的工作流走。打个比方普通提示词像是你临时拉了个实习生口头跟他讲今天帮我把测试用例整理一下他干成什么样全看悟性。而 Skill 相当于你给这个实习生配了一本厚厚的《岗位操作手册》和一套标准模板从打开文档到输出成果每一步都有规范。我用下来最明显的感受有几点输出格式稳定。字段、层级、表格结构只要模板不变每次生成的结果都是同一套骨架。领域知识内嵌。可以把等价类、边界值、状态迁移这些测试理论写进规则里而不是每次都在提示词里现教。可复用、可分享。一个 Skill 就是一个文件夹拷给同事就能用换项目也只需要改少量描述。这也是我为什么强烈推荐用 Skill 而不是收藏一堆提示词模板的原因——提示词是散的Skill 是成套的。2. 核心设计思路与方案选型2.1 为什么选 Markdown 文件作为技能载体刚开始设计这个 Skill 的时候我其实想过把规则写在一个 JSON 配置里或者直接用 Python 脚本去解析文档。后来都推翻了最终选了SKILL.md这个纯 Markdown 载体理由很简单规则本身需要被反复阅读和维护。Markdown 的优势在于它既是给人看的也是给模型看的。团队里不懂代码的测试同事打开 SKILL.md也能看懂这个 Skill 的工作流程而 Claude 对 Markdown 的结构化理解非常成熟一级标题、二级标题、表格、列表都能准确解析成指令。相比之下JSON 和脚本的可读性差很多改一条规则都得过一遍语法。另一个原因和 Git 有关。Markdown 文件在版本管理里非常友好每次改了规则git diff看得清清楚楚。我在实际维护过程中经常需要对比两个版本的 Skill 在生成结果上的差异如果是二进制配置文件这种对比就很痛苦。还要补充一点md 文件的生态足够成熟。Vitest、Playwright、各种文档站点都用 Markdown 做载体后续想把 Skill 的说明文档、示例用例和规则文件放在一起管理用目录结构就能轻松组织。这个选择不是最酷的但绝对是最省心的。2.2 从文档到用例的整体工序设计一个完整可用的测试用例生成流程不能只是把文档发给 Claude这么简单。我在设计时拆成了五道工序每道工序都有明确的输入输出文档解析先让 Claude 通读输入内容识别文档类型PRD、接口文档、操作手册还是历史用例提取出功能模块清单、业务流程、数据字段、业务规则。规则提取从业务流程和数据字段中找出所有可被测试验证的点包括正常路径、分支路径、异常路径。这一步我会让 Claude 特意标注出文档里模糊的地方方便后面追问。场景设计对每个功能点套用测试设计方法——等价类划分、边界值分析、状态转换、错误猜测生成具体的测试场景。这一步的目标是保证覆盖度不急着写详细步骤。用例编写把场景填充成标准格式用例包括前置条件、测试步骤、预期结果、优先级、用例编号。输出校验最后让 Claude 自查一遍对照原始需求文档检查有没有遗漏的功能点、有没有模棱两可的预期结果再按模板输出 markdown 文件。这套工序是我反复调了很久才定下来的。最早的方案只有三步理解文档、生成用例、输出。但后来发现有个致命问题——Claude 跳过了规则提取这个中间层直接生成用例导致它经常会漏掉文档里藏在某个表格里的边界条件。加了中间层之后生成的覆盖度提升非常明显因为规则提取让模型强制做了一次找全所有可测试点的动作而不是急着动笔写。2.3 关键决策把测试经验写进规则这个 Skill 对比普通提示词生成最大的差异点在于我把我自己的测试方法论写进去了一部分。比如规则里明确要求每个功能点至少覆盖一个正常场景、一个边界场景、一个异常场景有数值输入的地方必须检查边界值和边界外的值有状态切换的地方必须覆盖每个状态的入口和出口不能只测主流程涉及删除、修改操作的地方必须考虑数据关联影响比如删除一个正在被引用的数据应该被阻止预期结果不能写系统提示成功必须写清楚具体反馈形式和后续状态这些规则说白了就是我在多年测试生涯中踩过的坑。之前发现问题最多的地方就是所有人都测了正常能跑通但极少有人测这个值刚好超了一位小数会怎样这个状态删了正在被下一步使用会怎样。把经验写成规则之后好处是这个 Skill 不再是一个大语言模型玩具而是一个有测试思维的工具。同一个需求文档直接问 Claude 和通过 Skill 生成覆盖度完全不在一个量级。3. SKILL.md 文件编写实操3.1 Skill 目录结构与最小落地形态Claude Skill 的目录结构非常轻量不需要额外的依赖一个文件夹加一个 SKILL.md 就能跑起来。我常用的目录结构是这样的test-case-generator/ ├── SKILL.md # 核心技能定义 ├── templates/ │ ├── test-case-template.md # 用例输出模板 │ └── report-template.md # 覆盖度报告模板 └── examples/ ├── sample-prd.md # 示例需求文档 └── sample-output.md # 示例输出结果SKILL.md 是整个 Skill 的心脏。它最基础的结构包含两块metadata和instructions。metadata 写这个技能的名字和触发的描述相当于给 Claude 一个识别标签instructions 是核心写 Claude 拿到输入之后应该用什么样的流程去处理。一个最精简的 SKILL.md 头部长这样--- name: test-case-generator description: 基于需求文档自动生成结构化的功能测试用例输出标准 Markdown 文件。适用于 PRD、接口文档、功能描述等测试场景。 --- # Test Case Generator 你是一名拥有超过10年经验的资深测试工程师擅长功能测试、接口测试和自动化测试。你的任务是阅读用户提供的需求文档按照本文档中的流程和规则生成高质量的测试用例。这里的description字段非常关键它决定了 Claude 什么时候会调用这个 Skill。我试过比较泛的描述比如生成测试用例结果该调用的时候没触发不该调用的时候反而乱触发。后来改成基于需求文档自动生成结构化的功能测试用例输出标准 Markdown 文件触发准确率直线上升。这其实是 prompt 工程里的老原则——描述越具体触发越准确。3.2 规则指令段的设计要点instructions 部分是整个 Skill 的重头戏也是我调得最多的部分。我建议把规则拆成几个小节来写每个小节聚焦一个维度## Skill 工作流程 1. 第一步阅读用户提供的所有文档内容分类识别文档类型。 - 若文档包含接口地址请求方式参数说明等关键词归类为接口文档。 - 若文档包含用户故事业务规则功能描述等关键词归类为功能需求文档。 - 若文档是历史测试用例则先分析其覆盖度和格式再按新模板重构。 2. 第二步提取所有功能模块、业务流程、数据字段、业务规则形成测试点清单。 3. 第三步按照正常场景、边界场景、异常场景三类为每个测试点设计测试场景。 4. 第四步将测试场景填充为标准测试用例。 5. 第五步对照原始文档自查确认无遗漏后输出 Markdown 文件。流程写完之后一定要写约束条件## 约束条件 - 不允许编造文档中不存在的功能点如果文档描述不清晰在用例备注中标注待确认。 - 每个功能模块下必须有主流程用例和异常流程用例。 - 涉及数值输入的参数必须包含边界值用例值域最小值、最大值、超出值域一个单位。 - 预期结果必须具体到页面反馈、接口返回码或数据状态变化禁止写正常或成功这样模糊的词语。这里我踩过一个坑最早的时候我把约束条件写得非常多有20多条结果 Claude 生成的时候经常顾此失彼顾了边界值忘了异常场景。后来我把约束做减法只保留对覆盖度影响最大的核心规则其他的放到 templates 模板里让格式来兜底效果好很多。3.3 用例输出模板的设计细节输出模板决定了生成的用例长什么样。我设计的模板是这套字段字段说明用例编号规则模块名-功能点-序号例如 LOGIN-001所属模块顶层功能模块名称用例标题一句话描述测试场景格式为xxx时应xxx优先级P0核心路径、P1重要功能、P2次要或异常前置条件执行前需要满足的数据或状态测试步骤编号列表每一步都是可执行的操作预期结果与步骤一一对应的可验证结果把这个模板存到templates/test-case-template.md里SKILL.md 里只需要写一句严格按 templates/test-case-template.md 的模板输出Claude 就会自己去读模板文件。注意不要让 Claude 把这个模板内嵌到 SKILL.md 里否则规则越来越长指令之间会互相干扰。优先级判定我也写进了规则主流程且影响核心业务目标的是 P0重要分支、有数据变更的是 P1异常提示、边缘情况、UI细节是 P2。这个分类和很多团队的用例优先级定义是匹配的可以直接复用。4. 实操演示从需求文档到测试用例4.1 输入文档的准备技巧Skill 的效果很大程度上取决于输入文档的质量。我试过直接把零散的产品需求聊天记录抛进去结果生成的用例也很零散。这里的经验是进 Skill 之前先完成一次粗加工。我一般会先检查文档里有没有这样几个要素功能清单这个模块到底要做哪几个功能最好有模块树。业务流程用户从进入到完成操作的路径是什么有没有分支。字段说明每个输入框/接口参数的类型、长度、是否必填。业务规则比如同一用户最多绑定五张银行卡超过三笔未支付订单不能再下单这种。不是每个需求文档都有这些要素但缺了哪一个生成的用例在对应维度上就会偏弱。缺字段说明的文档生成的用例很少涉及输入校验和边界值缺业务规则的文档生成的用例很难覆盖到复杂的业务分支。所以我在 Skill 的 instructions 里加了一条如果输入文档缺少上述要素Claude 必须在输出用例之前先列出本次生成依据中缺失的信息清单并给出补充建议。这个小小的改动让整个生成过程从闷头输出变成了缺什么会主动告诉你实际体验好很多。4.2 一次完整的生成过程演示拿一个最简单的用户登录需求文档来举例。输入大概长这样登录功能 - 用户输入手机号和密码点击登录按钮验证通过后进入首页。 - 手机号为11位数字密码为6-20位字符。 - 手机号或密码错误时提示手机号或密码错误。 - 连续5次密码错误账户锁定30分钟。这个需求极其常见但真正写起来想覆盖全也不容易。通过 Skill 生成的结果会先产出一份测试点清单再展开为用例。下面是其中几条用例编号用例标题优先级前置条件测试步骤预期结果LOGIN-001输入正确的手机号和密码时应登录成功P0已注册用户且密码正确1. 输入11位手机号 2. 输入正确密码 3. 点击登录跳转至首页登录状态为有效LOGIN-004手机号位数小于11位时应提示格式错误P1未输入任何信息1. 输入10位手机号 2. 输入任意密码 3. 点击登录提示手机号格式不正确不发起登录请求LOGIN-007密码错误次数达到5次时账户应锁定P0正确手机号密码已知错误1. 连续输入错误密码5次 2. 第6次输入正确密码 3. 点击登录提示账户已锁定请30分钟后再试即使密码正确也不允许登录LOGIN-009锁定状态下第31分钟再次尝试应可以登录P2已锁定的账户锁定时间已过1. 等待锁定时间超过30分钟 2. 输入正确手机号和密码 3. 点击登录登录成功进入首页对比一下直接让 Claude 草草生成的用例差的往往是 LOGIN-007 和 LOGIN-009 这种涉及状态锁定与时间边界的用例。这两个恰好是线上最容易出问题的点——我们之前真出过一个事故用户输错密码锁定之后因为服务端用的是滚动窗口计时导致过了30分钟还解不了锁。如果当时就用了这个 Skill打死都不会漏这类场景。4.3 对接 Playwright 生成自动化脚本生成手工用例只是第一步这个 Skill 更大的价值在它可以继续往自动化测试方向延伸。我在 SKILL.md 里加了一个可选模式当用户提出需要自动化脚本时Claude 会基于已生成的 P0 和 P1 用例输出配套的 Playwright 测试脚本。为什么选 Playwright这个我自己实测过对比 Selenium 和 CypressPlaywright 在自动等待、选择器稳定性和浏览器兼容性上都要省心很多。尤其是它内置的auto-waiting机制测试脚本里不需要写一堆sleep跑起来又稳又干净。Skill 里对自动化脚本的规则简单几条只对 P0/P1 用例生成脚本P2 的边界场景优先保留为手工用例。定位元素优先顺序>import { test, expect } from playwright/test; test(LOGIN-001 输入正确的手机号和密码时应登录成功, async ({ page }) { await page.goto(/login); await page.getByLabel(手机号).fill(13800138000); await page.getByLabel(密码).fill(Passw0rd123); await page.getByRole(button, { name: 登录 }).click(); await expect(page).toHaveURL(/\/home/); await expect(page.getByText(欢迎回来)).toBeVisible(); }); test(LOGIN-007 密码错误次数达到5次时账户应锁定, async ({ page }) { await page.goto(/login); for (let i 0; i 5; i) { await page.getByLabel(手机号).fill(13800138000); await page.getByLabel(密码).fill(wrong-password); await page.getByRole(button, { name: 登录 }).click(); } const lockMessage page.getByText(/账户已锁定/); await expect(lockMessage).toBeVisible(); });这套脚本可以直接丢进现有的 Playwright 项目里跑。把 Skill 出来的人工用例和脚本结合起来整个流程就是需求文档进测试用例和自动化脚本出。测试工程师需要做的就是 review 和补充少数边缘场景工作量至少降了六成。5. 常见问题与排查技巧实录5.1 需求理解偏差问题Skill 用了一段时间之后我遇到的最典型问题是Claude 在理解需求时出现过度解读生成了一些文档里完全没有的功能。举一个真实案例需求文档里写了用户可以选择支付方式Skill 生成的用例里出现了用户选择支付方式后支付方式不可修改——这就是典型的主观脑补因为文档里并没有提到锁定逻辑。排查之后发现问题出在我的约束条件写得不够强硬。后来我在 SKILL.md 的约束里加了一条硬规则如果某个业务行为文档中没有显式描述你不能假设它存在。所有假设性内容必须放在用例的备注中标注待确认。这句话加完之后脑补现象基本绝迹生成的用例都严格贴着需求走。但这里还有个副作用如果需求文档本身写得非常笼统严格贴着需求走的用例可能会很浅。这种情况我会主动在流程里增加一步——让 Claude 在输出用例前先提出澄清问题清单我回答完再生成。虽然多了一步交互但最终用例质量高很多。5.2 用例粒度失控问题第二个常见问题是粒度失衡。有时候生成的用例太粗一条用例里塞了四五个操作步骤和多个预验证点出了问题根本无法定位是哪一步挂的有时候又太碎一个登录按钮拆出10条用例看着密密麻麻实际上都是重复覆盖。粒度问题靠提示词没法彻底解决我后来是用模板结构来约束的。在用例模板里做了几个硬性约定一条用例只验证一个行为或一个业务规则不要多个验证点混杂。超过6步的用例必须拆分为多条前置准备性质的低优先级用例。同一个功能的正常流程用例不超过3条异常流程可以适当放宽。另外我加了一条自查规则生成完用例之后Skill 自己检查一遍如果存在两个用例的标题语义高度重复自动合并或标注。这个机制让最终产出的用例表非常清爽评审会上也少了很多这条和那条有什么区别的灵魂拷问。5.3 自动化脚本生成失败排查自动生成 Playwright 脚本后面临的最大问题是稳定性。一开始生成的脚本十个里面大概有两三个跑不过原因基本集中在两块定位器不稳固和依赖顺序错乱。定位器的问题是 Claude 默认倾向用page.locator(text登录)这种文本定位稍有一点样式或文案变化就挂。后来我在规则里强制了选择器优先级首选>
用Claude Skill将需求文档自动生成测试用例与Playwright脚本的实践
干了这么多年测试最烦的事情不是写用例本身而是把需求文档里的那点业务逻辑一个字一个字地抠出来翻译成一条条用例。特别是碰上那种几千字的PRD还夹杂着流程图、状态表、异常分支光提取测试点就能耗掉一上午。后来我发现Claude Skill 这个能力完全可以把这件事做成一条流水线喂进去一份文档吐出来一份结构完整的测试用例md文件甚至还能顺手生成一套 Playwright 自动化脚本。这套东西的本质是把测试工程师脑子里那套怎么读需求、怎么拆场景、怎么定优先级的经验固化成规则写进 Skill 文件里再交给 Claude 去执行。听起来玄乎实际落地其实不复杂。这篇文章我会把这个 Skill 怎么设计、SKILL.md 文件怎么写、遇到问题怎么调从头到尾捋一遍测试同行可以直接照着搭一套属于自己的。1. 这个 Skill 到底解决了什么问题1.1 测试工程师每天都在做二次翻译很多人觉得测试用例就是点几下、看结果但真正写过用例的人都懂这活儿本质是在做翻译把产品经理写的自然语言翻译成计算机能验证的行为描述。翻译过程中要补充大量的上下文——这个按钮置灰是什么条件下出现的这个接口返回错误码前端要怎么表现用户取消操作之后数据要不要回滚这些上下文大部分时候文档里没有全靠测试自己去问、去猜、去翻历史代码。我经常看到团队里两个测试同学对同一个需求写出来两个版本的用例覆盖范围完全不一样原因就是大家在翻译的时候各自脑补的规则不同。Claude Skill 解决的就是这个脑补不统一的问题。把翻译规则固定下来让每一次用例生成都遵循同一套拆解逻辑输出格式也是统一的 Markdown 结构。对我来说它不是一个简单的AIGC 生成工具而是把团队里最有经验那个老测试的思维方式复制到了每一个项目里。1.2 Claude Skill 和普通聊天提示词有什么不同直接复制一段需求文档扔给 Claude 让它写用例也能跑通但效果非常不稳定。今天生成的用例结构是这种明天又变成另一种你每次都要改提示词而且改来改去颗粒度也时粗时细。Claude Skill 的差别在于它是一套打包好的职业能力包。通过项目目录下的SKILL.md文件把角色定位、执行步骤、输出格式、校验规则全部固定下来Claude 执行的时候不是自由发挥而是按你定义的工作流走。打个比方普通提示词像是你临时拉了个实习生口头跟他讲今天帮我把测试用例整理一下他干成什么样全看悟性。而 Skill 相当于你给这个实习生配了一本厚厚的《岗位操作手册》和一套标准模板从打开文档到输出成果每一步都有规范。我用下来最明显的感受有几点输出格式稳定。字段、层级、表格结构只要模板不变每次生成的结果都是同一套骨架。领域知识内嵌。可以把等价类、边界值、状态迁移这些测试理论写进规则里而不是每次都在提示词里现教。可复用、可分享。一个 Skill 就是一个文件夹拷给同事就能用换项目也只需要改少量描述。这也是我为什么强烈推荐用 Skill 而不是收藏一堆提示词模板的原因——提示词是散的Skill 是成套的。2. 核心设计思路与方案选型2.1 为什么选 Markdown 文件作为技能载体刚开始设计这个 Skill 的时候我其实想过把规则写在一个 JSON 配置里或者直接用 Python 脚本去解析文档。后来都推翻了最终选了SKILL.md这个纯 Markdown 载体理由很简单规则本身需要被反复阅读和维护。Markdown 的优势在于它既是给人看的也是给模型看的。团队里不懂代码的测试同事打开 SKILL.md也能看懂这个 Skill 的工作流程而 Claude 对 Markdown 的结构化理解非常成熟一级标题、二级标题、表格、列表都能准确解析成指令。相比之下JSON 和脚本的可读性差很多改一条规则都得过一遍语法。另一个原因和 Git 有关。Markdown 文件在版本管理里非常友好每次改了规则git diff看得清清楚楚。我在实际维护过程中经常需要对比两个版本的 Skill 在生成结果上的差异如果是二进制配置文件这种对比就很痛苦。还要补充一点md 文件的生态足够成熟。Vitest、Playwright、各种文档站点都用 Markdown 做载体后续想把 Skill 的说明文档、示例用例和规则文件放在一起管理用目录结构就能轻松组织。这个选择不是最酷的但绝对是最省心的。2.2 从文档到用例的整体工序设计一个完整可用的测试用例生成流程不能只是把文档发给 Claude这么简单。我在设计时拆成了五道工序每道工序都有明确的输入输出文档解析先让 Claude 通读输入内容识别文档类型PRD、接口文档、操作手册还是历史用例提取出功能模块清单、业务流程、数据字段、业务规则。规则提取从业务流程和数据字段中找出所有可被测试验证的点包括正常路径、分支路径、异常路径。这一步我会让 Claude 特意标注出文档里模糊的地方方便后面追问。场景设计对每个功能点套用测试设计方法——等价类划分、边界值分析、状态转换、错误猜测生成具体的测试场景。这一步的目标是保证覆盖度不急着写详细步骤。用例编写把场景填充成标准格式用例包括前置条件、测试步骤、预期结果、优先级、用例编号。输出校验最后让 Claude 自查一遍对照原始需求文档检查有没有遗漏的功能点、有没有模棱两可的预期结果再按模板输出 markdown 文件。这套工序是我反复调了很久才定下来的。最早的方案只有三步理解文档、生成用例、输出。但后来发现有个致命问题——Claude 跳过了规则提取这个中间层直接生成用例导致它经常会漏掉文档里藏在某个表格里的边界条件。加了中间层之后生成的覆盖度提升非常明显因为规则提取让模型强制做了一次找全所有可测试点的动作而不是急着动笔写。2.3 关键决策把测试经验写进规则这个 Skill 对比普通提示词生成最大的差异点在于我把我自己的测试方法论写进去了一部分。比如规则里明确要求每个功能点至少覆盖一个正常场景、一个边界场景、一个异常场景有数值输入的地方必须检查边界值和边界外的值有状态切换的地方必须覆盖每个状态的入口和出口不能只测主流程涉及删除、修改操作的地方必须考虑数据关联影响比如删除一个正在被引用的数据应该被阻止预期结果不能写系统提示成功必须写清楚具体反馈形式和后续状态这些规则说白了就是我在多年测试生涯中踩过的坑。之前发现问题最多的地方就是所有人都测了正常能跑通但极少有人测这个值刚好超了一位小数会怎样这个状态删了正在被下一步使用会怎样。把经验写成规则之后好处是这个 Skill 不再是一个大语言模型玩具而是一个有测试思维的工具。同一个需求文档直接问 Claude 和通过 Skill 生成覆盖度完全不在一个量级。3. SKILL.md 文件编写实操3.1 Skill 目录结构与最小落地形态Claude Skill 的目录结构非常轻量不需要额外的依赖一个文件夹加一个 SKILL.md 就能跑起来。我常用的目录结构是这样的test-case-generator/ ├── SKILL.md # 核心技能定义 ├── templates/ │ ├── test-case-template.md # 用例输出模板 │ └── report-template.md # 覆盖度报告模板 └── examples/ ├── sample-prd.md # 示例需求文档 └── sample-output.md # 示例输出结果SKILL.md 是整个 Skill 的心脏。它最基础的结构包含两块metadata和instructions。metadata 写这个技能的名字和触发的描述相当于给 Claude 一个识别标签instructions 是核心写 Claude 拿到输入之后应该用什么样的流程去处理。一个最精简的 SKILL.md 头部长这样--- name: test-case-generator description: 基于需求文档自动生成结构化的功能测试用例输出标准 Markdown 文件。适用于 PRD、接口文档、功能描述等测试场景。 --- # Test Case Generator 你是一名拥有超过10年经验的资深测试工程师擅长功能测试、接口测试和自动化测试。你的任务是阅读用户提供的需求文档按照本文档中的流程和规则生成高质量的测试用例。这里的description字段非常关键它决定了 Claude 什么时候会调用这个 Skill。我试过比较泛的描述比如生成测试用例结果该调用的时候没触发不该调用的时候反而乱触发。后来改成基于需求文档自动生成结构化的功能测试用例输出标准 Markdown 文件触发准确率直线上升。这其实是 prompt 工程里的老原则——描述越具体触发越准确。3.2 规则指令段的设计要点instructions 部分是整个 Skill 的重头戏也是我调得最多的部分。我建议把规则拆成几个小节来写每个小节聚焦一个维度## Skill 工作流程 1. 第一步阅读用户提供的所有文档内容分类识别文档类型。 - 若文档包含接口地址请求方式参数说明等关键词归类为接口文档。 - 若文档包含用户故事业务规则功能描述等关键词归类为功能需求文档。 - 若文档是历史测试用例则先分析其覆盖度和格式再按新模板重构。 2. 第二步提取所有功能模块、业务流程、数据字段、业务规则形成测试点清单。 3. 第三步按照正常场景、边界场景、异常场景三类为每个测试点设计测试场景。 4. 第四步将测试场景填充为标准测试用例。 5. 第五步对照原始文档自查确认无遗漏后输出 Markdown 文件。流程写完之后一定要写约束条件## 约束条件 - 不允许编造文档中不存在的功能点如果文档描述不清晰在用例备注中标注待确认。 - 每个功能模块下必须有主流程用例和异常流程用例。 - 涉及数值输入的参数必须包含边界值用例值域最小值、最大值、超出值域一个单位。 - 预期结果必须具体到页面反馈、接口返回码或数据状态变化禁止写正常或成功这样模糊的词语。这里我踩过一个坑最早的时候我把约束条件写得非常多有20多条结果 Claude 生成的时候经常顾此失彼顾了边界值忘了异常场景。后来我把约束做减法只保留对覆盖度影响最大的核心规则其他的放到 templates 模板里让格式来兜底效果好很多。3.3 用例输出模板的设计细节输出模板决定了生成的用例长什么样。我设计的模板是这套字段字段说明用例编号规则模块名-功能点-序号例如 LOGIN-001所属模块顶层功能模块名称用例标题一句话描述测试场景格式为xxx时应xxx优先级P0核心路径、P1重要功能、P2次要或异常前置条件执行前需要满足的数据或状态测试步骤编号列表每一步都是可执行的操作预期结果与步骤一一对应的可验证结果把这个模板存到templates/test-case-template.md里SKILL.md 里只需要写一句严格按 templates/test-case-template.md 的模板输出Claude 就会自己去读模板文件。注意不要让 Claude 把这个模板内嵌到 SKILL.md 里否则规则越来越长指令之间会互相干扰。优先级判定我也写进了规则主流程且影响核心业务目标的是 P0重要分支、有数据变更的是 P1异常提示、边缘情况、UI细节是 P2。这个分类和很多团队的用例优先级定义是匹配的可以直接复用。4. 实操演示从需求文档到测试用例4.1 输入文档的准备技巧Skill 的效果很大程度上取决于输入文档的质量。我试过直接把零散的产品需求聊天记录抛进去结果生成的用例也很零散。这里的经验是进 Skill 之前先完成一次粗加工。我一般会先检查文档里有没有这样几个要素功能清单这个模块到底要做哪几个功能最好有模块树。业务流程用户从进入到完成操作的路径是什么有没有分支。字段说明每个输入框/接口参数的类型、长度、是否必填。业务规则比如同一用户最多绑定五张银行卡超过三笔未支付订单不能再下单这种。不是每个需求文档都有这些要素但缺了哪一个生成的用例在对应维度上就会偏弱。缺字段说明的文档生成的用例很少涉及输入校验和边界值缺业务规则的文档生成的用例很难覆盖到复杂的业务分支。所以我在 Skill 的 instructions 里加了一条如果输入文档缺少上述要素Claude 必须在输出用例之前先列出本次生成依据中缺失的信息清单并给出补充建议。这个小小的改动让整个生成过程从闷头输出变成了缺什么会主动告诉你实际体验好很多。4.2 一次完整的生成过程演示拿一个最简单的用户登录需求文档来举例。输入大概长这样登录功能 - 用户输入手机号和密码点击登录按钮验证通过后进入首页。 - 手机号为11位数字密码为6-20位字符。 - 手机号或密码错误时提示手机号或密码错误。 - 连续5次密码错误账户锁定30分钟。这个需求极其常见但真正写起来想覆盖全也不容易。通过 Skill 生成的结果会先产出一份测试点清单再展开为用例。下面是其中几条用例编号用例标题优先级前置条件测试步骤预期结果LOGIN-001输入正确的手机号和密码时应登录成功P0已注册用户且密码正确1. 输入11位手机号 2. 输入正确密码 3. 点击登录跳转至首页登录状态为有效LOGIN-004手机号位数小于11位时应提示格式错误P1未输入任何信息1. 输入10位手机号 2. 输入任意密码 3. 点击登录提示手机号格式不正确不发起登录请求LOGIN-007密码错误次数达到5次时账户应锁定P0正确手机号密码已知错误1. 连续输入错误密码5次 2. 第6次输入正确密码 3. 点击登录提示账户已锁定请30分钟后再试即使密码正确也不允许登录LOGIN-009锁定状态下第31分钟再次尝试应可以登录P2已锁定的账户锁定时间已过1. 等待锁定时间超过30分钟 2. 输入正确手机号和密码 3. 点击登录登录成功进入首页对比一下直接让 Claude 草草生成的用例差的往往是 LOGIN-007 和 LOGIN-009 这种涉及状态锁定与时间边界的用例。这两个恰好是线上最容易出问题的点——我们之前真出过一个事故用户输错密码锁定之后因为服务端用的是滚动窗口计时导致过了30分钟还解不了锁。如果当时就用了这个 Skill打死都不会漏这类场景。4.3 对接 Playwright 生成自动化脚本生成手工用例只是第一步这个 Skill 更大的价值在它可以继续往自动化测试方向延伸。我在 SKILL.md 里加了一个可选模式当用户提出需要自动化脚本时Claude 会基于已生成的 P0 和 P1 用例输出配套的 Playwright 测试脚本。为什么选 Playwright这个我自己实测过对比 Selenium 和 CypressPlaywright 在自动等待、选择器稳定性和浏览器兼容性上都要省心很多。尤其是它内置的auto-waiting机制测试脚本里不需要写一堆sleep跑起来又稳又干净。Skill 里对自动化脚本的规则简单几条只对 P0/P1 用例生成脚本P2 的边界场景优先保留为手工用例。定位元素优先顺序>import { test, expect } from playwright/test; test(LOGIN-001 输入正确的手机号和密码时应登录成功, async ({ page }) { await page.goto(/login); await page.getByLabel(手机号).fill(13800138000); await page.getByLabel(密码).fill(Passw0rd123); await page.getByRole(button, { name: 登录 }).click(); await expect(page).toHaveURL(/\/home/); await expect(page.getByText(欢迎回来)).toBeVisible(); }); test(LOGIN-007 密码错误次数达到5次时账户应锁定, async ({ page }) { await page.goto(/login); for (let i 0; i 5; i) { await page.getByLabel(手机号).fill(13800138000); await page.getByLabel(密码).fill(wrong-password); await page.getByRole(button, { name: 登录 }).click(); } const lockMessage page.getByText(/账户已锁定/); await expect(lockMessage).toBeVisible(); });这套脚本可以直接丢进现有的 Playwright 项目里跑。把 Skill 出来的人工用例和脚本结合起来整个流程就是需求文档进测试用例和自动化脚本出。测试工程师需要做的就是 review 和补充少数边缘场景工作量至少降了六成。5. 常见问题与排查技巧实录5.1 需求理解偏差问题Skill 用了一段时间之后我遇到的最典型问题是Claude 在理解需求时出现过度解读生成了一些文档里完全没有的功能。举一个真实案例需求文档里写了用户可以选择支付方式Skill 生成的用例里出现了用户选择支付方式后支付方式不可修改——这就是典型的主观脑补因为文档里并没有提到锁定逻辑。排查之后发现问题出在我的约束条件写得不够强硬。后来我在 SKILL.md 的约束里加了一条硬规则如果某个业务行为文档中没有显式描述你不能假设它存在。所有假设性内容必须放在用例的备注中标注待确认。这句话加完之后脑补现象基本绝迹生成的用例都严格贴着需求走。但这里还有个副作用如果需求文档本身写得非常笼统严格贴着需求走的用例可能会很浅。这种情况我会主动在流程里增加一步——让 Claude 在输出用例前先提出澄清问题清单我回答完再生成。虽然多了一步交互但最终用例质量高很多。5.2 用例粒度失控问题第二个常见问题是粒度失衡。有时候生成的用例太粗一条用例里塞了四五个操作步骤和多个预验证点出了问题根本无法定位是哪一步挂的有时候又太碎一个登录按钮拆出10条用例看着密密麻麻实际上都是重复覆盖。粒度问题靠提示词没法彻底解决我后来是用模板结构来约束的。在用例模板里做了几个硬性约定一条用例只验证一个行为或一个业务规则不要多个验证点混杂。超过6步的用例必须拆分为多条前置准备性质的低优先级用例。同一个功能的正常流程用例不超过3条异常流程可以适当放宽。另外我加了一条自查规则生成完用例之后Skill 自己检查一遍如果存在两个用例的标题语义高度重复自动合并或标注。这个机制让最终产出的用例表非常清爽评审会上也少了很多这条和那条有什么区别的灵魂拷问。5.3 自动化脚本生成失败排查自动生成 Playwright 脚本后面临的最大问题是稳定性。一开始生成的脚本十个里面大概有两三个跑不过原因基本集中在两块定位器不稳固和依赖顺序错乱。定位器的问题是 Claude 默认倾向用page.locator(text登录)这种文本定位稍有一点样式或文案变化就挂。后来我在规则里强制了选择器优先级首选>