A-21-FSE-Benchmarking Automated GUI Testing for Android against Real-World Bugs

一、概括：

论文针对安卓自动化测试工具在实践中如何有效和彻底地发现崩溃错误的问题，从20个开源Android应用程序中构建了52个可再现的错误数据集。实验中，论文收集近年来公开的安卓自动化测试工具在数据集上测试，发现有18个错误任何工具都无法检测到。论文分析了实验结果出现的原因，提出了安卓自动化测试的五个主要问题，并开源了一个自动化测试工具（类似Droidbot），此工具可以结合其他开源方案（如Humanoid）。

二、方法流程：

选择开源应用程序作为收集关键错误的目标，因为issue是公开的
构建数据集（从20个开源Android应用程序中构建了52个真实错误的数据集）
结合了Monkey, Ape, Humanoid, ComboDroid, TimeMachine, Q-Testing。关注点（找到的bug的数量，给定次数运行可以触发bug的次数，以及触发bug需要多长时间）
分析实验结果

三、五个主要挑战

论文分析现有GUI测试技术和工具在查找收集的错误方面的共同挑战。
现有工具的测试策略没有发现基准数据集的18个错误
这18个错误的特征

(1) 深入的用例场景

某个软件的测试中，某个bug需要点击8个页面才能找到，这8个页面每个页面都有十几个可操作的点，因此，最后跟踪到这个bug的搜索空间是80642个，测试时间内（6个小时）很难找到。
深度用例场景测试仍然是一个很难的挑战。

(2) 特定的文本输入

18个错误中的4个错误需要文本输入，而这4个错误中的3个 (≈ 75%) 需要边界值 (或无效) 文本输入，而不是有意义的文本输入。
现有的测试工具通常在没有仔细设计的情况下生成纯随机文本，因此很难检测到这些错误。
测试工具应改进用于发现错误的文本输入生成策略。除了生成有意义的文本输入之外，还应该通过分析应用程序代码或文本字段的含义，或者定义一个有风险的文本输入列表来对带某些文本输入的应用程序进行压力测试

(3) 更改系统或应用程序设置

更改系统或app设置是常见的用户行为 [23]。但是，我们发现没有一个选定的工具专门考虑了错误发现中此类更改的必要性，尤其是对于系统设置 (因为更改系统设置通常需要与系统应用设置进行交互)。这导致无法检测到此类错误。

(4) 特定的用户交互模式

WordPress的 #6530需要上传大量图片 (使上传需要一些时间) 来发布帖子，然后在上传仍在进行时删除帖子; Omeditor4android的 #637需要从其验证程序偏好页面中删除所有条目，但保留最后一个条目；commons的 #1385需要在一个特定页面上进行轮换操作; WordPress的 #8659需要向下滚动并返回站点页面 (撤销新项目的页面加载) 并选择一些特定项目。AnkiDroid的 #4200需要将一个特定的活动放在后台一段时间

(5) 外部应用程序交互

18个错误中的5个 (≈ 27.8% 个) 需要与设备上的其他应用程序进行交互以获得所需的数据 (例如，图片文件)，从而能够测试后续功能。但是，大多数工具并未在错误发现中明确考虑这些交互的必要性，而是限制在应用程序内部。

四、结论

对于目的是发现错误的搜索策略，更直接和具有更细粒度指导的探索策略更有效（APE，ComboDroid，Stoat等）
对于目的是覆盖更多GUI页面，（Humanoid、Qtesting）
GUI表示策略越精细，发现的错误就会越多。比如Humanoid用状态抽象和实际GUI图作为输入。定义适当的状态抽象标准对于发现错误很重要，一种可能的解决方案是为特定类型的应用程序或功能定义特定的粒度，以减少丢失重要状态的机会。