技术摘要：用于移动端 GUI 文本输入生成的语言大模型：一项实证研究

1. 问题陈述

移动应用程序已无处不在，这使得其质量保证工作至关重要。虽然图形用户界面（GUI）测试是确保应用质量的标准方法，但自动化探索面临着一个显著的瓶颈：文本输入组件。与简单的点击或滑动操作不同，许多 UI 页面需要具有语义合理性的文本输入（例如，特定的电子邮件格式、有效的地点名称或密码约束），才能跳转到后续页面。传统的自动化工具往往在此失效，它们生成的通常是随机字符串（如“hello world”），这些字符串无法满足应用的上下文需求，从而导致 UI 探索不完整且覆盖率低。

尽管大语言模型（LLMs）在生成上下文感知文本方面已展现出潜力，但目前尚不清楚不同的 UI 上下文表示形式（文本式 vs 视觉式 vs 结构式）、执行反馈以及人工干预如何影响基于 LLM 的 Android GUI 测试中文本输入生成的有效性。目前缺乏系统性的实证证据来跨最先进的模型比较这些因素。

2. 研究方法

作者进行了一项涉及九种最先进（SOTA）LLM 的大规模实证研究。

2.1 实验设置

• 研究对象： 从 Google Play 收集了 115 个 Android 应用（提供 115 个 UI 页面和 183 个文本输入组件），以及从 F-Droid 和 GitHub 收集的 37 个真实的文本输入相关缺陷（Bugs）。
• 模型： 根据排行榜（Chatbot Arena+ 和 LLM Arena）、可用性和多模态支持（文本和视觉）选择了九种 LLM。其中包括闭源模型（如 GPT-5.4, Claude-4.6, Gemini-3.1）和开源权重模型（如 Qwen3.5, Mistral-large-3）。
• 任务：
  1. 页面通过任务 (PPTR)： 生成有效的文本输入，以实现从当前 UI 页面到下一页面的导航。
  2. 缺陷检测任务 (BDR)： 生成无效的文本输入，以触发特定的、已知的文本输入相关缺陷。

2.2 提示策略

研究评估了三种不同的 UI 上下文提示设置：

1. 提取上下文提示 (Extracted-Context Prompting)： 使用从 UI 层级结构中提取的自然语言描述，包括组件上下文（提示文本、资源 ID）、相邻上下文（附近的标签）和全局上下文（应用名称、Activity 名称）。
2. UI 层级 XML 提示 (UI-Hierarchy-XML Prompting)： 直接将原始 UI 层级 XML（通过 UIAutomator 获取）喂给 LLM，暴露完整的结构树。
3. 截图-视觉提示 (Screenshot-Vision Prompting)： 使用 UI 页面的截图图像结合文本提示，利用多模态能力。

2.3 反馈协议

测试了一种反馈增强的生成协议：将失败的尝试（解析错误、验证失败或执行结果）反馈给 LLM，并在新的提示词中引导后续的生成尝试。

2.4 人工评估

专业测试人员（20 名负责评估，3 名负责修改）对 LLM 生成的输入质量进行了评估，并尝试对其进行重构或修改，以提高有效性。

2.5 工具集成

将 LLM 生成的文本输入集成到知名自动化 Android 测试工具 DroidBot 中，以评估在深度优先搜索（DFS）和广度优先搜索（BFS）策略下 UI 探索能力的提升情况。

3. 核心贡献

1. 全面的实证研究： 首个系统比较了三种 UI 上下文提示设置（提取文本、XML、截图）在九种近期 LLM 中用于 Android 文本输入生成的实证研究。
2. 反馈协议评估： 评估了针对页面通过任务和缺陷检测任务的反馈增强生成协议。
3. 人机协同分析： 对 LLM 生成的输入与测试人员生成的输入及经过修改的输入进行了定量比较。
4. 工具集成： 将 LLM 能力集成到 DroidBot 中，以展示在实际自动化测试工作流中的改进。
5. 实践洞察： 为 Android 测试社区提供了关于成本、有效性和反馈及人工优化作用之间权衡的六项具体见解。

