移动应用GUI 测试技术综述

张光兰，万莹

（四川大学计算机学院，成都 610065）

0 引言

据统计，全球智能手机用户的数量预计将从2016年的21 亿增加到2019 年的25 亿左右[1]。这导致了对运行在这些设备（应用程序）上的新软件应用程序的持续需求，而目前针对移动应用的测试方法和传统的桌面端软件的测试方法一致，可分为手工测试和自动化测试。手工GUI 测试方法，顾名思义，就是一种比较传统也比较常见的方法，其存在的问题是：人工成本高、工作进度无法评估、工作成果依赖于测试工程师的经验[2]。并且随着时间的发展，GUI 软件会变得大型化、复杂化和多元化[3]。此外，带有GUI 移动应用程序的自动化技术比带有GUI 桌面应用程序自动化测试技术要更加复杂，例如：平台多样性、移动应用更新速度快、市场压力都给移动应用的测试带了新的挑战。

1 GUI测试的定义

GUI（Graphical User Interface，图形用户界面）是底层程序代码的前端表示形式，对诸如选择下拉列表框、菜单、导航栏、按钮控件等用户操作会作出相对应的前端反映[4]。因为带有图形界面的软件相对与传统的软件而言，其美观的图形用户界面带给了用户们最直观的体验，使得用户可以快速上手而逐渐受到用户的青睐。所以在目前市场上的软件大多都带图形用户界面。所以，针对GUI 进行的软件测试也应该成为整个GUI 软件测试中非常重要的一部分[4]。

而GUI 测试指对带有GUI 的软件进行软件测试，如文献[5～8]中说提及的GUI 测试是通过测试应用程序的GUI，从而达到测试被测系统的功能、GUI 的结构及实现GUI 的代码。而移动端的GUI 测试用例指的是一个完成的用户行为的一系列相关的事件/动作，即移动应用程序的GUI 测试用例是由一系列的事件/动作组成。由此可见，移动应用的GUI 测试的输入一般都是事件/动作，而输出一般是状态的变化。状态变化可能体现为页面的变化，也可能是页面中某些元素的状态变化等。针对移动应用的GUI 测试用例中，事件/动作之间的依赖关系也是一项非常重要的活动[9]。

2 GUI测试方法

2.1 GGUUII测试框架

目前存在常用的GUI 测试框架如表1 所示，由于篇幅的原因，我们只是列举了比较常见的框架，其中Uiautomator 框架中提供的API 可以对移动应用程序进行页面截图及页面的元素的结构信息文件。

表1 常见的GUI 测试框架

●Instrumentation 是Android 主推的白盒测试框架。在单元测试的基础上进行功能扩展，达到对Android系统的高度控制，Robotium[10]、Selendroid[11]、Athrun[12]都是基于Instrumentation 的二次封装框架，其缺点是不能跨应用使用。

●Calabash[13]是一个适用于iOS 和Android 开发者的跨平台App 测试框架，可用来测试屏幕截图、手势和实际功能代码。缺点：测试步骤失败后，将跳过所有的后续步骤，需要Calabash 框架安装在iOS 的ipa 文件中，因此测试人员必须要有iOS 的App 源码。除了Ruby，对其他语言不友好。

●Monkey[14]是谷歌提出的，它可以生成一些伪随机用户事件流发送到被测试系统中，然后模拟用户的点击等手势，以及一些系统级的事件。它应该是目前流行移动端自动化框架或者工具的一个鼻祖。Monkeyrunner 同样是Android SDK 自带的测试工具，它可以用于做功能测试，回归测试并且可以自己定义测试扩展，灵活性较大。Monkeyrunner 工具提供了一些API，可以通过该 API 来控制 Android 设备或者模拟器。

●Uiautomator 是通过以控件的方式来定位，当然也是支持坐标轴的方式来定位。缺点：Uiautomator 是Android 4.1 后加入的，所以仅支持Android 4.1 和以上的版本，但是不支持Webview。

●Appium[15]：同时支持 Android、iOS、FirefoxOS。并且Appium 可以用任何你熟悉的开发语言来进行编写测试用例。例如 Java、Python、Ruby、PHP、JavaScript、Object-C、C#。采用的控件的定位方式对不懂Java 而熟悉其他语言的来说还是相当不错的选择。缺点是稳定性相对较差。

2.2 GGUUII测试技术

