之前我们讨论了 LLM 如何通过"读"GUI 树来操作手机。但如果 App 用了 WebView、Canvas 或 Flutter 自渲染，GUI 树就残缺了——LLM 岂不是"半盲"？另一边，Android 上写了 200 条测试脚本，iOS 还得再写一遍？这篇文章拆解两个突破性方向：让 AI 直接"看"截图找 Bug，以及通过"意图提取"实现一套测试多端运行。

1、先说结论

多模态 LLM 可以直接"看"App 截图，发现传统工具完全发现不了的非崩溃功能 Bug——这是测试 Oracle 从"仅 Crash 检测"到"功能正确性验证"的关键一步。
跨平台测试迁移的本质不是"翻译脚本"，而是"传递意图"——LLM 从源端脚本中提取业务意图，然后在目标端从零重建操作序列，天然绕过 UI 差异。
这两个方向加在一起，覆盖了前文遗留的两大挑战：GUI 树残缺时怎么办和跨端怎么复用。

注：本文有 AI 辅助创作，确实排版和阅读都比纯手工更好。

2、为什么需要"看"而不只是"读"？

前面介绍的 GPTDroid、DroidAgent 等方法都依赖一种输入：GUI 树——Android 的 UIAutomator dump 或 iOS 的 XCUITest snapshot 提供的视图层次结构 XML/JSON。它包含每个控件的类型、文本、位置和 ID。

但现代 App 里大量场景的 GUI 树是残缺甚至不可用的：

场景	GUI 树的问题
WebView 内嵌网页	原生 GUI 树只看到一个大的 `WebView` 节点，内部的按钮、文本、图片全部不可见
Canvas 自定义绘制	图表、游戏界面、自定义动画——像素直接画在 Canvas 上，GUI 树中无对应节点
Flutter 自渲染	Skia 引擎绕过原生视图体系，Semantics Tree 信息通常很稀疏
地图 / 视频播放器	SurfaceView / TextureView 渲染，GUI 树只有一个"黑盒"节点

更根本的问题是：即使 GUI 树完整，它也不包含"视觉语义"。

GUI 树告诉你"这里有一个 ImageView"，但不告诉你"这张图片显示的是一双红色运动鞋还是一片灰色的加载失败占位图"。很多功能缺陷恰恰需要"看懂"视觉内容才能发现：

商品图片加载失败，显示灰色占位图——ImageView 在 GUI 树中存在且没有报错
深色模式下白色文字变成了深灰色，几乎看不清——GUI 树不记录颜色
两个商品卡片显示了完全相同的图片（数据重复）——GUI 树只知道有两个 ImageView
弹窗遮挡了"确认支付"按钮——GUI 树记录了两者的坐标，但不会判断"遮挡"

这些问题，人眼一看就知道，但 GUI 树里完全没有线索。

截图比 GUI 树更"诚实"。 GUI 树是声明式的——它告诉你"应该"有什么控件；截图是表现式的——它告诉你用户"实际"看到了什么。当两者不一致时，截图才是真相。

3、VisionDroid：让 AI “看见” Bug

3.1、核心思路

2024 年的 VisionDroid[2] 提出了一个直觉很强的方案：

不读 GUI 树，直接让多模态 LLM（MLLM）看 App 截图，判断页面上有没有 Bug。

就像把一个有经验的 QA 工程师放在 App 面前——不需要查看代码或 XML，只要"看"屏幕就能发现很多问题。

3.2、技术流程拆解

VisionDroid 的工作流分三步：

3.2.1、步骤一：自动探索，收集截图

先用已有的 GUI 遍历工具（如 DroidBot）自动操作 App，在每个页面状态都截一张图。这一步完全不依赖 LLM——就是传统工具的"体力活"。

3.2.2、步骤二：独立视图属性提取

对每一张截图，VisionDroid 提取每个可视组件的属性，包括传统的结构化信息和 MLLM 生成的视觉描述：

1
2
3
4
5
6
7
8


{
  "component_id": 3,
  "type": "ImageView",
  "bounds": [10, 200, 350, 500],
  "text": "",
  "content_description": "Product image",
  "visual_description": "一双红色耐克运动鞋的产品照片，白色背景"
}

关键在 visual_description——这是 MLLM 通过"看"截图中该区域生成的自然语言描述。它把纯视觉信息转化为了可供逻辑推理的文本。

为什么要这样做？直接把整张截图扔给 MLLM 问"有没有 Bug"太粗糙了——MLLM 不知道该关注什么。VisionDroid 的策略是先拆解、再审查：先把截图拆解为若干组件，为每个组件生成独立的属性描述，然后让 MLLM 在充分的上下文中进行系统化审查。

