用Claude Agent Skills将软件测试规则固化，告别重复劳动

干软件测试这行越久，越会发现一个矛盾：工具越来越智能，但测试同学的时间还是大量花在“准备数据、写用例、整理报告”这些看起来琐碎、实际上特别耗人的活上面。为什么？因为每一样都有规则，只是规则藏在人脑子里，没人整理成文档。最近几个月，我一直把Claude的Agent Skills用在测试日常里，让AI按固定流程帮我干接口用例生成、脏数据构造、缺陷单整理这类工作，实测效果相当能打。这篇文章不聊虚的，直接讲清楚Skills怎么落地到软件测试里，适合正在做接口测试、UI自动化、测试数据管理的团队，也适合一个人包打天下的测试开发。

1. Skills到底是个什么东西

先别急着动手，得把原理搞清楚，否则你照着网上的模板抄一遍，最后大概率是“看着像、跑不动”。

1.1 它不是传统插件，更像一份“给AI的岗位培训手册”

很多人一听Skills，下意识觉得跟IDE插件差不多，装上去就多几个按钮。错了。插件是给软件增加新功能，而Skills是给AI一份“执行某类任务的操作规程”。

在Claude体系里，一个Skill本质上就是一个文件夹，里面最核心的是一个叫SKILL.md的Markdown文件，外加一些可选的脚本和资源文件。这个大语言模型还是那个模型，推理能力没变，但Skill相当于给模型补了一节岗前培训，把“这类任务到底怎么做、边界在哪、步骤是什么”全部写清楚。模型看到匹配的任务时，会把这份手册读进来，然后照着手册执行。

拿生活里的例子类比：一个刚入职的测试新人，模型就是那个新人，SKILL.md就是带他的师兄，配套脚本是师兄给的检查清单小工具。没有师兄带，新人凭感觉干活，产出时好时坏；有师兄带，该走流程走流程，该调工具调工具，稳定性和质量立刻不一样。

这一点对测试工作特别重要。测试恰恰是最需要“规程”的工作，功能测试、接口测试、数据构造背后都有清晰的流程和验收标准。你直接让AI“生成测试用例”，它容易自由发挥，写得天花乱坠但没法用；但你给它一份你们团队的用例编写规范，连边界值约定、断言写法、输出格式都写清楚，它的产出立刻能用到实际工作中。Skills解决的就是“把规则固化成可复用资产”这件事。

1.2 一个标准Skill的目录结构长什么样

我自己常用的一个接口测试用例生成Skill，长这样：

~/.claude/skills/ └── api-case-generator/ ├── SKILL.md ├── scripts/ │ └── generate_cases.py └── templates/ └── case_template.yaml

SKILL.md是操作手册，写清楚什么场景用、怎么用、有什么禁忌。scripts/放脚本，负责解析OpenAPI、生成参数列表、算边界值这类确定性工作。templates/放输出模板，让AI产出固定格式的用例文件。

SKILL.md文件头是YAML格式的元信息，最关键的是name和description这两个字段：

--- name: api_case_generator description: 根据OpenAPI规范生成接口测试用例。当用户提供Swagger/OpenAPI文档并要求生成接口用例、补充接口测试场景时使用。如果用户需要的是测试策略规划，不要使用本技能。 ---

别小看这段描述。Claude判断什么时候调用哪个Skill，主要就是靠这个字段进行语义匹配。所以“什么时候用”“什么时候不用”“需要什么输入”都要写清楚，否则模型可能该用时不用，不该用时乱用。

1.3 为什么软件测试是Skills的最佳土壤

我总结过，一个任务适不适合做成Skill，看三个特征：

• 规则是否明确：测试用例有模板，缺陷单有字段，数据生成有约束。
• 重复性是否高：几十个接口穷举参数，几十条测试数据来回构造。
• 是否需要调用工具：解析JSON、发请求、跑脚本、生成报告。

这三个特征测试工作全占了。我实际用下来的感觉是，让AI“自由发挥”写测试方案，效果大概六十分；但给它一份清晰的Skill，输出能到八十五分以上。差的这二十五分，就是规则显性化的价值。

2. 测试场景里，四个立竿见影的Skills方向

不是所有测试工作都适合Skills化，我试过一些看起来很美好、做出来很鸡肋的方向。下面这四个是我在团队里实际验证过、真正能省时间的。

2.1 接口测试用例生成

做接口测试的人都有体会：OpenAPI文档一打开，几十个path、每个path又有get/post/put/delete，再叠加必填参数、可选参数、枚举值、边界值，人工整理一圈下来，纯体力活，还特别容易漏。

