金融风控测试老漏检用 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. 一端一套脚本。同一条风控规则银行 AppAndroid/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 KeyMIDSCENE_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 报告每一步做了什么、截图是什么、耗时多少、断言结果如何全部按时间轴铺开复盘和留证都很方便。报告长这样如果想跳过项目搭建、直接在浏览器里试PlaygroundChrome 扩展形态是最快的入口打开被测页面在侧边栏输入自然语言指令AI 的规划、定位、点击过程实时可见先验证想法再固化成 YAML。再进一步风控规则要同时覆盖 App 端的话Android Playground 可以在浏览器里直接连真机投屏执行界面见Android 平台文档还有一类更贴风控真实环境的玩法桥接模式Bridge Mode。它让本地脚本直接接管你正在用的桌面 Chrome——复用真实的登录态、cookies 和企业代理脚本和人工可以交替操作同一条会话。风控系统的测试环境往往要过一堆认证这条人肉登录、脚本接管的路径能省掉大量环境折腾原理见桥接模式文档落地踩坑与配置取舍先说四个最常见的坑坑 1Node 版本太旧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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 金融风控测试老漏检？用 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. 一端一套脚本。同一条风控规则银行 AppAndroid/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 KeyMIDSCENE_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 报告每一步做了什么、截图是什么、耗时多少、断言结果如何全部按时间轴铺开复盘和留证都很方便。报告长这样如果想跳过项目搭建、直接在浏览器里试PlaygroundChrome 扩展形态是最快的入口打开被测页面在侧边栏输入自然语言指令AI 的规划、定位、点击过程实时可见先验证想法再固化成 YAML。再进一步风控规则要同时覆盖 App 端的话Android Playground 可以在浏览器里直接连真机投屏执行界面见Android 平台文档还有一类更贴风控真实环境的玩法桥接模式Bridge Mode。它让本地脚本直接接管你正在用的桌面 Chrome——复用真实的登录态、cookies 和企业代理脚本和人工可以交替操作同一条会话。风控系统的测试环境往往要过一堆认证这条人肉登录、脚本接管的路径能省掉大量环境折腾原理见桥接模式文档落地踩坑与配置取舍先说四个最常见的坑坑 1Node 版本太旧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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考