基于位图识别的UI自动化测试研究和应用

余锦润，杨丹君，李波波

（浙江中控技术股份有限公司，杭州310053）

自动化测试是软件测试的一个重要分支，相对于手动测试而言，自动化测试是将人的测试行为通过代码框架转化成机器的测试行为，可用于各种测试范畴，主要强调的是通过工具结合自己的测试策略来辅助测试，可以全自动，也可以半自动，节省了大量的人力、时间和硬件资源，也同时提高了测试效率。一般来说，满足3 个条件就可以对项目采取自动化测试[1]：软件需求变动周期长、项目周期长、自动化脚本可以重复利用。

在自动化测试概念上，敏捷大师Mike Cohn 提出测试金字塔模式[2]，并衍生出分层自动化测试概念，区别于传统的自动化测试概念（基于产品UI 层面的自动化测试，黑盒测试），分层自动化测试倡导从黑盒单层到黑白盒多层的体系。

UI 层是用户使用产品的入口，在传统的测试模型中，大多数研发团队执着于通过UI 进行全面的测试，甚至投入大量的人力成本进行手工测试，而自动化实现难度也极大。进行分层后，自动化测试的设计就有了针对性，也因此诞生了许多针对UI的测试工具和框架。本文主要研究了UI 自动化测试的相关方法，结合Electron 应用的测试难点分析了位图识别技术Sikulix 以及Opencv 算法的优势，并进行自动化模块的设计和工程项目的实际应用，证明了其实用价值。

1 自动化测试的相关研究

在常规桌面客户端测试中，市面上流行很多测试工具，比如惠普公司开发的UFT 工具，商业软件Ranorex 等，均提供了强大的录制回放功能，能完成大部分测试需要。在Web 界面测试中，离不开两大神器——ChromeDriver 和WebDriverIO 的支持，正因为这两个驱动，Web 的自动化测试进行起来游刃有余，并且和很多框架相结合进行高级别的测试需求定制，比如Selenium 等。由于Web 的流行，Electron 应用程序也开始兴起，Electron 是由Github 开发，用HTML，CSS 和JavaScript 来构建跨平台桌面应用程序的一个开源库。Electron 通过将Chromium和Node.js 合并到同一个运行时环境中，并将其打包为Mac，Windows 和Linux 系统下的应用，节省了重复开发的资源[3]。针对于以上桌面端的UI 自动化测试，目前主流的方法分为基于传统框架的UI 自动化测试和基于Spectron 框架的UI 自动化测试。

1.1 基于传统框架的UI 自动化测试

传统框架主要分为基于代码API 层面的对象获取法和基于图片像素识别的对象获取法2 种。基于代码API 层面的对象获取法得益于开发人员给出了获取方式，测试时操作精准，但从另一个角度来说，消耗大量的人力开发和处理API；基于图片像素识别方式主要通过对整个软件界面进行二进制比对，类似于大多数测试工具中的录制-回放功能，但是这样的缺陷更加明显，在不同分辨率，不同浏览器渲染方式下，坐标点引起的偏移和失真，会导致识别出错，降低了其可移植性。在一些高级的录制-回放功能中，增加了元素id 识别，但很多非常规应用，比如Electron 加壳应用，或者开发修改过代码的定制应用，其元素id 是无法识别的。

1.2 基于Spectron 框架的UI 自动化测试

上文提到Electron 应用是Web 加壳的桌面客户端形式的一种应用，会导致其Web 元素id 被隐藏，常规的测试工具无法识别其元素id，官方给出了一个开源框架Spectron，通过JS 语言进行测试代码的编写，可以调用WebDriverIO 的API，但版本有限制。另一方面，Spectron 专门针对Electron，无法作为常规的测试工具，扩展性弱，且使用JS 语言，对于以Python 为基础语言的测试人员而言，学习成本也比较高。

1.3 基于Sikulix 框架的UI 自动化测试

Sikulix 是麻省理工学院的一个开源项目，是一种全新的UI 自动化测试模式，俗称“上帝之眼”，完全模拟人的操作模式[4]，可以利用Opencv 提供的图像识别算法进行可视化检索和操作，相对于以上两种框架，Sikulix 的优势在于：①Sikulix 由于其jar 包的独立性，完全可以作为API 跨平台操作，用Python调用可以灵活构建大型的测试方案；②Sikulix 的图像识别可以解决常规的录制-回放工具元素id 无法识别问题，对不同分辨率以及不同浏览器的渲染方式，Sikulix 不需去操作其坐标点，且图片识别精度可以按照需求设定，默认0.7，解决这种场景的问题；③对于UI 自动化测试，这种方式带来的可扩展性以及编写脚本的直观性，大大降低了测试人员的上手难度，使测试人员投入更多的资源去探索性测试领域。