Skill方案是让AI解析OpenAPI文件，按照固定逻辑生成三类用例：正常路径、参数校验、边界值。输出格式固定为“用例标题、请求方法、请求路径、请求参数、预期状态码”。我团队里一个60个接口的订单模块，原来手工写用例要一到两天，现在Skill跑一遍初稿大概十分钟，人工评审补齐遗漏再花一小时。

注意一个前提：生成的初稿不是直接可以上用例平台的最终版。AI对业务上下文的理解有限，比如“这个字段虽然在OpenAPI里是可选，但业务上登录用户必须传”——这种隐藏约束，脚本和Agent都发现不了，必须靠人来确认。所以我把这个Skill定位成“把两天的工作压缩成两小时”，而不是“完全替代人”。

2.2 测试数据构造

造测试数据是我见过最枯燥又最容易出错的环节。订单状态要覆盖待支付、已支付、已取消，用户等级要覆盖普通、VIP、黑名单用户，金额要覆盖0、负数、极小值、极大值、小数点后两位。手工构造一条正常数据容易，构造一百条覆盖边界的脏数据，真的想吐。

Skills在这个场景特别好用。我给测试团队写过一个“测试数据生成器”Skill，里面有一个Python脚本，负责按规则生成CSV或JSON数据文件，规则包括枚举值列表、数值边界、字符串长度限制、字段关联关系。使用方式极其简单，直接在对话里说：

“用测试数据生成器Skill，按订单模板生成100条测试数据，20条正常、80条边界脏数据，金额字段覆盖0、负数、超过两位小数、超大值，输出到/data/testdata/order_test.csv。”

脚本把规则跑完，AI再把结果整理成带注释的清单，每条数据标注“这是边界值：金额超过9999999”。这个Skill一旦稳定，复用的价值极高，换一个业务模块只需要改模板和数据规则。

2.3 UI自动化脚本生成

UI自动化的痛点不是写脚本本身，而是选择器不稳定。同一个按钮，有的页面用id，有的用placeholder，有的用data-testid，测试同学写脚本全靠经验和猜测。

Skill可以把“如何把自然语言操作转换成Playwright脚本”的规则固化下来。比如写清楚：定位元素时优先使用>--- name: api_case_generator description: 根据OpenAPI规范生成接口测试用例。当用户提供OpenAPI文档并要求生成接口用例时使用。如果用于测试策略规划，不使用本技能。 --- # 接口测试用例生成 ## 目标 根据输入的OpenAPI规范，生成符合团队模板的接口测试用例。 ## 执行步骤（必须按顺序完成，不得跳过） 1. 读取用户提供的OpenAPI文件路径。 2. 运行 scripts/generate_cases.py，传入OpenAPI文件路径和输出目录。 3. 读取脚本输出的 cases.json 文件。 4. 按 templates/case_template.yaml 的格式，将 cases.json 内容整理为用例文件。 5. 输出汇总清单，标注每个接口生成了几条用例、覆盖了哪些类型。 ## 规范 - 正常路径用例必须包含成功状态码断言。 - 参数校验必须覆盖：必填缺失、类型错误、边界值。 - 依赖场景（如登录token、前置业务数据）标注“前置条件待人工确认”。 - 禁止在用例中写入硬编码的环境IP地址。 - 生成结果必须包含：用例标题、请求方法、请求路径、请求参数、预期结果。 ## 示例 输入：OpenAPI文件 /data/openapi/order.yaml 输出： title: "创建订单-正常路径" method: "POST" path: "/api/v1/orders" expected_status: "2XX"

有几个细节值得注意。description要写否定边界，就是“什么时候不用本技能”，这能减少AI乱用。正文步骤一定要编号，而且注明“不得跳过”，AI模型在长上下文里容易自作主张，明确的顺序约束很有效。给一个输入输出示例也很重要，模型会参照示例的格式产出，这比你在正文里反复说“格式要统一”管用得多。

3.3 什么活交给脚本，什么活留给Agent

这是Skill设计里最考验功力的一点。我的原则是：确定性、可复现的逻辑丢给脚本，需要理解上下文、做价值判断的留在Agent。

比如解析OpenAPI、遍历路径、算边界值，这类工作用Python脚本最稳，一次跑完不会漏。但“哪些异常场景值得写进用例、哪些业务前置条件需要提醒用户确认”，脚本干不了，得让Agent根据业务上下文判断。脚本的输出最好是JSON或YAML格式，这样Agent能直接读进来，继续做整理和加工。

