android 弹出框崩溃_ATReG: Android 自动化测试驱动众包测试需求生成

南京大学智能软件工程实验室

iselab.cn

摘要

众包测试为解决 Android 应用测试面临的 Android 系统碎片化和应用场景多样性的问题提供了有效途径。生成测试需求是众包测试的一项重要任务。在传统的众包测试中，部分人工生成的测试需求内容不够明确，单个测试需求中涉及多个功能点，不易于众包工人理解。为了解决需求生成问题，我们开发了基于自动化测试结果派生测试需求的工具，ATReG，可以提升众包测试任务的分发速度，提高众包测试效率。ATReG 通过引入动态测试技术和静态分析技术，构建 Android 应用程序的 GUI 模型，采用搜索策略生成覆盖目标需求的最短操作路径，从而形成众包测试需求。通过实验验证，ATReG 生成的测试需求是易于理解的，并且可以帮助实现对目标需求的高覆盖率。演示视频可以通过https://youtu.be/EWjU0JblAbg获得。

关键字：静态分析 众包测试 测试需求

1 介绍

Android 应用以快速迭代的开发模式占据了大部分移动应用市场，但是 Android 系统日益严峻的碎片化问题向 Android 应用的质量提出了挑战。此外，多样的应用场景以及频繁的迭代周期使 Android 应用测试变得越来越困难，许多开发者通过使用众包测试和自动化测试解决 Android 应用测试面临的困境。

众包测试是指任务请求者向来着不同区域的众包工人发起测试请求，众包工人完成测试任务并提交测试报告。通过众包测试可以获得使用不同手机型号、处于不同测试环境的众包工人对产品使用的真实反馈。对于众包测试而言，生成测试需求是一项重要任务。在传统的众包测试过程中，测试需求是根据需求文档人工生成的，部分人工划分后的需求涉及面广，众包工人无法直观的理解具体需求。此外，对于执行操作简单的测试需求，使用自动化测试工具可以实现，采用众包测试的方式会导致资源的浪费。

Android 自动化测试通过模拟用户交互事件和系统事件，遍历 Android 页面组件并探索应用程序状态，通过产生测试输入检测应用程序中存在的异常。然而，Android 自动化测试的结果不易于程序员和测试人员理解，无法通过测试结果直观地获得有效的测试需求。此外，自动化测试检测出的异常对应用是否具有影响这是未知的。

因此，我们将 Android 自动化测试和众包测试相结合，开发了 ATReG 工具用以生成众包测试需求，解决了众包测试中测试需求不易理解和自动化测试检测的异常影响不明确的问题。ATReG 使用 Android 自动化测试技术和静态程序分析技术，构建 Android 应用的 GUI 模型。采用搜索算法获取覆盖目标需求的最短操作路径。实验结果表明通过 ATReG 生成的测试需求具有很强的可读性，并且对目标需求可以达到较高的覆盖率，少部分测试需求会对应用产生影响。

在本文中，我们主要做出了以下贡献：

• 我们为 Android 自动化测试和众包测试建立了连接，通过生成众包测试需求，探索 Android 自动化测试检测出的异常对 Android 应用的影响。
• 我们将动态测试技术和静态分析技术相结合，探索 Android 应用中未知的路径，允许众包工人发现更多潜在的异常。
• 我们提出了 ATReG，基于 Android 自动化测试驱动众包测试需求生成的工具，生成的测试需求易于理解并且可以有效的覆盖目标需求。

2 工具实现

图 1：ATReG 架构

ATReG 的架构如图 1 所示。首先，ATReG 通过分析 Android 自动化测试工具对 APK 的测试结果，获取执行操作并提取测试过程中触发的 Bug。然后，使用静态程序分析技术获取未覆盖的窗口，结合自动化测试的事件序列构造 Android 应用的 GUI 模型。最后，使用 Dijkstra 算法获取从应用程序入口界面到达 Bug 界面的最短路径操作，这些操作被语义化成自然语言。ATReG 根据触发的 Bug 和未覆盖的窗口生成众包测试需求，让众包工人对 Bug 进行复现或者探索未覆盖的窗口。

2.1 构建 GUI 模型

Android GUI 模型的构建流程如图 2 所示。我们使用慕测平台的 Android 自动化测试工具和静态分析技术分别解析待测应用程序。ATReG 通过对工具的解析结果进行分析和处理，生成待测应用的 GUI 模型。模型包括自动化测试过程中操作事件引起的正常窗口跳转、异常窗口跳转，以及通过静态分析得到的未覆盖窗口。

图 2：GUI 模型构建流程

在自动化测试过程中，Android 自动化测试工具不仅会记录测试事件序列，还会保存测试事件发生前的 Android 页面运行截图。我们使用截图信息辅助展示测试需求的测试步骤，结合用户交互事件中相关组件的坐标信息，标注事件作用的窗口组件，突出显示具体的测试步骤。下面介绍对截图处理的步骤：

