【论文写作】实现部分的剖析 ICSE2020

背景

Time-travel Testing of Android Apps

ICSE 2020

新加坡国立大学

4 Implementation

实施 我们的时间旅行框架作为一个全自动化的应用测试平台实施，它使用或扩展了以下工具：VirtualBox [4]，用于运行和控制Android-x86 OS [6]的Python库pyvbox [11]，用于观察状态转换的Android UI Automator [10]，以及用于与被测试应用交互的Android Debug Bridge (ADB) [5]。图3展示了我们平台的架构概览。灰色部分是我们实施的组件，而其他部分是我们使用或修改的现有工具。

使用或者扩展的工具

为了收集覆盖率，我们的框架使用Emma [9] （语句覆盖率）对开源应用进行检测，并使用Ella [8] （方法覆盖率）对闭源应用进行检测。Ella采用客户端-服务器模型通过套接字连接从Android OS将覆盖数据发送到VM主机。不幸的是，每次恢复快照时，这个连接都会断开。为了解决这个问题，我们修改了Ella，让其在Android OS上保存覆盖数据，以便在需要时主动拉取。

Emma、Ella对覆盖率进行检测，并且小改Ella

在时间旅行框架的基础上，我们实现了TimeMachine。为了方便分析所有的基准测试，我们将TimeMachine与两个Android版本集成。TimeMachine与使用最广泛的版本Android Nougat（具有API 25的Android 7.1）一起工作。然而，为了在AndroTest基准测试[23]上进行端到端的比较，我们还在Android KitKat版本上实现了TimeMachine（具有API 19的Android 4.4）。Sapienz [36]（我们实验的最先进/实践基线）的公开版本限制为Android API 19，并不能在Android 7.1上运行。为了收集状态级反馈，我们修改了Android Monkey和UI Automator，以监视每个事件执行后的状态转换。TimeMachine还包括一个从Stoat [40]中获取的系统级事件生成器，以支持如电话和短信等系统事件。

我们使用两个安卓版本，对照组的安卓版本分别是什么

5 EMPIRICAL EVALUATION

在我们的实验评估中，我们试图回答以下研究问题：

• RQ1 我们的时间旅行策略在实现更多代码覆盖率和找到更多崩溃方面的效果如何？我们将TimeMachine与其实现的基线进行比较。

• RQ2 在实现代码覆盖率和发现崩溃方面，时间旅行测试（即TimeMachine）与最先进的技术相比如何？

• RQ3 时间旅行测试（即TimeMachine）在较大的实际应用中（例如工业应用和来自Google Play的前100个应用）的表现如何？

RQ:模型在代码覆盖率和寻找更多bug方面与基线、最先进技术比较，在实际应用的表现。

5.1 实验设置

为了回答这些研究问题，我们对开源和闭源的Android应用进行了三项实证研究。

研究1. 为了回答RQ1，我们在AndroTest [23]上评估了TimeMachine和基线工具，并研究了使用时间旅行策略如何提高达到的代码覆盖率和发现的错误。我们选择AndroTest应用作为主题，因为AndroTest已成为Android的标准测试基准，并已被用来评估大量的Android测试工具[16, 20, 23, 34-37, 40, 44]。它是在2015年通过收集已经在14个Android测试工具的评估中使用的Android应用创建的。

TimeMachine将时间旅行策略应用于一个基线工具；这个基线工具是Monkey，它被扩展了Stoat的系统级事件生成器。为了准确评估时间旅行策略的有效性，我们将扩展了Stoat的系统级事件生成器的Monkey设置为基线（称为MS）。我们选择MS而不是Monkey作为基线工具，以确保TimeMachine的改进完全来自于时间旅行策略，而不是来自系统事件生成。

我们还实现了另一种Monkey的变体作为基线，以评估如状态保存和恢复等“重组件”对提高测试技术的有效性。这个变体只应用了我们的时间旅行策略中的进展缺乏检测组件，而没有状态保存和恢复组件。当检测到进展缺乏时，它只是从头开始重新测试，即重新启动正在测试的应用，而不恢复状态（称为MR）。

在TimeMachine中，参数l、maxNoProдress、α、β在Alg. 2的isStuck中被设置为10、200、0.2和0.8。这些值是在两位作者的初步实验中确定的，实验使用了AndroTest中的三个应用（Anymemo、Bites、aCal）。我们多次用Monkey执行这些应用，并记录了相关数据，比如当观察到循环时的状态转换次数，以及当Monkey从死胡同中跳出时执行的事件数量。基于观察到的数据和作者的启发式规则，我们提出了几组值，并在这三个应用上评估了它们，最后选择了上述数据作为默认参数值。在评估中，TimeMachine在所有三个研究中都使用了默认值。基线工具MS和MR使用和TimeMachine相同的参数值。