另外一个原则：脚本要尽量简单，不要塞太多逻辑。我见过有人把整个用例生成逻辑全写进脚本，Skill变成纯脚本调用，反而失去了灵活性和可解释性。正确姿势是脚本做“数据提取和计算”，Agent做“规则理解和文本整理”，各干各擅长的。

3.4 安装和加载：Claude怎么找到你的Skill

安装本身不复杂，把整个文件夹放到指定目录就行。

• 用户级：放到~/.claude/skills/目录下，所有项目都能用。
• 项目级：放到当前项目根目录的.claude/skills/下，只有当前项目能用。

放好之后，重开一个对话窗口。很多初次用的人会踩一个坑：改了SKILL.md之后，在旧会话里继续调试，结果AI还在按旧指令执行，怎么改都没反应。这是因为上下文里已经缓存了旧内容。所以我的习惯是每次改完Skill，必定新开会话再试。

验证是否加载成功，可以在会话里查看可用技能列表，或者更简单直接问AI：“请确认你是否已经加载了api_case_generator这个技能，并读取它的SKILL.md。”如果它描述出了技能内容，说明加载成功。初次调试时我会用一个测试任务跑一遍，不追求一次成功，而是看哪里跑偏，回去改SKILL.md。

4. 实战记录：接口自动化用例生成Skill完整落地

拿我自己做的一个“接口用例生成”Skill当案例，把完整过程过一遍，包括代码和踩坑。

4.1 背景与目标

我们有个订单服务，OpenAPI文档里有60多个path，覆盖订单创建、查询、支付、退款、取消。过去的问题是：手工写用例耗时一两天，边界值经常漏，新人写出来的格式五花八门。

目标很明确：10分钟内给出初稿，用例格式完全统一，覆盖正常路径、参数校验、边界值三类，并且把依赖场景单独标记出来让人工确认。

4.2 核心脚本：解析OpenAPI并生成用例初稿

脚本我用Python写，核心依赖是pyyaml。逻辑不复杂，遍历paths下的每个方法和参数，按规则生成用例。

#!/usr/bin/env python3 # scripts/generate_cases.py import json import sys from pathlib import Path import yaml def build_validation_cases(path, method, op): """针对必填参数和边界值生成校验类用例。""" cases = [] for p in op.get("parameters", []): name = p.get("name") required = p.get("required", False) schema = p.get("schema", {}) if required: cases.append({ "name": f"缺失必填参数-{name}", "expected_status": "4XX/5XX", "parameter": {name: None}, }) if schema.get("type") == "integer": minimum = schema.get("minimum") maximum = schema.get("maximum") if minimum is not None: cases.append({ "name": f"边界值-{name}-小于最小值", "expected_status": "4XX/5XX", "parameter": {name: minimum - 1}, }) if maximum is not None: cases.append({ "name": f"边界值-{name}-大于最大值", "expected_status": "4XX/5XX", "parameter": {name: maximum + 1}, }) return cases def main(openapi_path: str, out_dir: str) -> None: spec = yaml.safe_load(Path(openapi_path).read_text(encoding="utf-8")) result = {} for path, methods in spec.get("paths", {}).items(): for method in ["get", "post", "put", "patch", "delete"]: op = methods.get(method) if not op: continue key = f"{method.upper()} {path}" result[key] = { "summary": op.get("summary", ""), "normal_case": { "method": method.upper(), "path": path, "expected_status": "2XX", }, "validation_cases": build_validation_cases(path, method, op), } out = Path(out_dir) out.mkdir(parents=True, exist_ok=True) (out / "cases.json").write_text( json.dumps(result, ensure_ascii=False, indent=2), encoding="utf-8", ) print(f"[完成] 共处理 {len(result)} 个接口，结果写入 {out / 'cases.json'}") if __name__ == "__main__": if len(sys.argv) != 3: print("用法: python scripts/generate_cases.py <openapi.yaml> <输出目录>") sys.exit(1) main(sys.argv[1], sys.argv[2])

脚本本身不复杂，它干的是“提取和计算”的活，把每个接口的正常用例和校验用例先算出来。SKILL.md里写得很清楚：Agent拿到结果后，还要结合业务上下文整理成最终用例，并对前置依赖场景打上“待人工确认”标记。

注意一个细节：脚本要先在本地终端跑通，再交给Agent调用。我见过有人SKILL.md写得没问题，但脚本本身有bug，Agent一调用就报错，整个流程卡住。脚本调通后再进Skill，这是底线。

4.3 使用方式与实测效果

实际用的时候，我只需要在对话里说：

“用api_case_generator技能，解析 /data/openapi/order.yaml，输出到 /data/testcases/order/ 目录。”

