MTC 是一个面向开发者的移动测试平台，专注于为开发者提供一站式的 App 测试服务，随着业务的不断增长，我们迫切需要一套通用的、可以适用各类场景的脚本测试解决方案，但是传统的脚本测试框架如 UiAutomator、Robotium、Appium 都各有弊端，单一的测试框架无法满足我们的需求，因此，混合脚本测试解决方案应运而生。此次将向大家分享我们在设计、开发混合脚本测试框架及对应的脚本录制工具中碰到的一些问题和解决方案。

MTC是一个面向开发者的移动测试平台，专注于为开发者提供一站式的App测试服务，随着业务的不断增长，我们迫切需要一套通用的、可以适用各类场景的脚本测试解决方案，但是传统的脚本测试框架如UiAutomator、Robotium、Appium都各有弊端，单一的测试框架无法满足我们的需求，因此，混合脚本测试解决方案应运而生。

在介绍这个神奇的框架工具之前，让我们先了解下自动化测试的使用场景。

为什么需要自动化测试

为什么需要自动化测试？自动化测试本身的优点有很多，我大致列了主要的三个。

缩短测试周期

当前我们产品迭代速度非常快，我们经常会经历一些回归测试等相关测试，这些测试里面需要人力手工执行许多重复化的case，如果只是依赖人力执行，十分费时。如果通过自动化测试，我们就可以任意时间跑一些脚本，比如可以全天候跑回归测试，这样就大大的缩短测试周期。

统一标准，避免人为出错

目前的测试主要是强依赖于人工，但是人工难免会出错。比如忘了执行某一个case，忘了加断言等等。但是如果用自动化测试，完全可以把这些问题避免掉，并且也可以统一测试判定的标准，避免出现不同人有不同判定标准。

提升测试的覆盖率

现在Android碎片化如此严重，测试中我们也经常碰到一些APP需要覆盖到各种各样的手机机型，如果依赖于人工，很难做到比较大程度的覆盖，而通过自动化测试，一套脚本在很多款机型，比如600款机型上执行，这样可以大大提升测试的覆盖率，可以提早发现一些很难发现的问题。

如何自动化测试

常见的自动化测试场景

下图描述了一个简单的自动化测试场景：

流程上可以大致如下：

1. 测试人员接到一个case

2. 测试人员根据case编写测试脚本（依赖一些IDE或者工具之类的）

3. 本地测试验证

4. 将脚本下发至平台批量执行

5. 结果收集整理（如有必要，需要重新修改脚本兼容后重新下发）

如何选择测试框架

在这个场景里面我们会碰到几个比较重要的问题。但是首先碰到的第一个问题就是，如何选择自动化测试框架？

现在流行的自动化测试框架很多，这边列了几个我们比较常用的并稍作对比。

总结来看，这几个框架各有优劣，但是Robotium的两个致命问题以及Appium的稳定性问题都让我们最终放弃，我们最后的选择是UIAutomator，但是框架选择这块，主要看需求，合适自己的才是最好的。

自动化测试中的脚本干扰问题

选择好合适的框架，也制订好完整的自动化测试流程，开始执行后我们还是会发现存在各种各样的问题，干扰问题就是一个。

干扰的话，最常见的就是弹窗。弹窗也分为app内弹窗和app外弹窗。下面为两个例子。

因为脚本最终要在很多各类手机上运行，而不同手机又会有各种奇怪的弹窗设定，所以干扰问题就会变的比较凸显。

一般情况下，app内弹窗主要通过脚本自身解决，自己在脚本内增加各种适配兼容。因为我们使用的框架是UIAutomator，这样我们就可以使用他的跨进程能力来解决进程外弹窗了。

清道夫SDK

清道夫SDK是我们的一个进程外弹窗解决方案，基于UIAutomator的跨进程特性。

它主要由两部分组成：

发现弹窗
清理弹窗
发现弹窗

发现弹窗原理其实是比较简单的，一个APP执行过程中，界面可以理解为很多层，而如果有一个弹窗，那弹窗就等于在界面的最上层。

在UIAutomator框架中，页面最上层是被抽象成一个节点树的，所以我们只要判断当前根节点的packageName是不是待测app就可以判断出待测app是不是被遮盖了，从而发现潜在的弹窗，然后开始一些弹窗的清理工作，或者是APP自身的回到前台工作。

清理弹窗

由于国内各种定制的rom，导致想要通过弹窗节点元素的方案来清理弹窗变的不现实，比如系统的权限弹窗，在某些手机上是Button，在某些系统上可能又变成来ImageView，所以基于元素来解决十分困难。

在我们研究来很多场景之后发现，其实大部分的弹窗文本相对来说比较单一，变化较少，不同rom基本都差不多，所以最终我们综合考虑后，采用来基于文本匹配的方案来实现来弹窗的清理。

UIAutomator的封装

基于清道夫SDK的思路，我们在UIAutomator的基础上做了一套封装，通过封装之后的api来进行脚本测试，在我们的封装里面，基于UIAutomator的基础之上又增加来一些新的稳定性方案：

1. 自动的弹窗清理（app内和app外）

2. 操作记忆和重试，保证操作成功率（避免出现操作后无反应的情况）

3. 截图优化

非Native场景的测试

解决了脚本稳定性之后，我们还面临一个比较大的问题，非Native场景的支持。

什么是非Native场景？

WebView场景

WebView是我们碰到的最常见的非Native场景，低版本上UIAutomator对WebView对支持较差，所以测试起来非常麻烦，很多元素无法识别。

游戏场景

游戏对界面一般是直接渲染出来对一张大图，所以也很难进行元素对获取。

PopupWindow场景

