自动完成 Android 应用程序的 Bug 告

摘要

随着平板电脑和智能手机的普及，现代软件开发领域的焦点已转向移动应用程序。由于这一趋势，这些“应用程序”的复杂性不断增加，使得开发和维护变得更具挑战性。此外，当前的 bug 跟踪系统无法有效地支持构建包含可操作信息的 告，这些 告是可以用来直接解决 bug 的信息。为了满足对改进 告系统的需求，我们引入了一种称为 FUSION 的解决方案，它可以帮助用户自动完成移动应用程序错误 告中的复现步骤。FUSION 将用户提供的信息与程序工件融合，其中程序工件是在测试和发布前从静态与动态分析中提取出来的。FUSION 所采用的方法可以推广到其他现有的移动软件平台上，为移动软件项目的离线 bug 告提供了一种新的方法。在一项涉及 28 名参与者的研究中，我们应用 FUSION 来支持维护任务，即 告和再现 14 个开源 Android 应用程序中发现的 15 个真实世界 bug，同时定性地衡量系统的用户体验。我们的结果表明，与传统的问题跟踪系统相比，通过提供更详细的上下文应用程序信息，融合不仅有效地促进了 告，而且允许从 告中更可靠地再现 bug。

关键词

错误 告，android，复现步骤，自动完成

I 简介

近年来，智能手机和移动计算的普及率直线上升，2014 年，智能手机用户超过 27 亿，采用率几乎达到无处不在的水平。越来越多的用户在“智能”设备上执行越来越多的计算任务，这推动了对高质量、健壮的移动应用程序需求的增长。由于这种需求，移动应用的复杂性不断增加，使得开发和维护变得非常困难。谷歌 Play 和苹果 App Store 等移动应用市场的激烈竞争意味着，如果某个应用程序由于漏洞或缺少所需功能而无法按预期运行，那么 48%的用户就不太可能再次使用该应用程序，他们会放弃该应用程序，转而使用另一个具有类似功能的应用程序。

我们在一项研究中对 FUSION 进行了评估，该研究将使用我们的系统提交的 bug 告与使用 Google 代码问题跟踪器生成的 bug 告进行了比较，共有 28 名参与者 告了来自 14 个开源 Android 应用程序的 15 个实际故障的 bug。

我们的论文做出了以下值得注意的贡献：

1.

我们设计并实现了一种自动完成和扩充 Android 错误 告的新方法，称为 FUSION， 它利用静态和动态分析，并为开发人员提供可操作的信息。该工具有助于 告、复制和 后续解决 Android 错误。应用程序的程序分析技术可以在物理设备和模拟器上运行；

2.

我们设计并进行了一项全面的用户研究，以评估我们的方法的用户体验和使用 FUSION 生成的 bug 告的质量，并与 Google 代码问题跟踪器进行比较。这项研究的结 果表明，与完全编写的 告相比，融合使开发人员能够提交更可能重复的 bug 告；

3.

我们将融合和实验中的所有数据提供给研究人员，希望这项工作能够促进与改进 缺陷 告和缺陷 告系统质量相关的新研究。

II 研究和实践状况

Bug 和错误 告一直是软件工程界研究的一个活跃领域。然而，已经开展了一些工作，以改善进入复制步骤的 告机制中缺乏结构的问题，并在缺陷跟踪系统中添加了相应的支持。因此，在本节中，我们将简要介绍当前缺陷 告系统的特点以及推动这项工作的研究。然后，我们将我们的工作与现场故障再现方法区分开来，并解释我们的工作是如何对现有的缺陷 告研究进行补充的。

2.1 现有缺陷 告系统

2.2 缺陷 告研究

当前许多 bug 告系统面临的问题是，典型的自然语言 告捕获了粗粒度的细节级别，这使得开发人员很难对缺陷进行推理。这突出了 bug 告系统必须完成的基本任务：弥合 bug 的典型 告者和必须解决 bug 的开发人员之间的法律知识鸿沟。以前关于 bug 告质量和开发人员信息需求的研究强调了几个可能影响 bug 告质量的因素：

?

除了“插件间依赖关系”（即，在以前的补丁中修复了一个 bug）之外，信息不足是导 致不可复制 bug 告的主要原因之一；

?

开发人员认为（i）复制步骤，（ii）堆栈跟踪，以及（iii）测试用例/场景是 bug 告中 最有用的信息源；

?

