目录
测试团队的老问题：经验全在老 QA 身上
Skills 的本质：把测试经验变成可执行能力
Skills、Prompt、MCP 在测试工程中的分工
一个测试类 Skill 应该长什么样
为什么 Skills 适合复杂测试场景，而不是拖垮上下文
测试 Skills 的作用域：个人技巧 vs 项目质量体系
测试 Skill 是怎么沉淀出来的
从 Skills 到测试 Agent：变化真正发生的地方
五个可直接落地的测试 Skill 示例
写在最后：测试经验，终于有了“载体”
- 测试团队的老问题：经验全在老 QA 身上
几乎所有测试团队都会遇到类似的问题：
新人知道要“测”，但不知道先测什么
同一个线上问题，不同 QA 的排查路径完全不同
事故复盘时才发现，其实“老 QA 都知道要先看哪个点”
这并不是测试能力的问题，而是经验没有被结构化。
在大多数团队里，真正值钱的不是测试用例本身，而是这些隐性判断：
出问题时先看哪个系统
哪些日志字段是“信号”，哪些只是“噪声”
什么情况必须阻断发布，什么情况可以放行
哪些场景必须补回归，哪些可以忽略
这些内容，很少被系统性地写下来。
- Skills 的本质：把测试经验变成可执行能力
Skills 解决的不是“让 AI 更聪明”，而是一个长期存在的问题：
如何让测试经验可以被复用。
从工程视角看，一个测试 Skill 本质上包含三件事：
判断逻辑
执行流程
工具调用顺序
也就是说，它描述的不是“这次测什么”，而是：
在什么情况下，应该怎么判断，流程该怎么走。
Skills 做的事情，是把“老 QA 的工作方式”，变成 AI 可以反复执行的能力模块。
- Skills、Prompt、MCP 在测试工程中的分工
在测试工程里，这三者的边界非常清晰。
Prompt解决的是一次性请求，例如：
帮我分析这个接口异常
帮我生成一批测试数据
它是任务导向的，但不保证判断路径一致。
MCP解决的是测试工具接入问题：
调接口
查日志
查数据库
执行脚本
它让 AI 能“动手”，但并不知道什么时候该用哪个工具。
Skills解决的是测试中最难被代码化的部分：
先分析还是先跑用例
异常是数据问题还是逻辑问题
回归范围如何判断
是否需要升级处理
一句话总结测试工程视角：
Prompt 是测试请求 MCP 是测试工具 Skills 是测试方法论
- 一个测试类 Skill 应该长什么样
一个典型的测试 Skill，本质上是一个可版本化的目录：
api-regression-check/
├── SKILL.md
├── scripts/
├── references/
└── assets/
核心只有一个：SKILL.md。
元数据：定义适用场景
例如：
接口回归
灰度发布前校验
线上问题快速定位
这是 AI 判断“是否该用这个 Skill”的依据。
正文规则：测试 SOP
正文描述的是明确的判断和流程：
先检查哪些前置条件
哪些接口是高风险点
哪些字段必须重点关注
异常时如何缩小范围
这不是生成测试用例，而是测试决策流程。
- 为什么 Skills 适合复杂测试场景，而不是拖垮上下文
测试场景有一个特点：规则多，但不是每次都用。
Skills 采用的是分层加载策略：
元数据常驻上下文，用于场景匹配
正文规则按需加载
脚本和文档在执行到对应步骤时才读取
这意味着：
可以沉淀大量测试 Skill
不会一次性塞满上下文
测试复杂度上升，但 AI 不会失控
这一点对复杂系统测试尤为重要。
- 测试 Skills 的作用域：个人技巧 vs 项目质量体系
测试 Skill 通常分为两类。
个人级 Skills
接口分析技巧
用例设计方法
常见异常模式识别
用于提升个人效率。
项目级 Skills
项目核心链路校验
发布前质量门禁
事故处理流程
项目级 Skill 的关键价值在于：
可以和代码一起进入仓库。
测试经验第一次成为项目资产。
- 测试 Skill 是怎么沉淀出来的
高质量测试 Skill，通常来自三种场景：
线上事故复盘
老 QA 的长期经验
发布失败后的反向归因
这些经验一旦被写成 Skill，就不再依赖个人记忆。
- 从 Skills 到测试 Agent：变化真正发生的地方
当 Skill 与多智能体、自主执行机制结合，测试方式开始发生变化。
AI 可以：
接收测试目标
自动选择 Skill
执行校验
验证结果
根据规则决定是否继续
测试从“人盯流程”，变成“人盯结果”。
- 五个可直接落地的测试 Skill 示例
下面这 5 个 Skill，全部来自测试团队的高频真实场景。
Skill 1：接口异常快速定位（api-error-triage）
适用场景接口返回 500 / 502 / 业务错误码。
核心规则
区分 HTTP 异常与业务异常
HTTP 异常优先检查依赖服务
业务异常对照错误码表
输出问题类型、责任模块、是否建议升级
Skill 2：回归测试范围判定（regression-scope-analyzer）
适用场景代码合并、发版前回归评估。
核心规则
按变更类型分类
判断是否影响核心链路
输出必测模块与可跳过模块
Skill 3：测试数据合理性校验（test-data-sanity-check）
适用场景测试数据生成、联调、压测前。
核心规则
校验业务约束
检查高风险字段
输出风险数据与建议
Skill 4：线上问题测试视角复盘（incident-test-review）
适用场景事故复盘、质量改进。
核心规则
判断是否可测试阶段发现
明确缺失的是用例、数据还是校验点
给出是否可补自动化结论
Skill 5：发布前质量门禁评估（release-quality-gate）
适用场景灰度 / 正式发布前。
核心规则
汇总缺陷、变更、回归信号
给出放行 / 不建议放行结论
明确人工确认点
- 写在最后：测试经验，终于有了“载体”
测试行业长期存在一个现实：
最有价值的判断，往往最难被传承。
Skills 并没有取代测试工程师，而是第一次让测试经验：
被结构化
被版本化
被共享
被反复执行
当测试经验可以被“安装”， 质量这件事，才真正开始可规模化。
