还在用 Excel 写测试用例？盛京银行怎么用 Apifox 实现自动化闭环

对于许多金融机构、银行及大型政企单位的 QA 测试团队来说，接口自动化测试一直是一块极其难啃的骨头。

在过去，以盛京银行为代表的金融测试团队，测试用例的维护主要依赖复杂的 Excel 表格与离线脚本：

用例难以维护：Excel 中充斥着大量的 URL、JSON 报文与预期结果，接口一改就需要手动去逐个表格修正；
无法应对复杂业务链条：难以在 Excel 中表达“登录 -> 获取 Token -> 提取订单 ID -> 校验数据库 -> 支付”这种多接口强上下文关联的动态流程；
故障排查极慢：跑脚本报错后，测试人员要耗费数小时在命令行日志中寻找具体是哪个接口的断言出了问题。

在落地 Apifox 私有化部署方案后，盛京银行成功实现了从“人肉 Excel 维护”向“可视化测试场景编排与内网自动化闭环”的跨越。

一、金融级可视化场景编排：告别 Excel 手工表格

Apifox 为测试团队提供了零门槛、拖拽式的图形化场景编排能力：

┌────────────────────────────────────────────────────────────────────────┐
│                     Apifox 可视化自动化测试场景编排                     │
│                                                                        │
│   步骤 1: [POST /api/auth/login] ──► 提取后置变量: token             │
│              │                                                         │
│              ▼                                                         │
│   步骤 2: [POST /api/order/create] ──► 传参 Header: Bearer {token}    │
│              │                     提取后置变量: order_id              │
│              ▼                                                         │
│   步骤 3: [If 条件分支] (order_id != null)                              │
│              ├──► 步骤 4: [POST /api/payment/pay] (执行支付)          │
│              └──► 步骤 5: [测试断言报错并阻断]                         │
│              │                                                         │
│              ▼                                                         │
│   步骤 6: [DB 校验] 直连内网 MySQL 查询订单状态 == 1                   │
│                                                                        │
└────────────────────────────────────────────────────────────────────────┘

拖拽式流程编排：将多个接口按业务逻辑顺序编排在一起，直观展示测试流；
前后置变量提取：通过简单的 JSONPath 表达式（如 $.data.token），将上一接口返回的数据自动提取为变量，透传给下一个接口；
流程控制：支持 If 条件分支、For / Loop 循环判断、等待停顿与异常捕获，完美应对金融交易中的各种复杂逻辑。

// Apifox 自动化测试前/后置断言脚本示例
// 校验响应状态码为 200 且业务 code 为 0
pm.test("HTTP Status is 200", function () {
    pm.response.to.have.status(200);
});

var jsonData = pm.response.json();
pm.test("Business Code is Success", function () {
    pm.expect(jsonData.code).to.eql(0);
    pm.expect(jsonData.data.order_id).to.not.be.null;
});

// 提取 order_id 设置为环境变量供后置接口使用
pm.environment.set("current_order_id", jsonData.data.order_id);

二、内网自托管 Runner 与自动化告警闭环

在盛京银行的内网专网环境中，自动化测试建立了全自动闭环：

自托管 Runner 节点：测试用例直接运行在银行内网的自托管 Runner 节点上，测试数据纯本地流转，不出金融机房；
定时巡检与 CI 流水线触发：配置定时巡检任务（如每 10 分钟运行一次），并在 Jenkins 流水线中嵌入 Apifox CLI，代码一提交自动跑完自动化回归测试；
实时告警精准送达：一旦遇到接口断言失败，系统自动调用 Webhook，将包含失败步骤、状态码、现场日志链接的告警信息推送到钉钉/企微运维群。

三、盛京银行落地的工程效益对比

对比维度	传统 Excel + 人工测试模式	Apifox 私有化自动化闭环
用例维护成本	极为繁琐，接口变动需修改几十个 Excel 单元格	与 API 文档同源同步，一键生成更新
测试回归周期	人工回归耗时 2 天以上	自托管 Runner 10 分钟内全自动跑完
故障排查时效	数小时抓包与人工排查堆栈	报错秒级定位到具体的接口与断言细节
内网合规性	缺乏统一审计留痕	全量测试日志落库，满足金融等保要求