研究1，在基线工具+超参数（在三个app的初步实验上确认）

研究2. 为了回答RQ2，我们在AndroTest上评估了TimeMachine和最先进的应用测试工具，并在实现代码覆盖率和发现崩溃方面进行了比较。对于最先进的工具，我们选择了Monkey[3]、Sapienz[36]和Stoat[40]。Monkey是一个用于测试Android应用的自动随机事件序列生成器，已被报道在两项工作中[23, 42]实现了最好的性能。Sapienz和Stoat是最新的Android测试技术。这些测试工具也已经充分测试过，并在Android测试文献中是标准的基线。为了公平比较，所有技术都使用其默认配置。

研究3. 为了回答RQ3，我们评估了TimeMachine、基线工具和所有最先进的技术在大型实际的Android应用上的性能，并研究它们在闭源和开源的Android应用上是否有一致的性能。在这个评估中，我们使用IndustrialApps[42]作为主题应用。IndustrialApps是一个在2018年创建的基准套件，用来评估Android测试工具在实际应用中的有效性。作者从Google Play上每个类别的推荐应用中抽取了68个应用，并成功地用Ella[8]的修改版本对41个应用进行了工具化。在我们的实验中，我们选择使用原始版本的Ella，并成功地对工业应用套件中的37个应用进行了插桩。在这项基准测试中，我们无法与Sapienz进行比较，因为公开可用的Sapienz版本仅限于较旧版本的Android（API 19）。
为了进一步研究TimeMachine的可用性，我们在Google Play的Top-100流行Android应用上评估了TimeMachine，并研究了TimeMachine是否能有效地检测在线应用中的崩溃，即那些在撰写本文时可从Google Play下载的应用。按照一些前人[36, 40]的做法，他们将技术应用于Google Play上的最受欢迎的应用，我们主要分析了TimeMachine检测到的崩溃，并没有在这个数据集上将TimeMachine与最新的技术进行比较。Top-100流行应用是通过下载Google Play上排名最高的应用并用我们的覆盖工具Ella进行工具化，直到我们获得100个可以成功被Ella工具化的应用。

程序。为了减少实验者偏差并扩大我们的实验，我们选择在所有研究中在测试期间不提供人工辅助。对于所有的测试生成器，Android测试都是完全自动的。测试生成器都没有种子事件序列。测试过程在安装后自动开始。所有数据都是自动生成和自动处理的。我们既不提供任何输入文件，也不创建任何假账户。每个实验进行六（6）小时，并重复五（5）次，总共35580 CPU小时（≈ 4.1年）。为了减轻实验过程中随机变化的影响，我们重复了每个实验五次，并报告了平均值。相比之下，Sapienz的作者报告了一次重复一小时的实验，而Stoat的作者报告了五次重复三小时的实验。我们选择了六小时的时间预算，因为我们发现在许多应用中，三小时后的渐进覆盖率远未达到（即，没有达到饱和）。

覆盖率和崩溃。我们在六小时内测量达到的代码覆盖率和发现的错误。为了测量语句或方法覆盖率，我们使用Emma和Ella，这是在Sapienz和Stoat中使用的同样的覆盖工具。为了测量检测到的独特崩溃的数量，我们解析Logcat的输出，这是一个ADB工具，可以导出系统消息的日志。我们使用以下协议从错误堆栈中识别独特的崩溃（引用自Su等人[40]）： • 通过仅保留包含应用包名的异常（并过滤其他内容）来删除所有不相关的崩溃。 • 给出相关的崩溃信息后，只提取崩溃堆栈，并过滤掉所有不直接相关的信息（例如，“无效的文本…”）。 • 对清洗过的崩溃堆栈计算哈希值，以识别独特的崩溃。不同的崩溃应该有不同的堆栈追踪，因此有不同的哈希值。

执行环境。实验在两台具有64GB主内存的物理机上进行，运行64位Ubuntu 16.04操作系统。一台机器由Intel(R) Xeon(R) CPU E5-2660 v4 @ 2.00GHz提供动力，拥有56个核心，另一台拥有Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz的40个核心。为了允许并行执行，我们在Docker (v1.13)容器中运行我们的系统。每个Docker容器运行一个VirtualBox (v5.0.18)虚拟机，配置有2GB RAM和2核的Android 4.4，以及2核和4GB RAM的Android 7.1。我们确保每个被评估的技术在相同的工作负载下进行测试，即在同一台机器上运行所有的应用来评估所有的技术。

5.2 实验结果

