企业官网建设流程全解析

如果现在有人告诉我，一个测试工程师的日常有40%的时间花在了重复劳动上，我觉得这个数字还保守了。需求拆解、边界值枚举、用例编号、格式调整、优先级标注，这些事情本身并不需要太多所谓的“技术含量”，却极其消耗时间。真正值钱的不是“写”这个动作，而是“想”的过程。后来我开始尝试把“想”的过程也交给 Claude，用 Skill 把整套动作打包成可复用的能力，需求 md 文档丢进去，几分钟就能吐出一份结构完整的测试用例文档。这篇就把这套面向测试工程师的 Claude Skill 怎么设计、SKILL.md 里到底写了什么、以及哪些坑我替你先踩过了，一次性讲清楚。

1. 为什么我决定把“写测试用例”这件事交给 Claude Skill

1.1 手工拆需求的三大痛点：漏点、费时、格式不一致

先说最现实的痛点。产品同学写 PRD 的时候，经常把“登录”压缩成一句“支持手机号验证码登录”。但真正落到测试用例上，这句话要拆出多少条？正常登录、错误验证码、验证码过期、验证码错误五次、账号锁定、解锁后再登录、弱网、断网重连、多端同时登录、记住登录状态失效……数一数，十几条打底。如果靠人脑去扫这份几十页的 PRD，漏点是必然的，不是偶然的。

第二个痛点是边界条件和异常路径的覆盖。这块特别吃经验。老测试知道字符串长度要在 n、n-1、n+1 三个点上各测一遍，新人往往只写一个“输入合法手机号→登录成功”就完事。等上了生产环境，用户随便输入个全角数字，用例就翻车了。

第三个痛点是格式。几乎每个公司都有自己的用例模板，字段排序、命名规则、优先级定义各不相同。哪怕你在上一家公司把用例写得天花乱坠，到了新团队照样得老老实实对着模板重新誊一遍。这种复制粘贴的活干多了，真的会让人怀疑这份工作的意义。

再加上需求变更。产品说“验证码有效期从 5 分钟改成 2 分钟”，听起来是一行字，实际上要把所有涉及验证码的用例全部过一遍。没有自动化的辅助，这一轮改动就是纯纯的体力活。

1.2 Skill 与普通对话式提示词的本质区别

很多同学会问：我直接在 Claude 对话框里把 PRD 贴进去，说一句“帮我生成测试用例”，不也一样吗？

区别很大。直接对话时，你得到的是“一次性的、不可复现的运气”。今天生成的用例格式挺好，明天换个时间段再问，可能连表格结构都变了。你需要在每次对话里反复交代角色、模板、规则，效率非常低。

Skill 做的事情，是把“角色定义 + 处理流程 + 输出模板 + 参考示例”固化成一组文件，让 Claude 在任何一次调用里都执行同一套标准。打个不恰当的比方：直接对话像是临时找个实习生帮忙，能力全看遇见的什么人；Skill 像是把工作说明书、模板库和往年优秀案例全部塞给这位实习生，并且每次都是同一套流程。

从团队资产的角度看，Skill 还有一个普通对话给不了的价值：方法论沉淀。你团队里“只可意会不可言传”的用例设计经验，可以通过 Skill 的 md 文件显性化。新人来了不用靠“悟”，直接复用这套技能包就能产出接近老测试水准的用例。这比任何培训PPT都实在。

2. Skill 包的目录设计与 md 文件的分工配合

2.1 一个标准 Skill 包的目录结构

Claude 的 Skill 本质上是一个文件夹，核心入口是SKILL.md。我的目录是这样组织的：

test-case-generator/ ├── SKILL.md # 技能主文件，定义触发条件、角色、执行流程 ├── assets/ │ ├── test_case_template.md # 用例输出模板，规定字段和排版 │ ├── boundary_guide.md # 边界值、等价类、场景法规则速查 │ └── examples/ │ └── login_demo_output.md # 一个完整的登录模块用例示例

可能不同版本的 Claude 客户端对 Skill 目录位置的要求略有差异，但认准一个原则就好：SKILL.md是入口文件，所有辅助资源放在同一目录下的assets里，通过相对路径引用。这样不管你把整个文件夹搬到哪台机器，行为都是一致的。

