真正的黑盒测试自动化：用机器人测试移动应用程序

关键摘要

• Axiz 的原型使用成品硬件组件搭建而成，包括基于 3D 视觉的自校准系统和基于 Arduino 的四轴机器人手臂。它通过外置的 CMOS 1080 像素的摄像头监控测试执行。
• 基于机器人的测试可以解决从桌面到移动计算的巨大转变所带来的挑战，并且可以更轻松地对 UI 手势和传感器输入等特性进行测试。
• 诸如 Appium 、 Robotium 和 UIAutomator 之类的框架可以实现一定程度的自动测试执行。 然而，它们依赖人工来设计测试脚本，就会成为瓶颈。
• 手持设备的出现使我们需要重新考虑黑盒测试的真正含义，这涉及到增强真实性、设备独立性、成本效益比和减少对假设的依赖等诸多因素。
• 实验证明，Axiz 准确地执行了机器人测试生成的用例中包含的每个测试事件，并通过了所需的预置检查点。

本文最初发表于 IEEE Software 杂志。IEEE Software 杂志提供了有关当今战略技术问题的可靠的、经过同行评审的信息。为了应对运营可靠而又灵活的企业的挑战，IT 经理和技术主管需要依靠 IT 专业人员提供最先进的解决方案。

机器人被广泛应用于大量重复性任务。 那为什么不将它用于软件测试？机器人测试向测试人员展现了一种新的测试形式，比以前所见过的都更接近黑盒测试。为此，我们开发了 Axiz，用于移动应用的机器人测试生成器。在这篇文章中，我们将我们的方法与基于模拟的测试自动化进行比较，描述了一些能从使用机器人测试中获益（甚至是必须使用机器人测试）的场景，并展示了我们如何将 Axiz 应用于 Google 计算器应用程序的测试。

为什么要使用机器人测试？

基于机器人的测试可以解决从桌面到移动计算的巨大转变所带来的挑战 [1][2]。随着人们的常用设备从桌面设备转变为移动设备，这一转变趋势预计将会加速爆发 [3]。在这个新兴的移动世界中，我们比以往任何时候都需要自动化软件测试。但是，我们可能需要重新考虑软件测试的一些原则。

移动设备支持丰富的用户交互输入，比如通过触摸屏进行手势操作、通过传感器（GPS、加速度计、气压计、NearId 通信等）得到各种信号。它们为异构和动态环境中的大量用户提供服务，例如地理位置和网络基础设施。为了全面地探索和发现缺陷，测试必须考虑在各种测试场景下与各种传感器的复杂交互。一项关于移动应用程序开发的调查表明，目前移动应用测试实践主要依赖手工测试，而手工测试本身是低效且存在偏差的 [4]。诸如 Appium 、 Robotium 和 UIAutomator 等框架可以实现一定程度的测试自动化。然而，它们依赖人工来设计测试脚本，就会成为瓶颈。

幸运的是，Android 测试自动化相关研究最近有了很多新进展 [5][6][7][8]。然而，这些技术使用侵入式（部分或全部白盒）方法执行测试用例，并且假设测试工具享有开发者权限，而实际情况并不总是如此。

这些技术中很多需要修改应用程序代码甚至操作系统，而最接近黑盒测试的方法仍需要通过测试套件与被测应用程序（AUT）通信。这不是真正的黑盒测试，因为它依赖于测试套件与被测应用程序之间的机器对机器接口。

真正的黑盒测试方法将不会作假设，而只依赖于人与应用之间的设备级网络物理接口。在这个抽象级别进行测试能更好地模拟真实用户的体验，从而可以得到更接近真实场景的测试用例。此外，这种方法本质上是与设备无关的，在可能涉及 2000 多个不同待测设备的情况下可以带来相当大的好处 [9]。

机器人测试宣言

手持设备的出现使我们需要重新考虑黑盒测试的真正含义。移动应用程序的用户体验与桌面应用程序截然不同，现有的机器对机器黑盒测试缺乏真实性、使用情况敏感度以及快速并廉价地生成可操作的测试用例所需的跨平台灵活性。

本节列出了机器人测试的宣言，采用这套方法生成的测试用例能以真正的黑盒（完全非侵入式）方式执行。表 1 对手动测试、基于模拟的测试和机器人测试进行了比较。