5.2.1 研究1：时间旅行策略的有效性。 表1显示了每种技术在68个Android应用上达到的覆盖率和发现的错误。每个应用上的最高覆盖率和发现的最多错误以灰色高亮显示。TimeMachine和基线技术的结果显示在"TimeMachine "和"基线"列中。请回忆一下，MS表示猴子扩展了Stoat的系统级事件生成器，MR表示猴子在检测到进展缺乏时可以从头开始测试。

TimeMachine和MS的比较。TimeMachine在68个基准应用上平均实现了54%的语句覆盖率，并检测到199个唯一的崩溃。MS平均实现了47%的语句覆盖率，并检测到115个唯一的崩溃。TimeMachine覆盖了MS的1.15倍的语句，并揭示了1.73倍的崩溃。为了进一步调查这些结果，图4显示了所有68个应用的执行时间上的代码覆盖率。我们可以看到，TimeMachine在大约第20分钟开始就取得了更高的覆盖率，在执行时间结束时最终实现了7%更多的语句覆盖率。图5呈现了按应用大小分组的应用的最终覆盖率结果的箱形图，其中"x"表示每个箱形图的均值。我们看到，对于所有四个应用大小组，覆盖率的提高都很大。我们的时间旅行策略通过在68个基准应用上实现1.15倍的语句覆盖率和检测1.73倍的崩溃，有效地增强了现有的测试技术（MS）。

TimeMachine和MR的比较。MR在68个基准应用上平均实现了47%的语句覆盖率，并检测到45个唯一的崩溃。TimeMachine实现了MR的1.15倍的语句覆盖率和4.4倍的唯一崩溃。同样，图4和图5显示TimeMachine在短时间内覆盖了更多的代码，并显著提高了所有四个应用大小组的语句覆盖率，相比之下，MR。这表明，简单地在检测到进展缺乏时从头开始重启应用是不够的，尽管MR通过3%的语句覆盖率提高了Monkey（Monkey的语句覆盖率显示在表1的"最新技术"列的第三个子列中）。

状态保存和恢复以及其他组件对于增强测试技术有显著的贡献，当检测到进展缺乏时，简单地从头开始重新启动应用是不够的。

5.2.2 研究2：测试有效性。 最新技术的结果显示在表1的"最新技术"列中（ST，SA和MO分别表示Stoat，Sapienz和Monkey）。可以看到，TimeMachine实现了平均最高的语句覆盖率（54%），其次是Sapienz（51%），Stoat（45%）和Monkey（44%）。图6也显示，TimeMachine在所有四个应用大小组中实现了最高的语句覆盖率。TimeMachine也检测到最多的崩溃（199），其次是Stoat（140），Sapienz（121）和Monkey（48）

TimeMachine更好的结果可以解释如下：状态级反馈准确地识别出应用程序中哪些部分探索不足。更重要的是，不充分探索的状态可以通过恢复快照来任意地和确定地启动进一步的探索。现有的技术通常观察一个事件序列上的程序行为，这个序列通常非常长，经历了许多状态。单个状态的覆盖率反馈是不可用的。因此，我们的时间旅行框架通过提供细粒度的状态级覆盖率反馈，增强了应用程序的测试。与最新技术相比，TimeMachine在68个基准应用上实现了最高的语句覆盖率，并检测出最多的崩溃。有希望的是，我们的时间旅行框架有可能增强最新的应用测试工具，以实现更好的结果。

为了研究各种应用的性能，对于每一种正在评估的技术，我们计算出该技术在哪些应用上达到最佳性能。在语句覆盖率方面，TimeMachine在45个应用上表现最好，其次是Sapienz（19个应用），Stoat（11个应用）和Monkey（1个应用）。在检测崩溃方面，TimeMachine在32个应用上表现最好。对于Stoat、Sapienz和Monkey，分别有16个，15个和4个应用。我们进一步进行了评估技术之间检测到的崩溃的成对比较。如图7所示，TimeMachine和Stoat或TimeMachine和Sapienz发现的崩溃之间的重叠不到百分之十。与Monkey的重叠相当高。Monkey发现的约60%的唯一崩溃也被TimeMachine发现；然而TimeMachine发现了很多Monkey没有发现的新的崩溃。这个分析表明，TimeMachine可以和其他最新的Android测试技术一起使用，共同覆盖更多的代码和发现更多的崩溃。

TimeMachine在发现更多的崩溃和覆盖更多的代码方面，补充了最新的Android测试技术。

