1. 引言
GUI (Graphical User Interface)，即图形用户界面，它允许用户通过图像元素与计算机、笔记本、智能手机和平板电脑等电子设备进行交互 [1]。GUI的广泛应用，极大地方便了用户操作，同时也给测试人员带来了相应的挑战。通常软件中，GUI相关的代码量在整个项目中占了非常大的比重，同时GUI的质量直接影响着整个系统的运行。因此，GUI测试在确保软件质量方面起着至关重要的作用。
GUI测试经历了从传统的手工测试阶段到录制回放的自动化测试阶段，由于GUI自动化测试的测试效率高且测试成本低，目前已成为各大公司的首选。GUI自动化测试最关键的点在于如何识别控件对象，主要方法有基于关键字驱动的方法、基于UI控件搜索的方法、基于图像匹配的方法，相对应的较为成熟的GUI自动化测试工具有Mercury Interactive公司的QTP，Microsoft的Coded UI、WinAppDriver以及MIT的SikuliX等。现有的这些测试工具存在着对不同GUI开发框架的支持程度不同，测试断言少，且生成的测试报告需人工汇总等问题 [2] [3] [4]。
针对上述问题，本文提出一种基于Airtest的GUI自动化测试框架。该框架使用图像匹配技术来识别控件对象，以此实现对不同框架下开发的应用程序的测试支持，并提出几种新的断言以支持判断文件修改正确与否和页面预期结果正确与否，同时在测试报告的生成方面进行优化，实现测试执行完成后无需人为干预自动输出汇总报告。
2. 相关工作
2.1. 基于关键字驱动的GUI自动化测试
基于关键字驱动的GUI自动化测试，也被称为表格驱动测试或基于动作字的GUI自动化测试。它由Test Step、Test Object、Action、Test Data四部分组成，其主要思想为将关键字从测试用例和测试步骤中分离出来存放到对应的Test Step、Test Object、Action、Test Data中，测试发生变更时只需修改关键字即可，实现了测试数据与测试脚本的分离。
基于关键字驱动的测试工具中典型的代表是QTP。QTP将每个控件(如窗口、按钮、文本框等)都视为一个对象，同时构建一个对象库，把每个对象相应的属性和方法一并存入，脚本录制时将每一步操作的操作对象、操作类型和输入数据提取出来并进行记录，测试人员根据需要对其进行修改，增加检查点；脚本回放时按照记录文件中的内容依次调用相应对象的属性和方法进行录制还原，同时根据设置的检查点判断测试是否通过。
QTP的应用大幅提高了测试脚本的可重用性，同时使得编程能力不强的测试人员加快了测试进度。但QTP仍存在一些缺点：某些控件对象不易识别、不开源免费、只为每个测试用例单独生成测试结论，无法生成整体的测试结论。同时QTP只能识别Windows标准的控件(按钮，滚动条，静态控件，列表框，编辑框，组合框)，不能识别自定义控件 [5] [6] [7]。
2.2. 基于UI控件搜索的GUI自动化测试
基于UI控件搜索的GUI自动化测试 [8]，通过给定的控件属性(如id、name、xpath等)来进行控件元素的搜索定位，获得要进行操作的控件元素的相关信息，对控件进行操作，与预期结果进行比较，判断是否一致，从而完成测试。通过该方式来完成测试的工具，Web端是Selenium，移动App端是Appium，而Windows桌面端上实现较好的是AutoIt [9]。
AutoIt通过内置的Finder Tool获取被测应用程序中的控件，然后通过模拟键盘敲击、鼠标移动等操作来完成整个测试过程。它拥有类BASIC的语言表达式，同时支持多种语言以及多种Windows版本，使得新旧测试人员都可以很快上手。同时支持Win32和第三方DLL API的调用，脚本还可以编译成exe文件单独运行，在跨设备的测试工作中表现良好。
虽然AutoIt很强大，但它也存在一些缺点：对于不同桌面浏览器可能存在一些兼容性问题，没有断言，没有测试报告，每次测试通过与否需凭人工判断，不能做到无人值守。
基于关键字驱动和基于UI控件搜索的测试方法，在定位元素方面出现一点误差就可能导致控件对象定位不到，因此提出了基于图像匹配的UI自动化测试方法。
3. 基于图像匹配的GUI自动化测试
3.1. 图像匹配在GUI自动化测试的可行性分析及优势
基于图像匹配的GUI自动化测试，通过寻找当前界面中与给定图片相同或相似的图像区域，返回该图像区域的中心点坐标，再根据该坐标对控件操作从而完成测试。屏幕大小有限，屏幕上显示的内容也是有限的，这使得图像匹配的复杂度控制在了一定范围内 [10]。
由于不同GUI开发框架的底层架构不同，使用不同框架所开发的功能相同的应用程序，控件结构属性也相应会存在差异。这样就导致关键字驱动和UI控件搜索的测试方法需要为不同框架下开发的应用分别编写测试脚本来识别控件，造成了测试成本高昂。而基于图像匹配的测试方法由于应用的控件图像不会因开发框架的变化而发生太大变化，所以测试时无需对脚本进行大量改动，极大地降低了测试成本，更符合生产需要。
3.2. 图像匹配算法
在常用于自动化测试方法的诸多算法中，主要有以下两个分支：基于模板匹配的算法和基于特征点匹配的算法。
基于模板匹配的算法，即实现在当前屏幕图像上绘制一个与给定模板图像相同大小的矩形框，将该矩形框内的图像与给定的模板图像进行像素点级别的对比，如果该图像与给定模板图像的相似程度很高(即两张图片中相同的像素点数与总像素点之商大于给定的阈值)，就认为找到了该图像，同时返回该图像在当前屏幕上的坐标，从而可以对该坐标上的控件进行操作，完成自动化测试；否则该框向前移动继续比较，直到找到相似度极高的区域或当前屏幕图像遍历完成。
基于特征点匹配的算法，先对模板图像进行特征提取，得到一定数量的特征点及描述子，再对当前屏幕图像进行特征提取，得到当前屏幕图像的一系列特征点以及特征点描述子，计算模板图像的特征描述子与屏幕图像的特征描述子之间的距离，若两个特征点描述子之间的向量距离(常见的距离有欧式距离、汉明距离等)最小，则将这两个描述子视为它们所对应特征的最佳匹配。根据所有最佳匹配特征点对的横纵坐标，计算出模板图像转化到屏幕图像上的中心点、左上点、右下点坐标，取出屏幕图像中的该部分图像，与模板图像进行相似度计算，若相似度大于阈值返回中心点坐标，否则认为当前屏幕图像上不存在与模板图像相似的图像区域。
基于模板匹配的算法相对简单，运行速度快，但它不具有旋转不变性和尺度不变性，即当待匹配图像发生旋转或者缩放时，该算法就可能无法找到正确的匹配图像对。因此基于模板匹配的算法常用于对固定设备上的静态元素编写测试脚本的场景；基于特征点匹配的算法相对复杂，但它提取到的特征在旋转不变性和尺度不变性方面有着良好的表现，当待匹配图像发生旋转或者缩放时，该算法对正确匹配和错误匹配的图像对仍具有一定的辨别能力。真实生产环境中常常需要对软件在不同环境下的兼容性和稳定性进行测试，从而测试脚本所运行的设备可能会发生更改，设备发生更改时待匹配图像也可能会发生变化，所以基于特征点匹配的算法更适用于实际测试活动中。
4. 技术实现
4.1. 系统框架
本自动化测试框架以Airtest为基础框架并遵循维护性强和可复用性强的原则进行设计，同时集成Pytest测试框架和Allure测试报告框架对Airtest进行了扩展。采用图像匹配技术实现控件对象的识别，使得控件识别不受开发框架的限制，新增的断言模式和测试报告使得测试人员对测试工作更加得心应手，从而提高测试效率。框架采用分层设计，分为四层：公共库层、控件识别层、测试管理层、表现层。
图1是本测试框架的系统架构图。
Figure 1. Diagram of the system architecture
图1. 系统架构图
第一层是公共库层，该层主要实现一些通用功能，包含常用方法封装、基础配置、文件解析、截图等功能；第二层是控件识别层，该层包含了常用的图像匹配算法，为测试脚本执行过程中的控件对象识别提供支持；第三层是测试管理层，该层根据测试项目与功能点一对多的需求构建了脚本树用以管理脚本，同时使用Pytest来实现多个测试脚本的执行，并新增了测试断言以及相应的异常捕获；第四层是表现层，该层主要展示测试执行结果，测试人员可以通过测试报告与用例截图对照着查看每个测试脚本的执行细节，并根据测试日志定位失败用例中存在的问题。
4.2. 测试脚本自动运行
基于特征点匹配的图像匹配算法种类有很多，如SIFT、ORB、BRISK、AKAZE等。为了挑选出效果更好、更适合用于测试环境中的匹配算法，本文从一些应用程序中截取了部分控件图像，并对SIFT、ORB、BRISK、AKAZE等算法的特征点检测能力进行了对比，从图2 (左上右下依次为SIFT、ORB、BRISK、AKAZE算法检测到的特征点示意图)中可以得出，BRISK算法检测出的特征点基本覆盖了所有控件且误检概率较低；AKAZE和SIFT均检测到了大量特征点，但SIFT检测到的特征点中有不少误检，而AKAZE对部分控件的特征点检测有所遗漏；ORB检测到的特征点数量远少于其他算法且对勾选框的检测效果很差，所以，本框架选择BRISK作为图像匹配的主算法，并以SIFT算法为辅，当使用BRISK算法未在待匹配图像中找到与模板图像相似的图像块时，再改用SIFT算法继续执行相同操作。
基于图像匹配算法的控件识别方法，在面对不同开发框架所开发软件进行测试时，有很强的适应能力，我们对其进行了验证，如图3所示，左为对Tkinter所编写的软件进行测试时的截图，右为对Qt所编写的软件进行测试时的截图，图中红圈指代测试过程中鼠标的光标所在位置。
Figure 2. Comparison chart of feature point detection
图2. 特征点检测对比图
Figure 3. Testing software developed in different frameworks
图3. 对不同框架所开发软件进行测试
4.3. 测试断言模式
断言用来验证应用程序执行的正确性，快速定位错误。本测试框架除了支持目标图像是否存在于当前页面的断言、目标图像与模板图像是否一致的断言等这些常规的断言以外，还根据文件操作需求以及判别页面正确需求，新增了以下几种测试断言：目标文件是否存在、目标文件的最后n行是否为预期文字、OCR (Optical Character Recognition，光学字符识别)结果与预期是否一致。
支持目标文件是否存在的断言。一些测试场景下(如对下载文件、删除文件和导出文件等功能进行测试)经常会生成或修改一些文件，此时文件存在与否关系着测试用例的通过与否。考虑到有些软件生成的文件名字会很长，因此本框架还加入了断言文件是否存在的模糊选项，测试断言输入的文件名是给定路径下某个文件的文件名一部分即可视为通过。
支持目标文件的最后n行是否为预期文字的断言。许多软件都有日志功能，测试时可以通过其日志来判断测试是否通过。具体实现：先判断文件字符数是否小于读取字符数m，若小于，从文件开头读取所有字符，否则从文件末尾读取m个字符；随后判断读取到的文件行数是否大于n，若不大于n则判断读取到的文件行数是否等于n且文件读取指针移动到了文件起始位置，两个条件满足其一，便可将读取到的文件内容与预期结果进行比较从而完成断言，若两个条件均不满足则将读取字符数m翻倍，重复执行上述操作直至条件满足。流程图如图4所示。
支持OCR结果与预期是否一致的断言。一些软件操作过程中会在界面中显示大量的文字，用OCR便可判断预期结果与实际结果是否一致。由于OCR识别过程中可能会存在部分文字识别错误，因此本断言支持以实际结果与预期结果之间的编辑距离来决定断言是否通过。同时考虑到大量文字中重要的信息只有小部分，本断言还支持了判断预期结果是否包含于实际结果之中。图5为OCR断言失败时测试系统的输出。
4.4. 测试报告
Allure 是一种灵活的轻量级多语言测试报告工具，能以简洁的报告形式显示已执行测试的结果，而且还允许参与开发过程的人员从执行过程中提取有用信息 [11]。本框架以Allure为主，脚本树为辅，来完成测试报告的生成工作。待测试完成后，可以先从脚本树中根据脚本颜色来直观地查看各脚本的通过情况，再根据失败用例的名字从Allure生成的详细报告中查看执行失败的原因，判断是否为bug所致，再决定下一步是提交问题还是修改脚本。
图6为测试执行后的展示，左为脚本树情况，右为生成的测试报告。
5. 结束语
本文提出了一种基于Airtest的GUI自动化测试框架，解决了测试工具对不同GUI开发框架的兼容性问题，支持更多种类的断言模式，并且可以自动生成汇总后的测试报告，一定程度上提高了测试人员的测试效率。但本框架还存在一些问题，如跨分辨率匹配不稳定，而深度学习图像匹配技术相较于传统的图像匹配技术有着更高的鲁棒性和实时性 [12] [13] [14] [15] [16]，因此下一步将尝试在自动化测试框架中使用一些深度学习的技术，提高自动化测试的准确率和效率。
基金项目
校级研究生创新资助项目(项目编号：YKY-2021-21)；廊坊市科技支撑计划项目(项目编号：2021011029)。
NOTES
*通讯作者。