【背景介绍】

百度深研MMGame项目组每天提测的apk游戏包数量较大，但由于都是第三方游戏，游戏测试仅包括游戏的简单功能测试和游戏广告测试，人工测试较为繁琐，为了自动化验证游戏功能和广告、提高游戏测试效率，测试项目组在测试中引入开源的Appium自动化测试框架进行自动化测试。但在使用过程中，由于游戏的特殊性，发现很多游戏无法获取到控件、资源ID等内部资源（非原生android代码或使用OpenGL、ActiveX），而目前主要的移动端自动化测试工具基本都是基于获取内部控件元素来进行操作。因此，传统的测试框架和工具无法满足项目组游戏自动化测试的需求。

这种情况下，只能通过点击坐标代替控件操作，而如何自动获取控件坐标就成了能否实现自动化的关键。解决的方法是将开源计算机视觉库OpenCV引入Appium框架，将按钮或控件的截图作为参数输入，在屏幕中通过图像特征识别获取对应控件坐标，调用AppiumAPI实现坐标点击，然后再次调用OpenCV图像识别库，自动判断操作结果，完成自动化测试。

一、Appium与OpenCV简介

Appium 是一个开源、跨平台的自动化测试工具，可以支持 iOS、Android 和 FirefoxOS 平台。Appium的核心是一个遵守REST设计风格的web服务器，server监听一个端口，接收由client发送来的command，将其转换成移动设备可以理解的形式，发送给移动设备，移动设备执行完command后把执行结果返回给appiumserver，appiumserver再把执行结果返回给client，其使用Selenium的WebDriver JSON协议，这种架构提供了很好的开放特性，只要某种语言有http客户端的api，就可以通过这个语言编写测试脚本，因此，Appium支持SeleniumWebDriver支持的所有语言，如java、Object-C、JavaScript、Php、Python、Ruby、C#、Clojure、 Perl语言。Appium在iOS部分封装了UIAutomation，Android 4.2以上使用UiAutomator，Android 2.3～4.1使用Instrumentation，也就说Appium同时封装了UiAutomator和Instrumentation。

Appium在不同平台中使用了标准的自动化APIs，所以在跨平台时，不需要重新编译或者修改自己的应用，Appium实现了真正的跨平台自动化测试。

OpenCV的全称是：Open Source Computer Vision Library（开源计算机视觉库），其可以运行在Linux、Windows和Mac OS操作系统上。OpenCV轻量级而且高效的实现了图像处理和计算机视觉方面的很多通用算法，算法实现由一系列 C 函数和少量 C++ 类构成，同时提供了Python、Ruby、MATLAB等语言的接口。

二、游戏自动化测试框架（Appium与OpenCV结合）

MMGame游戏自动化测试整体框架由Appium构成，Appium作为client与被测APP的桥梁，可以实现连接设备、完成被测APP输入/输出等，OpenCV则为Appium自动化测试提供场景判断、控件获取、结果判断等功能。在对设备进行自动化操作的过程中，关键环节之一就是元素的定位，对于普通应用，Appium提供的API基本能满足测试需求（直接获取控件或资源ID），但是对于游戏（尤其是大型游戏）来说，很多游戏直接使用OpenGL或ActiveX，传统的自动化工具无法通过获取视图元素或资源ID进行元素定位，只能在外部通过坐标点击和屏幕读取进行输入/输出，但是坐标点击适用范围和场景固定，且需要根据特定设备和测试案例进行坐标适配，通用性、可移植性和可维护性较差。

因此，在Appium测试框架的基础上，考虑引入OpenCV进行图像识别与定位，确定控件元素位置，返回坐标，然后由Appium完成对坐标的操作，以此实现游戏的自动化测试与结果验证。OpenCV开源可定制化，兼容多种平台，能够识别经过拉伸和扭曲的图像，适用于测试2D/3D游戏，非常适合引入Appium进行游戏自动化测试，更进一步，可以依此实现游戏云端远程并行测试，极大的扩展测试规模和测试服务，减少测试人力，加快测试效率。除此之外，图像处理功能模块独立且通用性极强，与平台、设备无关，也可以应用到其他任何需要图像识别的产品进行功能扩展。鉴于此，OpenCV的引入，不仅不会影响Appium的跨平台通用性，且解决了Appium无法获取普通应用部分元素和游戏中无法获取内部资源的问题，极大的扩展了Appium的功能。

在具体游戏测试中，OpenCV实现以下3个功能：

•   确定当前在游戏的哪个阶段；

•   根据提供的按钮、控件截图，确定其坐标；

•   判断游戏表现是否符合预期。

Appium+OpenCV整体框架如下图1所示：

图1 Appium+OpenCV整体框架

Appium测试框架的使用网上已经很多，在此不再做多说明，本文主要介绍OpenCV在Appium中的使用。

三、自动测试整体结构和实现原理

Appium中使用OpenCV进行游戏自动化测试的大致流程如下：

• 首先收集相关控件的截图；

• 然后通过Appium获取屏幕当前截图，将提供的截图和当前截图作为输入，使用OpenCV（3.0及以上版本）中集成的Akaze特征识别算法进行特征识别，确定截图在屏幕中的坐标；

