Android UI自动化测试框架

1、UI自动化测试简介

软件测试简介

软件测试是伴随着软件开发一同诞生的，随着软件规模大型化，结构复杂化，软件测试也从最初的简单“调试”，发展到当今的自动化测试。

自动化测试是什么呢？自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程，自动化测试通常会借助某些工具或者框架。虽然不能完全取代手工测试，但相比手工测试来讲，自动化测试可以减少人力成本，降低重复工作，从而更快速、高效的进行测试活动。

测试金字塔是一种自动化测试过程的金字塔形策略结构，用来指导软件开发过程中各层测试投入的工作量比例，其最早由Mike Cohn在2009年的著作《Scrum敏捷软件开发》中提出。Mike Cohn在书中指出：测试金字塔从上到下分为三层，分别是UI测试、服务/接口测试、单元测试，越接近金字塔底部的测试活动，投入的工作量应该越多，即单元测试投入工作量最多，接口测试次之，UI测试投入最少。

UI测试

UI测试是最接近软件真实用户使用行为的测试类型。通常是模拟真实用户使用软件的行为，即模拟用户在软件界面上的各种操作，并验证这些操作对应的结果是否正确。

接口测试（API测试）

API测试，主要针对的是各模块暴露的接口，通常采用灰盒测试方法。首先以黑盒方式设计如何调用API的测试用例，同时在测试执行过程中统计代码覆盖率，然后根据代码覆盖率情况来补充更多、更有针对性的测试用例。

单元测试

单元测试，属于白盒测试的范畴，通常由开发工程师自己完成，越早发现缺陷其修复成本越低。

为什么要做 UI 自动化？

随着不停的版本迭代，软件新增功能变的越来越多，对测试资源的需求也变得越来越大，执行人工测试的时间越来越长。对于人工测试的依赖开始变得棘手，因此大家开始寻找解决方案，UI 自动化也应运而生。

人工测试存在以下的弊端：

人工回归测试需要花费很长时间才能完成，很小的延迟就会让发布面临风险。
发布节奏受到人工回归测试的限制。两天以上的人工回归测试意味着最好的情况下能够一个月发布两次。而且，开发者需要一次性发布所有东西。要么全部发布，要么什么都发布不了，因为需要将所有东西一起测试。

UI 自动化测试存在以下的优点：

解放了测试团队针对临时的和探索性案例的测试时间；
可以一边开发一边进行回归测试，减少等待时间；
可重复性使用，快速进行回归测试；
更好的利用资源（周未/晚上的资源空闲时段）。

UI 自动化测试的特点

了解到为什么要选择UI自动化测试之后，我们需要了解UI自动化测试的使用场景。UI 即 User Interface（用户界面）的简称，UI 自动化做的事情就是模拟用户行为进行操作，完成对用户界面的测试。这也就从本质上限制了它的使用场景：

软件需求变动不频繁
产品更新维护周期长
比较频繁的回归测试
自动化测试脚本可重复使用

所以在开始之前，我们最好先认识清楚哪些业务场景是可以自动化测试的。

2、Android UI自动化测试工具

UI自动化测试经过多年的发展，也已经涌现出很多优秀的测试工具。下面简单介绍一下Android测试领域内的一些常见的测试工具。

1、Monkey

是Android SDK自带的测试工具，在测试过程中会向系统发送伪随机的用户事件流（如按键输入、触摸屏输入、手势输入等)，实现对正在开发的应用程序进行压力测试，也有日志输出。实际上该工具只能做程序做一些压力测试，由于测试事件和数据都是随机的，不能自定义，所以有很大的局限性。

2、MonkeyRunner

也是Android SDK提供的测试工具。严格意义上来说MonkeyRunner其实是一个Api工具包，比Monkey强大，可以编写测试脚本来自定义数据、事件。Monkeyrunner 足够强大了，但是录制的脚本是以坐标轴来作为定位方式，而安卓设备类型众多，各种分辨率，所以移植性不好。

3、Instrumentation

是早期Google提供的Android自动化测试工具类，虽然在那时候JUnit也可以对Android进行测试，但是Instrumentation允许你对应用程序做更为复杂的测试，甚至是框架层面的。通过Instrumentation你可以模拟按键按下、抬起、屏幕点击、滚动等事件。

