Midscene实战：AI视觉驱动的安卓UI自动化，告别脆弱定位符

干测试的同学应该都有过这种体验昨天还在正常跑的 UI 自动化今天因为开发在页面上挪了一个控件整个用例就废了。改 xpath、等元素、重新截图、维护数据依赖一遍遍重复消耗时间投入产出比低到让人怀疑自动化到底值不值得做。所以我一直在想UI 自动化最该改的不是等待策略和封装层级而是识别方式本身。直到我把 Midscene 这个 AI 驱动的 UI 自动化框架接到安卓模拟器上用一句自然语言让 AI 完成点击、输入、翻页和校验第一条用例稳定跑通之后我才确定一件事这条路是真的能落地的。这篇内容我按“从入门到实战”的节奏来写适合手工测试想转自动化的同学、正在维护大套脆弱脚本的测试开发以及想节省回归人力、但又不想引入大量定位符维护成本的团队。下面会讲明白 Midscene 的架构原理、安卓端环境搭建、第一份可用脚本、字段校验怎么写、踩坑记录以及怎么把它接进日常回归流程。1. 为什么测试团队要换成“AI 看屏幕”这套思路1.1 传统定位符为什么这么脆弱很多项目里UI 自动化的维护成本大半不是在写用例而是在“改定位符”。resource-id 重构、动态列表导致 xpath 序号错乱、同类型控件使用相同 id、文本变化触发断言失效……只要前端把页面结构动一个层级自动化脚本立刻变成一堆红色失败。在实际项目里我还见过因为开发一句话就把整个底部标签栏换成自定义组件导致所有基于文本的查找全挂掉的情况查了半天才发现是控件属性彻底换了。问题场景传统自动化表现开发改了控件层级xpath 失效脚本崩溃动态组件嵌套resource-id 重复定位不确定验证码 / 混淆视图元素树信息不可信复杂手势操作需要额外封装代码量大定位符思路的底层假设是“屏幕结构是稳定的”但在真实 App 里这个假设经常不成立。于是大家只能不断加等待、加重试、加逻辑判断最后代码量越来越大稳定性却不一定变好。1.2 AI 驱动的方案到底改了什么Midscene 这类 AI 驱动框架的关键是把“从元素树里找控件”换成了“截个图让模型理解整个屏幕”。它不再关心某个控件的 id 叫什么而是通过视觉信息理解屏幕上一个区域是什么按钮、什么输入框。换句话说传统自动化是在“读代码”Midscene 是在“看屏幕”。这正是人类测试员操作 App 的方式我们看到一个页面知道哪里能点、能填然后操作、看结果。这种方式天然有很强的容错性开发改动控件位置不影响识别文案变化多数情况下也不影响操作语义。同一个 task 描述在不同分辨率、不同安卓版本上往往能直接复用。1.3 用自然语言描述操作是什么体验写一条 Midscene 用例本质上是在给 AI 下任务指令。比如下面这段话就是很典型的任务描述打开设置页点击“电池”等待页面加载读取当前剩余电量百分比并告诉我。到了 Web 端任务描述也差不多“打开首页点击搜索框输入‘咖啡’点击搜索读取第一张商品卡片的标题。”整个任务不需要关心电池入口的 resource-id、不需要知道列表索引甚至不需要关心当前是不是横屏。框架自己会规划动作找到入口、点击、等待页面、抽取结果。这种表达方式对手工测试非常友好从“写代码”直接退化成“写需求”新人上手的成本被压得非常低。1.4 这个方案适合谁最适合三类人。第一类是被海量元素定位符折磨的测试开发工程师能把维护成本降一个数量级。第二类是手工测试出身、想转型自动化的同学入手门槛低很多。第三类是测试经理或项目负责人可以用极小成本验证一条核心链路能不能稳定回归。如果你所在团队同时有 Web 和安卓业务Midscene 的优势会更明显因为它两套栈共用一套思路学一遍就能用在两个平台上。2. 先搞清楚 Midscene 在安卓上到底是怎么工作的2.1 核心流水线截图、大模型、动作、执行然后循环在跑脚本之前建议先理解它的工作流水线。简单说它是循环执行四个步骤对当前设备屏幕截图可能还会同时获取无障碍节点信息做辅助把截图和当前任务描述一起交给大语言模型由模型分析“现在应该做什么”模型输出结构化的动作比如点击某个坐标区域、输入文字、滑动、等待、断言框架在设备上执行该动作截取新截图反馈给模型继续下一步循环直到任务完成。可以把这套过程类比成“一个人戴着眼罩操作手机每隔几秒钟被摘下来看一眼然后根据当前看到的画面决定下一步怎么走”。模型是决策中枢截图是感知器官adb 或 Appium 是执行手脚。正因为每一步都基于最新屏幕状态来决定所以它对页面变化的耐受度远高于脚本写死的步骤。2.2 三个关键角色Agent、视觉理解引擎、执行桥接拆开看Midscene 在安卓场景下有三个关键角色Agent负责处理任务指令、维护上下文、决定何时停止。它知道当前任务做到哪一步还需要几步。视觉理解引擎实际调用大模型的模块负责从截图提取页面语义、识别控件位置、判断页面状态。这是整个框架的核心贡献点。执行桥接层负责把模型输出的动作变成真实设备操作。安卓上常见的桥接方式是通过 ADB 工具或 Appium 服务下发指令。从代码角度看大多数人只需要接触 Agent。模型配置、桥接层初始化通常在项目里一次性写好。2.3 模型选择不是越贵越好Midscene 本身不绑定某个模型只要接口兼容 OpenAI Chat 格式就能用。所以在选模型时核心是考虑三个因素理解截图的视觉能力、动作输出的稳定程度、单次调用的延迟和成本。模型类型优势劣势典型场景头部商业视觉模型理解准确、动作稳延迟偏高、按 token 收费核心回归链路中等规格视觉模型成本低、速度快复杂页面偶尔失灵冒烟脚本、日常巡检本地部署开源模型数据不出内网需要 GPU 资源隐私要求高的项目我在实际项目里一般是核心用例用更贵的模型普通巡检用便宜模型跑。两者共用一个 Agent 封装切换成本只是改一个配置。这里有一个容易忽略的点模型输出的“动作”指令本质上也在消耗上下文。如果任务步骤太长建议拆成多个小任务而不是让一个 Agent 跑完整条链路否则模型越到后面越容易“忘记”前面做了什么。2.4 核心 API 的样子从使用角度看核心 API 非常少。大致是初始化一个 Agent然后给它下任务它会返回执行轨迹和执行结果。下面这段用 TypeScript 风格的伪代码描述整个流程import { createAgent } from midscene; const agent await createAgent({ platform: android, deviceId: emulator-5554, model: { provider: openai-compatible, apiKey: process.env.LLM_API_KEY, baseUrl: process.env.LLM_BASE_URL, model: your-model-name, }, }); const result await agent.runTask( 打开设置找到“电池健康”读取当前电池健康度数值。 ); console.log(result.summary);只要你理解了上面这个结构后面所有伪代码都是在这个基础上加加减减。具体到某个版本的 API 名称可能有变化但 Agent 任务描述 返回轨迹的骨架非常稳定。3. 安卓自动化环境搭建模拟器、真机、ADB 一页清3.1 选择设备形态Midscene 的安卓支持本质上是在设备上执行 ADB 或通过 Appium 桥接操作所以你需要一个可以连接的安卓环境。实际项目里可以分成两类模拟器适合 CI 集成可以无头启动、可创建快照缺点是部分硬件场景无法模拟比如蓝牙、相机。真机适合复现真机问题尤其是涉及系统设置、弱网、多任务切换的场景缺点是设备管理麻烦。我个人建议第一套环境优先用模拟器比如可以随意重置、创建干净快照跑崩了大不了重建。等到核心链路稳定以后再找人借几台真机做补充验证。3.2 工具链准备你需要准备的基础工具基本上都是做安卓开发的老朋友Node.js 16 以上版本Android SDK主要是 adb 和 uiautomator用于设备连接与交互一个可用的安卓模拟器或一台开启开发者模式和 USB 调试的安卓手机在真机上建议关掉锁屏和自动休眠避免执行中断。装完以后用adb devices确认能看到设备。如果找不到先查驱动、USB 调试授权、adb 版本兼容性。这里有个常见问题模拟器冷启动以后adb 偶尔会识别不到设备。重启 adb 服务通常能解决adb kill-server然后adb start-server。3.3 初始化项目并安装依赖新建一个 Node.js 项目然后安装 Midscene 相关包。这里我以社区里最常见的方式为例mkdir midscene-demo cd midscene-demo npm init -y npm install midscene不过要注意Midscene 本身迭代很快建议直接去官方仓库看最新安装命令不要把上面的命令当成永恒真相。安装完成以后还需要准备环境变量主要是大模型服务的 API Key 和 Base URL。我会把配置放到.env文件里用dotenv加载避免把密钥写进代码。3.4 连接验证脚本用一个最简单的脚本验证 Agent 能不能正常连接设备和大模型再执行任务const agent await createAgent({ platform: android, deviceId: emulator-5554, model: { provider: openai-compatible, apiKey: process.env.LLM_API_KEY, baseUrl: process.env.LLM_BASE_URL, model: process.env.LLM_MODEL_NAME, }, }); const result await agent.runTask(打开设置告诉我当前“关于手机”里显示的安卓版本号。); console.log(result.summary);如果这一步能跑通说明从“Midscene 到 ADB 到模拟器到大模型”的整条链路是通的。如果报错八成集中在三处设备连接失败、模型接口鉴权失败、设备上弹出了权限确认框没被处理。前两个好解决第三个需要在初始化时把屏幕解锁、跳过弹窗等基础操作前置。总的来说环境搭建最耗时的不是安装依赖而是把设备状态调到“随时可交互”。等这一步做好了后面写用例反而很快。4. 第一个能跑的用例让 AI 去操作设置页4.1 用例设计原则第一次跑千万不要让 AI 做太复杂的多页面任务。推荐一个原则只做“能看到反馈”的单步任务。比如打开设置、点击某个入口、读取一个文本值。这样即使模型行为异常你也能立刻看出来是识别问题还是执行问题。等 Agent 在你的设备和模型组合上表现稳定了再逐步加路径。4.2 一份可以直接跑的任务脚本下面这份脚本是一个很典型的入门用例打开设置进入电池页面读取当前电量。import { createAgent } from midscene; import dotenv from dotenv; dotenv.config(); const agent await createAgent({ platform: android, deviceId: emulator-5554, model: { provider: openai-compatible, apiKey: process.env.LLM_API_KEY, baseUrl: process.env.LLM_BASE_URL, model: process.env.LLM_MODEL_NAME, }, taskTimeoutMs: 60_000, }); const result await agent.runTask( 打开设置页面。找到“电池”入口点击进入。 进入后读取页面上显示的当前电量百分比比如“87%”然后返回给脚本。 ); console.log(执行结果摘要, result.summary); console.log(桌面轨迹详情, result.plan);4.3 逐段解析第一步createAgent把平台指定为 android然后指定 deviceId。这里 deviceId 可以通过adb devices获取。第二步 model 配置指定大模型。第三步taskTimeoutMs是任务级超时我之前没设结果模型卡在一个页面反复尝试直到把所有 token 用完。设一个超时对应的是给 Agent 一个止损点。第四步runTask是整个框架的核心。任务描述有几个技巧明确起点比如“打开设置页面”如果 Agent 不知道起点它可能乱猜明确目标比如“读取电量百分比并返回”中间步骤不要写得太死让 Agent 自己规划路径它反而更灵活。result.summary是模型对整个任务的收尾总结result.plan是每步动作的执行轨迹JSON 形式里面有截图、思考过程、动作坐标。跑完直接看这两个字段基本就能知道 AI 到底干了什么。4.4 运行日志到底怎么看第一次跑通后别急着写下一条用例先把执行轨迹翻一遍。我会重点看三样东西每一步模型是否按照设定目标走有没有走弯路点击坐标和实际控件位置是否偏差过大模型判断“任务完成”的依据是什么是否可能提前终止。比如有一次模型看到“电池”两个字就认为已经打开了电池页面实际上那只是列表入口字样。这类问题通过轨迹一眼就能发现然后就可以在任务描述里加一句“点击进入后确认页面标题包含‘电池’”可以显著减少提前终止的问题。这里有一个来自实测的体会自然语言任务描述不是越详细越好。太细会限制模型灵活性太粗又会让它自由发挥过头。你需要根据自己的模型和设备组合反复调一两轮找到合适的描述粒度。5. 让 AI 写字段校验把“看到了什么”变成硬性断言5.1 为什么传统断言在 AI 场景里不够用UI 自动化里最关键的环节是校验结果。传统做法是等一个元素出现、读取文案、对比预期。但在视觉理解模式下页面里有大量信息是元素树没有的比如图形状态、卡片视觉样式。所以 Midscene 在处理字段校验时思路更接近“看着屏幕问问题”而不是“检查元素是否存在”。这也是很多做 Web 自动化的同学第一次用 Midscene 写断言觉得奇怪的原因——不是去看 DOM而是让 AI 回答一个状态问题。5.2 三类实用的校验写法我在项目中会把校验分成三类分别处理第一类是状态校验询问某个开关或控件的状态。比如“WiFi 开关当前是什么状态开启还是关闭”第二类是数值校验从地址栏、卡片、详情页里抽取具体文本并做比较。比如“页面上显示的剩余电量是多少请只输出数字。”第三类是事件校验验证某个操作后出现了预期反馈比如“点击推送通知后屏幕上是否出现了‘已开启推送’的提示”实现层面Midscene 的 Agent 会给出一个带评分的判断结果通常在 1 到 5 分之间分数表示它对判断结论的置信程度。可以把分数理解成传统断言中的“通过/失败”只不过它多了一个软性置信度。5.3 一个实际校验案例验证移动网络的开关状态假设我们要做一条用例打开“移动网络”设置检查“移动数据”开关是否是开启状态。const result await agent.runTask( 打开设置进入“移动网络”。 找到“移动数据”开关读取它的当前状态。 如果状态是开启校验通过如果是关闭校验失败。 最后直接告诉我结果是通过还是失败。 ); console.log(校验结果, result.summary);这整段其实就把“操作 校验”做进同一个任务里了。从执行轨迹能看到模型是先定位开关然后根据视觉信息判断状态最后给出结论。这样做的好处是你不用为“开关”定义任何定位符校验逻辑本身也嵌在自然语言里非常贴近测试人员的表达方式。5.4 置信度和误判怎么处理我最开始用这类断言时碰到过一个典型问题模型在低概率判断下仍然给出肯定结论。比如屏幕上根本没有“移动数据”开关模型仍然可能在任务里模糊带过。规避方法主要有三个在下任务时严格要求“如果找不到状态直接回答找不到而不是猜测”利用置信度分数设置一个阈值低于阈值的校验一律视为失败在关键链路上加传统方式的二次确认比如截图中裁剪区域比大小、读颜色值。这套组合下来能把误判率压到可接受范围。我的体会是AI 校验适合从“强语义”的内容开始做比如按钮文案、页面标题、明显的开关状态不适合一开始就去校验颜色渐变或者像素级视觉差异。6. 实战踩坑记录模型幻觉、失控滑动、token 燃烧6.1 模型幻觉AI 会“脑补”看不到的内容这是使用 Midscene 过程中最容易遇到的问题。所谓幻觉就是模型在截图中根本没有看到某个控件时仍然做出点击动作或描述出一个不存在的状态。比如屏幕上只有四个按钮模型却点了“第五个”或者页面还在加载中模型已经断言数据加载完成了。应对思路主要有两条一是尽量保证截图信息密度足够避免低分辨率导致模型看不清二是在任务描述里限制想象空间明确要求“请严格基于当前屏幕可见内容操作不要猜测屏幕外内容”。另外把步骤拆短一些也能减少幻觉——步骤越长模型越容易在自圆其说中出错。6.2 截图失真横屏、分辨率、暗色模式安卓端执行时截图质量直接决定识别效果。我踩过的坑包括模拟器窗口分辨率过低导致文字看不清页面进入横屏后模型对整体布局的判断变差深色模式下部分控件对比度不足模型会认为按钮不存在。常规做法是固定模拟器分辨率例如选择 1080x2400 一档横屏场景单独写任务说明暗色模式在测试环境里尽量统一开关。这些都是很小的设置但能明显降低识别失败率。6.3 adb 掉线、设备休眠和弹窗干扰长时间跑任务时adb 连接偶尔会僵死特别是模拟器冷启动后频繁执行。现象是任务突然超时查看设备发现 adb 无响应。重启 adb 服务能恢复但自动化中断的损失已经产生。更稳妥的是在任务循环前做一次adb reconnect并且把设备锁屏超时调到永不。另一个高频问题是系统级弹窗。比如第一次运行 App 时的权限弹窗、系统更新提示弹窗、输入法切换提示。AI 模型看到弹窗可能不知道怎么处理甚至反复点击弹窗区域。我的做法是在 Agent 初始化后先加一个“预处理任务”解除锁屏关闭通知栏点击掉当前所有弹窗。把它当作进入测试场景之前的“清场”动作。6.4 token 成本控制上下文越长越烧钱Midscene 每执行一步基本上都会把当前截图和任务历史发给模型。所以任务越长、步骤越多token 消耗越大。一个 10 步的任务消耗量不是 10 份截图的简单相加因为每次请求还会带上历史动作和之前的截图上下文整体呈上升趋势。控制成本的办法有几种拆分任务让每个 Agent 只负责一段明确的小目标精简任务描述去掉冗余铺垫选择合适的模型档位巡检场景用低成本模型。如果公司有自建模型网关走网关统一计费和限流更省心。6.5 多语言和复杂文本页面的处理如果被测 App 支持多语言模型在中文环境下训练效果最好但切到英文界面后识别质量和描述匹配度会下降。所以建议多语言项目把每一条任务的界面语言写明确比如“当前界面是英文你要找的 Battery 入口可能在页面的下半部分”。复杂文本页面的麻烦在于信息密度高模型容易把状态文本和操作按钮混淆。比如长列表页面里一个可点击的“详情”按钮和一段“详情”文本语义相近。遇到这种页面我会在任务里明说“优先点击按钮样式的元素而不是文本”。这些都是用真金白银换出来的经验最后简单说一句不要因为踩坑就否定整套方案。AI 自动化的容错距离传统自动化确实近很多但在“理解界面”这件事上它也需要一台够清晰的设备和一条描述恰当的任务。7. 把 Midscene 塞进日常回归测试执行策略与结果回传7.1 作为 Playwright 生态的一环很多团队已经用上了 Playwright 来跑 Web 端 UI 自动化Midscene 和 Playwright 的整合是比较成熟的路径。在安卓场景里可以通过 Playwright 的客户端体系管理用例、执行逻辑和结果报告每一条 Midscene 任务相当于一个 Playwright 用例的“步骤单元”。这样做的好处是可以用一套工程体系去管理 Web 和安卓用例测试报告、重试策略、标签筛选都是现成的。实际命令也非常简单典型的做法是在 Playwright 测试文件中引入 Midscene 的 agent 辅助函数再像写普通用例一样组织import { test, expect } from playwright/test; import { runMidsceneTask } from ../helpers/midscene; test(安卓设置-电池信息回归, async () { const summary await runMidsceneTask( 打开设置进入电池页面读取当前电量百分比并返回。 ); expect(summary).toContain(%); expect(summary).not.toContain(未知); });这里用expect做最后的文本断言把 Midscene 的输出结果纳入到 Playwright 的断言体系里。这样可以复用 Playwright 的重试机制、并行策略和测试报告。7.2 用例结构设计怎么组织一套可持续维护的用例集我建议把用例分成三层预检层设备连接、解锁、App 冷启动、首页加载。这层不涉及业务失败直接报环境问题核心链路层登录、首页跳转、关键入口等优先级最高用高质量模型跑扩展场景层非核心页面、低风险页面可以用低成本模型 较长超时。这样一个结构的好处是环境和业务问题能快速区分。设备连接失败不会浪费大模型 token核心链路跑挂后会立刻告警扩展层失败不阻塞主流程。7.3 结果回传与报告Midscene 的执行轨迹是 JSON 格式里面包含每一步的截图、动作、模型思考和判断分数。把这些轨迹接进自己的汇报体系非常简单CI 跑完把 JSON 存成 artifact再按用例维度汇总失败原因。我通常在报告里把失败用例的“最后一张截图”单独放大让开发一眼看到卡在哪里。这里有个细节结果回传时不要把 summary 作为唯一判断依据。summary 是模型总结的语言可能和实际动作轨迹不一致。要判断任务是否真的成功还得看执行轨迹里的步骤数和最终状态。7.4 落地的第一步建议先跑通一条核心链路最后给个实在建议不要想着一次性把所有用例全部迁到 Midscene。先选一条最核心的业务链路比如“登录 - 进入首页 - 打开搜索 - 输入关键字 - 查看结果”把它跑通并稳定两星期再决定要不要扩大范围。跑通一条链路的收获不仅是一条稳定用例更是帮你验证设备环境、模型组合、token 成本和执行稳定性这套体系。这套体系没问题后面推广只是复制粘贴和改任务描述的事。