金融风控测试老漏检？用 AI 自动化测试框架 midscene 一次跑通 Web、Android、iOS

金融风控测试老漏检？用 AI 自动化测试框架 midscene 一次跑通 Web、Android、iOS

【免费下载链接】midsceneGUI Agent for E2E Testing项目地址: https://gitcode.com/GitHub_Trending/mid/midscene

写风控自动化用例，最怕的不是脚本跑不赢，而是脚本"通过了"，线上还是出了事。

一次真实感很强的"假通过"

想象这样一个场景：反欺诈链路改版上线，测试脚本全绿，大家准备发布。结果灰度第二天，值班群炸了——某个风控页面的拦截提示语改了个文案位置，用户实际看到的是旧提示，但页面 DOM 里那个节点一直存在。断言只检查"节点在不在"，所以测试永远是通过的。

问题出在哪？传统 UI 自动化的断言，盯的是页面的结构（DOM、控件树），而不是用户看到的画面。金融风控页面恰恰是重灾区：弹窗、浮层、验证码、风控提示卡片，DOM 结构经常和视觉呈现脱节。结构对了，画面不一定对；画面错了，结构未必报警。

这就是本文要解决的问题：用 AI 自动化测试的思路，让测试"看屏幕"而不是"读源码"。下文以开源框架 midscene 为例，走一遍它在金融风控场景下的用法。

传统方案在风控场景的三个硬伤

不展开理论，只说三个我们大概率都遇到过的痛：

1. 选择器是碎玻璃。风控页面改版频率高，前端换个 div 嵌套、换个组件库，一堆 XPath 和 class 选择器集体阵亡。修用例的工时往往比写业务逻辑还长，而且修起来全是体力活。

2. 一端一套脚本。同一条风控规则，银行 App（Android/iOS 两个版本）、Web 后台、小程序各写一遍脚本，逻辑重复三四处。某端选择器挂了，你根本不知道另外几端有没有同样的问题——策略不一致，恰恰是风控测试最不能漏的点。

3. 视觉盲区。风控场景大量关键信息是"看起来对不对"：红色警示文案高亮了没有？限额数字渲染完整吗？人脸识别框的位置正不正？这些用 DOM 断言根本够不着，传统方案只能人肉截图核对。

这套框架到底在做什么：给测试装上一双眼睛

midscene 的核心思路一句话：不读页面结构，只看截图。它把多模态大模型的 UI 定位能力接进测试流程，你不需要写选择器，用大白话描述每一步要做什么、要验证什么。

三个机制，分别对应上面三个硬伤：

视觉驱动定位。框架截图 → 交给多模态模型 → 模型告诉它"点击搜索框"、"输入金额"该落在哪里。只要人眼能在屏幕上看到的东西，它基本都能定位到，包括 canvas 画布、原生 App、跨域 iframe 这些选择器方案天然够不着的区域。前端怎么改结构都不影响用例，因为用例里根本没有结构。

自然语言写用例。用例就是 YAML，里面写的是"在收款方输入框填入测试账号"这样的句子，而不是xpath://...。不懂 UI 自动化的同事、甚至测试负责人，都能看懂、能 review 一条用例——这对风控这种需要多方评审的领域是实质性收益。

跨端一套 API。同一个agent接口，背后可以是 Web 浏览器、Android 真机、iOS 模拟器或桌面应用（代码分别在 packages/web-integration/、packages/android/、packages/ios/ 里）。写一次流程逻辑，换端只换设备初始化那几行。

类比一下：传统方案是"背下每个按钮的门牌号去按"，门牌号一改就迷路；midscene 是"看着屏幕找那个写着'确认转账'的按钮"，按钮挪到哪儿都能找到。

从装到跑通：跟着走一遍风控用例

以"验证 Web 端大额转账触发人脸识别拦截"为例，完整路径四步。

第一步，装工具、配模型。

npm i -g @midscene/cli

然后在运行目录放一个.env，填入模型服务地址和 API Key（MIDSCENE_MODEL_BASE_URL、MIDSCENE_MODEL_API_KEY、MIDSCENE_MODEL_NAME），变量含义和取值示例见模型配置文档。模型选 UI 定位能力强的多模态模型，比如 Qwen-VL、UI-TARS 这类开源模型可以自托管，金融数据不出内网，这是选型时值得优先考虑的一条。

第二步，写用例。一条 YAML 就是一个测试点：

page: url: https://pay.example-bank.test/transfer tasks: - name: 大额转账触发人脸核验 flow: - ai: 在收款账户输入框填入测试账号 6222 **** 0001 - ai: 在金额输入框填入 50000，点击下一步 - aiAssert: 页面出现人脸识别核验提示，且交易处于待验证状态