Instrumentation是通过将主程序和测试程序运行在同一个进程来实现这些功能，你可以把Instrumentation看成一个类似Activity或者Service并且不带界面的组件，在程序运行期间监控你的主程序。

缺点是对测试人员来说编写代码能力要求较高，需要对Android相关知识有一定了解，还需要配置AndroidManifest.xml文件，不能跨多个App。

4、UiAutomator

也是Android提供的自动化测试框架，基本上支持所有的Android事件操作，对比Instrumentation它不需要测试人员了解代码实现细节（可以用UiAutomatorviewer抓取App页面上的控件属性而不看源码）。基于Java，测试代码结构简单、编写容易、学习成本低，一次编译，所有设备或模拟器都能运行测试，能跨App（比如：很多App有选择相册、打开相机拍照，这就是跨App）。缺点是只支持SDK 16（Android 4.1）及以上，不支持Hybird App、WebApp。

5、Espresso

是Google的开源自动化测试框架。相对于UIAutomator，它的特点是规模更小、更简洁，API更加精确，编写测试代码简单，容易快速上手。因为是基于Instrumentation的，所以不能跨App。

6、Selendroid

基于Instrumentation的测试框架，可以测试Native App、Hybird App、Web App，但是网上资料较少，社区活跃度也不大。

7、Robotium

也是基于Instrumentation的测试框架，目前国内外用的比较多，资料比较多，社区也比较活跃。缺点是对测试人员来说要有一定的Java基础，了解Android基本组件，不能跨App。

8、Appium

Appium 是目前最主流的移动测试自动化框架，不仅支持 Android 应用，而且适用于 iOS、混合和 Web 应用程序。

它底层完全使用了 Selenium 和 WebDriver 的 API，所以如果你之前有用过 selenium, 几乎不需要额外的学习成本就可以使用 appium。appium 通过 uiautomator（API 级别 16 或更高）和 Seledroid（API 级别低于 16）支持 Android，但是你不需要具体懂这两个框架的具体用法，appium 都已经帮你封装成了统一的使用规则。Appium 的优势之一是几乎可以使用任何编程语言（例如 Java、Objective-C、JavaScript、PHP、Ruby、Python 或 C# 等）编写 Appium 脚本。不需要重新编译或改变应用程序来匹配Appium，Appium有一个非常大而活跃的社区。

9、Airtest

是网易出品的一款基于图像识别和poco控件识别的一款UI自动化测试套件，由Airtest框架、poco框架、airtestIDE 组成。是一个跨平台的UI自动化测试框架，适用于游戏和App。用户不需要一行行的去写代码，而是用屏幕截屏的方式，用截出来的图形排列组合成执行的程序。另外，Airtest也基于poco这个UI控件搜索框架，这个框架也是网易自家的跨平台U测试框架，原理类似于appium，通过控件的名称，id之类的来定位目标控件，然后调用函数方法，例如click(),swip()之类的方法来对目标控件进行点击或者是操作。

虽然Airtest刚开始是为了游戏测试，现在在app测试中也有很大的应用范围。只是进行录制、执行脚本的AirtestIDE没有开源，不方便进行深度定制。

10、Solopi

是蚂蚁金服开源的一款移动端APP测试工具，提供脚本录制、编辑、回放，结果展示以及一机多控（即通过设备间的socket通讯实现1台手机可以控制多台手机执行脚本）等功能，其测试用例的录制和执行等操作均在手机端的一个APP中完成。不需要借助电脑软件与测试设备交互，所以通信结构比Appium简单高效，对元素的识别也是使用类似于appium的控件的方式，并且引入了类似于airtest的图像识别的方式。

3、SoloPi的介绍

以往的性能测试工具，无外乎三种形态：PC 驱动工具、侵入式的测试模块、ROOT 工具。

PC 工具：除了 Android Studio 自带的性能测试工具，市面上大多数文档都是介绍命令行方法，而且各家方案存在差异，不少还存在错误，实际成型的工具也不多。

侵入式的测试模块：这类工具由于需要侵入到源码中，需要单独打包进行测试，工具本身也可能对性能产生影响。

ROOT 工具：首先是需要 Android 系统的 Root 权限，对于权限管控越来越严格的 Android 系统，其路必将越走越窄。

SoloPi提供了一种能够在 Android 手机上不需要 root 也能实现应用提权的方案。可以简单概括为：SoloPi是一种无线化、非侵入、免 Root 的 Android 专项测试方案。