5.2.3 研究3：封闭源应用程序。 表2显示了37个封闭源基准应用程序的结果。很明显，TimeMachine在所有评估的技术中实现了最高的方法覆盖率19%和发现最多的崩溃281个。与基线MS和MR相比，TimeMachine将方法覆盖率提高到19%，分别从17%和15%提高。请注意，2%到4%的提高是相当大的，因为每个应用程序平均有44182个方法，每个应用程序覆盖的方法数量增加了大约900到1800个。在发现的崩溃数量方面，TimeMachine分别检测到比MS和MR多1.5倍和18.7倍的崩溃。MS检测到183个崩溃，MR检测到15个崩溃。

与最新的技术相比，TimeMachine在方法覆盖率和发现的崩溃数量上都显著优于它们。Stoat实现了14%的方法覆盖率，检测到3个崩溃。Monkey实现了15%的方法覆盖率和20个崩溃。出人意料的是，Stoat表现出最差的结果，比Monkey还差。更深入的检查发现，这些现实世界的应用程序使用复杂的UI容器（例如，动画），这给Stoat建立模型带来了困难。某些应用程序页面可能完全被忽视，因为与这些小部件关联的事件处理程序不能被触发。然而，由于TimeMachine和Monkey都不依赖于任何UI模型，所以它们都能克服这个问题。我们向Stoat的作者报告了这个问题，他们确认了我们的观点。

我们的时间旅行策略通过覆盖大约900个更多的方法和发现1.5倍的崩溃，显著提高了现有的技术（即，MS）。在方法覆盖率和发现的崩溃数量方面，TimeMachine也优于最新的技术（Stoat和Monkey）。

在Google Play的Top-100已进行工具测试的应用程序中，我们成功测试了87个应用程序。其余的13个应用程序由于自我保护机制（尽管它们成功地进行了工具测试）而持续崩溃。如图8所示，测试的应用程序非常多样化，被选择自超过10个类别。并不奇怪的是，它们大部分被评为超过4星，正在积极维护。

在这87个应用程序中，我们发现了137个独特的崩溃。这些都是非本机崩溃，即他们的堆栈追踪明确地指向测试应用程序中可能的错误的源代码行。检测到的137个崩溃是由图8中显示的9种异常引起的。最常见的类型是NullPointerException。

总的来说，TimeMachine在Google Play的Top-100应用程序中的25个应用程序中检测到137个独特的崩溃。

5.2.4 状态识别和时间旅行分析。

状态识别。评估显示，GUI布局适合识别应用程序的状态。这种状态抽象为应用生成可接受数量的状态，同时充分捕获状态的特征。如我们在表1和表2的"#State"列中所见，功能丰富的应用中发现了更多的状态，而简单的应用中发现的状态较少。例如，活动丰富的应用AnyMemo有311个发现的状态，而活动较少的应用Frozenbubble有15个发现的状态。对于工业应用，可以找到类似的结果。请注意，在评估中没有提供登录，因此TimeMachine可能会为一些大规模应用，如K9Mail，识别出少量的状态。

GUI布局充分捕获了应用状态的特征。平均来说，开源基准应用中找到了85个状态，工业基准应用中找到了358个状态。

频率。像Monkey这样生成非常长的事件序列的自动Android测试工具可能会陷入循环或死胡同。我们测量我们的时间旅行基础设施被使用的次数，以了解Monkey多久会卡住一次。在所有运行和应用的六个小时内，Monkey平均卡住305.6次，中位数为308.5次。如我们在图9的箱线图中所见，随着应用变得更大，恢复的次数一般会减少。这是由于状态空间的增加。更大比例的随机动作会导致尚未发现的状态，因此进度得以维持。较小的应用有小的状态空间，Monkey可能会更快地进入已经观察到的状态的循环。

平均来说，TimeMachine每小时大约返回51次到过去观察到的更有进展的状态——因为Monkey陷入了循环或死胡同。

成本。时间旅行的成本是可以接受的。在具有4GB内存的Android 7.1虚拟机上，TimeMachine花费大约10秒钟拍摄快照，恢复快照花费9秒钟。一个快照需要大约1GB的磁盘空间。对于评估中的大规模工业应用，一个会话通常生成少于100个快照。因此，就消耗的存储空间而言，TimeMachine能够在台式机上运行。此外，由于每个"有趣"的状态都存储了一张快照，通过重新配置"有趣"的定义，可以潜在地减少存储。

这对于以确定的方式达到Android测试的特定状态是一个合理的成本，尤其是对于大规模的应用。要达到一个深层的状态，人类测试者可能需要执行几十个事件，并由于Android应用的非确定性，需要多次重复这些操作。对于自动化测试生成器来说，这更难，因为它通常需要自动生成一个非常长的事件序列。这些工具因此在达到难以达到的状态时花费更多的时间，而TimeMachine通过记录和恢复"有趣"状态的快照，使可达性更容易。

时间旅行的成本是可以接受的，也适合测试有状态的程序。