当选择器全部失效之后：我为什么转向 AI 视觉自动化测试

当选择器全部失效之后我为什么转向 AI 视觉自动化测试【免费下载链接】midsceneGUI Agent for E2E Testing项目地址: https://gitcode.com/GitHub_Trending/mid/midsceneMidscene.js 是一款基于视觉 AI 与自然语言驱动的跨平台 UI 自动化测试工具——它不解析 DOM、不维护选择器只凭一张屏幕截图理解界面你只需用一句大白话描述想做什么剩下的定位、点击、输入和校验都交给它完成。这篇文章会从一个测试工程师的真实视角讲清楚它解决的是什么问题、怎么在十分钟内跑通第一段脚本以及落地前值得算清的三笔账。先聊聊那段让人想转行的日子如果你维护过一套传统 UI 测试用例下面这些场景应该不陌生产品经理说把登录按钮改个样式前端顺手重构了 DOM你追着更新了十八条xpath第二天又碎了一地页面上一排只有图标没有文字的按钮可访问性树里全是空白测试脚本根本不知道该点哪个遇到canvas渲染的图表、跨域 iframe 里的组件、或者压根没有 DOM 概念的原生 App传统工具直接宣告无能为力更憋屈的是样式错位、颜色不对这类看起来有问题的 bug结构性断言完全发现不了。这些问题不是某个框架的锅而是依赖页面结构这条路线本身的局限。结构是脆弱的也是残缺的——它只描述了这里有什么元素却描述不了这个界面看起来对不对。Midscene.js 的解题思路跳过 DOM直接看图Midscene.js 换了一条完全不同的路线把整张屏幕截图直接喂给多模态视觉模型让模型像人一样看界面、理解界面再根据你的自然语言指令去定位元素、执行动作。翻译成大白话就是它关心的不是代码结构而是像素本身。你写点击右上角的设置图标它就在截图里找到那个图标你写检查表单是否校验通过它就盯着截图判断错误提示有没有出现。这套逻辑带来的直接好处有三点对比维度传统选择器方案Midscene.js 视觉方案维护成本每次 UI 改动都要同步更新选择器界面变了只要语义不变描述就能继续用元素覆盖只认语义化标记图标按钮、canvas、iframe 容易失明人眼可见的一切都能作为操作目标断言能力验证节点是否存在验证颜色、布局、高亮、渲染状态等用户真正看到的东西核心 API 也很直观基本可以分成两派一类是规划并交互的aiAct给它一个目标它会自己拆步骤、执行到底另一类是即时交互的aiTap、aiInput等一次只做一件事。具体用法后面实战部分会看到。十分钟上手从安装到跑通第一段脚本先说结论不用写一行代码也能先跑起来。最简单的方式是安装 Chrome 扩展在任意网页的侧边栏里直接输入自然语言指令浏览器就会照做。想走脚本化路线的话步骤如下确认 Node.js 版本在20.19、22.12或24CLI 依赖的工具链对旧版本不友好安装命令行工具npm i -g midscene/cli在运行目录建一个.env填入模型配置MIDSCENE_MODEL_BASE_URLhttps://your-model-gateway.example.com/v1 MIDSCENE_MODEL_API_KEYsk-xxxx MIDSCENE_MODEL_NAMEqwen2.5-vl-72b MIDSCENE_MODEL_FAMILYqwen写一个 YAML 脚本。以在线教育平台完成课程报名为例page: url: https://demo-edu.example.com tasks: - name: 完成课程报名 flow: - ai: 进入课程中心页面 - ai: 在搜索框输入数据结构然后点击搜索 - ai: 打开第一门课程的详情页 - ai: 点击立即报名按钮 - aiAssert: 页面出现报名成功提示一条命令跑起来midscene ./edu-course.yaml执行过程中命令行会实时输出进度跑完自动生成一份可视化报告。如果你想把整个仓库拿下来研究可以用git clone https://gitcode.com/GitHub_Trending/mid/midscene拉取源码monorepo 结构下packages/web-integration/、packages/android/、packages/ios/等目录对应着各平台的实现。第一次实战用一句话让浏览器自己干活装好之后就可以试试 JavaScript SDK 的写法了。下面这段代码基于 Playwright完成一次在线问诊预约import { AgentOverPlaywright } from midscene/web; const agent new AgentOverPlaywright(page); // 规划式交互自己拆步骤、自己执行 await agent.aiAct(在科室列表中选择呼吸内科打开今天可预约的医生); // 提取结构化数据 const doctors await agent.aiQuery Array{ name: string; title: string; rating: number } (当前页面展示的医生列表{name: string, title: string, rating: number}[]); // 校验界面状态 await agent.aiAssert(预约确认页显示医生姓名和就诊时间);注意aiAct和aiTap这类即时交互的区别aiAct把提示词当成工作流允许 AI 连续规划多步、自己处理中间的分支而aiTap(预约挂号按钮)这类 API 只把提示词当成某个元素的描述点一下就结束不会擅自多做别的事。写脚本时想清楚我要的是一个目标还是一个动作能省掉很多调试时间。那些传统工具够不着的角落选择器方案最大的软肋是无结构可依的场景。Midscene.js 因为只看截图这些场景反而成了它的主场纯图标按钮没有文字、没有 aria-label人眼能认出来视觉模型就能认出来canvas 绘制的图表与游戏整个界面就是一块画布DOM 里什么都没有但截图里有全部信息跨域 iframe同源策略拦得住脚本拦不住看一眼原生 App 与桌面应用根本没有 DOM 和选择器这回事但一定有屏幕。这也是它能同时覆盖 Web、Android、iOS、HarmonyOS 和桌面端的原因——只要能截到图、能回放操作剩下的理解工作都交给视觉模型。各平台的接入文档可以在apps/site/docs/zh/platforms/下找到。一份脚本五种设备跨平台自动化测试怎么做到跨平台不是五套工具而是同一套 API 背后的五个适配层平台底层通道源码位置WebPlaywright / Puppeteerpackages/web-integration/src/playwright/Androidadb scrcpy 投屏packages/android/src/iOSWebDriverAgentpackages/ios/src/HarmonyOShdc 工具链packages/harmony/src/桌面端原生键鼠控制Windows / macOS / Linuxpackages/computer/写起来几乎一样。比如用同一套 YAML 思路驱动 Android 设备做地图导航android: deviceId: s4ey59 # 通过 adb devices 获取 tasks: - name: 地图导航 flow: - ai: 打开地图应用 - ai: 在搜索栏输入杭州西湖然后点击搜索按钮 - ai: 点击第一个搜索结果进入详情页 - ai: 点击路线按钮进入路线规划页面 - ai: 点击开始按钮开始导航这种一套心智、多端复用的模式特别适合移动端和 Web 端都需要回归、又不想维护两套框架的团队。断言与取数校验用户真正看到的东西传统断言的局限在于只能证明元素存在而aiAssert可以直接校验视觉事实await agent.aiAssert(登录按钮处于不可点击的置灰状态); await agent.aiAssert(页面顶部的警告横幅是红色);配合aiQuery还能把界面里的信息直接抽成结构化数据比如医生列表、课程价格、订单明细省掉定位 取值 清洗一长串样板代码。对于这个问题是或否的判断还有返回布尔值的aiBoolean可用。整套界面理解类 API 只读不改天然适合做巡检和数据核对类的任务。调试、报告与翻车现场纸上谈兵容易真跑起来总会遇到状况。几个实用经验先用 Playground 试指令在交互式环境里把每条自然语言指令验证通过再固化进脚本能省掉大量试错。想驱动你正在用的这个浏览器可以用 Bridge 模式让本地脚本连接已打开的 Chrome复用现有登录态和插件环境给指令加业务上下文通过agent.setAIActContext()补充遇到 Cookie 弹窗先关掉这类背景能明显减少 AI 的自由发挥批量跑的时候用上 CLI 的并发与重试--concurrent 4并行执行互不依赖的脚本--retry 2缓解大模型偶发输出不稳定导致的失败--continue-on-error让单个失败不拖垮整批截图会累积开销官方文档里有缓存策略apps/site/docs/zh/caching.mdx命中缓存能显著缩短执行时间建议默认开启。跑完生成的报告会把每一步的操作、截图和时间轴拼在一起复盘失败用例时非常直观。落地前把这三笔账算清楚把工具引入团队之前有三个问题值得认真想第一模型选谁、成本多少。Midscene.js 依赖具备 UI 定位能力的多模态模型官方支持 Qwen、豆包 Seed、GLM-4V、UI-TARS 等其中也有可以本地自部署的开源模型。每条指令背后都是一次模型调用页面越复杂、步骤越多token 消耗越大。对数据敏感的场景自托管模型是值得考虑的路子相关取舍可以看apps/site/docs/zh/model-strategy.mdx。第二稳定性怎么兜底。视觉方案偶尔会出现这次认得、下次认不得的波动。应对手段有三层复杂任务开deepThink任务拆解更稳、目标元素小或容易混淆时开deepLocate定位更准、CI 里配置重试与失败后的人工复核。它替代的是维护选择器的体力活而不是理解业务的脑力活。第三哪些用例适合视觉方案。我的建议是凡是人眼能判断对错的场景界面回归、跨端一致性、无结构元素、视觉缺陷都值得迁过来凡是纯逻辑、无界面的校验传统断言依然更便宜、更确定。两种手段搭配而不是互相替代。写在最后从追着选择器跑到用一句话描述目标改变的不仅是写用例的方式更是思考测试的方式——你开始关心用户看到了什么而不是DOM 里有什么。如果你也想试试推荐从克隆仓库git clone https://gitcode.com/GitHub_Trending/mid/midscene开始装上扩展、配好模型找一个你维护的页面写下第一条自然语言指令。也欢迎在评论区聊聊你手头最想摆脱选择器的那个用例是什么我猜大概率是 canvas或者某个连文案都没有的图标按钮。【免费下载链接】midsceneGUI Agent for E2E Testing项目地址: https://gitcode.com/GitHub_Trending/mid/midscene创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考