注意最后一条aiAssert：它断言的是"画面上出现了人脸核验提示"，这正是传统 DOM 断言的盲区。用例写法细节可以参考官方 YAML 指南。

第三步，执行。一条命令：

midscene transfer-facial-check.yaml

第四步，看报告。运行结束会生成可视化 HTML 报告：每一步做了什么、截图是什么、耗时多少、断言结果如何，全部按时间轴铺开，复盘和留证都很方便。报告长这样：

如果想跳过项目搭建、直接在浏览器里试，Playground（Chrome 扩展形态）是最快的入口：打开被测页面，在侧边栏输入自然语言指令，AI 的规划、定位、点击过程实时可见，先验证想法，再固化成 YAML。

再进一步，风控规则要同时覆盖 App 端的话，Android Playground 可以在浏览器里直接连真机投屏执行，界面见Android 平台文档：

还有一类更贴风控真实环境的玩法：桥接模式（Bridge Mode）。它让本地脚本直接接管你正在用的桌面 Chrome——复用真实的登录态、cookies 和企业代理，脚本和人工可以交替操作同一条会话。风控系统的测试环境往往要过一堆认证，这条"人肉登录、脚本接管"的路径能省掉大量环境折腾，原理见桥接模式文档：

落地踩坑与配置取舍

先说四个最常见的坑：

坑 1：Node 版本太旧，CLI 直接罢工。@midscene/cli要求 Node 20.19+、22.12+ 或 24+，旧版本会在构建工具链上报Unsupported Node.js version。内网老机器先查node -v，能解决一半的安装问题。

坑 2：.env放错了目录。它必须放在命令执行目录下，不是 YAML 文件所在目录。脚本在 CI 上跑、本地能跑，八成是这里。

坑 3：用例写得像给人看的，模型却理解不了。"检查页面是否正常"这种句子，模型无所适从。断言要具体到可观察的画面要素："页面出现人脸识别核验提示，且订单号下方显示待验证标签"。写不清楚的断言，先拿 Playground 手测一遍再落 YAML，比闷头改文件快得多。

坑 4：并发开太猛，成本先爆。每个 AI 步骤背后都是一次模型调用，视觉模型按 token 计费时，截图质量、用例步数、并发数相乘才是真实账单。批量回归前先小样本跑一遍，估算单条用例成本再放量。

一个反直觉的提醒：风控核心链路上，慎用定位缓存省钱。缓存命中能省调用，但一旦页面改版而缓存没失效，测的就是一张"旧世界的截图"——对金融测试来说，这种静默失效比失败更危险。缓存适合日常回归这类低风险场景，核心链路建议直接关掉，把"每次都是实时画面"当作硬约束（缓存机制细节见官方说明）。

参数怎么取舍，可以直接抄这张表：

测试场景	模型选择	定位缓存	并发	适用说明
日常回归（批量用例）	轻量多模态模型，如 Qwen-VL 小参数量版	开启，省调用	2~4	跑量大、单条低风险，控制成本优先
风控核心链路（转账/核验/拦截）	定位精度高、上下文长的旗舰视觉模型	关闭	1	截图逐张实时，断言宁严勿松
视觉断言密集（弹窗/提示语/布局核对）	旗舰视觉模型	关闭	1~2	模型"看得细"比跑得快重要
多端一致性比对（App + Web）	各端可用同档位模型	关闭	每端 1	重点是逐端留证，报告可比对

再往前一步：三个可以排进路线图的方向

测试左移。把 YAML 用例挂进 CI，提交即跑。风控规则改动频繁，与其上线前集中补测，不如每次规则配置变更都自动回归一遍核心链路，问题在合并前暴露。

失败智能诊断。报告里已经沉淀了每一步的截图和模型判断。把失败报告喂给 LLM 做二次分析——"这次失败是页面没加载完，还是文案真的变了"——能显著减少人工排查时间，也是把测试资产变成知识资产的捷径。

视觉模型自托管。开源视觉模型（UI-TARS、Qwen-VL 等）可以部署在内网。数据不出域之外，还能用自己的风控页面语料做针对性验证，逐步逼近"懂本行业界面"的专用能力。

写在最后

对金融风控测试来说，AI 自动化测试的价值就一句话：让断言对准用户看到的画面，而不是页面的结构——选择器不碎、三端一套逻辑、视觉盲区补上，这三件事是传统方案怎么优化都补不齐的。

如果你的风控系统也有 Web 后台，现在就可以装一个 Chrome 扩展进 Playground，挑一条最常翻车的拦截流程，用一句自然语言先试一单；跑通了，再把它写成 YAML 收进仓库。

【免费下载链接】midsceneGUI Agent for E2E Testing项目地址: https://gitcode.com/GitHub_Trending/mid/midscene