AI 测试必备：推荐一款能让自动化失败脚本「自己修好」的 AI skill！

导读：上一篇我们推荐了让接口测试"跑起来"的 api-test-executor。但脚本跑起来只是第一步------跑完之后，几十条失败用例怎么排查？

今天，给大家分享一款能让失败脚本自己修好 的 AI skill------api-failure-diagnoser。

写在开头

先问大家一个问题：接口测试跑完之后，你最头疼的是什么？

大概率是这样的------

1. 几十条失败用例堆在面前，不知道从哪条看起；
2. 翻日志，错误堆栈一大堆，看不出所以然；
3. 判断是环境问题、数据问题、脚本问题还是产品缺陷，全靠个人经验；
4. 好不容易定位了根因，还要手写代码修复；
5. 修完不确定对不对，得重跑一遍验证；
6. 下次接口一变更，同样的问题又来一遍；
7. 失败用例没人盯、没人修，脚本越跑越烂；
8. 最后整个团队对自动化报告"视而不见"......

行业统计，测试工程师平均花费 40%~60% 的时间在失败分析上------这恰恰是最该被 AI 接管的环节。

如果以上场景你中了三条以上，那么今天这款 skill，你一定要了解------api-failure-diagnoser，一款能让失败脚本"自己修好"的 Agent Skill。

一、它是什么？

api-failure-diagnoser 是接口自动化测试的失败智能诊断专家，该技能是失败分析的"智能大脑"，基于执行结果和日志，自动分类失败类型、定位根因、生成修复建议、自动修复。

它的核心定位同样------只做两件事：

1. 失败诊断：自动分类失败类型（环境/数据/脚本/产品缺陷），定位脚本层面的根因；
2. 自动修复：针对"脚本问题"类失败，自动生成修复补丁、应用、验证。

听起来像魔法？但它是真实存在的。

二、5 大核心亮点

① 分类自动诊断：不是所有失败都一样

这是它最核心的能力。

面对一堆失败用例，第一步不是急着修，而是先分类。

api-failure-diagnoser 会自动把失败分成四类：

失败类型	判定特征	处理方式
ENV_ERROR（环境问题）	连接超时、拒绝连接、502/503/504	❌ 不修复，提示人工检查服务
DATA_ERROR（数据问题）	404、401/403、数据校验失败	❌ 不修复，提示人工清理数据
SCRIPT_ERROR（脚本问题）⭐	断言失败、接口路径 404、响应字段缺失、参数构造错误	✅ 自动修复
BUG（产品缺陷）	500、业务逻辑错误、状态流转异常	❌ 不修复，生成 Bug 报告

为什么要先分类？

因为不同类型的失败，处理方式完全不同：

• 环境问题 → 找运维
• 数据问题 → 清数据
• 脚本问题 → 改脚本（AI 能干）
• 产品缺陷 → 提 Bug

不分类就乱修，等于瞎忙。

② 只修该修的：明确的能力边界

这点是它最被低估的优势。

明确不做的事：

• 不做环境修复（服务宕机交给运维）
• 不做产品缺陷修复（Bug 交给开发）
• 不做复杂重构（架构级改动交给人工）

为什么不做？

因为一个试图修好所有的 AI，最终什么都会修不好。环境、产品缺陷------每一项都涉及不同的协作链路和权限边界，强行让一个 Skill 包揽，只会带来误操作和混乱。

api-failure-diagnoser 只聚焦"脚本问题"这一类，把这件事做到极致------这种克制反而让它更安全、更可靠、更值得信赖。

③ 7 种根因精准定位：不是笼统说"脚本错了"

针对 SCRIPT_ERROR，它还会进一步细分根因，给出具体的修复策略：

根因类型	典型特征	修复策略
接口变更	请求返回 404/405，响应字段缺失/新增	同步更新请求路径、参数、断言
断言过严	断言检查非核心字段（时间戳、随机 ID）	放宽断言条件，移除不稳定字段
定位失效	元素定位失败（XPath/CSS 失效）	更新定位策略
参数构造错误	参数类型错误、必填字段缺失	修正参数构造逻辑
异常处理缺失	未处理错误响应结构，导致 KeyError	补充异常分支处理
时序/异步问题	断言时响应尚未完成	补充显式等待、轮询
数据依赖错误	前置步骤未正确传递参数	修正参数传递逻辑