信息需求在 bug 生命周期的早期是最大的，因此，在 bug 告创建期间，轻松添加上 述功能的方法非常重要。

利用这些问题作为动机，我们开发了融合，并考虑了两个主要目标：（i）向开发人员提供具有立即可操作知识的 bug 告（可靠的复制步骤）和（ii）通过自动完成机制提供这些信息来促进 告。

值得注意的是，Bhattacharya 等人之前进行的一项研究得出的结论是，大多数针对开源应用程序的 Android 错误 告都是高质量的，但是在他们的研究中，只有大约 46%的错误 告包含了复制的步骤，甚至更少（≈20%）包含额外的信息（例如，bug 触发输入，甚至是应用程序版本）。因此，在开源 Android bug 告中包含的信息类型方面，显然还有改进的空间。

2.3 现场故障再现

一系列被称为现场故障再现的工作与我们的方法有相似的目标。这些技术从插入指令的程序收集运行时信息（例如，执行跟踪），使开发人员能够更好地了解现场故障的原因，这将有助于加快这些故障的修复。然而，有几个关键的不同之处使我们的工作与众不同，并说明了融合是如何改善研究状况的。

首先，关于现场故障再现的技术依赖于潜在的昂贵的程序工具，这需要开发人员修改代码并引入开销。FUSION 是完全自动的；我们的静态和动态分析技术只需要在发布测试的程序版本中应用一次。此外，分析过程可以在不需要对现场程序进行说明的情况下完成。第二，当前的现场故障再现技术要求甲骨文表示故障发生的时间（例如，崩溃）。FUSION 不是一种用于崩溃或故障检测的方法；它是为在错误 告过程中支持测试人员而设计的。第三，这些技术尚未应用于移动应用程序，很可能需要进一步优化，以适用于相应的资源受限环境。

2.4 错误和错误 告研究

先前工作的一个子集集中在 bug 和崩溃分类上。与本主题相关的技术通常采用不同的程序分析和机器学习或自然语言处理技术，将错误 告与适当的开发人员相匹配。我们提出的研究是对开发人员推荐框架的一种补充，因为 FUSION 可以为这些框架工作提供比当前实践状态错误 告系统更详细的“知识”。

III 融合方法

融合的分析 → 生成工作流主要分为两个阶段。在分析阶段，FUSION 通过静态和动态分析的结合，收集与 GUI 组件和应用程序事件流相关的信息。然后，在 告生成阶段，FUSION 利用移动应用程序以 GUI 为中心的特性，自动完成重现 bug 的步骤，并使用上下文应用程序信息增强每个步骤。FUSION 的总体设计如图 1 所示。我们鼓励读者观看我们正在使用的工具的视频，并附上评论，可在第 9 节概述的复制包中获得。

3.1 分析阶段

分析阶段收集 告生成阶段操作所需的所有信息。第一阶段有两个主要部分：1）静态分析（初级），2）目标应用程序的动态程序分析（引擎）。分析阶段必须在应用程序的每个版本发布测试之前或发布给最终用户之前执行。分析阶段的两个组件都将提取的数据存储在融合数据库中（图 1-3）。

3.1.1 静态分析（底漆）

入门（图 1-1）的目标是从应用程序源代码中提取所有 GUI 组件和相关信息。对于每个 GUI 组件，Primer 提取：（i）该组件上可能的操作，（ii）组件的类型（例如，按钮、微调器），（iii）组件包含在其中的活动，以及（iv）实例化组件的类文件。因此，这一阶段为我们提供了应用程序域中可能的组件，并建立了可追溯性链接，将 告者操作的 GUI 组件连接到特定于代码的信息，例如它们所在的类或活动。

初级读本由几个步骤组成，用于提取上述信息。首先，它使用 dex2jar 和 jdcmd 工具进行反编译；然后，它使用 srcML 将源文件转换为基于 XML 的表示。我们还使用 apktool 从应用程序的 APK 中提取资源文件。GUI 组件的 id 和类型是从位于应用程序资源文件夹（即反编译应用程序或 src 的/res/layout 和/res/menu）中的 xml 文件中提取的。使用源代码的 srcML 表示，我们能够解析 GUI 组件信息并将其链接到提取的应用程序源文件。

3.1.2 动态分析（发动机）