4. 关键结果

4.1 提示有效性 (RQ1)

• 页面通过任务： 提取上下文提示和 UI 层级 XML 提示实现了相似的页面通过率 (PPTR)，分别为 71.4% 和 71.0%。截图-视觉提示略低，为 65.1%。
• 成本效率： 提取上下文提示的成本效益显著更高，每次尝试平均仅需 1,272.7 个 token。相比之下，基于 XML 的提示需要 7,896.6 个 token，而视觉提示需要 5,664.5 个 token。
• 缺陷检测： 三种设置在 30 次尝试下的缺陷检测率 (BDR) 均表现相似（约 51%）。然而，提取上下文仍然是最具成本效益的，而 XML 和视觉提示在没有显著 BDR 增益的情况下，产生了大幅更高的 token 消耗。
• 模型差异： 统计分析表明，对于特定的提示设置，大多数 LLM 对对之间不存在显著差异。提示策略的选择对性能的影响大于特定 LLM 的选择。

4.2 反馈协议 (RQ2)

• 页面通过任务： 反馈将平均 PPTR 从 69.18% 提升至 73.78%（提升了 4.60 个百分点）。该提升具有统计学意义，但幅度较小。
• 缺陷检测： 反馈在此任务中的影响更为显著，将平均 BDR 从 50.95% 提升至 64.46%（提升了 13.51 个百分点）。
• 成本： 反馈协议显著增加了 token 使用量和延迟，尤其是在缺陷检测方面（平均每次尝试的延迟从约 35 秒增加到约 506 秒）。

4.3 人工评估与修改 (RQ3)

• 评估： 测试人员对有效的页面通过输入给予了较高评价（平均分 ~4.1/5），但对无效的缺陷检测输入评价较低（平均分 ~3.2/5），指出 LLM 难以生成触发缺陷所需的特定且多样化的无效输入。
• 修改： 当专业测试人员修改 LLM 生成的输入时，有效性得到了剧烈提升。
  • 页面通过任务： PPTR 从 59.75%（LLM 基准）提升至 90.00%（测试人员修改后）。
  • 缺陷检测： BDR 从 36.10%（LLM 基准）提升至 100.00%（测试人员修改后）。
  • 测试人员利用执行历史和具体的缺陷描述来优化输入，这是静态 LLM 提示词所缺乏的能力。

4.4 实践意义 (RQ4)

• 工具集成： 将 LLM 生成的文本输入集成到 DroidBot 中，使 UI 页面探索量相比原工具分别增加了 36.06% (DFS) 和 26.41% (BFS)。
• 洞察： 研究结论认为：提取上下文是兼顾成本效益的实际默认选择；反馈对于困难案例很有价值但成本高昂；人工优化对于边缘情况非常有效。

5. 意义与主张

本文声称通过提供如何有效利用 LLM 进行 GUI 文本输入生成的实证证据，推动了 Android 测试领域的知识进步。

• 成本效益： 研究确立了提取相关文本上下文通常优于直接喂入原始 XML 或截图，因为后者存在巨大的 token 成本差异，且在页面导航方面的有效性损失微乎其微。
• 反馈效用： 研究证明，虽然反馈循环能显著提高缺陷检测能力，但也会带来高延迟和高 token 成本，因此仅适用于高价值、高难度的测试场景。
• 人机协作： 研究强调，虽然 LLM 提供了强大的基准，但专业测试人员可以通过根据执行结果和特定缺陷触发器来修改输入，从而显著弥补差距，达到 100% 的有效性。
• 工具增强： 研究验证了通过 LLM 生成的上下文感知输入来增强传统自动化工具（如 DroidBot），可以实质性地提高 UI 覆盖率，解决了随机或静态输入生成的已知局限性。

作者保持了审慎的态度，指出其发现是基于特定样本（115 个应用，37 个缺陷）和当前 LLM 版本，结果可能会随不同的应用架构或未来的模型迭代而变化。他们强调，本研究提供的是实践指南，而非适用于所有 Android 测试场景的普适规则。