2 Sikulix+Opencv 模型与算法介绍

Sikulix 是以Java 为运行环境，本身提供了一个简易的IDE，并提供了一个完整的方法库模拟测试人员的操作行为，为了实现更复杂的测试需求，我们不使用其IDE，而应用Jython 集成Python 环境编写驱动模块，Sikulix 的工作原理如图1所示。

图1 Sikulix 系统框架Fig.1 System framework of Sikulix

可以看到，除了常规的Java 和Jython 支持外，最重要的一个底层驱动Opencv 用于图像对比和图片匹配，Opencv 是目前最流行的计算机视觉开源库，在人工智能领域应用完善。Opencv 的图片对比指标主要有：①均方差MSE 对比：将两张尺寸一样的图片的所有RGB 三种颜色的像素点进行一一对比；②峰值信噪比PSNR 对比：将一张原图和一张压缩过的图片进行对比，用PSNR 值表示其失真程度；③结构相似性SSIM 对比： 不同于前两种指标只是机械地通过线性变换分解图片信息，SSIM 考虑了人眼的生物特征，基于感知模型（自然图像具备高度结构化，像素点之间存在相关性），可检测结构信息的差异。SSIM 主要由3 个模块组成：结构、对比度和亮度，在本文中使用SSIM 对比，其算法流程如图2所示[5]。

图2 SSIM 测量系统Fig.2 SSIM measurement system

将以上3 个模块的函数整合之后，得到SSIM的表达式：

式中：μx表示x 的均值；μy表示y 的均值；表示x的方差；表示y 的方差；σxy表示x 和y 的协方差；常数c1=（k1L）2，c2=（k2L）2是为了避免分母接近0 时引起系统不稳定，其中，L 为图像灰度级数（L=2bit数-1），k≪1，默认为k1=0.01，k2=0.03。

Opencv 的图片匹配原理是在原图片中找到一块与模板图片匹配的区域，通过全范围滑动覆盖原图像进行比较，并将滑动时的度量值存入结果图片矩阵中，矩阵的值表示匹配度，矩阵的位置就是匹配位置。Opencv 通过MatchTemplate 函数提供了6种匹配算法，如表1所示。

本文使用的是相关系数匹配-归一化版本：采用模板与目标图片像素与每个图片的平均值计算数量积，正值越大匹配度越高，范围为［-1，1］，如果图片没有明显的特征，则为0，表示无法进行匹配。

表1 Opencv 匹配算法Tab.1 Matching algorithms of Opencv

3 UI 自动化测试设计与应用

3.1 系统结构的整体设计

针对UI 的功能测试，以本公司内部的Electron应用为测试目标，为了覆盖其完整的功能测试点，本文基于Opencv 的图片识别匹配算法以及Sikulix的操作库设计出如图3 的系统结构图。

图3 系统结构图Fig.3 Systematic structure diagram

前端UI 事件 在图片素材给定的基础上，通过鼠标的点击操作，键盘的输入以及快捷键操作，界面状态的检测，截图保存等操作，完成一套UI 自动化测试的流程事件。

优化层 在整体流程无重大逻辑错误的基础上，对于素材图片，过程图片，结果图片的匹配度有一个预先设定的阈值，因为不同类型的截图，不同类型的区域，匹配度不尽相同，不能一个匹配度用于所有情况，必须灵活设定。本文每轮至少经过3次测试以确定阈值。只有当匹配度大于这个阈值时，才能进行下一步操作。对于软件界面，有2 种情况，一种是软件界面被遮挡，导致识别不到相应图片，解决方式是采用区域遍历的方式，搜索出遮挡区域，确认存在遮挡后，将软件前置或者强制重启（极端情况）；第二种是软件崩溃情况，会弹出error指示框，识别出指示框界面后，标记未通过测试，并强制重启后进行下一个用例测试。

界面层与功能模块层 这两层同属于测试核心驱动项，针对整个界面，结合各个功能模块的操作，完成了UI 自动化驱动框架的编写。其中过程图片和更新图片模块是动态自动更新，对比点击功能点的前后截图，如果相似度小于设定的阈值，则判断此处UI 发生变化，当UI 发生变化时（核心图片素材未变），会以自动截图的形式保存至相应的路径中。

管理组件和运行环境 本文使用RobotFrame work 来管理整个测试工程以及用例的编写[6]，主要的三大核心部分如图4所示。其运行环境调用Java虚拟机，Sikulix 的函数库，Python 的第三方库。

图4 测试工程结构图Fig.4 Testing engineering structure diagram

