Skills 驱动测试自动化：从手写脚本到智能体协作的进化之路
作者：浅木·先生
发布日期：2026-06-16
一、引言：从一条手工断言说起
六年前，我所在的财政系统测试团队接到一个任务：为预算编审系统编写 200 条接口自动化用例。那时的做法是——打开 JMeter，逐个录入接口地址、配置参数、写 Beanshell 断言、整理 CSV 数据源。一个人一天最多写 15 条，200 条用例需要两周。更令人沮丧的是，预算系统的业务逻辑每季度调整一次，接口字段增删改频繁，维护成本居高不下。
那时我们就在想：能不能让 AI 来写测试脚本？答案是可以，但早期的尝试很快撞上了天花板——通用的 AI 对话能生成一段代码，但生成的内容不贴合项目规范，缺少上下文理解，无法融入现有测试框架。真正的突破，来自于Skills这个概念的提出。
今天这篇文章，我想以财政系统的测试场景为背景，完整讲述 Skills 驱动测试自动化从理论到实践的进化之路——从一个想法，到一套 YAML 配置，再到一个可交付的 Skill 包，最后进化到多 Skill 协同的智能测试体。
二、什么是 Skill？—— 给 AI 的一本"测试操作手册"
2.1 Skills 的本质
在深入技术之前，我们需要先回答一个根本问题：Skill 到底是什么？
我们团队内部有一个形象的比喻：如果把大模型比作一个刚入职的测试新人，Skills 就是培训手册。新人（大模型）有很强的学习能力（推理能力），但如果不知道你们团队怎么写用例、用什么框架、遵循什么规范，他照样会写出不合规的东西。而 Skill 就是把这些"隐性知识"显性化——告诉他"我们团队是这样写测试脚本的"。
从技术角度看，Skill 的本质是一份结构化的 Markdown 文档（通常命名为 SKILL.md），外加可选的脚本文件和资源模板。这份文档告诉 AI：
- 这个场景的输入是什么（需求描述、接口文档、业务规则）
- 输出应该是什么格式（测试代码、测试报告、Bug 描述）
- 遵循什么规范和约束（命名规则、框架选择、断言策略）
- 分几步完成，每一步做什么
2.2 Skills vs MCP：不是二选一，是互补
在做技术选型时，很多团队会问：Skills 和 MCP 有什么区别？我的理解是：Skills 是"说明书"，MCP 是"工具协议"。
Skills 依靠 AI 的阅读理解能力来执行——AI 读完 SKILL.md 中的步骤说明，自己决策怎么做。而 MCP 是把功能封装成持续运行的服务，通过 Tool 调用的方式暴露给 AI，函数内部的具体逻辑（鉴权、参数校验、接口调用）对 AI 是透明的。
基于这个区别，选型原则就很清晰了：
- 流程性任务用 Skills——比如"根据接口文档生成测试用例→初始化框架→生成代码→执行测试→输出报告"，这是一个有明确步骤的流程，Skills 的说明书模式天然适合。
- 需要精确控制的场景用 MCP——比如"用 execute_sql 查数据库"“调用 MeterSphere API 创建测试计划”，这些操作需要精确的参数校验和安全控制，用 MCP 更可靠。
在实际落地中，我们往往将两者结合使用：Skill 描述"做什么"和"按什么顺序做"，MCP 提供"怎么做"的具体工具。比如在接口自动化测试 Skill 中，用 MySQL MCP 的 execute_sql 工具做数据层断言校验，就是典型的 Skills + MCP 组合。
三、从零到一：打造一个 JMeter 脚本生成 Skill
为了让读者对 Skill 有一个具象的认知，我以财政系统性能压测中最常用的场景——JMeter 脚本生成——为例，完整展示一个 Skill 从设计到交付的全过程。
3.1 痛点分析
在财政系统的性能测试中，JMeter 脚本编写占了大量时间。一个典型的压测场景（比如"1000 个预算单位同时申报"）需要：
- 配置线程组、循环控制器
- 编写 HTTP 请求默认值
- 配置 CSV 数据源参数化
- 添加聚合报告、查看结果树
- 编写断言（响应状态码、响应时间、响应内容）
手动编写耗时不说，不同测试人员写出的脚本风格差异大，维护困难。如果能用 AI 自动生成规范统一的 JMX 脚本，将大幅提升效率。
3.2 架构设计
我们采用了五层架构来设计这个 Skill：
jmeter-script-writer/ ├── SKILL.md # 调度中枢（核心说明书） ├── templates/ # 模板层 │ ├── basic-threadgroup.jmx # 基础线程组模板 │ ├── csv-datasource.jmx # CSV 参数化模板 │ └── assertion-template.jmx # 断言模板 ├── references/ # 知识库（五份参考文档） │ ├── jmeter-best-practice.md # JMeter 最佳实践 │ ├── budget-api-spec.md # 预算系统接口规范 │ └── assertion-rules.md # 断言规则说明 ├── scripts/ # 校验脚本 │ ├── validate_jmx.py # 脚本结构校验 │ └── parse_input.py # 输入解析 └── output/ # 输出目录五层职责划分：
| 层级 | 职责 | 说明 |
|---|---|---|
| Prompt 层 | 调用入口 | SKILL.md 中的触发词和意图识别 |
| 参数解析层 | 输入处理 | 将自然语言描述解析为结构化参数 |
| 模板渲染层 | JMX 生成 | 基于模板组装完整的 JMeter 脚本 |
| 文件输出层 | 工程打包 | 输出可执行的 JMX + CSV 数据文件 |
| 校验容错层 | 质量门禁 | 结构校验、断言复核、日志输出 |
3.3 SKILL.md 核心配置
以下是精简后的核心配置内容：
# SKILL.md — jmeter-script-writer 调度中枢name:jmeter-script-writerdescription:根据接口信息和压测需求，自动生成规范的 JMeter 压测脚本version:1.0.0author:kongfantengtrigger:keywords:["生成压测脚本","jmeter脚本","性能测试脚本","jmx脚本"]context:["API","performance_test","