3.2.3、步骤三：缺陷推理（Bug Reasoning）

将完整截图 + 所有组件的结构化属性列表一起交给 MLLM，Prompt 引导它像 QA 工程师一样逐项审查：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


请作为一个资深 QA 工程师，检查以下 App 页面。
重点关注以下类型的问题：
1. 文本显示异常（乱码、截断、重叠、不可读）
2. 图片加载异常（灰色占位图、错位、重复）
3. 布局问题（控件重叠、溢出屏幕、对齐不正确）
4. 数据一致性（重复数据、空数据、矛盾信息）
5. 功能状态异常（按钮状态不正确、导航错误）

[截图]
[组件属性列表]

如发现问题，请描述：问题位置、问题类型、严重程度、判断依据。

3.3、能发现什么样的 Bug？

VisionDroid 最大的突破在于：它是第一个能自动发现非崩溃功能性缺陷的移动端测试工具。

什么叫"非崩溃功能性缺陷"？就是 App 没有闪退、但功能不正确或用户体验有问题的 Bug。在真实的线上环境中，这类 Bug 往往比 Crash 更多、更隐蔽、对用户影响更大。

VisionDroid 在 20 个流行 Google Play App 上的实验中发现了 29 个此前未知的非崩溃功能缺陷，其中 19 个被开发者确认为真实 Bug。缺陷类型包括：

数据重复显示：商品列表中同一个商品出现了两次
图片加载失败：商品图片显示为灰色占位图，但没有报错
文本截断：商品名称只显示"苹果 iPho…"，关键信息丢失
布局重叠：价格文字和"已售罄"标签叠在一起，都看不清
主题适配异常：深色模式下某些文字变得几乎不可见

这 29 个 Bug 是所有传统方法（Monkey、Stoat、GPTDroid）都无法发现的——因为它们的 Oracle 仅限于 Crash 检测，而这些 Bug 不会导致 Crash。

4、AUITestAgent：从一句话需求到完整测试报告

4.1、更进一步的全自动化

VisionDroid 解决了"能不能看懂"的问题，但它仍然需要先用别的工具做 GUI 探索。AUITestAgent[3] 更进一步，实现了从自然语言需求到完整测试执行再到结果判定的端到端全自动化。

一个典型场景：

QA 输入一句话：

1

验证用户能否通过手机号注册新账户，注册成功后应跳转到首页。

AUITestAgent 自动完成：

打开 App → 识别到欢迎页 → 找到"注册"入口并点击
在注册页面识别手机号输入框 → 输入 13812345678
点击"获取验证码" → 等待验证码输入框出现
输入验证码 → 点击"注册"按钮
截图 → MLLM 分析当前页面是否为首页
输出测试报告：✅ 通过（附截图证据链）

4.2、操作-观察-推理的闭环

AUITestAgent 的核心不是"生成所有步骤然后执行"，而是一个持续的闭环：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


              ┌────────────────────┐
              │  自然语言测试需求   │
              └─────────┬──────────┘
                        │
                        ▼
                ┌──────────────┐
        ┌──────│  规划下一步    │◀──────┐
        │      └──────────────┘       │
        ▼                              │
   ┌─────────┐                   ┌──────────┐
   │ 执行操作 │                   │ 截图+分析 │
   │ (点击等) │──────────────────▶│ (MLLM)   │
   └─────────┘                   └──────────┘
                                  是否符合预期？
                                  需要调整计划？

每执行一步后，AUITestAgent 截取当前屏幕，用 MLLM 分析：执行结果是否符合预期？如果不符合（比如弹出了意料之外的权限请求弹窗），动态调整后续计划。这种反应式执行使它能应对各种运行时不确定性。

4.3、实验效果

在注入 Bug 的 App 上，AUITestAgent 达到了 90% 的缺陷检测召回率——也就是说，10 个故意植入的 Bug 中，它能自动找到 9 个，并正确判断测试通过/失败。

这意味着 AUITestAgent 不仅能"走完流程"，还能判断结果对不对——这是从"自动化操作"到"自动化测试"的本质区别。

4.4、视觉理解 vs. GUI 树解析：什么时候用什么

两种方式各有所长，最佳方案是互补使用：

维度	GUI 树解析	视觉理解（截图）
对 WebView 的支持	❌ 不可见	✅ 能看到渲染结果
对 Flutter 的支持	⚠️ 依赖 Semantics	✅ 不依赖标注
对 Canvas 绘制的支持	❌ 不可见	✅ 像素级可见
检测布局/颜色问题	❌ 无视觉信息	✅ 直接可见
定位精度	✅ 精确坐标	⚠️ 可能有偏差
处理速度	✅ 快	⚠️ 慢（需推理）
Token 消耗	✅ 低	⚠️ 高（图片编码）