引擎（图 1-2）用于收集动态上下文的实际信息，例如屏幕上 GUI 组件的位置，并使用运行时 GUI 和应用程序事件流信息增强数据库。该引擎的目标是以系统的方式探索一个应用程序，在执行过程中剥离和提取与 GUI 组件相关的运行时信息，包括：（i）与不同 GUI 组件相关的文本（例如，发送电子邮件消息的按钮上的“发送”文本），（ii）GUI 组件是否触发到应用程序的转换不同的活动，（iii）系统执行期间对 GUI 组件执行的操作，（iv）执行每个操作前后的全屏截图，（v）GUI 组件对象在测试设备屏幕上的位置，（vi）每个步骤的当前活动和窗口，（vii）特定 GUI 组件的屏幕截图，以及（viii）GUI 组件的对象索引（允许在一个屏幕上区分相同 GUI 组件的不同实例）。

该引擎使用 android sdk 中包含的 UIAutomator 框架对应用程序进行系统的探索。这个应用程序的系统化执行与现有的 GUI 翻录方法非常相似。通过使用 UIAutomator 框架，我们可以捕获以前的工具中没有捕获到的情况，例如存在于菜单、内部窗口和屏幕键盘中的弹出菜单。为了有效地探索应用程序，我们为应用程序遍历实现了我们自己版本的系统深度优先搜索（DFS）算法，该算法在 GUI 层次结构中的所有可单击组件上执行单击事件，这些组件可以使用 DFS 启发式方法访问。

图 1 FUSION 工作流概览

在翻录过程中，在 GUI 上执行每个步骤之前，引擎调用 UIAutomator 子例程，以提取上述关于当前显示的每个 GUI 组件的上下文信息。然后在当前屏幕上以深度优先的方式执行与每个 GUI 组件相关联的操作。我们当前的 DFS 实现只处理 click/tap 操作；然而，由于这是最常见的操作，它仍然能够探索应用程序的大量功能。

在 DFS 算法中，如果单击一个链接，该链接通常会转换到外部活动中的屏幕（例如，单击一个 web 链接，该链接将启动 Chrome web 浏览器应用程序），我们将执行 back 命令以保持在当前应用程序中。如果 DFS 探索出于任何原因将应用程序退出到设备/仿真器的主屏幕，我们只需重新启动应用程序并继续 GUI 遍历。在 DFS 探索过程中，引擎捕获在执行每个操作后发生的每个活动转换（例如，在启动菜单的操作后是否启动/恢复新活动）。这允许 FUSION 构建应用程序执行的模型，我们稍后将使用该模型来帮助跟踪 告者在应用程序中的相对位置，当他们使用系统记录复制错误的步骤时。

3.2 告生成阶段

在设计 FUSION 的 告生成阶段组件时，我们有两个主要目标：

1 允许传统的自然语言输入，以便对 bug 进行高级概述。

2 通过跟踪 告者的步骤条目在应用程序事件流中的位置，自动完成 bug 的复制步骤。

图 2 FUSION 告界面

在 告生成阶段，FUSION 通过根据声明的步骤达到的“潜在”GUI 状态提出建议，帮助 告者构建重新创建 bug 所需的步骤。这意味着，对于每个步骤，FUSION 都会通过考虑步骤的历史，在线推断目标应用程序应处于的 GUI 状态 GUI。对于每个步骤，FUSION 通过向 告者呈现上下文相关的屏幕截图来验证向 告者提出的建议是正确的，其中 告者选择与 告者想要描述的当前动作相对应的屏幕截图。

3.2.1 表生成器用户界面

在第一次选择要 告问题的应用程序之后， 告员通过在 UI 的上半部分填写一些识别信息（例如，名称、设备、标题）和有关 bug 的简短文本描述，与 FUSION 进行交互。接下来， 告者使用自动完成框以逐步的方式输入重现 bug 的步骤，从冷应用程序启动 1 的初始屏幕开始，并继续进行，直到重现 bug 的步骤列表用尽为止。让我们考虑一个正在运行的示例，其中用户正在为表 2 中的文档查看器错误填写 告。根据图 2 中的各个字段， 告者将首先填写他们的（i）名称（字段 1），（ii）设备（字段 2），（iii）屏幕方向（字段 3），（iv）错误 告标题（字段 4），（v）错误的简要描述（字段 5）。

3.2.2 自动完成错误复制步骤

