上个月，团队接了一个支付网关的回归测试。需求文档12份，接口87个，测试周期只有5天。测试组长看了一眼排期，说了句：“按老规矩，加班吧。”
我把他拦住了：“先别急着排班，给我一天时间，我把流程重构一下。”
一天后，我给他看了一条流水线：需求文档进去，用例集出来；测试执行完，失败原因自动分类；缺陷定位报告直接推到飞书。
他看完问了一句：“这是把整个测试流程都拆了？”
我说：“不是拆了，是用 Agent Skills 重新串了一遍。”
一、传统测试流程的“断点”在哪？
先说说我们原来的流程。
拿到需求文档 → 人工啃文档 → 手写测试用例 → 人工评审 → 写自动化脚本 → 跑测试 → 失败了人工排查 → 提Bug → 回归验证。
每一步之间都是断的。用例写完要导到Excel，评审要拉会，脚本要单独写，失败了要从日志里翻原因。每个断点都是一次人工交接，每次交接都在丢信息、耗时间。
更麻烦的是，每个环节的经验都散落在不同人手里。老张擅长写用例，但他的经验只在他脑子里。小李擅长排查失败，但他的方法从来不写下来。人一走，经验就没了。
Agent Skills 解决的就是这个问题——把每个环节的经验封装成可复用的能力单元，再用流程把它们串起来。
二、重构后的流程：四个 Skill 串起全链路
我重构后的测试流程，核心是四个 Skill：
Skill ①：需求拆解——把 PRD 变成测试地图
Skill ②：用例生成——把测试地图变成结构化用例
Skill ③：失败归因——把失败日志变成分类结论
Skill ④：缺陷定位——把疑似 Bug 变成可复现的缺陷报告
每个 Skill 单独可用，串起来就是一条从需求到缺陷的自动化流水线。
三、Skill ① 和 ②：从需求到用例
这两个 Skill 我在之前的文章里拆过，这里只讲关键设计。
需求拆解 Skill
SKILL.md 的 description 决定了它什么时候触发：
name: prd-to-test-map
description: 从PRD中提取功能点、业务规则、数据约束和风险预判，生成结构化测试地图。当用户提到“分析需求”“拆解PRD”“梳理测试点”时触发。
正文写清楚四步：读取文档 → 提取实体和规则 → 识别风险 → 输出测试地图。输出格式固定为：功能清单、业务规则、数据约束、风险预判。
用例生成 Skill
这个 Skill 的核心是场景覆盖的完整性。正文里必须强制要求覆盖四类场景：正常流程、异常场景、边界条件、权限校验。
执行步骤
步骤1：理解测试地图
读取测试地图中的功能清单和业务规则。
步骤2：识别测试场景
- 正常流程：至少覆盖1条完整Happy Path
- 异常场景：参数缺失、格式错误、依赖服务超时
- 边界条件：数值边界、状态边界、时间窗口边界
- 权限校验：未授权访问、越权操作
步骤3：生成用例
每条用例包含：用例编号、测试场景、前置条件、测试步骤、预期结果、优先级。步骤4：自检
对照四类场景检查是否有遗漏。
关键点：SKILL.md 控制在 500 行以内。 详细的用例模板放到 references/test-case-template.md，只在需要时加载。
四、Skill ③：失败归因——把噪音过滤掉
这是重构后流程里最省时间的一个环节。
以前 CI 跑完，50条失败，测试同学一条条翻日志，两小时就没了。现在 Agent 自动跑一遍归因，把失败分成五类：环境问题、用例问题、代码Bug、数据问题、未知。
SKILL.md 设计
name: failure-triage
description: 分析CI流水线中失败的测试用例，对每条失败进行归因分类，输出结构化结论。当用户提到“分析失败”“CI红了”“失败归因”时触发。
正文里定义分类标准和输出格式：
任务
对每条失败用例进行归因分类，只能选择以下类别：
- 环境问题：网络超时、容器启动失败、依赖服务不可用
- 用例问题：定位器失效、测试数据污染、断言过强/过弱
- 代码Bug：业务逻辑错误、接口返回不符合预期
- 数据问题：测试数据不存在、数据被其他用例修改
- 未知：无法判断
输出格式
JSON数组，每条包含：用例名称、分类、一句话结论、置信度、复现步骤。
配套脚本
scripts/triage.py 负责调用大模型 API，读取 pytest 的 JUnit XML 报告，生成分类结果。然后在 CI 的 after_script 里调用这个脚本，把结论推送到飞书。
实测效果：50条失败，AI 归因后只有5条需要人工看。测试同学从“花两小时翻日志”变成“花十分钟复核5条”。
五、Skill ④：缺陷定位——从“疑似Bug”到“可复现报告”
这是整条流水线的最后一环，也是最难的一环。
归因分类只能告诉你“这5条疑似代码Bug”。但到底是哪个模块的问题、怎么复现、影响范围多大——这些需要更深的分析。
SKILL.md 设计
name: defect-localizer
description: 基于失败日志、代码变更和调用链路，定位疑似缺陷的根因模块，生成可复现的缺陷报告。当用户提到“定位Bug”“缺陷根因”“生成缺陷报告”时触发。
正文要求 Agent 做三件事：
第一，关联代码变更。 读取 Git diff，找出本次提交改动了哪些文件、哪些函数。
第二，分析调用链路。 基于失败用例的接口路径，追踪后端服务的调用链，定位异常发生在哪个环节。
第三，生成复现步骤。 结合失败日志和代码变更，给出最小复现路径。
输出格式
缺陷报告
- 缺陷标题：[模块] 问题简述
- 严重程度：P0/P1/P2
- 影响范围：[受影响的功能/接口]
- 复现步骤：编号列表，每步具体可执行
- 根因分析：[哪个模块、哪行代码、什么条件触发]
- 关联变更：[Git commit hash 或 MR 链接]
- 建议修复方向：[简要建议]
六、把四个 Skill 串起来
四个 Skill 写好了，怎么串成流水线？
在 CI 的 .gitlab-ci.yml 里，把流程拆成四个 stage：
stages:
-analyze
-generate
-test
-triage
-localize
analyze-prd:
stage:analyze
script:
-claude--skillprd-to-test-map--inputdocs/prd.md--outputtest-map.json
generate-cases:
stage:generate
needs:["analyze-prd"]
script:
-claude--skilltest-case-generator--inputtest-map.json--outputcases.yaml
run-tests:
stage:test
needs:["generate-cases"]
script:
-pytest--junitxml=report.xml
artifacts:
when:always
paths:
-report.xml
triage-failures:
stage:triage
needs:["run-tests"]
script:
-pythonscripts/triage.pyreport.xml
localize-defects:
stage:localize
needs:["triage-failures"]
script:
-claude--skilldefect-localizer--inputtriage-results.json--outputdefects.md
关键点：每个 stage 的输出是下一个 stage 的输入。artifacts 负责传递文件。needs 定义依赖关系。
跑通之后，整个流程是这样的：
需求文档 → 测试地图 → 用例集 → 执行报告 → 失败归因 → 缺陷报告
从需求到缺陷，全程自动化。人只在最后一步复核缺陷报告。
七、实测数据
我们拿一个支付网关的回归测试做了对比。
环节
传统方式
Skill 流水线
用例生成
2天
2小时
用例评审
半天
1小时
失败归因
2小时
10分钟
缺陷定位
半天
30分钟
全流程
5天
1.5天
最关键的改变不是“快了”，是“可复现”了。 以前每次回归，流程都一样，但每次都在重新做。现在 Skill 固定下来了，流程可以重复执行，结果可以量化对比。
八、避坑指南
坑一：Skill 粒度拆得太细。 一个工作流拆成 10 个 Skill，AI 不知道该用哪个。2-3 个模块的 Skill 表现最好。四个 Skill 串一条流水线是极限。
坑二：description 写得太空。 “帮助测试”——这等于没写。要写清楚触发条件，让 Agent 知道什么时候该调用这个 Skill。
坑三：SKILL.md 超过 500 行。 每次加载都浪费 Token。把详细内容移到 references/ 目录，SKILL.md 只留核心流程。
坑四：不做 Skill 的回归测试。 模型版本一变，Skill 行为可能漂移。用 skill-up 给 Skill 写评测用例，每次修改后跑一遍，确保行为不变。
坑五：指望全自动，不设人工复核。 AI 归因是“预筛”，不是“判决”。我们永远在流程末尾设一个人工复核节点。AI 负责把噪音过滤掉，人负责做最终判断。
最后
用 Agent Skills 重构测试流程，本质是把“人的经验”变成“可复用的能力单元”，再用流程把它们串起来。
以前每个环节的经验都散落在不同人手里，人一走经验就没了。现在每个环节的经验都封装在 Skill 里，谁都能调用，谁都能复用。
从用例生成到缺陷定位，一条流水线跑完。人只做最后那一步判断。
下次你面对一个新项目的时候，别急着排班加班。先花一天时间，把测试流程拆成几个 Skill，串起来。
你会发现，测试不是只有“加班”这一条路。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