实际推荐：精确的控件操作用 GUI 树定位，视觉一致性和功能正确性审查用截图。不必每一步都做视觉分析，在关键页面节点（登录后首页、搜索结果页、订单确认页、支付完成页）做视觉快照审查即可。

5、跨平台测试迁移：迁移"意图"而非"脚本"

5.1、老问题的新视角

跨平台测试复用是工程界的经典痛点。假设你的购物 App 有四个版本：

版本	技术栈	测试框架
Android 原生	Kotlin + Compose	Espresso
iOS 原生	Swift + SwiftUI	XCUITest
Flutter 跨端	Dart	Integration Test
微信小程序	WXML + JS	Miniprogram Automator

四个版本的业务逻辑完全相同，但要维护四套独立的测试代码。功能变更时要改四遍。遗漏一处，下次回归就有盲区。

传统的"测试迁移"思路是控件映射——在目标平台上找到与源平台"等价"的控件。但这个思路有一个致命缺陷：

同一个功能在不同平台的 UI 实现可能完全不同。

同样是"搜索商品"，Android 上可能是首页顶部一个可直接输入的搜索栏（EditText），iOS 上可能是一个搜索图标（UIButton），点击后跳转到独立的搜索页面。操作步骤不同、控件数量不同、页面结构不同——控件怎么"映射"？

更极端的情况：Flutter 版本用了完全自定义的搜索组件，其 Semantics Tree 中甚至可能连 TextField 标签都没有。控件映射彻底失效。

5.2、IntentDroid：换一个根本性的思路

2025 年发表于 ISSTA 的 IntentDroid[1] 提出了一个优雅得多的方案：

不要在目标平台上找"等价控件"。先从源端脚本中提取"业务意图"，再让 LLM 在目标平台上从零推导出实现该意图的操作序列。

用翻译做类比：

控件映射 = 逐字翻译：“把’点击 search_bar’翻译成’tap SearchTextField'"。语法不通，意思走样。
意图迁移 = 理解后重述：读懂原文表达的意思（“搜索商品”），再用目标语言地道地表达同一个意思。

5.3、三阶段技术流程

5.3.1、阶段一：意图提取（Intent Extraction）

把源端测试脚本交给 LLM “阅读”，提取高层业务目标。

输入（Android 端测试脚本）：

1
2
3
4
5
6
7


find_element(id="search_bar").click();
find_element(id="search_bar").send_keys("汉堡");
find_element(id="search_btn").click();
find_element(id="result_item_0").click();
find_element(id="add_to_cart_btn").click();
find_element(id="cart_tab").click();
assert find_element(id="cart_item_name").text == "汉堡";

输出（LLM 提取的意图）：

1
2
3
4


意图：在外卖 App 中搜索"汉堡"，将第一个搜索结果加入购物车，
然后进入购物车页面验证"汉堡"已成功添加。
前置条件：用户已登录。
关键断言：购物车中存在名为"汉堡"的商品。

注意两点：（1）意图描述中没有任何控件 ID 或平台细节，完全是业务语言；（2）LLM 连断言信息都保留了——“验证’汉堡’已成功添加”。

5.3.2、阶段二：目标端页面理解

在目标端（如 iOS）App 上，LLM 结合 GUI 截图或 Accessibility Tree 理解当前页面的功能入口。

5.3.3、阶段三：操作序列重建

LLM 基于提取的意图 + 目标端的页面理解，逐步推导出在 iOS 上实现同一业务目标的操作序列：

1
2
3
4
5
6
7


1. 点击首页右上角的搜索图标        ← Android 上没有这一步！
2. 在搜索输入框中输入"汉堡"
3. 点击"搜索"按钮
4. 点击第一个搜索结果
5. 点击"加入购物车"按钮
6. 点击底部导航的"购物车"tab
7. 验证购物车中存在"汉堡"          ← 断言也成功迁移了

关键观察：iOS 版的操作序列多了一步"点击搜索图标”，但业务意图完全一致。这就是意图迁移的威力——它不受 UI 差异的影响。

5.4、对 Flutter 的特殊意义

IntentDroid 天然绕过了 Flutter 的"可访问性盲区"，原因有三：

意图提取不依赖目标端：意图是从源端（比如 Android 原生）提取的，与目标端的 Widget 树无关。
操作重建可以基于视觉：在 Flutter 端，即使 Semantics Tree 不完整，LLM 仍可通过截图理解页面——“这里有搜索图标"“这里有一个列表"“这里写着’加入购物车'"。
操作粒度是语义级的：生成的操作是"点击’搜索’按钮"而非"点击 ID 为 xxx 的元素”。前者可被映射到任何具体的定位方式。