根据以上方法，本文的具体实施测试对象是公司内部的AppDev 前端程序，是一款使用Electron加壳的应用，从图4所示的测试工程可以看出：

（1）工程建立了测试驱动文件夹，用来管理此应用的各个功能模块的Python 驱动代码，比如菜单栏、工具栏等操作代码；

（2）工程建立了测试用例文件夹，使用RF 统一管理测试用例的代码，可以符合测试一体化平台的运行要求；

（3）工程建立了资源库文件夹，用来管理测试过程中使用的图片素材，更新过程文件等，这也是自动化测试必不可少的判断要素。

整个测试工程搭建了之后，进行以下章节的对比实验，并分析了实验结果。

3.2 实验及结果分析

实验环境DELL 5820 工作站，CPU Inter Xeon 3.20 GHz，内存8 G，Windows10 64 位中文版操作系统，分辨率1920*1080 以及1280*1024

测试对象Electron 应用

实验1Opencv 算法的对比分析

上文提到，本文使用Sikulix+Opencv 图片识别和匹配算法进行自动化框架的集成。我们基于Opencv 的SSIM 图片对比算法基础上，通过6 种匹配算法遍历匹配此应用的126 个图片元素（未优化匹配度），结果如表2所示。

表2 匹配算法对比Tab.2 Comparison of matching algorithms

从表中可以看出相关系数匹配法成功率最高，但是耗时最多。而图片识别率是保证自动化进行的前提条件，因此使用其归一化版本，在降低一定耗时量的同时，识别率不变。

实验2主流的UI 自动化测试软件对界面的识别效果

本文的Electron 应用界面一共拥有126 个可点击以及键盘编辑元素，UI 自动化测试的前提是能在不同分辨率下识别这126 个元素，将本文设计的系统方案和主流的UI 自动化工具进行对比实验，并增加了不同分辨率以及匹配度优化的实验数据。

图5 工具的元素识别数对比Fig.5 Element recongnition number comparison of tools

从图5 可以看出，Ranorex 和UFT 由于无法识别到元素id，而自带的位图识别功能效果不佳，导致识别率很低。Spectron 由于是官方提供的框架，能准确识别元素id，因此均能完整识别。而本文Sikulix 方案，由于基于图片识别匹配，在匹配度没有进行调整的状态下，会出现少量的错误，在匹配度优化后，能完全识别，进而可以满足UI 自动化的功能测试要求，且扩展性，代码易读性方面均优于Spectron。

实验3与人工测试进行对比

自动化和人工测试的一个差异就是，自动化可以无差别的进行测试，杜绝了某些情况下人工的疏忽。我们在RF 框架下运行编写好的148 条冒烟测试用例，运行结果如图6所示，同时参照文字版测试用例进行人工测试，对比两者的时间，通过数，fail率等，结果如表3所示。

图6 RF 自动化测试结果Fig.6 RF automation test results

表3 人工与自动化测试的效果比对Tab.3 Comparison of the effects of manual and automated testing

从表3 中分析可知，就冒烟测试而言，自动化测试发现bug 效率明显高于人工，证明本文方案符合自动化测试的效率要求。

综合以上实验结果，我们可以看出，本文结合Sikulix+Opencv 的作为底层驱动，整个系统设计是可以满足测试要求的，对比了其他工具在electron应用的表现，通过低成本的方法可以解决id 元素识别，分辨率更改，UI 发生某种改变等一些突出问题。在UI 自动化测试领域，本方案拥有上手难度低，扩展性强等优势，测试人员能很快设计出对应的测试框架，是一种实用性很强的方法。

4 结语

本文从UI 自动化测试出发，从Electron 应用的角度思考，提出一种简洁易上手，扩展性高的测试设计方案。通过研究Opencv 图片识别和匹配算法，Sikulix 的库函数，得出相应的底层设计思路，并完成了整个测试系统框架的设计搭建。通过将本方案和常规工具进行对比，从不同的角度进行冒烟测试，实验结果表明本方案优于传统的测试工具。

由于本文主要针对桌面应用，且目前只实现了冒烟用例的编写，后期复杂测试需求提出，可能面临各种如下的改进：①过度依赖截图，某些功能组合数很多，单一的图片识别方式会导致图片数巨大，此时需要考虑以图片识别辅助接口测试的方案；②由于是界面展示型测试，和后台数据型测试相比，未知干扰多，包括输入法兼容，桌面变化等因素，后期需要思考其规避方案；③目前可以解决UI重排的图片更新问题，但是无法解决UI 文字，图形变化问题，需要重新手动进行素材的提取，后期可能要从人工智能的角度出发，探索新的无人值更新方法。