这意味着：它不是笼统告诉你"脚本错了"，而是精准告诉你"错在哪一行、该怎么改" 。

④ 5 条修复原则：安全可信赖

自动修复最怕的是什么？改坏了原本好的代码。

api-failure-diagnoser 用 5 条原则保证修复安全：

1. 最小侵入：仅修改导致失败的最小代码范围，不改动无关逻辑；
2. 规范一致：修复后的代码严格遵循团队编码规范；
3. 可回滚 ：修复前自动备份原文件（.bak），支持一键回滚；
4. 验证闭环：修复后自动重跑受影响用例，验证通过才确认修复成功；
5. 人工确认 ：默认生成 .patch 文件，由人工审核后应用。

特别说明 ：默认是 --auto-fix=false，也就是先生成补丁让你审核，确认没问题再应用。这是对人工经验的尊重------AI 负责"初筛和提效"，人负责"把关和决策"。

⑤ 结构化输出：可追溯、可审计、可衔接

修复完成后，它会输出一套完整的"修复档案"：

1. repair_report.md（诊断与修复报告）

人能直接读的修复报告，包含：

• 执行摘要（分析用例数、各类问题数量）
• 脚本问题详情（每个问题的根因、修复操作、修复前后对比、验证状态）
• 未修复问题（环境、数据、产品缺陷的处理建议）

2. 修复补丁文件（.patch）

当 --auto-fix=false 时生成，供人工审核后应用。

3. 修复后的脚本文件

当 --auto-fix=true 时直接修改原文件，并保留 .bak 备份。

4. bug_reports/ 目录

产品缺陷的详细 Bug 报告，建议提交给开发团队。

也就是说，每一次修复都有完整的档案可追溯------改了什么、为什么改、改完效果如何，全部留痕。这对团队协作和审计至关重要。

三、典型使用场景

场景一：日常失败排查

一轮测试跑完，面对几十条失败用例：

/api-failure-diagnoser 请诊断 shop-lab-api-test 项目本次执行中的失败用例，帮我看看，并修复一下失败的测试脚本

它会自动加载执行结果，分类失败、定位根因、给出修复方案------几分钟干完你半天的活。

场景二：接口变更后的批量修复

后端接口改了（路径变了、参数增减、响应结构调整），脚本批量失效：

/api-failure-diagnoser 请针对本次失败用例自动修复，并结合最新接口文档对比变更

它会自动识别"接口变更"根因，批量同步路径、参数、断言------不用你一条条手改。

场景三：数据污染问题修复

脚本里硬编码了用户名，第二次跑就因为账号重复失败：

/api-failure-diagnoser 请诊断并修复 test_register_success 这条失败用例

它会识别为"数据依赖错误"，给出修复方案（如动态生成用户名）------从根因上解决重复执行失败。

场景四：产品缺陷自动识别

有些失败不是脚本的问题，而是接口真的有 Bug。它会自动识别为 BUG 类型，生成完整的 Bug 报告，包含：

• Bug ID、发现用例、接口路径
• 问题描述、期望结果、实际结果
• 优先级、复现步骤

直接可以提交给开发，省去你写 Bug 报告的时间。

场景五：接入 CI/CD 的自愈闭环

通过 Claude CLI 的非交互模式，可以实现"失败 → 诊断 → 修复 → 重跑"的自愈闭环：

claude -p "调用 api-failure-diagnoser 技能，参数: project_path=${PROJECT_PATH}, execution_results=${RESULTS_PATH}, auto-fix=true, verify=true" \
  --permission-mode bypassPermissions \
  --output-format json \
  --max-turns 30

让接口测试真正具备"自我修复"能力。

四、真实案例：从 25% 到 98.7% 的自愈爬坡

这是AI 进化社中一个非常典型的实战案例，完整展现了 api-failure-diagnoser 的自愈能力。

1、调用 api-test-executor 跑 P0 用例。

/api-test-executor 在 test 环境跑一下shop-lab-api-test 项目P0级测试用例
shop-lab-api-test项目路径为：/xxx/shop-lab-api-test