5.5、理想化的四端迁移

1
2
3
4
5
6
7
8


Android 测试脚本
       │
       ▼  LLM 意图提取
   业务意图（自然语言）
  ┌────┴────────┬───────────┬─────────────┐
  ▼             ▼           ▼             ▼
iOS 端       Flutter 端   小程序端      Web 端
操作序列      操作序列     操作序列     操作序列

一次提取，四端复用。 测试资产的可迁移单元是"意图"而非"脚本”。

6、两个方向的交汇

把视觉理解和意图迁移放在一起，可以看到它们在解决前文遗留问题上的互补关系：

前文遗留问题	视觉理解（VisionDroid / AUITestAgent）	意图迁移（IntentDroid）
GUI 树残缺时怎么办	✅ 直接看截图，不需要 GUI 树	✅ 意图提取不依赖目标端 GUI 树
Oracle 只能查 Crash	✅ 能发现非崩溃视觉/功能缺陷	——
跨平台无法复用	——	✅ 意图级复用，天然跨平台
LLM 调用太慢太贵	⚠️ MLLM 更贵（图片 Token）	⚠️ 每步重建仍需 LLM 调用

注意最后一行：成本问题仍未解决。视觉理解因为图片编码甚至更贵。GraphDroid 的"异步架构"有望把 LLM 调用量降低一个数量级——这是一个值得单独展开的话题。

同时，目前所有方法的 Oracle 上限仍然是"视觉层面的功能异常”。真正的业务逻辑断言（“满 100 减 20 的优惠券是否正确扣减了金额”）需要理解业务规则，而不仅仅是理解 GUI。LogiDroid 正是为此而设计的——通过 RAG + DSL 方案自动生成业务逻辑断言，值得单独深入。

7、对工程实践的建议

7.1、测试策略的分层使用

测试目标	推荐方法	频率
冒烟测试（“App 能不能打开”）	Monkey / 传统遍历	每次提交
精确的控件操作和数据验证	传统脚本（Espresso / XCUITest）	每次提交
探索性测试（发现未知 Bug）	LLM + GUI 树（GPTDroid 类）	每日/每周
视觉一致性审查	MLLM + 截图（VisionDroid 类）	每周/版本发布前
端到端功能验收	MLLM + 截图 + GUI 树（AUITestAgent 类）	版本发布前
跨端一致性验证	意图迁移（IntentDroid 类）	版本发布前

7.2、给客户端开发者的建议

如果你希望未来的 AI 测试工具能更好地理解你的 App：

为关键控件添加 Semantics / contentDescription：即使用 Flutter 或 Canvas 自绘，也确保核心交互元素有可访问性描述。这不仅帮 AI，也帮视障用户。
保持 UI 视觉清晰：避免小于 44pt 的点击区域、避免元素重叠——这不仅是 UX 原则，也是让 MLLM 准确理解页面的前提。
维护核心场景的意图文档：用自然语言列出"用户能做什么"，作为测试迁移和 AI 测试的输入。

8、总结

这篇回答了两个问题：

“GUI 树残缺时怎么测？" → VisionDroid 和 AUITestAgent 证明了多模态 LLM 可以直接"看"截图，不仅能操作 App，还能发现传统工具完全发现不了的非崩溃功能 Bug（29 个独有 Bug，19 个被确认）。

“跨平台怎么复用？" → IntentDroid 证明了测试迁移的正确抽象层次不是"控件"而是"意图”。一次意图提取，四端操作序列重建——天然适配包括 Flutter 在内的跨端框架。

但仍有三个深层问题悬而未决：怎么让多个 AI 分工合作测试？怎么解决 LLM 推理太慢太贵的问题？怎么让 AI 自动生成业务逻辑断言？ ScenGen、GraphDroid、LogiDroid 分别给出了各自的方案，值得深入拆解。

参考文献

[1] Shaoheng Cao, Minxue Pan, Yuanhong Lan, Xuandong Li. “Intention-based GUI Test Migration for Mobile Apps using Large Language Models”. ISSTA 2025.

[2] “VisionDroid: Vision-driven Automated Mobile GUI Testing via Multimodal Large Language Models”. arXiv preprint, 2024. arXiv:2407.03037.

[3] Yongxiang Hu, Xuan Wang, Yingchuan Wang, et al. “AUITestAgent: Automatic Requirements Oriented GUI Function Testing for Apps”. arXiv preprint, 2024. arXiv:2407.09018.

让 AI "看懂"你的 App —— 多模态视觉测试与跨平台意图迁移

文章目录