为了方便 告者输入复制步骤，我们将复制过程中的每个步骤建模为action，component元组，对应于 告者在每个步骤中要描述的动作（例如，轻触、长轻触、轻扫、键入）和应用程序 GUI 中与之交互的组件（例如，“Name”textview，“确定”按钮，“天”微调器）。由于 告者通常知道与之交互的动作和 GUI 元素，因此这是他们构建复制步骤的直观方式。FUSION 根据决策树将自动完成建议分配到下拉列表中，同时考虑 告者在应用程序执行中的位置（从应用程序冷启动开始）。

图 3 自动填充下拉按钮

从自动完成下拉列表中选择组件的一个潜在问题是，应用程序中的同一屏幕上可能有重复的组件。融合从两个方面解决了这个问题。首先，它通过指定文本“Option#”，区分列表中的每个重复的组件。第二个 FUSION 尝试通过从 FUSION 数据库中获取代表整个设备屏幕的屏幕快照来确认 告者在每个步骤中输入的组件。这些屏幕截图中的每一个都突出显示了图 5 所示的代表性 GUI 组件。要完成步骤输入， 告者只需选择对应于应用程序状态和 GUI 组件的屏幕快照。在我们正在运行的示例中， 告者将选择与他们从下拉列表中选择的组件相对应的完整增强屏幕截图。在我们的例子中，“OK”按钮的屏幕截图的示例部分如图 5 所示。

在 告者从下拉列表中进行选择之后，他们有机会在自然语言文本输入字段中输入每个步骤的附加信息（例如，按钮具有意外行为）。例如，在我们正在运行的示例中， 告者可能会指出，在按下“OK”按钮之后，弹出窗口消失的时间比预期的要长。

3.2.3 表生成器自动完成引擎

基于 web 的 表生成器的自动完成引擎（图 1-4）使用在分析阶段预先收集的信息。当 FUSION 为下拉菜单建议选项时，它会查询数据库中应用程序事件流的相应状态，并根据 告者输入的过去步骤建议信息。因为我们总是假设应用程序启动是“冷”的，所以自动完成引擎从应用程序的主要活动开始复制步骤输入过程。然后，我们使用基于过去步骤的预测度量，通过应用程序跟踪 告者的进度。

自动完成引擎使用多个不同的信息作为输入，对应用程序步骤进行操作。它将 告者的再现步骤建模为步骤 s 的有序流，其中每个步骤 si 可以是空的或满的。每个步骤都可以建模为一个五元组，由{step num，action，comp name，activity，history}组成。动作是 告者在第一个下拉菜单中提供的手势。组件名称是 UIautomator 接口在引擎阶段 告的单个组件名称。活动是组件所在的 Android 屏幕。历史记录是当前步骤之前的步骤的历史记录。自动完成引擎使用决策树逻辑预测建议信息，如图 4 所示。

FUSION 在活动或应用程序屏幕的常规位置向 告者展示组件。为了总结建议过程，FUSION 回顾了过去几个步骤的历史，并根据与之交互的组件寻找从以前步骤到将来步骤的可能过渡。如果 FUSION 由于前面提到的应用程序执行模型不完整而无法从 告程序捕获最后几个步骤，那么 FUSION 将从应用程序的所有已知屏幕中呈现可能性。在我们正在运行的示例中，让我们考虑 告第二个复制步骤的 告员。在这种情况下，FUSION 将查询历史以查找“确定”按钮所在的上一个活动，然后在用户停留在同一个活动中的情况下提供来自该活动的组件建议，在用户转换到不同活动的情况下提供来自可能的转换活动的组件建议。

图 4 决策树在自动完成引擎中的应用

图 5 相对位置枚举和示例增强屏幕截图

3.2.4 处理 FUSION 的应用模型差距

由于基于 DFS 的探索并非详尽无遗，FUSION 的可能应用程序屏幕数据库中可能存在漏洞（例如，未对触发活动转换的动态生成组件采取行动）。因此，搬运工可能无法在下拉列表中找到合适的建议。为了优雅地处理这些情况，我们允许 告者在“自动完成”下拉列表中找不到与之交互的组件时选择一个特殊选项。在我们正在运行的示例中，假设搬运工希望指示他们单击了标记为“打开文档”的按钮，但该选项在“自动完成组件”下拉列表中不可用。在这种情况下， 告者将选择“不在此列表中…”选项并手动填写（i）组件的类型（为了限制混淆，我们将此选项显示为一个下拉框，仅自动填写应用程序中存在的 GUI 组件类型，如 Primer 提取的，在我们的情况下，用户将选择“按钮”），（ii）与 GUI 组件相关的任何文本（在本例中为“Open Document”），以及（iii）GUI 组件的相对位置，如图 5 所示（在本例中为“Top Center”）。

