技术摘要：自动增强 Android 应用缺陷报告质量

问题陈述

移动应用程序中的大多数缺陷在设备屏幕上是视觉可见的，然而，自动检测和报告这些缺陷的机制通常是缺失的，特别是对于那些不会产生显式信号（如崩溃）的问题。因此，用户、测试人员和开发人员必须手动提交缺陷报告（BR）。这些报告通常是不完整的、模糊的或不准确的，往往缺乏关键信息，例如观察到的行为（Observed Behavior, OB）、预期行为（Expected Behavior, EB）以及复现步骤（Steps to Reproduce, S2Rs）。这一问题在以 UI 为中心的缺陷中尤为严重，因为终端用户难以精确描述应用程序的内部逻辑、执行状态以及触发故障所需的 GUI 交互序列。

现有的改进缺陷报告的方法要么将纠错负担留给用户，要么主要基于原始报告文本生成内容。这些方法无法确保生成的的信息能够准确反映应用程序的实际行为，可能会产生看似合理但并不符合有效 GUI 交互的错误复现步骤。核心挑战不仅在于如何改进缺陷描述，更在于如何恢复缺失的缺陷信息与应用程序底层 UI 执行之间的联系。

方法论：BUGSCRIBE

本文提出了 BUGSCRIBE，一种利用大语言模型（LLM）驱动的方法，用于自动增强用户编写的 Android 缺陷报告。其核心洞察在于：高质量的缺陷报告生成应被构造成一个将缺陷描述与应用程序 UI 执行信息相连接的问题。BUGSCRIBE 采用了针对特定组件的落地策略（component-specific grounding strategy），为大语言模型提供最相关的上下文，以生成缺陷报告的每个特定组成部分（OB、EB 和 S2Rs）。

该系统通过三个阶段运行：

1. 应用执行模型生成：
   BUGSCRIBE 构建了一个基于图的应用执行模型。节点代表唯一的 GUI 屏幕（通过 UI 组件层级进行区分），边代表用户交互（例如点击）。该模型通过 UI 元数据进行了增强，包括组件类型、ID、标签和描述。该模型是使用来自自动化探索（使用修改后的 CRASHSCOPE）和人工应用使用的追踪数据构建而成的。

2. 上下文信息提取：
   系统会对用户提交的报告进行标注，以识别表达 OB、EB 和 S2Rs 的句子。随后，它会提取三个关键的应用信息元素，作为 LLM 的上下文：

   • 应用屏幕描述： 由 LLM 生成的关于屏幕功能、布局和可用操作的摘要。
   • GUI 交互： 从执行模型中提取的（动作, 目标元素, 源屏幕, 目标屏幕）元组。
   • 缺陷屏幕定位： 通过 LLM 根据报告的缺陷和屏幕描述对屏幕进行排名，从而确定发生故障的具体屏幕。

3. 缺陷报告生成：
   利用零样本（zero-shot）任务分解提示策略，BUGSCRIBE 按顺序生成报告组件：

   • S2R 生成： LLM 将原始报告中的 S2R 句子映射到执行模型的交互序列中，以推断出通往缺陷屏幕的有效复现路径。
   • OB/EB 生成： LLM 通过将原始报告的描述映射到上下文应用信息（包括疑似缺陷屏幕、生成的 S2Rs 和屏幕描述）来生成观察行为和预期行为。
   • 组装： 系统组装成一个结构化报告，包括标题、OB、EB、S2Rs 和环境详情。

核心贡献

本文做出了四个主要贡献：

1. BUGSCRIBE： 一种 LLM 驱动的方法，通过将报告信息与应用特定的执行信息相链接，生成准确、完整且正确的 OB、EB 和 S2R 描述。
2. 数据驱动的方法论： 确定了哪些特定的应用信息元素（例如 GUI 交互对比屏幕描述）对于生成不同报告组件最为有效。
3. 实证评估： 通过全面评估证明了 BUGSCRIBE 能够改进原始缺陷报告，并优于缺乏应用特定信息的基于 LLM 的基准模型。
4. 复现包： 提供了一个公开的数据集，包含 58 份缺陷报告（10 份开发用，48 份测试用）、地面真值（ground truth）OB/EB/S2Rs、代码、提示词及实验基础设施。

实验结果

作者在包含 26 个 Android 应用的 48 份缺陷报告测试集上对 BUGSCRIBE 进行了评估，并将其与原始报告以及三个基于 LLM 的基准模型（在缺乏应用上下文的情况下使用 GPT-5.4 和 CLAUDE-Opus-4.6，以及 U2SBR）进行了对比。

• S2R 质量： BUGSCRIBE 显著优于基准模型和原始报告。它将 S2R 质量提升了 44.1% 至 82.3%（以 F1 分数衡量）。具体而言，它生成的正确步骤显著增多（532–538 对比基准模型的 196–345），并大幅减少了多余和缺失的步骤。
• OB/EB 质量： BUGSCRIBE 将 OB 和 EB 的质量提升了 3.8% 至 35.2%。它生成的正确信息元素更多（158–165 对比原始报告的 122），并极大地减少了缺失元素（0–3 对比原始报告的 59）。
• 上下文有效性： 研究发现，不同的组件受益于不同的上下文。S2R 生成高度依赖于 GUI 交互和缺陷屏幕，而 OB/EB 生成则受益于生成的 S2Rs、缺陷屏幕描述以及屏幕级上下文。
• 成本： 平均处理时间约为每份报告 2.3 分钟，根据所使用的 LLM 不同，每份报告的成本在 $0.44 到$0.92 之间。

意义与主张

论文声称，这项工作的首要意义在于将缺陷报告增强的范式从基于文本的重写转变为基于执行的推理（execution-grounded reasoning）。通过将用户报告与应用程序真实的 UI 执行模型相连接，BUGSCRIBE 确保了生成的复现步骤和行为描述不仅在语言上合理，而且在特定应用的上下文中在技术上是有效的。

作者断言，他们的特定组件落地策略具有创新性，因为它能根据生成特定报告组件的需求，量身定制提供给 LLM 的上下文。这种方法解决了先前工作的局限性，即由于缺乏应用程序执行流的地面真值，先前的方法往往会生成“看似合理但错误”的描述。结果表明，将动态应用分析与 LLM 推理相结合，是自动生成高质量、可操作的缺陷报告（可直接用于开发人员诊断和复现）的一条可行路径。