增强真实性

对于 Android 测试，MonkeyLab 基于应用使用数据生成测试用例 [10]。研究人员还发布了几种方法用于为 Web 系统提供真实的自动化测试输入 [11]。然而，这些基于自动化测试输入的系统并不是针对移动平台的，而在关于如何生成自动化测试输入的文献中对测试用例的真实性几乎没怎么提到。

如果开发人员认为测试集与真实情况不一致，他们就不会对出现崩溃的测试集采取任何行动。此外，由于缺乏领域知识，与真实情况不符的测试会让自动测试数据的生成变得很困难。移动计算还引入了另外一个问题：人类可能无法执行测试。例如，测试可能需要使用超过五个手指同时点击屏幕。

相比之下，机器人测试套件可以模拟人的手势操作。虽然可能有一部分手势是机器人无法模拟的（还有一些手势可能机器人可以操作但人类无法重复），但至少机器人手势同为身体手势。因此，相比现在的非机器人测试环境模拟的虚拟手势——只是简单地在被测设备端生成一系列事件，机器人手势更接近真实的人机交互。

设备独立性

目前已有的白盒自动化测试和（声称的）黑盒自动化测试都需要修改被测设备和操作平台中的一个或两者皆要修改。即使是所谓的黑盒技术也是通过模拟信号与应用程序通信，而不是通过移动设备上真实存在的传感器（例如触摸屏或重力传感器）触发的信号。

如前所述，机器人测试使用与人类用户相同的网络物理接口。它不太容易受到底层平台、API 接口和实现细节的变化的影响。在如今这个上市时间至关重要的世界，能够在不同平台上进行快速部署是一个相当大的优势。

更好的成本效益比

人工测试是相当昂贵的，虽然它有更好的真实性和设备独立性。反之，目前的自动化测试数据生成则相对便宜，仅依赖于计算时间，但它缺乏真实性和设备独立性。机器人测试则能达到最佳的成本效益比，它结合了人工测试和机器对机器自动测试的优点。

虽然从历史上来看机器人技术曾经非常昂贵，但如今机器人技术的成本正在迅速下降。虽然众包也可以降低人工测试的成本 [12]，但说到底还是不可能比机器人测试更便宜。

减少对假设的依赖

传统的自动化测试对被测系统提出了许多假设，而人工测试生成测试数据时提出的假设较少。机器人测试在提出假设的数量上更接近人工测试，但是它能够低成本地生成大量测试用例这一点则更接近现有的自动化测试。

Axiz

图 1 展示了 Axiz 的架构，包括两个高级组件：机器人测试生成器和机器人测试执行器。

机器人测试生成器

机器人测试生成器分析被测设备，并使用提取到的信息（包括应用程序类别、静态字符串和 API）来调整真实性模型。该模型使用之前收集的经验数据，其中包括已知的真实场景测试用例。

表 1：选择手动测试、基于模拟的测试或机器人测试的参考标准

基于对用户使用情况的观察结果，我们得到了一个完整的属性列表（例如两个相邻事件之间的延迟、事件类型和事件模式），其中涵盖了潜在的真实场景测试用例的特征和属性。我们希望这些特征能够反应真实用户环境中发生的情况，以便 Axiz 利用它们来指导和约束自动化测试数据生成。

图 1. Axiz 机器人测试系统的架构。机器人测试生成器生成基于真实场景的测试用例。机器人测试执行器剔除无法执行的测试用例并执行其余的测试用例。

机器人测试生成器将真实性模型和被测设备信息传递给进化搜索组件，以生成和改进测试用例。这些测试用例的真实性来源于两个方面。首先，我们通过重用和扩展基于真实场景的测试用例（例如 Robotium 或 Appium 测试脚本），改进应用程序测试人员以前手动编写的测试。其次，通过搜索由真实性模型约束的解决方案空间，重点生成满足早先由众包测试确定的约束条件的测试用例。

我们基于测试用例的性能（如代码覆盖率和故障发现率）和由真实性模型评定的真实性来评估生成的测试用例的质量。

机器人测试执行器