这套结构里，最容易被低估的是examples目录。Claude 在生成用例时，会根据示例文件来对齐输出风格。你给它的示例是好用例，它输出的就是好用例；你懒省事不提供示例，它就会用通用的、常常带着“系统正常运行”这种废话预期的大路货。后面我会专门讲怎么准备这个示例文件。

2.2 SKILL.md 的 YAML 头信息与触发条件设计

SKILL.md 的开头有一段 YAML 格式的元信息，这是让 Claude 知道“什么时候该用这个技能”的关键。我实际使用的版本：

--- name: test_case_generator description: 当用户提供 PRD、需求说明、接口文档或需求变更单，并要求生成测试用例、编写测试用例、拆分测试点、做测试覆盖分析时，使用此技能。其他闲聊类请求一律不使用。 ---

这段描述里最重要的是触发条件写清楚。我一开始把 description 写得特别宽泛，结果 Claude 动不动就触发这个技能，连用户问“今天天气怎么样”都想套测试用例模板。后来加了限定词“测试用例、拆分测试点、覆盖分析”，并强制加了一句“其他请求不使用”，触发立刻精准了。

name 也要注意，不要起类似assistant这种通用名。技能名越具体，Claude 越能区分它和其他技能的使用场景。

2.3 用例模板文件：比想象中更重要的“输出锚点”

test_case_template.md是我踩过几次坑之后才补上的文件。最初我把用例字段直接写在 SKILL.md 里，结果 Claude 偶尔会发挥创造力，自己加字段、删字段，输出结构飘忽不定。把模板单独拆成一个文件，并在 SKILL.md 里强制要求“严格按照模板输出”，稳定性提升非常明显。

我用的模板字段如下：

这里多说一句为什么用 md 表格而不是 Excel。Claude 对 md 表格的解析比 Excel 表单稳定得多，而且输入源就是 md 文档，输出 md 不需要任何格式转换。md 文件还能进 Git，用例变更历史一目了然。真需要 Excel 的时候，一个脚本就能把 md 表格导过去。团队要求提交 Excel 的话，我叫它“中间格式”，一点不亏。

模板里我会特别强调两条约定，写进模板文件本身：

- 测试步骤使用有序列表，每条步骤单独一行，禁止写成一大段话。 - 预期结果必须可判定，禁止使用“系统正常运行”“界面正常显示”这类模糊表达。

这两条是所有用例评审冲突的根源。把它们固化进模板，等于在源头上就把质量下限抬高了。

3. 从需求文档到测试用例的自动化处理链路

3.1 六步处理流程的设计

光有模板还不够，必须让 Claude 按照一套固定的思考流程来干活。如果上来就生成用例，它很容易漏掉关键场景。我在 SKILL.md 里定义了六步流程：

1. 通读需求，整理“需求理解清单”。这一步只输出对文档的理解，包括功能模块清单、用户角色、业务规则、待确认问题，不急着写用例。

2. 功能点拆解。把每个模块拆成可测试的最小单元。比如“登录”拆成账号验证、密码验证、验证码、记住状态、找回密码。

3. 设计主流程用例。对每个功能点，覆盖正常主流程和最重要的反向流程。

4. 补充边界与异常用例。这一步强制要求参考boundary_guide.md里的规则库。

5. 整理覆盖矩阵。输出需求编号与用例编号的对应关系，没有对应用例的需求点标红。

6. 按模板输出最终用例文档。

第 5 步特别关键，它解决了“用例漏没漏”这个最容易扯皮的问题。以前评审用例，评审人凭直觉挑刺，现在覆盖矩阵往那儿一摆，哪个需求缺用例一目了然。

3.2 边界值、等价类、场景法的规则化表达

边界值和等价类分析是测试用例质量的分水岭。但它们之所以难教，是因为规则太多太碎。Skill 的办法是把这些方法论固化成boundary_guide.md，让 Claude 在生成异常用例时按规则执行，而不是凭感觉。

我的boundary_guide.md里核心规则包括：

