Automatically Discovering, Reporting and Reproducing Android Application Crashes

Kevin Moran, Mario Linares-Vasquez, Carlos Bernal-Cacute;ardenas, Christopher Vendome, and Denys Poshyvanykacute;

College of William amp; Mary

{kpmoran, mlinarev, cebernal, cvendome, denys}@cs.wm.edu

Abstract—Mobile developers face unique challenges when detecting and reporting crashes in apps due to their prevailing GUI event-driven nature and additional sources of inputs (e.g., sensor readings). To support developers in these tasks, we introduce a novel, automated approach called CRASHSCOPE. This tool explores a given Android app using systematic input generation, according to several strategies informed by static and dynamic analyses, with the intrinsic goal of triggering crashes. When a crash is detected, CRASHSCOPE generates an augmented crash report containing screenshots, detailed crash reproduction steps, the captured exception stack trace, and a fully replayable script that automatically reproduces the crash on a target device(s).

We evaluated CRASHSCOPErsquo;s effectiveness in discovering crashes as compared to five state-of-the-art Android input generation tools on 61 applications. The results demonstrate that CRASHSCOPE performs about as well as current tools for detecting crashes and provides more detailed fault information. Additionally, in a study analyzing eight real-world Android app crashes, we found that CRASHSCOPErsquo;s reports are easily readable and allow for reliable reproduction of crashes by presenting more explicit information than human written reports.

I. INTRODUCTION

Continued growth in the mobile hardware and application marketplace is being driven by a landscape where users tend to prefer mobile smart devices and apps for tasks over their desktop counterparts. The gesture-driven nature of mobile apps has given rise to new challenges encountered by programmers during development and maintenance, specifically with regard to testing and debugging [41]. One of the most difficult [22], [24] and important maintenance tasks is the creation and resolution of bug reports [35]. Reports concerning application crashes are of particular importance to developers, because crashes represent a jarring software fault that is directly user facing and immediately impacts an apprsquo;s utility and sucess. If an app is not behaving as expected due to crashes, missing features, or other bugs, nearly half of users are likely to abandon the app for a competitor [12] in a marketplace such as Google Play [10].

Mobile developers heavily rely on user reviews [42], [49], [65], crash reports from the field in the form of stack traces, or reports in open source issue tracking systems to detect bugs in their apps. In each of these cases, the bug/crash reports are typically lacking in information [27], [41], containing only a stack trace, overly detailed logs or loosely structured natural language (NL) information regarding the crash [23]. This is not surprising as previous studies showed that information, which is most useful for a developer resolving a bug report (e.g., reproduction steps, stack traces and test cases), is often the most difficult information for reporters to provide [33]. Furthermore, the absence of this information is a major cause of developers failing to reproduce bug/crash reports [22]. In addition to the quality of the reports, some other factors specific to Android apps such as hardware and software fragmentation [3], API instability and fault-proneness [21], [48], the event-driven nature of Android apps, gesture-based interaction, sensor interfaces, and the possibility of multiple contextual states (e.g., wifi/GPS on/off) make the process of detecting, reporting, and reproducing crashes challenging.

Motivated by these current issues developers face regarding mobile application crashes, we designed and implemented CRASHSCOPE, a practical system that automatically discovers, reports, and reproduces crashes for Android applications. CRASHSCOPE explores a given app using a systematic input generation algorithm and produces expressive crash reports with explicit steps for reproduction in an easily readable natural language format. This approach requires only an .apk file and an Android emulator or device to operate and requires no instrumentation of the subject apps or the Android OS. The entirety of the CRASHSCOPE workflow is completely automated, requiring no developer intervention, other than reading produced reports. Our systematic execution includes different exploration strategies, aimed at eliciting crashes from Android apps, which include automatic text generation capabilities based on the context of allowable characters for text entry fields, and targeted testing of contextual features, such as the orientation of the device, wireless interfaces, and sensors. We specifically tailored these features to test the common causes of app crashes as identified by previous studies [26], [45], [79]. During execution, CRASHSCOPE captures detailed information about the subject app, such as the inputs sent to the device, screenshots and GUI information, exceptions, and crash information. This information is then translated into detailed crash reports and replayable scripts, for any encountered crash.

This paper makes the following noteworthy contributions:

