从 Monkey 随机点击到 GPT-4V 看懂界面，这条路走了两年，踩过不少坑，也找到了几个真正值得用的场景。本文是工程师视角的实操选型指南，不是技术综述。

我最近被问到最多的问题是：”视觉大模型能替代 UIAutomator 吗？”

答案是：现在还不能，但有些场景它已经比 UIAutomator 好用很多了。

这篇文章不讲技术综述，只讲安卓测试工程师视角下，视觉大模型（VLM）能帮你解决什么具体问题、不能解决什么、以及手头有哪些工具可以直接用。

和网上大多数”VLM+测试”的文章不同，这里不会列一堆论文数据然后得出”很有潜力”的结论。我想讲的是：在真实项目里，这些工具在哪个环节接入、带来了什么改变、以及为什么有的场景根本不值得用。

传统自动化的三堵墙

在说 VLM 之前，先说清楚我们在解决谁的问题。

安卓自动化测试卡了多年的地方，基本集中在三个死角：

第一堵墙：UI 改了，脚本挂了。 XPath 和 resource-id 是和界面强耦合的。哪怕只是把按钮从屏幕左移到右，find_element_by_id("btn_login") 照样可能失败。我维护过一个有 300+ 条用例的测试套件，每次大版本改版，光修脚本就要花两天——而那些脚本本身根本没有任何业务逻辑，全是定位符。

第二堵墙：复杂 UI 探索不到。 Monkey 靠随机点击，Stoat 靠状态机建模，遇到嵌套滚动列表、动态加载的弹窗、需要特定顺序操作才能触发的深层路径，覆盖率就上不去。有个 Bug 在一个电商 App 的”收货地址+优惠券叠加”场景下必现，Monkey 跑了三天没触发，用户反馈才发现。

第三堵墙：视觉断言做不了。 “登录按钮是不是蓝色”、”购物车右上角的数字是不是 3″——这类视觉状态，传统框架要么截图像素比对（脆弱），要么完全不验证。

VLM 把这三堵墙的底层逻辑改了：它不是通过 ID 找元素，而是看懂屏幕上显示的是什么。

[配图建议：传统 ID 定位 vs VLM 视觉理解的对比示意图，左侧是 XML hierarchy，右侧是屏幕截图被 VLM 理解为语义区域]

三条技术路线，先搞清楚选哪条

目前做安卓测试的 VLM 方案，分化成了三条路线：

纯视觉方案接近人类感知，但每一步都要截图+调 API，跑 100 个测试用例可能要花几十分钟，也要花几十块 API 费用。放进 CI/CD 流水线不现实。

结构化 UI 方案反过来，速度快、成本低，但依赖 Accessibility API——遇到自定义 View、游戏引擎渲染的 UI、或者故意屏蔽 Accessibility 的 App，就抓不到元素。

混合方案是目前学术界和工程实践都在收敛的方向：常规情况走结构化 UI，遇到复杂场景按需调 VLM。

具体到 10 个场景，哪些值得用

场景 1：动态加载的弹窗和权限提示

App 启动后随机弹出”开启通知权限”、”允许位置访问”、”评分弹窗”——这类弹窗没有固定 ID，出现时机不可预测。

传统做法是枚举所有可能的弹窗 ID，维护一个”弹窗处理器”，每次新版本上线都要更新。我最多的时候维护了 17 个弹窗 ID，还是会漏。

VLM 方案：截图 → 让 VLM 判断”当前屏幕是否有弹窗需要关闭，如果有，点击关闭按钮”。一行自然语言指令，不需要维护枚举表。

在实际项目里用这个思路处理”双因素认证提示是否出现”，比之前维护 5 个 XPath 的方案稳定很多。工具层面，Maestro 的 assertWithAI 命令正好为这类场景设计，截图发给 LLM 做自然语言断言，可以直接上手试。

场景 2：复杂 UI 状态的视觉断言

“购物车图标右上角显示数字 3″——像素级别的数字，用 UIAutomator 读 text 属性未必能拿到（很多购物车角标是用 Canvas 画的）。

VLM 的断言写法：

# Maestro assertWithAI 示例
- assertWithAI:
condition: >
购物车图标右上角显示数字 3，
且数字背景为红色圆形

断言失败时，LLM 会返回具体的失败原因，不是冷冰冰的”expected 3, got null”。这在排查问题时省了不少时间。