应用程序“简诗”的部分 GUI 模型如图 3 所示。由于两个窗口之间可能存在多种跳转方式，GUI 模型中两个节点同一方向上可能存在多条边，为了便于展示，对于某个方向上存在跳转的两个节点，图 3 只选取两个节点在该方向上的一条边。图中红色箭头代表异常窗口跳转，蓝色节点代表未覆盖的窗口，黑色箭头和节点分别代表正常窗口跳转和已覆盖的窗口。

图 3：应用程序“简诗”的部分 GUI 模型

2.2 生成测试需求

通过构造 Android 应用的 GUI 模型，将 GUI 模型中的异常跳转生成众包测试需求。使用 Dijkstra 算法获取从应用程序入口界面到达 Bug 界面的最短操作路径，这些操作被转义成易于理解的自然语言。对每一步操作附加操作截图并标注触发的控件(图 4)。对于 GUI 模型中自动化测试未覆盖的窗口，我们将其生成众包测试需求，让众包工人对未覆盖的窗口进行探索(图 5)。

图 4：异常跳转的众测需求

图 5：未覆盖窗口的众测需求

众包测试需求的示例如图 4 和图 5 所示，图 4 是异常跳转的众包测试需求，主要包括三个主要部分：基本信息(图 4 , PartA)，包括应用名称、应用版本号、设备型号和网络情况。目标需求(图 4, PartB)，包括异常信息和异常信息截图，这是测试需求中预期出现的异常。步骤列表(图 4, PartC)，包括每个步骤的操作描述以及对应的步骤截图，并在截图中用红色框标注触发的控件。图 5 是未覆盖窗口的测试需求，包含两个部分，已覆盖的窗口截图(图 5 , PartA)和待探索的窗口的名称(图 5, PartB)。

3 实验

为了评估 ATReG 生成的测试需求的可读性和有效性。我们希望解决以下研究问题：

RQ1：ATReG 生成的测试需求的可读性如何？

RQ2：ATReG 生成的测试需求是否可以覆盖目标需求，是否会对应用产生影响？

我们选择“JianShi”、“Bilibili”等共十款开源的 Android 应用作为待测应用，使用 ATReG 生成测试需求，共挑选了 50 名众包工人参与实验，实验的众包工人主要来着软件工程专业的大四到研三之间的学生。

为了探讨 RQ1，我们通过问卷调查的形式收集 50 名参与者对生成的测试需求的可读性满意度，收集这样一批专业素养较高的众包工人对 ATReG 的评价，其统计结果具有更高的参考价值，测试需求的可读性满意度结果如图 6 所示。从统计结果发现，绝大多数众包工人对 ATReG 生成的测试需求的可读性持有积极的态度，少部分众包工人表现出消极态度，我们通过进一步调查这部分众包工人评较低分的原因，总结出是由于测试需求中的预期目标描述不够详细，影响众包工人对目标需求的判定。

图 6：测试需求的可读性满意情况

为了探讨 RQ2，我们将众包工人分为十组，对于每款待测应用选择 5 人进行测试需求验证实验。众包工人通过使用待测应用遵循 Bug 测试需求的步骤，检验 Bug 测试需求中的目标需求是否可以被覆盖，并且观察对应用是否会产生影响。对于同一个 Bug 测试需求，当有 3 人或 3 人以上都可以覆盖目标需求，我们就认为目标需求是可覆盖的，对于可覆盖的测试需求当有 3 人或 3 人以上都认为对应用有影响，则认为测试需求对应用会产生影响。

表 1：测试需求的评估结果

表 1 是测试需求的评估结果，“需求数量”是 Bug 测试需求的数量，“覆盖数量”是目标需求可以被覆盖的测试需求数量，“影响数量”是会对应用产生影响的测试需求数量。由表 1 可知 Bug 测试需求的平均可覆盖率为 96.1%，平均影响率为 39.2%。通过进一步分析得知，由于受特定环境(如设备型号，网络环境)的影响，一些测试需求无法被覆盖。对于平均影响率较低的现象，是因为有些 Bug 是人感知不到的，并非 UI 级别或者崩溃级别的 Bug。由此可以得出，通过 ATReG 生成的测试需求可以有效的覆盖目标需求，少部分测试需求会对应用产生影响。

4 结论

本文提出了一个基于 Android 自动化测试驱动众包测试需求生成的工具，ATReG。ATReG 通过将动态测试技术和静态分析技术结合探索 Android 应用未知的路径，将 Android 自动化测试和众包测试相连接生成众包测试需求，众包测试需求包括异常跳转的测试需求以及未覆盖窗口的测试需求。实验证明 ATReG 生成的测试需求具有很强的可读性，对异常跳转的目标需求平均覆盖率达 96.1%，对应用的平均影响率为 39.2%。

致谢

本文由南京大学软件学院 2019 级硕士郭超翻译转述。

感谢国家自然科学基金(61932012，61802171，61772014)支持！