3.2.5 表结构

当 告者完成错误 告时，自动完成引擎会将每个步骤保存到数据库中。一旦 告者完成了这些步骤并完成了数据输入过程，一个包含最终 告的屏幕（带有一个自动分配的唯一 ID）就会显示给 告者，并保存到数据库中，供开发人员稍后查看（参见图 6 中的 Document Viewer 告示例）。该 告以三个主要部分向开发人员提供信息：第一，初步信息，包括 告标题、设备和简短描述（如图 6 中的蓝色部分所示）。其次，将显示一个步骤列表，其中包含有关每个步骤的以下信息（在图 6 中以蓝色突出显示）：（i）每个步骤的操作，（ii）组件的类型，（iii）组件的相对位置，（iv）在源代码中实例化组件的 activity Java 类，以及（v）特定于组件的屏幕截图。第三，与每个步骤相对应的全屏快照列表显示在页面底部，这样开发人员就可以通过每个应用程序屏幕跟踪这些步骤（图 6 中以绿色突出显示了该部分）。

IV 实验设计

FUSION 背后的两个主要设计目标是：1）简化并鼓励 告者为 Android 应用程序提交有用的 bug 告；2）为开发者提供关于这些 告中所包含 bug 的更多可操作信息。为了衡量 FUSION 在实现这些目标方面的有效性，我们评估了我们方法的两个主要方面：1）系统生成的 bug 告的质量，2）使用 FUSION 的 告者和开发人员的用户体验。为此，我们调查了以下研究问题：

?

RQ1：在 Android 应用程序中 告 bug 时，bug 告中的哪些信息字段是有用的？

?

RQ2：FUSION 比传统的 bug 跟踪系统更容易 告 bug 吗？

?

RQ3：融合 告是否比传统的错误 告更容易用于重现错误？

?

RQ4：与使用传统错误跟踪系统提交的 告相比，使用 FUSION 生成的错误 告是否允 许更快的错误复制？

?

RQ5：与传统的错误跟踪系统相比，使用 FUSION 的开发人员是否会复制更多的错误？

对这五个 RQ 进行了调查，并进行了实证研究，其中包括两项维护活动，涉及 告和复制开放源码应用程序中的真实 bug。在下面的小节中，我们将描述这两项研究的背景（即 Android 应用程序和 bug 告）以及每项研究的细节。

4.1 背景：研究中使用的缺陷 告

为了在 告和复制来自真实世界 bug 的 bug 告时正确地评估融合，我们在 FDroid 中手动选择了来自 Android 开源应用程序的 bug 告。我们对应用程序的问题跟踪系统的链接进行了爬 ，然后手动检查了 F-droid 拥有链接问题跟踪器的每个项目的 bug 告。选择缺陷 告的标准如下：1）考虑到我们的融合实现的技术限制，可重复出现的缺陷；2）复杂程度不同的缺陷，需要至少三个用户交互步骤才能表现出来；3）用于用户研究的 Nexus 7 平板电脑上可重复出现的缺陷。这些 bug 告的详细信息可以在表 2 中找到。

FUSION 的目标是 bug 告，这些 bug 告可以用 GUI 事件来描述，并且不依赖于上下文。例如，当改变设备的方位时会触发一些错误，或者与上下文有关（即，错误取决于 络信 质量、GPS 位置等）。我们并不声称融合方法适用于所有类型的 Android bug。

4.2 评估用户体验、偏好和编程背景

表 1 用于评估缺陷跟踪系统的用户体验的问题和陈述，以及使用分析的系统生成的缺陷 告。

4.3 研究 1：使用 FUSION 告 Bug

第一项研究的目标是评估 FUSION 的功能在 告 Android 应用程序的 bug 时是否有用，该应用程序旨在回答 RQ1 和 RQ2。特别是，我们想确定自动完成步骤和现场屏幕截图功能在 告 bug 时是否有用。为了完成这一点，我们在威廉和玛丽学院招募了 8 名学生（4 名本科生或非专家，4 名研究生或专家），用 FUSION 和 Google Code Issue Tracker（GCIT）构建 bug reports，作为传统 bug 跟踪系统的代表，用于表 2 所示 告中的真实世界 bug。这四名研究生参与者有着广泛的编程背景。四名参与者使用 FUSION prototype 为表 2 中的 15 个 bug 中的每一个构建了一个 bug 告，四名参与者使用 Google Code Issue Tracker 界面 告了 bug。参与者被分配到系统中，两个非专家和两个项目人员对这两个系统进行评估。参与者总共构建了 120 个 bug 告，其中 60 个使用 FUSION，60 个使用 GCIT。参与者使用安装了 android4.4.3kitkat 的 nexus7 平板电脑来重现这些漏洞。