场景 3：深层路径的 GUI Fuzzing

这是我觉得 VLM 目前最有实际价值的场景之一。

VLM-Fuzz 的做法：用静态分析提取 AndroidManifest 和运行时 UI hierarchy XML，遇到复杂 UI 布局时按需调用 VLM 推理”下一步最值得点哪里”。在 59 个 App 的基准测试中，类覆盖率比最佳基线高 9.0%。

在真实 App 的 Bug 发现上，VLM-Fuzz 做了两轮测试：

• arXiv 实验（80 个 Google Play App）：检测到 208 个独特崩溃，来自 24 个 App，全部确认为真实 Bug，已报告给各 App 开发者
• Springer 2026 版本（另一轮实验）：在 50 个 App 中诱发崩溃，12 个 App 里的 52 个崩溃被人工确认为真实 Bug

Monkey 跑同样的 App，能跑出多少崩溃？大部分时候远少于此，因为随机点击很难触达需要特定操作序列才能到达的深层路径。那个”收货地址+优惠券叠加”的 Bug，如果当时有 VLM-Fuzz，很可能早一两个版本就发现了。

场景 4：自然语言驱动的 E2E 测试

Droidrun 的使用方式是这样的：

# 不需要写 find_element、click、swipe
# 测试意图直接用自然语言描述
from droidrun import DroidAgent

agent = DroidAgent(
    goal="打开抖音，搜索家常菜，收藏第一个视频",
    llm_provider="anthropic"
)
await agent.run()

Droidrun 在 AndroidWorld 基准（116 个真实 Android 任务）上的表现有过显著演进：

• 早期版本达到 63.0% 成功率，是当时移动 Agent 的最高水平
• 最新版本通过引入”Manager-Executor 动态反馈循环”架构，成功率已提升至 91.4%

91.4% 的成功率意味着冒烟测试和探索性测试已经够用。它的架构思路是：Manager 创建高层任务，Executor 执行一个具体动作，Manager 立刻基于执行结果重新评估并调整计划——相比固定的 planner-executor 模式，这个动态循环对 UI 变化的适应性强很多。

场景 5：跨 App 的工作流测试

测”分享到微信，再从微信跳回 App 完成购买”这类跨 App 流程，传统自动化要分别维护两套脚本，切换 App 时还要处理 Activity 跳转。

阿里巴巴 X-PLUG 团队的 Mobile-Agent-v2 为跨 App 复杂任务设计，多 Agent 协作架构——Planning Agent 负责任务分解，Decision Agent 负责单步决策，纯视觉感知不依赖系统 API，天然支持跨 App 场景。有电商团队用它打通”商品详情页分享到微信，再从微信跳回 App 完成购买”这条链路，效果比维护两套 Appium 脚本稳定——这种跨 App 场景正是纯视觉方案相对于 Accessibility API 方案的天然优势所在。

场景 6：相似 App 之间的测试用例迁移

这个场景很多人没想到，但很实际：同一家公司的 iOS 和 Android 版本、同类竞品、或者同一 App 的多个渠道包（比如华为版和小米版），功能基本一样，但底层实现不同。

传统做法是把测试用例从头写一遍。

ReuseDroid 的做法是：离线阶段用 VLM 分析源测试用例，提取”核心操作骨架”（忽略具体控件 ID）；在线阶段在目标 App 里执行，遇到 UI 差异时用 Active Feedback 机制动态校正。在 578 个迁移任务上达到 90.3% 的成功率，比之前最好的 mapping-based 方案高了 318%。

维护多渠道包的团队，这个方向值得重点关注。

场景 7：无障碍功能的自动化测试

Google 把 Gemini 集成到 Android TalkBack 之后，系统无障碍层能理解图像内容。这对测试有一个直接价值：可以用视障用户依赖的同一套 AI 来测试无障碍功能。

以前测 content description 是否合理，要靠人工用 TalkBack 听——”这个按钮的描述是’图片’还是’提交按钮'”。现在可以用 Gemini 视觉模型自动评估：给截图，让模型判断”每个可交互元素是否有有意义的无障碍描述”，一次性覆盖整个页面。

场景 8：UI 改版后的回归验证

App 做了设计改版，怎么验证新版本和旧版本在视觉上符合预期？