传统的功能测试通常有两种方式：一种是人工手动执行测试，另一种则是编写基于测试框架的自动化脚本。前者成本巨大，为应付不断加速的产品迭代可能需要投入大量人力；而后者则对测试同学的代码能力有不小的要求，这也导致由手动测试转化为自动化测试从而节省人力的进度相对缓慢。

SoloPi将传统上仅能用于 PC 的自动化测试能力移植到了移动平台，并根据手机的使用习惯，开发了一套简单易用且功能强大的自动化测试框架。不需要测试同学有代码能力，降低了使用门槛，更方便推广。

Solopi主要有以下功能：自动化测试-录制回放、兼容性测试-一机多控、性能测试、稳定性测试。

虽然Appium和Airtest都有很大的应用范围，但是Solopi相比于appium和airtest有以下优势：

改进的控件匹配算法，更高的匹配成功率；

不需要依赖pc端的桌面应用，全部操作都在手机端的app中完成，实现了无线化，随时可测；

不需要代码基础，使用人群覆盖范围广；

提供性能测试的功能等。

（1）整体架构

这套方案中，底层依赖主要是 “无线 ADB、系统辅助功能、Chrome 调试以及图像识别技术”，后文将会介绍它们具体的应用场景。同时，在底层依赖的基础上，封装了一套核心能力，由 “控件定位、事件驱动、性能采集以及依赖注入” 组成，并在服务层实现了录制、回放、数据处理等公共服

务能力。在架构的最顶端，结合界面交互逻辑包装出了各个功能的入口。

（2）录制回放

在录制过程中，SoloPi 会对用户的操作进行拦截，识别用户操作的位置，高亮当前操作的控件，记录用户当前要做的操作类型，在每一步操作后，将操作类型及目标控件的各种信息都记录下来。这里的控件信息包括控件的 ID、文字等基本信息，以及相对布局、截图信息等。

在回放时，SoloPi会逐条解析之前录制的数据，通过智能查找算法，综合各种属性，定位目标控件，找到控件后，就会执行相应的操作，如点击、滑动等。在所有步骤执行后，会展示本次回放的结果，包括日志、截图等信息，作为本次回放的总结。

SoloPi 的录制和回放，基于同一套逻辑，包括控件结构构建、控件定位、事件驱动三个部分。两者的区别主要在于控件定位：

在录制过程中，SoloPi 会基于用户的点击行为进行定位；

在用例回放时，SoloPi 会根据录制时记录的控件信息，通过 SoloPi 的控件查找算法进行定位。

（3）底层依赖的核心功能

1）基础依赖

下面主要介绍SoloPi的控件查找功能和操作监控功能需要依赖的基础方案：无线ADB方案和AccessiblityService方案。

无线ADB方案

对于 Android 自动化，ADB shell 的执行能力是一切的基础。在 PC 上，通过 Android SDK 提供的ADB client 与同样运行于 PC 中的 ADB server 通信，再由 ADB server 通过 USB 与位于设备中的 Adbd 通信。要实现一套无线化的方案，必须要摆脱对 USB 线的依赖。好在 Android 系统还提供了一种基于 Socket 的 ADB 连接模式，既然是这样，那么只需要按照 ADB 通信协议在端上与本机的 5555 端口进行通信即可获得 ADB shell 的执行能力。

此无线ADB方案是SoloPi区别于其他UI自动化测试框架的核心方案之一，大家可以在其他项目中借鉴这种无线化方案。

AccessiblityService方案

辅助功能（AccessibilityService）其实是一个Android系统提供给的一种服务，本身是继承Service类的。这个服务提供了增强的用户界面，旨在帮助残障人士或者可能暂时无法与设备充分交互的人们。

从开发者的角度看，主要使用两种功能：查找界面元素，实现模拟点击。

UiAutomator（Appium、Airtest使用的方案）和AccessibilityService是有联系的：UiAutomator底层使用的是AccessibilityManagerService，AccessibilityService底层也是使用的AccessibilityManagerService，它们都是通过RPC与AccessibilityManagerService进行交互，获取界面元素和对界面元素进行操作的。区别是：UiAutomator只能在shell环境中执行，AccessibilityService是可以运行在app环境中的，但是需要用户手动开启服务。

2）基础功能

基于以上两种基础能力，下面介绍solopi底层依赖的两种功能：基础控件查找功能、用户操作监控功能。

控件查找功能