在移动应用程序的测试中，现有很多的测试手段：云测、众测、自测、外包测试等不同的方式；目前提供云测试的平台服务很多，最出名的是Testin 云测（Android&iOS）、百度 MT（Android&iOS）、阿里 MQC（Android&iOS）、贯众云测试（Android&iOS）、腾讯优测（Android）。其中括号内表示云测试平台可以支持的测试类型。此外，这几个测试平台都是用到Monkey 工具做兼容性，稳定性测试。这几个云测试平台的测试场景如表2 所示。但是云测试在测试过程中真正使用真机来测试的很少，据我们所知，在测试过程中使用真机和模拟机是有很大的不同的，模拟机消耗的资源太大，使用它作为测试平台的话，测试出来的很多问题其实在真机中是不存在或者说是反应是不一样的。另外，众测、自测、外包测试其实是属于同一种测试方法的不同形式，即可分为手工测试和自动化测试。目前国内外已经存在很多关于移动应用GUI 测试方法。这些有关移动应用GUI 测试方法的研究方向可分为模糊技术、录制/回放，基于模型，且在这些技术中，基于模型生成测试用例的方法被认为是最具有希望的研究方向之一[14]。

表3 列出了自动化GUI 测试方法的优缺点，可供测试工程师选择GUI 的测试方法作为一个依据。

2.3 GGUUII测试工具

表4 中列举出针对现有的GUI 测试方法对应的工具，其排名不分先后顺序。这些工具来源于论文的整理得到，由于工具比较多，这里列出论文中出现较多次数的工具，包括随机探测工具、基于模型探索、系统化探测工具及针对移动应用的录制回放工具，另外我们还列出每个工作是否需要源代码。

表2 云测试平台对比表

表3 测试方法的优缺点

表4 GUI 测试工具

2.4 GGUUII测试的评估方法

Amalfitano 等人在文献[25]中提出GUI 测试的主要是以覆盖率作为评价标准。其覆盖率包括缺陷覆盖率、活动覆盖率、事件覆盖率。如公式（1）所示，缺陷覆盖率是规定的测试时间内或者执行相同数目的测试用例时覆盖的缺陷数目与缺陷总数的比值，是衡量测试工具或者测试用例有效性的主要指标之一。活动覆盖率如公式（2）所示是在规定的测试时间内或者执行相同数目的测试用例时已经覆盖的活动数量与活动总数的比值。事件覆盖率如公式（3）所示是在规定的测试时间内或者执行相同数目的测试用例时已覆盖事件数量与事件总数的比值。另外，现今软件开发人员通常采用更多的代码来实现应用软件的GUI，几乎能占到整个应用软件程序代码量的60%[26]，现在也有代码覆盖率来评估工具的效率之一，例如文献[20]、[28]中就使用代码覆盖率来评估。

2.5 GGUUII测试技术的挑战

Ozlem Muslu 提出了基于模型的GUI 测试用例生成的三大挑战，状态相等的判断，状态搜索，输入之间的等待时间[29]。在Choudhary S Rdeng 等人[24]对目前研究存在有关移动应用的自动化工具进行对比研究，目的是为了验证当前的自动化工具是否实现自动输入技术，最后发现，我们的自动化输入可以实现，但是输入的值并不能模拟用户的真实输入，只能是简单的随机输入而已。正如因为面临这些挑战，使得自动化测试在实际工程中使用甚少。这一结果和Vasquez M L 等人[27]通过向移动应用测试工作者发送问卷调查的方式来统计实际工业中的测试工程师依然采用测试手段，最后发现实际测试工程中测试工程师偏向于手工测试。在表4 的工具只有Monkey、MobiGUITAR 在实际中也得到一些测试工程师的青睐。

3 结语

本文从GUI 测试的定义，自动化的测试框架、工具特别多，但是在实际工作中并没有得到真正意义上的应用，存在这一现象的原因是很多方面的，最突出的原因如下：

（1）测试工程师缺少自动化相关的测试知识；

（2）当前的自动化工具缺乏相应的使用文档；

（3）工具的安装环境比较复杂，安装过程比较耗时。

为了满足实际测试工作者的需求，我们需要研究出可行度极高的移动应用GUI 自动化测试方法，使得测试工作者从测试工作中的某些阶段逐渐解脱出来，把更多的精力放在更重要的测试阶段中。

4 未来展望

按照目前的发展趋势，未来的移动应用会呈现爆炸式增大，而我们的移动应用的GUI 测试实现自动化是必然的趋势，我们当前使用到的随机测试、基于模型的测试、录制回放测试中，基于模型的测试被认为是最具有研究价值的测试，而基于模型的测试难点在于模型的构建上。现有的MobiGUITAR[5]工具主要应用于在模拟器上，构建出的模型是映射到被测系统的控件上，其控件的有效性没有进行验证，另外，通过控件模型转化为事件模型，最后再转化为有限状态机模型。接下来，通过遍历模型得到的测试用例并没有进行测试用例约简和优先级的排序。导致在有限的时间内，测试用例的执行力不高。这样子就没有满足尽快尽早暴露被测系统的缺陷。而Stoat[20]工具构建出的模型是随机模型，然后根据随机模型进行遍历，从一开始的模型就不能真正映射到系统，所以Stoat 构建出来的模型不能完全代表被测系统。因此，在未来的研究中，对于模型的自动化构建以及如何构建出可以映射被测系统的模型是未来研究方向之一。