截图像素对比（传统方案）的问题是：哪怕只是字体颜色微调，像素差异率就会超过阈值，产生大量误报。我经历过一次改版，像素对比方案报了 400+ 个”差异”，人工确认后真正有问题的只有 3 个。

VLM 方案：不比像素，比语义。

断言：新版登录页是否包含——
  Logo、用户名输入框、密码输入框、
  登录按钮、忘记密码链接

这种断言对布局细节调整不敏感，只验证关键元素的存在和语义。Maestro assertWithAI 的视觉回归模式支持这种方式，400 个误报的问题可以直接消掉。

场景 9：多语言版本的 UI 验证

App 出海版本测试的噩梦：阿拉伯语是 RTL 布局，日语字符可能撑破按钮，德语单词普遍比英语长 30%。

传统做法：每种语言维护一套截图基准，肉眼对比。

VLM 方案：截图给模型，直接问”按钮文字是否被截断”、”页面布局是否出现元素重叠”——模型看图判断，不需要维护多套语言基准。

场景 10：App 首次安装的引导流程测试

新用户引导（Onboarding）流程是 VLM 特别适合的地方：通常只走一次，流程长（5-10 步），每步有不同的 UI 状态，传统脚本容易因为动画时序问题失败。

腾讯 QQ 游戏 Y-Lab 的 AppAgent 设计里有一个”探索阶段”：Agent 先自主走一遍 App 的功能，生成操作知识库文档；之后在”部署阶段”，把这个文档当作测试用例的基础，让 Agent 按知识库复现操作。在 10 个应用、45+ 个任务的测试里，AppAgent 在所有评估指标上优于 MobileAgent，首次安装引导这类一次性流程是它表现最稳定的场景之一。

[配图建议：AppAgent 两阶段流程示意——探索阶段生成知识库，部署阶段参考知识库执行任务]

不值得用 VLM 的场景

说了这么多”能用”，也要说清楚”不值得用”：

高频回归测试（CI/CD 流水线）：每次 commit 跑几百个用例，纯视觉方案的 API 成本和等待时间都不可接受。这里还是用 UIAutomator + Espresso，稳定、快、零 API 成本。

元素精确定位：需要精确点击固定坐标、或者操作严格按像素对齐的场景，VLM 的输出本质上是概率推理——它”看图猜位置”，而不是读 XML 坐标。在需要像素级精度的场景，find_element_by_id 更可靠。

游戏 App 测试：Unity、Unreal 渲染的 UI 本来就没有 Accessibility API，纯视觉方案在这里其实有优势，但游戏测试本身的特殊性（帧率、物理引擎、实时状态）让 VLM 目前还很难发挥。

工具横向对比

我现在的工具选择

如果你刚开始在安卓测试里引入 VLM，我的建议是这样的优先级：

第一步，先给现有框架加 AI 断言。 Maestro assertWithAI 不需要改变测试架构，直接在现有用例里加一行，成本最低。挑 5 个最难写断言的用例试试，感受一下”用自然语言描述期望状态”比”写 XPath + 像素比对”省多少事。

第二步，用 Droidrun 做冒烟测试。 把核心业务流程用自然语言描述出来，让 Droidrun 跑一遍。目前 91.4% 的成功率意味着大部分情况能跑通，失败的用例再手动处理。

第三步，跑 VLM-Fuzz 做周期性 Bug 扫描。 不要每天跑，选每周一次或者大版本发布前跑一遍，重点是找那些随机点击触达不到的深层崩溃。

AppAgent 和 Mobile-Agent-v2 目前在实验阶段，作为探索性测试工具用，不放进 CI。ReuseDroid 是个值得持续关注的方向，特别是维护多渠道包的团队，测试资产复用的价值会很大。

从 Monkey 的随机点击到 VLM 的语义理解，安卓测试的底层能力确实变了。但工程实践的本质没变：找到瓶颈在哪里，用最合适的工具解决它，而不是为了用新技术而用新技术。

视觉大模型让测试工程师可以用”描述意图”代替”写脚本”——这件事在特定场景里是真实的效率提升，但 CI 流水线还是要靠 UIAutomator 撑着。

知道边界在哪里，才算真正会用这个工具。

你在安卓测试里遇到过哪些 VLM 搞不定的场景？或者有没有在用某个工具效果出乎意料的好？欢迎留言，我们一起把这份”坑的地图”补完整。