1. We design and implement a practical and automatic approach for discovering, reporting, and reproducing Android application crashes, called CRASHSCOPE. To the best of the authorrsquo;s knowledge, this is the first approach that is able to generate expressive, detailed crash reports for mobile apps, including screenshots and augmented NL reproduction steps, in a completely automatic fashion. CRASHSCOPE is also one of the only available fully-automated Android testing approaches that is practical from a developersrsquo; perspective, requiring no instrumentation of the subject apps or OS. Our app

   剩余内容已隐藏，支付完成后下载完整资料

   ---

   自动发现、报告和再现的Android应用程序崩溃

   Kevin Moran, Mario Linares-Vasquez, Carlos Bernal-Cacute;ardenas, Christopher Vendome, and Denys Poshyvanykacute;

   College of William amp; Mary

   {kpmoran, mlinarev, cebernal, cvendome, denys}@cs.wm.edu

   摘要：移动开发检测和报告在应用崩溃时，由于其通行GUI事件驱动性质和额外的输入源例如，传感器读数面临独特的挑战。为了支持开发者在这些任务中，我们介绍了一种新的，自动化的方法称为CRASHSCOPE应付。此工具探索了使用系统的输入生成一个给定的Android应用程序，根据几种策略通过静态和动态分析得知，与触发崩溃的内在目标。当检测到崩溃，CRASHSCOPE应付生成包含截图，详细崩溃再现步骤，所捕捉的异常堆栈跟踪以及自动再现的目标设备（一个或多个）上的碰撞完全重玩脚本增强崩溃报告。我们评估CRASHSCOPE应付的在相比于国家的最先进的五款Android输入生成工具61级上的应用程序发现崩溃效果。结果表明，执行关于以及用于检测当前崩溃工具，并提供更详细的故障信息。此外，在研究分析八套房产世界的Android应用程序崩溃，我们觉得CRASHSCOPE应付的报告是易于阅读和呈现比人书面报告更明确的信息，允许崩溃的可靠再现。

   1 引言

   移动硬件和应用市场的持续增长是由一种景观驱动的，用户倾向于在桌面上使用移动智能设备和应用程序来完成任务。移动应用程序的手势驱动特性已经引起程序员在开发和维护过程中遇到的新挑战，特别是关于测试和调试^[41]。最困难的^[22]，^[24]和重要的维护任务是创建和解决错误报告^[35]。有关应用程序崩溃的报告对开发人员来说特别重要，因为崩溃代表了直接面向用户的软件故障，并立即影响应用程序的实用性和成功性。如果一个应用程序由于崩溃、丢失的特征或其他错误而不符合预期，那么将近一半的用户可能会在市场上放弃应用程序^[12]，比如Google Play^[10]。

   移动开发者严重依赖于用户评论^[42]、^[49]、^[65]，以堆栈跟踪的形式从现场崩溃报告，或者在开源问题跟踪系统中报告其应用程序中的bug。在每一种情况下，错误/崩溃报告通常缺乏信息^[27]，^[41]，仅包含堆栈跟踪、过于详细的日志或关于崩溃的松散结构化自然语言信息^[23]。这并不奇怪，因为先前的研究表明，对于解决bug报告的开发者（例如，复制步骤、堆栈跟踪和测试用例）最有用的信息通常是记者提供的最困难的信息^[33]。此外，这种信息的缺失是开发者无法重现bug /崩溃报告的主要原因^[22]。除了报告的质量之外，Android应用程序中的一些其他因素如硬件和软件碎片^[3]、API不稳定和错误倾向^[21]、^[48]、Android应用程序的事件驱动性质、基于手势的交互、传感器接口以及多个上下文状态（例如WIFI/GPS ON/OFF）的可能性。检测、报告和再现碰撞的过程具有挑战性。

   2 相关工作与动机

   2.1 移动应用程序的输入生成和测试工具

   自动输入生成的方法可以大致分为三大类：基于随机的输入生成^[7]，^[11]，^[53]，^[68]，^[76]，系统输入生成^{[18 ]-[20]},和基于模型的测试^[18]，^[20]，^[28]。基于随机的输入生成技术依赖于选择任意的GUI或上下文事件；它们可以通过将选择偏置过去事件的频率，并有目的地选择先前未被锻炼的那些来适应这样的策略。DyNODROID^[53]通过在整个执行过程中跟踪相关事件的上下文敏感的方式来保持事件执行频率的历史。Intent Fuzzer^[68]通过考虑离线静态分析阶段中提取的信息来生成测试应用程序的意图。然而，由于需要存储在内存中的路径数量来处理大型应用程序，所以它不容易缩放，而只测试应用程序意图。VanarSena ^[66]是一种工具，用于Windows Phone工具的应用程序二进制文件，以测试应用程序的外部可诱导的故障，使用随机勘探和注射不利的上下文条件。VanarSena能够生成包含堆栈跟踪和异常的崩溃报告。与VanarSena相比，CRASHIST不需要任何类型的仪器，能够生成更详细的碰撞报告，包括截图、自然语言再现步骤和可重放脚本。

   系统输入生成方法根据预先定义的启发式（如广度或深度优先搜索（BFS/DFS））执行输入事件。例如，AndroidRipper动态分析应用程序的GUI，目的是获得可触发的事件序列。然后，它根据应用程序的GUI层次结构提取任务列表，并系统地执行生成列表中的事件。A3E ^[20]利用静态字节码、污点样式和数据流分析来构建高级控制流图，该图捕获应用程序屏幕（活动）之间允许的转换。该工具实现了基于该图的两种勘探策略：一种简单的DFS和目标勘探。ACTEve ^[19]是一种基于混合语言的智能手机应用程序测试方法，它象征性地跟踪事件从开始点到处理点。

   2.2 之前关于移动应用程序错误/崩溃的研究

   移动应用程序错误/崩溃研究的激励因素帮助我们设计了崩溃范围。Ravindranath等人^[66]对“Windows Phone错误报告系统”（WPER）用户收集的2500万份真实的崩溃报告进行了研究。尽管这项研究是针对不同移动操作系统的崩溃进行的，但由于平台的相似性，本研究报告的几个发现在Android环境中是相关的：

   1）少量的根本原因覆盖了大多数被检查的崩溃；

   2）许多崩溃可以映射到定义良好的外部诱导性故障，例如，网络连接问题引起的HTTP错误；

   3）主要的根本原因可以影响应用程序中的许多不同用户执行路径。

   此外，Zaeem等人^[79]对13个开源Android应用程序中的106个bug进行了bug研究，目的是找出自动生成包含Oracle的测试用例的机会。最值得注意的是，这项研究的结果被定义为不同Android应用程序缺陷的分类。具体来说，这些分类被分为三个标题：基本Oracle、不可知应用程序的Oracle和特定应用程序的Oracle。CrashScope使用定义良好的未捕获异常和应用程序崩溃的Oracle来检测故障；但是，本研究中的一些错误分类对于触发这些错误非常有用，特别是应用程序不可知的旋转分类、活动生命周期和手势。具体来说，我们实现了双旋转功能的目标（即本地化）版本^[79]。

   3 破碎机设计

   3.1 提取活动和应用程序级上下文功能

   CrashScope使用基于抽象语法树（ast）的分析来提取上下文功能调用中涉及的API调用链。它检测与网络连接和传感器（即加速度计、磁强计、温度传感器和GPS）相关的Android API调用。由于API调用可能不会直接由活动执行，CrashScope执行调用图分析以提取以调用上下文API的方法结束的路径。由于某些API调用可能无法通过反向传播的调用链（例如，传感器或作为服务实现的网络）进行跟踪，CrashScope使用两种粒度来测试上下文功能：活动（屏幕）级别和应用程序级别。如果与上述某个上下文功能相关的特定API调用能够追溯到某个活动，那么该功能稍后将在活动级别进行测试（当相应的活动位于前台时，启用或禁用上下文功能）。如果该功能无法链接到某个活动，则在整个应用程序的级别测试该功能（在应用程序执行开始时启用或禁用上下文功能）。为了获得可旋转的活动，crashscope解析androidmanifest.xml，其中必须声明可旋转的活动。在测试期间，如果在浏览应用程序时遇到可旋转的活动，那么在进行任何GUI交互以测试相应旋转事件处理程序的正确实现之前，屏幕将从纵向旋转到横向，然后再向后旋转。

   3.2 应用程序探索和故障检测

   为了探索一个应用程序，crashscope动态地提取在探索过程中访问的每个应用程序屏幕的GUI层次结构，并识别要执行的可点击和长可点击组件，以及用于文本输入的可用组件（如编辑文本框）。将组件添加到工作列表中，以确保系统地执行所有可单击组件。CrashScope根据GUI层次结构在当前屏幕上执行每个可能的事件（在可用的GUI组件上的操作）。如果文本输入字段在特定的应用程序屏幕中可用，那么在执行屏幕上的每个组件之前，将填充每个文本框。目前，我们的翻录引擎支持tap、long tap和type事件。用户输入的文本是许多Android应用程序功能的主要部分，因此，CrashScope的GUI翻录引擎采用了独特的文本输入生成机制。crashscope通过查询与文本字段^[4]关联的键盘类型，检测文本字段预期的文本类型（如数字）。这是通过adb shell dumpsys input_method命令完成的。一旦检测到预期输入的类型，crashscope就使用两种策略来生成文本输入：预期输入和意外输入。预期策略在键盘参数中生成一个不带任何标点或特殊字符的字符串，而预期策略生成随机字符串，其中包含给定键盘类型的所有允许特殊字符。这种输入生成机制背后的直觉是测试一些实例，其中开发人员可能在不知情的情况下设置了一个允许某些字符的键盘，但没有在代码中正确地检查这些字符，从而导致错误。

   除了文本输入生成策略之外，崩溃范围从层次结构的底部向上或从层次结构的顶部向下遍历GUI层次结构。拥有两个这样的策略的基本原理通常是模拟用户将要做的事情，即在没有预先定义的顺序的情况下执行GUI事件。如果在探索过程中记录到另一个屏幕的转换，则会检测到新屏幕的GUI层次结构，然后执行新屏幕上的组件。gui-ripping引擎构建一个包含所有可能的转换状态的图形，并在特定分支中的可执行组件用完后使用back按钮返回到以前的状态。它还保存了所有尚未访问的组件的堆栈。为了检测和捕获异常，crashscope过滤logcat以查找仅与正在测试的应用程序相关的未捕获异常。为了检测崩溃，crashscope会检查标准Android崩溃对话框的外观。如果遇到崩溃，执行信息会记录到数据库中，但由于转换图和未访问组件的堆栈，执行可以继续向其他剩余程序路径执行，而无需从头开始执行。

   剩余内容已隐藏，支付完成后下载完整资料

   ---

   资料编号：[19756]，资料为PDF文档或Word文档，PDF文档可免费转换为Word