数值范围输入： - 有效等价类：范围内的任意值 - 无效等价类：小于最小值、大于最大值 - 边界点：min、min-1、min+1、max、max-1、max+1 字符串长度： - 空字符串、1个字符、n-1、n、n+1、远超上限的字符串 - 全角/半角字符、非法字符、Emoji、SQL注入语句、XSS脚本 时间日期： - 有效期临界点：有效期-1秒、有效期当天最后一秒、过期后1秒 - 闰年、月末、跨年、时区切换 状态流转： - 未激活 / 正常 / 锁定 / 注销 等状态的互相切换 - 每个状态下的可操作动作与不可操作动作 网络与并发： - 无网 / 弱网 / 断网重连 / 请求超时 - 多人同时操作同一资源、重复提交

这套规则虽然看起来简单，但 Claude 一旦在生成用例时引用它，输出质量会立刻从“能用”变成“好用”。以手机号字段为例，规则化表达之后能自动推导出这些用例：空手机号、11位正常手机号、10位、12位、非数字开头、全角数字、含空格、含加号区号、超长字符串注入。人工去枚举这么多情况很容易烦，但对 Claude 来说只是按图索骥。

3.3 优先级与测试类型的自动判定规则

优先级标注是另一个容易让测试和产品打起来的点。为了避免 Claude 乱标优先级，我同样把判定规则写进了 SKILL.md：

P0：核心主流程、数据安全相关、高频使用路径。一旦出问题，业务直接不可用。 P1：重要分支流程、涉及数据一致性、中高频操作。出问题影响明显。 P2：边界条件、异常输入、恢复机制、中低频功能。 P3：UI 细节、兼容性、非核心文案、视觉表现。

同时我会限定一个硬性约束：“P0用例不应超过总用例数量的10%，若超过，重新审视是否把边界用例误标为P0。”这一招是为了防止 Claude 把大量用例都标成高优先级。用例类型我固定为：功能、接口、UI、安全、性能、兼容性、异常。其中安全用例会在登录、上传、支付这类涉及输入点的模块中自动补充，不需要人工额外嘱咐。

4. 手把手构建自己的测试用例生成 Skill

4.1 环境准备与目录初始化

动手前需要准备两样东西：一份结构化的 md 格式需求文档，以及安装了支持 Skill 功能的 Claude 客户端。对测试工程师来说，输入文档最好满足一个条件——表格和标题用得比段落实。比如接口文档里的字段说明表就有极高的信息密度，Claude 解析起来非常准。

然后创建目录。我这里以 macOS/Linux 的常见路径为例：

mkdir -p ~/.claude/skills/test_case_generator/assets/examples

如果你用的是团队内部部署的方案，目录位置按实际约定来就好。核心是保证SKILL.md在技能包根目录下，assets与之同级。

4.2 可直接粘贴使用的 SKILL.md 完整示例

这是本文的核心文件，我直接把当前在用的公开版贴出来。你可以按自己的团队模板调整字段。

--- name: test_case_generator description: 当用户提供 PRD、需求说明、接口文档或需求变更单，并要求生成测试用例、编写测试用例、拆分测试点、做测试覆盖分析时，使用此技能。其他请求一律不使用。 --- # 测试用例生成器 ## 角色 你是一名拥有十年经验的资深测试工程师，精通等价类划分、边界值分析、场景法、错误推测法和需求覆盖分析。你的工作风格是严谨、细致、绝不遗漏边界条件。 ## 输入 用户会提供一个或多个 md/txt 格式的需求文档。如果文档中包含图片，先提示用户对图片区域做 OCR 后重新提供，不要凭空猜测图片中的内容。 ## 执行步骤 ### 第1步：输出需求理解清单 先不写用例。阅读完用户提供的文档后，输出： - 功能模块清单 - 用户角色和权限列表 - 业务规则与约束条件 - 待确认问题清单（如果有理解不确定的地方，必须列在这里等待用户确认） 在用户确认之前，不要继续下一步。 ### 第2步：功能点拆解 对需求理解清单中的每个模块，拆解成可测试的最小功能点。以登录模块为例，拆解为：账号验证、密码验证、验证码、记住登录状态、找回密码、账号锁定与解锁。 ### 第3步：编写测试用例 严格按照 assets/test_case_template.md 中的模板和字段要求编写用例。每个功能点至少覆盖： - 1条正常主流程用例 - 1条反向流程用例 - 2条边界或异常用例 边界与异常用例的生成必须参考 assets/boundary_guide.md 中的规则，禁止凭感觉编写。 ### 第4步：生成覆盖矩阵 输出需求编号与用例编号的对应表。若某条需求没有对应用例，在矩阵中明确标注“待补充”。 ### 第5步：自查并输出 对照以下清单逐项检查： - 每个功能模块是否有主流程用例 - P0用例数量是否明显异常 - 预期结果是否全部可判定 - 是否存在“系统正常”“页面正常”这类模糊表达 自查通过后，输出完整用例文档。 ## 输出规范 - 一律使用 markdown 表格 - 用例编号规则：模块缩写-类型缩写-三位序号，例如 LOGIN-FUNC-001 - 测试步骤使用有序列表，每条一行 - 优先级仅允许 P0、P1、P2、P3 - 预期结果必须可验证、可判定 - 禁止编写需求文档中未提及的功能 ## 参考 - examples/login_demo_output.md 提供登录模块的完整参考输出，生成前先阅读该文件对齐风格。