进行第一项研究的一个挑战是向参与者说明缺陷，而不引入来自原始缺陷 告的偏见。为了实现这一点，我们创建了一些简短的视频，介绍了使用尽可能少的操作来重现每个 bug 的步骤。观看视频后，要求每位参与者在 Nexus7 平板电脑上复制病毒，并由研究监护仪确认复制。然后参与者为分配给他们的系统的 15 个 bug 中的每一个都填写一份 bug 告。在 告收集过程中，错误 告系统的名称被匿名化为“系统 A”用于 FUSION，而“系统 B”用于 GCIT。向用户提供了一个简短的教程，介绍如何为每个系统输入 bug，以免给任何 告系统带来偏见。在创建 bug 告之后，用户被要求在一次在线调查中回答表 1 中列出的问题。

4.4 研究 2：缺陷 告的再现性

研究 2 的目标是评估开发人员使用 FUSION 告 bug 的可用性和偏好，以及我们提出的方法提高 bug 告可重用性的能力，从而回答 RQ3-RQ5。特别是，我们评估了 FUSION 和传统问题跟踪器的以下方面：1）使用 bug 跟踪系统的 GUI 读取 bug 告时的可用性，2）使用 bug 告复制 reals bug 所需的时间，以及 3）成功复制的 bug 数量。研究 1 期间使用 FUSION 和 GCIT 生成的 告以及原始错误 告（表 2）均由一组新的 20 名参与者通过尝试在物理设备上复制错误来评估。

参与者是威廉和玛丽学院计算机科学系的研究生，他们都熟悉 Android 平台，都是经验丰富的程序员。所有参与者的努力都得到了 15 美元的补偿。每个用户评估了 15 个 bug 告，6 个来自 FUSION，6 个来自 GCIT，还有 3 个原始的。对 135 份 告进行了评估（120 份来自研究 1 加上 15 份原始缺陷 告），并以这样的方式分发给 20 名参与者，即每个缺陷 告由两名不同的参与者进行评估（完整的设计矩阵可在我们的复制包中找到）。每个参与者只评估一个给定 bug 的 bug 告的一个版本，因为学习效果表明，在用户复制一次 bug 之后，他们将能够在随后的尝试中轻松地复制其他 bug 告。

表 2 用于实证研究的错误 告摘要。GDE=Gui 显示错误，C=崩溃，DIC=数据输入/计算错误，NE=导航错误。

在研究过程中，研究人员向参与者发送了与 告相对应的链接，要求他们复制错误。每位参与者都被租借了一台安装了安卓 4.4.3kitkat 的 nexus7 平板电脑；这些应用程序是预先安装在设备中的。对于每个 bug 告，用户都试图仅使用 告中包含的信息在平板电脑上重新创建 bug。用户为每一个 bug 的复制进行计时，时间限制为 10 分钟。如果一个参与者在十分钟后不能复制一个错误，那么这个错误会被标记为未复制。一名监考员监测研究，判断参与者是否成功复制了一个给定的错误。在用户试图重现分配给他们的所有 15 个 bug 之后，他们被要求为他们使用的每种 bug 告类型填写一份匿名在线调查，包含用户体验和表 1 中列出的问题。在分析中，我们使用描述性统计来分析 UX 语句的响应、重现 bug 的时间以及成功重现的次数。

V 结论和今后的工作

先前的研究强调了缺陷 告者和开发人员之间固有的词汇差异。为了帮助解决这个问题，我们引入了 FUSION，一种新的 bug 告方法，它利用了程序分析技术和 Android 应用程序的事件驱动特性，以帮助自动完成 bug 的复制步骤。我们的综合评估结果表明，FU SION 比传统的问题跟踪系统能够生成更多可重复的错误 告。我们希望我们在融合方面的工作能够鼓励一个旨在改进 告系统的新的研究方向。在未来的工作中，我们的目标是通过支持更多的手势来改进我们的 DFS 引擎，探索在 告中添加更具体的程序信息，以便更快/自动地定位故障，并使用 FUSION 作为 告功能请求的工具。

致谢