处理一个60接口的模块，大概10分钟出初稿。生成的cases.json里包含60条正常路径用例，以及按必填和边界值展开的140多条校验用例。AI再把JSON整理成符合模板的YAML用例文件，同时标记了其中大约20个涉及前置状态的接口。

对比一下效率：原来1.5天人工活，现在初稿10分钟，人工评审加补齐依赖场景大约2小时。最关键的不是快，而是格式统一了、边界值不漏了。

4.4 踩过的坑：依赖场景不能全靠脚本

第一版Skill只生成正常路径和参数校验，用了一周发现一个明显短板：很多接口有依赖关系，比如“先登录拿token才能下单”“商品要先创建才能被购买”。这类用例脚本生成不了，因为它需要理解业务上下文。

我的解决办法不是硬让脚本去猜，而是在SKILL.md里加了一步：Agent在输出汇总时，必须对每个涉及前置状态的接口标注“前置条件待人工确认”。这一步看起来简单，但它明确了“AI负责能确定的部分，人负责需要判断的部分”，分工清晰，产出质量明显提升。

5. 常见问题与排查经验

用Skills做测试几个月，踩了不少坑，整理成速查表，照着排查能省很多事。

5.1 技能文件存在，但Agent就是不调用

这是最高频的问题。原因一般有三个：description写得太泛，导致模型在语义匹配时没选中它；安装路径不对，放到了Claude不会扫描的目录；改了Skill之后还在旧会话里继续用。

排查步骤：

1. 用命令查看当前对话识别到了哪些技能。
2. 直接问Agent：“你会使用api_case_generator这个技能吗？”
3. 检查项目级和用户级技能目录，两边都放了一份时，内容是否一致。
4. 改完SKILL.md，新开一个会话再试。

提示：description是匹配入口。别写“用于软件测试”这么宽的描述，要写“根据OpenAPI生成接口测试用例”，同时把“不适合测试策略规划”这类否定条件写进去，匹配准确率会高很多。

5.2 脚本一跑就报错，流程中断

第一种情况是环境依赖缺失，比如机器上没有装pyyaml。解决办法是在SKILL.md里写清楚前置条件：“执行前确认Python3与pyyaml已安装。”

第二种情况是路径问题。脚本接收到的输入路径可能是Windows格式、Linux格式混着来，一定要用pathlib而不是手拼字符串，否则反斜杠和斜杠会出问题。

第三种情况最坑：Agent遇到脚本报错，会出于好意自己修改脚本。一改往往改错，反而引入新问题。我的处理是在SKILL.md里加了一句：“如果脚本返回非零退出码，把错误信息原样反馈给用户，不要自行修改脚本文件。”这句话能拦住大多数AI的自由发挥。

5.3 Agent不按SKILL.md的步骤走

SKILL.md写得太开放，Agent就会有“自由发挥”空间。比如你写“根据情况决定是否调用脚本”，它就可能选择不调，直接自己脑补结果。

对策是：所有步骤写成必须序列，关键动作写“不得跳过”，然后在最后一步加一个校验动作。我在Skill里加的校验是：“统计最终用例文件中的接口数，如果少于解析结果的一半，说明生成不完整，重新执行步骤4和步骤5。”有了这步，异常情况能被兜住。

5.4 生成的测试资产质量不稳定

Skill不是银弹，输出质量取决于输入和约束。我见过同事把生成的用例直接粘到用例平台，结果有几个接口参数类型理解错误，差点上线前被打回。原因不是AI太笨，而是OpenAPI文件里本身就有不规范的地方，比如参数类型写错、枚举值缺失。

所以我的团队现在把“质量门禁”写进Skill的最后一步，Agent输出前必须自查：每条用例是否有预期结果、是否包含请求参数、是否存在重复用例。形成“AI初稿加人工评审”的固定机制。测试这个工种，最终把关的一定是人，AI负责把重复劳动压缩，人负责判断质量是否达标。

我自己折腾这套东西下来，最大的感受是：Skills真正解决的，不是让AI变聪明，而是把团队的隐性知识显性化。测试最值钱的不是点键盘的手，是脑子里那套“什么值得测、怎么测才对”的判断。Skill把这些判断沉淀成文件，AI帮你执行重复动作，人负责做决策。后面我还打算把性能测试经验、安全测试checklist都做成技能，让团队新人一进来就能用上老师傅的套路。如果你也在测试岗位，建议先从你工作日复一日次数最多的那个动作开始，把它变成你的第一个Skill。技术上很简单，真正难的是能不能忍受前一天写说明书、第二天就看到AI开始顶替你一部分重复工作的心理落差——不过这种落差，我个人非常欢迎。