这种场景的一个常见的就是安全键盘，由于焦点不在安全键盘上，导致安全键盘元素根本识别不到。

可行的解决方案：基于元素

一般情况下，对于如上的场景，我们有一些可能可行的解决方案，如下：

WebView通过参考Appium的原理基于ChromeDriver来进行元素解析
游戏通过嵌入SDK，针对引擎特点反射UI控件元素
PopupWindow通过代码层增加focus操作
但是经过实践，这些方案都有确定，比如基于ChromeDriver的方案并不稳定，基于SDK来做游戏测试的方案侵入式太强等等。

基于图像识别的测试方案

下图是一个简单的基于图像识别的测试方案。

可以看出，其实原理操作上很简单，主要流程如下：

测试流程开始前截取待操作元素图标
将图标文件和脚本一起作为输入提交至平台
每次操作都实时截图
将元素图标和截图进行匹配获取元素位置
通过adb对元素进行操作
基于上述对方案，我们可以发现这是一个无侵入式对测试方案，而且因为不基于元素，所以对任意场景都可以支持，所以它的普适性比较高。

图像识别方案 vs 基于元素对方案

下面是我对基于元素和基于图像对两种方案对一个简单对比

我们主要参考三个方面：稳定性、易用型、准确性。

稳定性主要指对各种场景对支持情况。易用性主要指我们的脚本编写方式是否易用。准确性主要指元素的识别是否准确。

通过图可以看出，综合来看，图像识别的方案各方面都比较不错，所以我们最终选择了图像识别的方案。

图像识别方案的匹配算法

提到图像识别方案就不得不提到匹配算法，因为匹配是图像识别方案的核心。

常见的算法主要有两类：

模板匹配算法
基于特征点的算法
具体的算法此处不做细述，大家可以自行搜索学习，这里只对两类算法进行一个简单对对比：

可以看出这两种算法其实是优势互补的，所以如果把他们整合起来，可以较好对适应各类场景。

同时，这两种方案本身也存在一定对弊端，比如对于简单对数字、字母识别较差，这个缺点我们也通过OCR对方案来进行弥补。基于OCR对识别能力，可以比较精确的找到对应数字、字母对位置。

工程化解决方案

所以，综合以上的方案，我们最终综合的实现来一套图像识别的解决方案。核主要包括如下：

整合三种方案（模板算法、特征点算法、OCR）
增加不同分辨率下截图，并自动匹配
限定匹配区域，提高匹配准确度
第一条主要目的是通过整合方案来提升对各个场景的支持 。

然后为了让模板匹配的成功率更高，我们增加了自动匹配分辨率的功能。

最后，为了提升匹配的准确度，减少干扰，我们还提供了限定匹配区域的方案。

通过整合和调优，我们的这套图像识别方案可以达到99%的匹配精度，能较好的支持大部分的非Native场景，给UIAutomator的方案提供了一个有力的补充。

方案整合：混合脚本测试

目前来看，我们主要使用图像识别方案和UIAutomator方案来进行自动化测试。很明显，它们是一个优势互补的关系。

如果能把它们结合起来，我们就可以对各类场景做到较好的支持了。

但是目前的问题是，它们是两套方案，脚本编写也是两套脚本，所以，如何进行整合呢？

我们的图像识别方案是运行在PC端，而UIAutomator是运行在手机端，所以整合一般也就两种方案：

1. UIAutomator迁移至PC端

2. 图像识别方案迁移至手机端

综合比较下来，我们采用了方案1，因为图像识别迁移至手机端本身可能会对我们的测试进行影响，影响我们收集到的一些性能数据，而UIAutomator迁移至PC端本身也有一些开源的解决方案，所以综合考虑来看还是方案1较优。

如图是我们的最终解决方案：

通过在PC端整合一套测试API，我们把两种服务结合了起来，对测试人员来说完全无感知，一套脚本即可很好地解决各类场景中的问题。

脚本录制回放工具

既然有了一套通用的脚本解决方案，我们来实现录制回放工具也变的容易了。

简单的录制工具流程

如图是一个简单的录制工具流程，可以看出录制工具的主要组成就是一个UI界面，我们可以通过在UI界面上的一些简单的点击操作，自动生成测试代码，然后生成最终脚本。

录制工具的核心

如下是一个录制工具等主要组成部分：

- 手机屏幕展示（通过adb、minicap等均可简单实现）

- 手机操作功能（通过adb即可实现）

- 根据操作生成脚本（难点）

可以看出第一和第二条都可以比较容易的实现，真正的难点在于第三点，所以我们如何根据操作生成脚本呢？

脚本生成方案

其实我们可以很容易的想到一些方案：

1. 基于坐标的方案

2. 基于元素的方案

基于坐标的方案，优点就是实现简单，但是缺点也很明显，就是不稳定，受分辨率、场景等影响太大，所以可以直接pass。

基于元素的方案相对较优，但是很多时候一个元素的属性并不能完全唯一确定它，同样的界面中可能存在多个类似的元素属性。所以这个方案也存在一定局限性。

但是我们可以很容易的在基于元素的方案的基础上想到改进方案：基于点击路径的方案。

如图，整个界面其实可以抽象成一颗树，而每个元素都有一条到根节点的路径，所以如果我们根据路径去匹配，就能较好的解决唯一的的问题。

录制工具整体架构

基于前面的探索，我们实现了一套完整的录制工具，整体架构如下：

通过基于路径的方案，我们可以很好的解决基于元素生成脚本的问题，另外，我们还在操作前端通过截图等方式实现了图像识别方案等脚本生成。通过整合，使得我们可以使用工具生成完整的混合测试脚本。