将提示词发送后，api-test-executor技能会先自主检测服务是否正常，然后根据执行要求过滤统计出了，当前项目共有八十多条P0级测试用例，覆盖了49个文件。

第一轮执行结果如下：

从上述执行结果可知，只有21条通过，通过率仅25%。（首轮P0级测试用例执行通过率只有 25%（21/83 通过））

2、首轮测试执行完成后，我们不用急于人工介入排查修复，直接调用api-failure-diagnoser 技能自动批量修复问题。

等待修复即可，需要注意不同的问题会采取不同的脚本修复策略。

第一轮修复完成后，会重新跑一遍P0级测试，从验证结果可知，经过一轮自主修复后，用例成功数量从21个提升到了29个。

第一轮自愈：

调用 api-failure-diagnoser 自动诊断 + 修复，它识别出多种 SCRIPT_ERROR：

• conftest.py 中 allure.environment() 不兼容
• 业务码断言错误（脚本断言 code=0，API 实际返回 code=200）
• logout 断言过严（API 返回 data: null，但脚本断言非空）

修复后重新执行，通过率提升到 35%（29/83 通过）。

前期要学会降低预期，不要指望一轮就能将所有问题全部修复好，Skill技能也是需要不断学习进化的。

3、继续调用 api-failure-diagnoser 修复剩余失败，比如把硬编码用户名改为动态生成（增加时间戳），解决数据污染问题。

最终 P0 通过率达到 98.7%，全程没有人工写一行代码。

这个案例最有意思的不是最终数字，而是整个过程------测试执行 + 自动诊断 + 自动修复 + 重新执行，形成了完整的自愈闭环。前期要学会降低预期，不要指望一轮就将所有问题修复好，Skill 也是需要不断学习进化的。

五、适合谁用？

强烈推荐：

• 接口自动化测试工程师：日常排查失败、修复脚本
• 测试开发工程师：搭建团队自愈能力、降低维护成本
• 全栈测试工程师：希望降低自动化维护门槛
• 测试团队负责人：希望提升团队失败处理效率、降低脚本腐化速度

特别适合：

• 失败用例多、排查工作量大的团队（价值立现）
• 接口变更频繁、脚本维护成本高的团队（自愈能力是救星）
• 希望让自动化"活"起来、而非沦为僵尸脚本的团队
• 新人较多的团队（AI 诊断能帮新人快速理解失败根因）

不太适合：

• 还没有自动化测试脚本的团队（先解决"有"再解决"修"）
• 期望 AI 100% 替代人工排查的团队（复杂的故障分析仍需要人工经验）

六、如何获取和安装？

api-failure-diagnoser GitHub 仓库地址：

git clone git@github.com:AI进化社/skills.git

安装到 WorkBuddy：

cp -r skills/api-failure-diagnoser ~/.workbuddy/skills/

安装到 Claude Code：

cp -r skills/api-failure-diagnoser ~/.claude/skills/

安装完成后，在你的 AI 工具里直接说：

"/api-failure-diagnoser 请诊断 xxx 项目本次执行中的失败用例，并修复脚本"

就可以开始用了。

小贴士 ：建议先用 api-test-executor 跑一轮测试，生成 execution_results.json，再调用本 skill 进行诊断------两者是天然的上下游搭档。

写在最后

测试行业有句老话："自动化测试的三座大山------跑起来、看明白、修得快。"

api-failure-diagnoser 解决的就是最难的那座------修得快。

它不会替代你的故障分析经验，不会替代你对业务逻辑的理解，更不会替代你对产品质量的判断。

它只是把你从逐条翻日志、手写修复代码、反复验证 的循环中解放出来，让你把精力聚焦在更有价值的事情上------复杂故障深度分析、产品质量策略优化、自动化体系持续改进。

需要强调的是：AI 仅仅只是为了简化或者辅助人工排障，复杂的故障分析仍需要人工介入和人工经验。建议形成"AI 初筛 → 人工复核 → 闭环确认"的机制------AI 处理 80% 常规失败，人工聚焦 20% 复杂场景。

而这，正是 AI 赋能测试的真正意义------不是替代人，而是解放人。

如果你也厌倦了每天花半天排查失败用例，强烈推荐试试这款 skill。