干软件测试这行越久越会发现一个矛盾工具越来越智能但测试同学的时间还是大量花在“准备数据、写用例、整理报告”这些看起来琐碎、实际上特别耗人的活上面。为什么因为每一样都有规则只是规则藏在人脑子里没人整理成文档。最近几个月我一直把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.yamlSKILL.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(encodingutf-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(parentsTrue, exist_okTrue) (out / cases.json).write_text( json.dumps(result, ensure_asciiFalse, indent2), encodingutf-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写得没问题但脚本本身有bugAgent一调用就报错整个流程卡住。脚本调通后再进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之后还在旧会话里继续用。排查步骤用命令查看当前对话识别到了哪些技能。直接问Agent“你会使用api_case_generator这个技能吗”检查项目级和用户级技能目录两边都放了一份时内容是否一致。改完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开始顶替你一部分重复工作的心理落差——不过这种落差我个人非常欢迎。