随着移动端动态化能力的稳步发展，越来越多的应用采用了 “Native + H5/小程序” 这种混合开发的方案。再考虑到近年来手游行业的飞速发展，手机游戏自动化测试的需求也越来越多。为了尽可能的适配各种场景，SoloPi提供了三种查找模式：

第一种方案的核心就是基于 AccessbilityService 生成当前控件视图树，并记录下id、文字等属性，适用于 Native 场景。

第二种方案基于 Chrome 的调试协议，通过注入js可以获得页面布局以及各元素属性，控件的定位思路与辅助功能这一套方案是一致的。适用于 H5/小程序场景。

第三种方案是图像匹配方案，SoloPi 在端上实现了一套图像比对能力，结合了模板匹配、特征匹配等算法，并做了一定的适配和调优。适用于游戏自动化的场景。

现阶段的开源代码中，native控件和webview中的控件都是使用AccessbilityService生成的控件视图树，断言功能和截图点击功能会使用到图像匹配方案，现阶段基于 Chrome 的调试协议方案未开源。

用户操作监控功能

a、事件获取机制：

关于用于操作监控与控件获取，AccessibilityService 能够获取用户的操作事件并关联对应的控件，可以实现大部分功能。

但 AccessibilityService 也有不足的地方，比如面向 HTML5 场景，辅助功能获取控件会出现延迟从而导致获取的控件结构不够精确；另外，对于部分自定义控件，辅助功能只能获取到对应的控件，但缺乏具体的坐标信息，从而导致控件操作不符合预期。

因此，SoloPi 采取了“结合 Android 系统 getevnet 功能”策略，通过直接解析系统原生事件，获取到用户的操作行为。

简单来说，通过 getevent，SoloPi 可以获取到用户操作屏幕的具体坐标，以及手指落下、抬起的具体时间。不过，getevent 命令的使用需要 SHELL 权限，这限制了普通 Android 应用获取相关数据的能力。SoloPi 通过Android 系统的无线调试功能实现了一套纯端的 SHELL 执行能力，能够在 Android 系统上执行 adb 相关命令。在SoloPi应用中集成了 AdbLib 开源库，包装成一套 ADB 命令执行工具。

通过 getevent 命令，SoloPi 获取到了用户点击的具体坐标，结合 AccessibilityService 获取到当前页面的控件结构树。遍历控件树找到坐标点击位置最上层的控件。

b、事件拦截机制：

在soloPi代码中，当需要拦截事件时，就会设置AccessibilityService进入触摸监控模式（通过此标志位 FLAG_REQUEST_TOUCH_EXPLORATION_MODE）。在此模式下，系统不会在view树中分发事件，各种事件会分发到AccessibilityService的实现类中。此时，soloPi会自己监听get event事件，进行事件的分发和处理。当不需要拦截系统分发事件时，就会重新设置AccessibilityService的标志位。

（4）回放能力的扩展

通过 SoloPi 录制的用例会以 JSON 的形式存储起来，用例不仅可以在设备本地直接回放，还可以通过 SoloPi 的解析器将用例转换为 Appium等目前主流自动化测试框架的脚本，轻松打通云测平台。另外，得益于文本抓取和图像识别能力，SoloPi还实现了在 Android 端录制一遍用例，生成的脚本能够同时在 Android、iOS 双端回放的能力。

（5）脚本编辑

SoloPi还提供了用例步骤的插入、删除、修改等用例编辑功能，可以有效降低用例的维护成本。另外，SoloPi还引入了循环、条件等流程控制能力，若对用例进行合理编排，可轻松实现需要重复操作的工具脚本或是需要暴力回放的稳定性测试脚本。

（6）一机多控

在各类专项测试中，兼容性测试是最为耗时费力的一项，测试人员需要关注各种系统版本、各大手机厂商，各种类型的屏幕等等，想要通过纯人工测试来保证兼容性测试的质量成本是非常高的。

SoloPi 在录制回放能力的基础上实现了一套兼容性测试的解决方案。在录制回放的场景中，先是在一台设备上记录了用户的操作，然后再在任意一台设备上实现操作的回放。如果把场景扩展到多台设备上，就可以实现通过一台设备操控多台设备，这套功能称为 “一机多控”。具体说来就是主机与从机建立 Socket 连接，然后在主机上将用户的操作实时发送到各个从机，在从机上完成操作的回放。