我们通过在真实设备上执行用例来进一步验证候选的测试用例，使这些用例与用户或手动测试人员操作的方式大致相同。机器人测试执行器将代码形式的测试脚本转换为机器可执行的命令，然后在机器人手臂上执行它们。

机器人手臂可以与移动设备进行非侵入式地交互，就像人类一样。这个过程需要利用反向运动学和校准组件使操纵器的动作更准确。摄像头监控移动设备的状态。机器人测试执行器通过计算机视觉技术进一步处理来自摄像头的图像数据，包括执行对象检测和预测点对照。

最后，机器人测试执行器将执行过程中记录的所有过程数据发送到测试筛选器，以确定候选测试用例是否可以在真实场景中执行。如果无法执行，测试执行器会将其过滤掉。否则，Axiz 将保存该测试用例以便后续再次使用。

Axiz 原型实现

我们开发了 Axiz 的原型来演示这套系统的可行性（见图 2）。我们使用一套廉价、适用性广且通用的成品硬件组件来开发这个原型。我们使用 3D 视觉自校准功能 [13] 来校准和调整机器人的机械手，使系统得以可靠运行，并为预测点对照器提供输入。

机械手是一个基于 Arduino 的四轴机器人手臂。它由重复定位精度为 0.2 mm 的步进电机驱动。每个轴的最大移动速度从 115 至 210 度 / 秒不等（这是负载为 200 克时的计算结果，这个最大移动速度对于大多数移动设备来说都已经足够大了）。在机械手的末端是用于模拟手指手势的触控笔。

一个外置的 CMOS 1080 像素摄像头监控测试执行。我们在配置有 2.3GHz CPU 和 16GB RAM 的 MacBook Pro 笔记本电脑上运行测试生成器和机器人控制器。

我们利用 Python 中的反向运动学组件控制机器人手臂。对象检测器和预测点对照器则基于 OpenCV 库实现。机器人测试生成器使用（目前最先进的）工具 Sapienz[14] 并应用 NSGA-II（非支配排序遗传算法 II）——一种广泛使用的多目标遗传算法，进行基于多目标搜索的软件测试。这个工具可以生成一系列测试事件，用最少的测试事件实现更高的测试覆盖率和故障发现率。

Axiz 与 Google 计算器应用程序

Google 计算器应用程序的安装数已经达到了 500 万到 1000 万次 [15]。虽然 Google 计算器的功能很简单，但不失为一个非常重要的基于真实场景的应用程序，因此通过它能够展示真正的黑盒机器人测试的潜力。

我们使用机器人测试生成器来生成与真实场景相符的测试用例，并用机械手臂执行测试。 被测设备是 Nexus 7 平板电脑，配置了普通的用户权限和 Android 官方操作系统（无需修改）。作为对比，我们使用另一台 Nexus 7，并对它进行更传统的侵入式测试。第二台 Nexus 7 直接连接到 MacBook 上的机器人控制器。它对应的测试工具具有开发者权限，并且可以修改操作系统。

图 3 展示了整个测试过程。MacBook 的解释器组件将事件指令转换为机器人手臂控制器的运动规律。然后该控制器基于反向运动学将运动规律转换为关节角度指令。如图 3 所示，机器人手臂点击第一台 Nexus 7 上的按钮执行测试。预测点对照器监控每一个测试事件。在执行每一个测试步骤之后，预测点对照器通过外置摄像头捕获图像并验证移动 GUI 的状态。

Axiz 准确地执行了生成的机器人测试用例中每一个测试事件，并通过了所需的预置检查点，使 Sapienz 的能力得以发挥到极致。

图 2：用四轴机器人手臂测试移动应用程序。我们使用一套廉价、适用性广且通用的成品硬件组件进行开发。

图 3：使用 Axiz 测试一个真实的计算器应用程序。Axiz 准确地执行了生成的机器人测试用例中每一个测试事件，并且通过了所需的预置检查点。

Axiz 执行测试的视频可以在这里查看。在这个视频中，我们将 Axiz 与传统的自动化测试工具并排展示，后者不使用机器人手臂，而只是产生一系列测试事件。该视频表明，用廉价的成品硬件开发的机器人手臂可以产生一组相同的测试事件，但更接近真实的使用场景，从而实现更好的设备独立性和真实性。