• 再通过Appium API实现坐标操作，并获取操作后屏幕截图；

• 再次进行图像处理，判断点击后的效果是否符合预期，给出测试结果，完成测试。

完整工程结构如下：

图2 Appium+OpenCV整体结构

这其中最为核心的是Akaze特征识别算法。Kaze是 Pablo F. Alcantarilla，Adrien Bartoli和Andrew J. Davison2012年在ECCV2012[ECCV是计算机视觉领域最顶尖的三个会议（CVPR、 ECCV， ICCV）之一，每两年一次]中提出来的一种比SIFT、SURF（OpenCV 2.4.9版本中实现的图像特征检测算法）更稳定、性能更好的特征检测算法。

KAZE特征检测是在图像域中进行非线性扩散处理的过程。KAZE算法的作者提出采用加性算子分裂算法(Additive Operator Splitting, AOS)来进行非线性扩散滤波，可以采用任意步长来构造稳定的非线性尺度空间。

KAZE特征的检测步骤大致如下：

1）首先通过AOS算法和可变传导扩散方法来构造非线性尺度空间。

2）检测感兴趣特征点，这些特征点是在非线性尺度空间上经过尺度归一化后的Hessian矩阵行列式中的局部极大值（3×3邻域）。

3)计算特征点的主方向，并且基于一阶微分图像提取具有尺度和旋转不变性的描述向量。

Kaze算法的作者在2013年的BMVC（British Machine Vision Conference）会议上，又对Kaze算法做了改进，引入了一个最新的称为快速显示扩散的（Fast Explicit Diffusion，FED）数学框架去进行特征发现和描述，FED方案构建非线性尺度空间的速度比其他离散化方案的速度都要快，此外，FED方案非常易于实现，也比AOS方案更为精确，作者提出在椎体框架中嵌入FED可以显著加快非线性尺度空间的特征发现，并将这种改进的Kaze算法称之为 AcceleratedKAZE ，即为Akaze。

作者基于OpenCV实现了Akaze算法的代码，在作者项目主页（http://www.robesafe.com/personal /pablo.alcantarilla/kaze.html）可以下载到完整的实现源代码，具体使用中可以下载OpenCV 3.0及以上版本直接调用Akaze算法类，或者将下载的Akaze代码添加进工程来使用。

图2中的Img文件夹中保存了预先传入的截图（queryImg文件夹）和获取到的屏幕截图(sceneImg文件夹)，以及使用特征识别算法匹配到的结果图片（matchImg文件夹），具体如下图3所示：

图3 工程图片目录结构

图2中imgProcess.py基于OpenCV提供的底层图像处理接口，封装了一系列自动化测试中所需要的特征识别、结果图绘制、获取坐标等接口，以获取截图坐标函数为例，其大致实现过程如下：

•   使用特征检测算法Akaze分别计算控件截图和屏幕截图的特征值和描述向量；

•   将两张图的特征值进行匹配；

•   过滤匹配成功的坐标对；

•   根据过滤后的坐标对计算转换矩阵；

•   获取控件截图的4个顶点坐标，使用转换矩阵运算，映射至屏幕坐标；

•   根据屏幕坐标计算中心点坐标并返回。

大致代码如下图4所示：

图4 imgProcess.py代码结构

图2中Appium_OpenCV_TestCase.py是执行具体测试逻辑的测试用例，代码具有简单易写，结构简单，逻辑清晰的优点。Appium测试用例有固定的模板，不同的是，在测试case代码中，使用OpenCV进行图像匹配、坐标获取、结果确认等，取代了传统的通过获取视图元素或资源ID实现操作，大致代码如下图5所示：

图5 测试用例Appium_OpenCV_TestCase.py代码结构

四、使用效果

1、功能测试

为了展示使用效果，以实际工作中的一款被测游戏APP为例，使用以上实现的框架和图像匹配功能，进行简单的基于Appium+OpenCV实现的功能自动化测试演示。

     首先，我们根据需要测试的功能逻辑，收集相关截图，如下图6所示：

图6 相关控件截图

运行测试脚本中，会自动获取特定时刻的屏幕截图，如下图7所示：

图7 屏幕截图

然后将屏幕截图与传入的按钮截图进行图像匹配，部分匹配结果如下图8所示：

图8 图像识别结果（绿色方框区域即为识别到的控件区域）

上面绿色方框就是通过图像匹配，在屏幕截图中找到的对应控件的位置，可以看出，除了第一张稍有偏差，其他控件基本是100%匹配，而且第一张虽有一定偏 差，但是匹配结果的中心坐标点（即绿色方框的中心点）仍在控件的可点击范围内，也是可点击成功的。至于为何Star按钮会出现匹配误差，这与传入的按钮截 图有关。项目组在实际使用中总结了以下3条经验：

•    截取最精确的源图片（最小化原则），提高匹配精确度

      将需要匹配的控件图片拆分成较小的、唯一的元素。

      缺点：图片小，获取到的特征点少，容易匹配失败，匹配成功率低

      优点：匹配精确度高

•   放大源图片，提高匹配成功率