4.3 稳定输出高质量用例的三个关键提示词技巧

第一个技巧：强制先出“需求理解清单”。不确认就生成，跑偏率极高。一旦 Claude 先把理解清单列出来，你扫一眼就能发现它哪里理解错了，及时纠正，后续输出的返工率会大幅下降。这个步骤值得牺牲一次交互成本。

第二个技巧：用资产文件做规则注入，不要全都堆在 prompt 里。把边界值规则、优先级规则、模板字段全部拆到 assets 里的 md 文件中。好处有两个：SKILL.md 保持简短，Claude 不会因为指令太长而“抓大放小”；后续迭代规则时只改一个文件，不用动主流程。

第三个技巧：少用“尽量”“大概”这类模糊词，多用“必须”“禁止”“严格”。我实测下来，Claude 对祈使句的遵循度远高于建议句。比如“请尽量覆盖边界值”效果就远不如“每个功能点必须包含2条边界或异常用例”。命令越具体，执行越可靠。

5. 实测效果与坑位记录

5.1 用一份登录需求实测：输入与产出对照

为了让你直观感受效果，我用一份极端精简的登录 PRD 做了测试。输入 md 只有三行：

# 登录模块需求 v1.2 - 支持手机号 + 验证码登录 - 验证码有效期5分钟，错误5次锁定账号30分钟 - 支持记住登录状态，最长保持7天

Skill 生成的用例节选如下：

上表只是节选。整个输出还包括记住登录状态的有效期临界点、断网重连、多端登录互踢等共 23 条用例。对一个只有三行需求来说，这个覆盖度已经接近人工编写的水平。我看到结果是有点吃惊的，尤其是 SEC 那条安全用例，它把“输入框长度限制”和“不泄露SQL报错”考虑进去了。

5.2 三次翻车场景与对应修正

第一次翻车：测试步骤变成一整段话。Claude 把“1.进入页面 2.点击按钮”写成“用户进入登录页面后点击按钮并输入”。步骤不可拆分，用例没法执行，也无法转自动化。修正办法是在模板和 SKILL.md 中双重复强调：步骤必须是有序列表，每条单独一行。

第二次翻车：异常用例严重不足。第一次生成的 21 条用例里，19 条是正常流，只有2条是异常流。这就是因为没有强制规则导致的“路径依赖”。修正方法就是我在 4.2 节里写的“每个功能点必须包含2条边界或异常用例”，加了这个硬性指标后，异常用例比例才正常。

第三次翻车：P0 泛滥。生成结果里超过30%的用例是 P0，这等于没标。后来我加了“P0用例不超过总用例10%”的自查项，并要求 Claude 重新审视每条 P0 用例是否真的满足“核心主流程、数据安全、高频”三条标准。效果立竿见影。

还有一个不算翻车但值得注意的现象：当需求文档表述非常模糊时，Skill 会生成大量“需求文档中未提及的功能”。我在输出规范里加了“禁止编写需求文档中未提及的功能”后，它反而会通过“待确认问题清单”把模糊点浮出来，让你知道是你需求没写清楚，而不是它编不出来。

5.3 与 Playwright 等自动化体系的衔接思路

测试用例生成的最终目的不应该是停留在文档阶段，最好能跟自动化测试衔接起来。目前我在这套 Skill 里刻意把用例步骤写成接近 Gherkin 语法的结构，原因就在这里：结构化步骤可以低成本映射到自动化脚本。

