上个月，团队接了一个支付网关的回归测试。需求文档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 固定下来了，流程可以重复执行，结果可以量化对比。

八、避坑指南

坑一：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 测试等内容，侧重测试实践、工具应用与工程经验整理。