api-scenario-runner 如何執行端到端業務場景測試

2026-10-29 7

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 本文介绍新上线的AI测试技能`api-scenario-runner`：作为业务链路执行引擎，它可全自动运行「注册→登录→搜索→加购→下单→支付→查单」全场景编排（YAML），支持变量注入、三级断言、DB终态校验、失败快照留存，并能编译为Pytest脚本融入现有CI流水线，补齐接口测试向端到端业务验证的关键一环。

在之前发布的SKILL，我们已经能把接口测试的 AI 流水线跑通了，但一直留着一个缺口：登录、加购、下单各自都测得很好，拼到一起却不一定通——单接口全绿，业务照样可能卡死。

这次新增的两个 Skill 就是补这块的：把「注册→登录→搜索→加购→下单→支付→查单」这样一条完整业务链路，当成一个测试对象来搞。

🔹 api-scenario-modeler（场景建模）
🔹 api-scenario-runner（链路执行引擎）

两个 Skill 一个管「测什么」，一个管「怎么跑」，和前面篇章的执行、诊断、清理、报告技能无缝衔接，单接口和业务场景两条线从此在同一个体系里跑。

上一篇，我们已经介绍了api-scenario-modeler（场景建模），今天这篇来来带大家拆解一下api-scenario-runner（链路执行引擎）这个Skill。

实战项目准备

本篇教程的实战案例，依旧延续 shop-lab 全栈电商项目，这次业务场景链路skill，会横跨项目的 5 个业务模块：

模块	链路中承担的角色
auth（认证）	注册、登录，产出全程要用的 token
search（搜索）	找到目标商品，产出 productId
product（商品）	查看详情，获取库存基线 stockBefore
cart（购物车）	加购，产出 cartItemId
order（订单）	下单、支付、查单，是断言的主战场

先确保后端服务已正常启动，Swagger UI 可访问：http://localhost:8080/swagger-ui.html，

业务场景接口测试执行引擎：api-scenario-runner

api-scenario-runner这个Skill的作用，就是把 api-scenario-modeler（或人工）产出的 scenario_xxx.yaml 编排文件真实执行起来：按序发请求、自动变量提取与注入、鉴权头注入、三级断言（步骤断言 + db 终态断言）、每步执行快照留存、失败即停保留现场，还支持把编排文件编译为 pytest 或任意指定框架链路脚本工程。

适用场景

执行场景编排文件、跑链路、端到端流程验证
把场景 yaml 编译成 pytest 链路脚本，纳入 api-test-executor 统一调度
失败后保留完整现场，交给 api-failure-diagnoser 深度诊断

使用方式

在 Claude Code 中提供编排文件路径，或输入：

/api-scenario-runner

两种执行模式

模式	说明
run（默认）	直接执行：结构校验 → 按序请求 → 三级断言 → 报告 + 快照
compile	编译为 pytest 工程：`testcases/test_scenario_<id>.py` + `data/scenario_<id>.yaml`，复用被测项目 utils/config

核心能力

场景上下文：${var} 自动提取与注入（支持整串替换与拼接），auth: true 步骤自动注入 Bearer token
三级断言：步骤断言（status_code → 业务码 → jsonpath）→ 终态 db 断言（expect_value 直接比对 / expect_expr 变量表达式求值）
失败即停 + 现场留存：每步快照写入 steps_snapshot.json（注入后真实请求、响应、变量视图，敏感值脱敏）
归因初判五类：VARIABLE_MISSING / ASSERTION_FAILED / API_ERROR / CONNECTION_ERROR / DB_ERROR
安全机制：db 断言仅允许 SELECT、SQL 参数化执行、编排文件禁止写死连接信息、配置缺失 fail-fast

输出： scenario_report.md（执行报告）+ steps_snapshot.json（诊断快照）+ compile 产物（pytest 工程）

实操演示

输入下方提示词，如图所示：

skill运行期间，会自行对比与修正各接口字段名称

并对MySQL数据库、redis缓存数据一致性进行校验。

执行完成，SC-order-001 全链路通过（全链路共包括了14个接口调用步骤）

同时，scenario_shopping_flow.yaml和modeling_notes.md这两份场景资产已同步为实测最新版：

最后，还会自动生成一份md格式的场景测试执行报告（默认会存放在：接口测试项目目录/shop-lab-api-test/scenario_run_results/xxx/scenario_report.md）

融入既有体系（compile + 流水线）：

/api-scenario-runner 编译场景编排文件 /Users/xxx/scenarios/scenario_order_flow.yaml 为 pytest 脚本，输出到 shop-lab-api-test 项目

编译产物检查两点：目录结构符合 007 篇的分层规范（testcases/ + data/ ），如上图所示，在testcases/目录下，生成了包含 pytest 链路脚本：test_scenario_order_001.py

在data/目录下，生成业务场景关联脚本测试数据scenario_order_001.yaml

之后的一切都是熟悉的：用 009 篇的 api-test-executor 按标签（scene:business-flow）调度执行，或交给 api-pipeline-scheduler 纳入"执行 → 清理 → 报告"流水线。

比如输入如下提示词：

调用api-test-executor技能，跑一下~/ai_project/shop-lab-api-test/testcases/test_scenario_order_001.py这个业务场景测试脚本

执行后，链路 14 步 + 终态 DB 校验 4 条全部通过，期间还顺手修复了一个编译器的Bug。

执行完成后，顺带调用api-report-generator技能，让其生成测试报告

会自动生成好两份测试报告，一份是基于Allure 原生报告（在线服务）

另一份，是一份自研定制的HTML 测试报告（单文件，可独立打开）

幂等与重复执行

第四轮解决"昨天能跑今天跑不过"的问题：不做任何修改，紧接着再执行一遍同一条链路。

合格标准非常明确：第二遍同样全绿。因为 username 是 timestamp 策略动态生成的，第二遍注册的是新用户，不存在 009 篇 newuser_001 那种重复注册冲突；链路数据回收按 cleanup 配置联动 api-testdata-cleaner，两遍执行之间环境是干净的。如果第二遍失败，大概率暴露两类问题——唯一性字段漏了动态策略，或 cleanup 配置漏了某个数据对象，回改编排文件即可。

这一轮直接决定链路能不能进 CI 流水线天天跑，是五轮里最不能省的一轮。

至此，业务场景测试完全并入前面篇章建立的自动化体系，单接口与业务场景两条线，在同一个体系里跑了起来。

至此，接口自动化测试的 Agent Skill 体系补上了最后一块拼图，完整版图如下：

如何获取Skill

所有实战演练创建生成的 skill，会统一上传到 GitHub中，可按需自取。

同时，目前所有 Skill 均已统一上传至网站 testfather.cn Skill 技能商店中。

本篇新增的两个 Skill，安装方式与之前一致，将 Skill 目录复制或克隆到你的 Claude Code 或 WorkBuddy 技能目录下即可使用：


## 在线安装
npx skills add xxx/api-scenario-modeler
npx skills add xxx/api-scenario-runner

# 克隆仓库
git clone git@github.com:xxx/skills.git

# 复制到 Claude Code 技能目录
cp -r skills/api-scenario-modeler ~/.claude/skills/
cp -r skills/api-scenario-runner ~/.claude/skills/

# 或复制到 WorkBuddy 技能目录
cp -r skills/api-scenario-modeler /Users/xxx/.workbuddy/skills/
cp -r skills/api-scenario-runner /Users/xxx/.workbuddy/skills/