致谢

我们感谢 Andreas Zeller 在第 36 届 CREST（进化、搜索和测试研究中心）开放研讨会 [16] 上所作的演讲，在演讲中他展示了一个有趣的视频，视频中一款人造手臂自动与移动设备进行交互。这成为了我们研究的灵感之一。

参考资料

1. F. Richter, “ Global PC Sales Fall to Eight-Year Low ,” 14 Jan. 2016.
2. “ Global Smartphone Shipments Forcast from 2010 to 2019(in Million Units)
3. “ Worldwide Device Shipments to Grow 1.9 Percent in 2016, While End-User Spending to Decline for the First Time ,” Gartner, 20 Jan. 2016.
4. M.E. Joorabchi, A. Mesbah, and P. Kruchten, “Real Challenges in Mobile App Development,” Proc. 2013 ACM/IEEE Int’l Symp. Empirical Software Eng. and Measurement (ESEM 13), 2013, pp. 15–24.
5. A. Machiry, R. Tahiliani, and M. Naik, “Dynodroid: An Input Generation System for Android Apps,”Proc. 9th Joint Meeting Foundations of Software Eng. (ESEC/FSE 13), 2013, pp. 224–234.
6. D. Amalfitano et al., “Using GUI Ripping for Automated Testing of Android Applications,” Proc. 27th IEEE/ACM Int’l Conf. Automated Software Eng. (ASE 12), 2012, pp.258–261. 10.
7. W. Choi, G. Necula, and K. Sen, “Guided GUI Testing of Android Apps with Minimal Restart and Approximate Learning,” Proc. 2013 ACM SIGPLAN Int’l Conf. Object Oriented Programming Systems Languages & Applications (OOPSLA 13), 2013, pp. 623–640.
8. K. Mao, M. Harman, and Y. Jia, “Sapienz: Multi-objective Automated Testing for Android Applications,”Proc. 25th Int’l Symp. Software Testing and Analysis (ISSTA 16), 2016, pp. 94 –105.
9. A. Reversat, “ The Mobile Device Lab at the Prineville Data Center ,” Facebook, 13 July 2016.
10. M. Linares-Vasquez et al., “Mining Android App Usages for Generating Actionable GUI-Based Execution Scenarios,” Proc. 12th Working Conf. Mining Software Repositories (MSR 15), 2015, pp. 111–122.
11. M. Bozkurt and M. Harman, “Automatically Generating Realistic Test Input from Web Services,” Proc. IEEE 6th Int’l Symp. Service Oriented System Eng. (SOSE 11), 2011, pp. 13 –24.
12. K. Mao et al., “ A Survey of the Use of Crowdsourcing in Software Engineering ,” J. Systems and Software, 2016.
13. J.M.S. Motta, G.C. de Carvalho, and R. McMaster, “Robot Calibration Using a 3D Vision-Based Measurement System with a Single Camera,” Robotics and Computer-Integrated Manufacturing, vol. 17, no. 6, 2001, pp. 487–497.
14. “ Calculator ,” Google, 2016.
15. A. Zeller, “ Where Does My Sensitive Data Go? Mining Apps for Abnormal Information Flow ,” presentation at 36th CREST Open Workshop (COW 36), 2014.

关于作者

Ke Mao是伦敦大学学院进化、搜索与测试研究中心（CREST）的研究生。读者可以通过 k.mao@cs.ucl.ac.uk 与他联系。

Mark Harman是伦敦大学学院进化、搜索与测试研究中心（CREST）的主任。读者可以通过 mark.harman@ucl.ac.uk 与他联系。

Yue Jia是伦敦大学学院进化、搜索与测试研究中心（CREST）的软件工程讲师。读者可以通过 yue.jia@ucl.ac.uk 与他联系。

本文最初发表于 IEEE Software 杂志。IEEE Software 杂志提供了有关当今战略技术问题的可靠的、经过同行评审的信息。为了应对运营可靠而又灵活的企业的挑战，IT 经理和技术主管需要依靠 IT 专业人员提供最先进的解决方案。

查看英文原文： Robotic Testing of Mobile Apps for Truly Black-Box Automation

感谢薛命灯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。