拿上面 LOGIN-FUNC-001 举例，手工改写成 Playwright 脚本其实很快：

test('LOGIN-FUNC-001 手机号验证码登录成功', async ({ page }) => { await page.goto('/login'); await page.fill('#phone', '13800000000'); await page.fill('#code', '123456'); await page.click('#submit'); await expect(page.locator('.welcome')).toBeVisible(); });

不过，我得给自动化团队提个醒：Skill 生成的是用例，不是脚本。直接让 Claude 完整生成可以稳定跑通的 Playwright 脚本目前还不现实，因为脚本依赖页面元素定位、响应等待策略、运行环境等大量工程细节。但用例结构规范之后，人工写脚本的沟通成本和时间成本确实降下来了。这已经足够有价值。

6. 适用边界、安全提醒与落地扩展

6.1 适合与不适合交给 Skill 的文档类型

这是很多同学上手前会先问的问题。从我这段时间的实测情况看，以下几类文档效果最好：

• 结构化程度较高的 PRD，尤其是用标题和表格组织的。
• 接口文档，字段说明表信息密度高，解析准确度惊人。
• 需求变更单，效果尤其好，因为基于现有用例做增量更新比从零生成容易得多。
• 竞品测试分析报告，可以按功能维度自动生成对照测试矩阵。

不建议直接扔给 Skill 的有两类。一是以图片为主的扫描件，Claude 读不了图片里的需求细节，必须手动 OCR。二是信息高度敏感的核心商业文档，尤其是涉及未公开产品策略、用户隐私数据的，不建议直接放进第三方大模型平台处理。无论 Skill 多好用，合规红线不能碰。

6.2 质量验收清单：自动化生成的用例也要人工把最后一道关

Skill 能把用例产出效率提升一大截，但它只是“高水平的助理”，不是“免责金牌”。每一批自动生成的用例，我建议按下面这份清单人工复核一遍：

• 需求覆盖率：对照覆盖矩阵，确认每条需求都有至少一条用例关联。
• 边界值覆盖：抽查三个核心输入字段，确认 n、n-1、n+1 都被覆盖。
• 步骤可执行性：把用例丢给一个不了解背景的新同学，看能否按步骤还原场景。
• 预期结果可判定性：凡是“系统正常”“页面正常”等模糊表达，全部打回重写。
• 安全用例检查：登录、上传、支付、搜索等输入点，手工确认是否有注入、越权、敏感信息泄露类用例。
• 自动化适配：步骤是否可拆解成独立操作，与动作一一对应。

这套清单同时也是给 Skill 的自查 prompt 用的。你甚至可以把它写进 assets 里的review_checklist.md，让 Claude 在输出前先行检查一轮，把明显问题在交给人工之前就挡掉。

6.3 从个人效率工具到团队测试资产

最后聊一下这套能力在团队层面的扩展。我现在的用法是，将生成的 md 用例通过一个小脚本转成 Excel，导入团队的测试管理平台。字段直接映射到平台的自定义属性，不需要手工重建。这一步成本极低，收益却很直接：用例评审时终于不用再对着 Excel 的滚动条上下翻飞了。

如果你的团队在做嵌入式或单元测试方向，类似 TESSY 这类工具同样有特定的用例模板。Skill 输出的 md 表格和这些工具的 Excel 模板之间，本质就是一次字段映射的事。可以先用十几个用例做试点，跑通后整体平移。

长远来看，真正有价值的不只是“省时间”，而是团队把测试方法论沉淀成了一个个可安装、可传阅、可迭代的文件包。新同学入职不再需要从零积累边界值经验，因为他用的 Skill 里已经包含了团队认可的边界规则库。Skill 里的任何一个规则过时了，改一个 md 文件，全员复用版本就同步更新。这个价值，远超“自动生成用例”本身。

最后说一个我实际使用中的体会：这套 Skill 我用了差不多两个月，最大的感受是它的输出质量取决于你喂进去的模板和示例文件的质量。别指望不投入就产出，先用一个你最常写的模块，把模板和示例调到满意，再逐步加规则。从一个小而美的技能包起步，远好过一开始就试图覆盖全部测试场景。你需要的不是一个“万能用例机”，而是一个“能准确执行团队方法论”的稳定助手。