稳定性更高的iOS自动化测试是怎么做的？

最新推荐文章于 2024-09-17 21:35:52 发布

IMplementist

最新推荐文章于 2024-09-17 21:35:52 发布

阅读量835

点赞数 14

分类专栏：自动化测试文章标签：自动化测试计算机视觉模板匹配 OCR

本文链接：https://blog.csdn.net/Mr_Megamind/article/details/140965610

版权

自动化测试专栏收录该内容

2 篇文章 0 订阅

订阅专栏

一、自动化测试的不稳定因素有哪些？

由于 iOS 设备本身的特性，对 iOS 应用做自动化测试天然得会比 PC、Android 等端多出诸多不稳定的因素。

1. WDA 连接不稳定

Facebook WebDriverAgent（WDA）是一个用于 iOS 设备的 WebDriver 服务器，它允许我们通过 WebDriver 协议进行远程控制和自动化测试。它基于 Apple 的 XCTest 框架构建，可以在模拟器和真实设备上运行。我们的 iOS 自动化测试基于 WDA 来实现对控件的识别、点击、输入值、读取值等操作。

图1 WDA 启动检查失败问题示例
WDA 启动后，会通过以下的代码向 iOS 设备发送一个 status 请求，检查连接是否成功，设备是否完成了测试前的准备。此时，有一定的概率 status 请求不能及时响应，用例还未执行就抛错退出了，具体的示例如图 1 所示。

	def is_ready(self) -> bool:
		try:
			self.http.get("status", timeout=3)
			return True
		except Exception as e:
			return False

2. 测试资源不稳定

测试资源即测试过程中所需的一切资源，以下列举一些常见的测试资源不稳定情形：

测试账号: 有的测试账号有时效，过期了就没法登录使用，导致自动化测试任务全部失败。
测试环境: 前端/后台的测试环境可能经常处于变更部署中，无法提供服务；或者包含开发人员新引入的严重Bug，导致自动化测试任务大量失败。
测试文件: 有的测试用例需要操作一些提前构造好的文件、文档。这些重要的物料有时会被不知情的人、设计不合理的前置/后置步骤改写或删除，导致自动化测试任务部分失败。
测试框架: 例如笔者近期遇到的一个问题，新版的Flutter中引入了这个Bug：自动化测试进行到一定界面的一定步骤时，会使APP发生Crash，但人工执行这些步骤不会Crash。
…

像这样的问题多如牛毛，几乎每天都有新的情况发生。但在正常的软件开发流程中，上述的大部分问题是测试/测开人员无法控制和避免的（除了第3条，可以妥善保存测试文件），因此也不是本文重点要解决的问题。

3. 高频变更的业务需求引入了很多控件定位的不稳定因素

随着业务和功能越来越完善和丰富，传统的自动化测试脚本基于XPath来定位控件，在这种APP高频变更的场景下显得岌岌可危，维护成本陡然增加。

下面在iOS端上，选择一个功能比较复杂的APP——企业微信——作为对象，举几个例子来说明：

3.1 图标控件的 XPath 变更导致无法识别

图2 高频变更的图标控件示例

如图2所示，高频变更的图标控件已用红色的方框标出。由于开发人员的代码变更，使得这些控件在整个页面的 DOM 树中位置层级、或者 class、id 等常用于定位控件的属性频繁发生变化，进而导致在自动化测试脚本中使用传统的通过 XPath 定位控件的方法经常失效。

例如一某个控件的原始的XPath为：

	//div[@class="tool_bar"]/div[3]/div[1]/span

变更后变成了：

	//div[@class="tool_bar"]/div/div[2]/div[1]/span

又例如某个控件的原始XPath为：

	//span[@id="at"]

变更后变成了：

	//span[@id="mention"]

这是我们每天都在经历的真实事件。对于维护自动化测试脚本的人来说，可能前一秒刚用n号安装包写好自动化脚本，下一秒换到n + 1号安装包就报错跑不了了。

但令人无法接受的是：这些图标现在清清楚楚的出现在屏幕中间，肉眼可见，自动化测试代码却无法定位和点击它们。

3.2 文字控件的 XPath 变更导致无法识别

图3 高频变更的文字控件示例

如图 3 所示，高频变更的文字控件已用红色的方框标出。与图标控件的问题类似，高频的变更导致我们无法设置一个稳定的XPath，用于稳定地定位这些控件。

同样令人无法接受的是：“多选”两个字现在清清楚楚的出现在屏幕中间，肉眼可见，自动化测试脚本却无法定位和点击它。

二、问题分析

先是结论：问题出在传统的控件定位方法：XPath上。

XPath是自动化测试出现以来仅有的一种控件定位方式，被沿用至今，哪怕是新兴的鸿蒙系统，也准备为我们提供一套类似的控件定位方案。但XPath具有以下的严重缺陷：

XPath本身就是一种 “作弊机制”，「解析控件树得到的控件定义」和「用户看得见摸得着的控件」有着天壤之别！

下面针对「图标控件」和「文字控件」分别举一个例子，说明XPath的缺陷：

2.1 图标控件加载失败时的漏判问题

例如我们待测的APP中有一个图标，用以下的标签定义：

	<img id="image" src="https://xxxxxx.xxx"/>

img标签是前端常见的用于显示图片的标签，如果通过 XPath，我们只能检查一个页面中//img[@id="image"]是否存在，而当 img 的 src 存在拼写错误或者图片资源因为跨域、被删除等问题无法加载，就会出现 「裂图」， 如图4所示。这种检查就会存在漏判。

图4 图片资源无法加载时页面出现的“裂图”图标

2.2 文字控件颜色异常时的漏判问题

图5 文字控件颜色异常的实例

一般情况下，界面中按钮文字的颜色会和背景色有一定的差异，便于用户分辨。如图10所示的一个异常变更情况，这里有一个提示弹框，其上有一个“确定删除”的按钮。由于开发人员的手误，将原本为dodgerblue（一种设定的深蓝色）的按钮文字设置为了white（白色），此时并未修改该按钮的层级，即未改变该控件的XPath。

此时若执行自动化测试，使用XPath方式点击该按钮，仍可以点击到，执行下面的操作，就会放过该Bug，造成漏测！

2.3 总结根本矛盾

上述矛盾的核心在于：「电脑看到的」和「人看到的」完全不同！

在前文中，我们已列举了几种XPath控件定位的反例：
1）肉眼看得到的控件，自动化脚本点不到，判断不存在，抛错退出。
2）肉眼看不到的控件，自动化脚本判断其存在，意料之外地通过检查，造成漏测。

2.4 解决问题的思路

随着「计算机视觉技术」的不断发展，我们可以越来越大程度得让「电脑看到的」≈「人看到的」。

进而在我们自动化测试的控件定位方面也应该不断地趋近于以下目标：

肉眼看得到的 = 可以被点到（可以操作）= 被电脑判断为存在
肉眼看不到的 = 不可以被点到（不可以操作）= 被电脑判断为不存在

三、引入模板匹配技术

为了解决通过XPath定位图标控件不稳定、有严重缺陷的问题，我们引入模板匹配技术。

3.1 原理

模板匹配并不是一个新兴技术，也是我的老生常谈。为了阐明将其引入到 iOS 端自动化测试如何解决我们的问题，这里简要介绍其原理。

图6 模板匹配原理示例
如图 6 所示，模板匹配可以帮我们在一张原图（Source）中搜索模板图（Template），并输出模板图在原图中的位置和坐标。

3.2 用法

由前文中所知，部分控件变更非常频繁，定位这些控件的 XPath 经常失效，这导致了自动化用例的稳定性非常低。通过引入模板匹配技术，我们解决了上述图标控件定位的难题。

图7 模板匹配在 iOS 端自动化中的应用示例

如图 7 所示，我们通过模板匹配定位文档的“插入”按钮，该方法会返回匹配到的模板在原图中的所在区域和中心点坐标(center_x,center_y)，如图中所示的(x, y)。此时我们点击该坐标，就点击到了“插入”按钮。

3.3 优点

相较于传统的 XPath 定位方式，模板匹配有以下的优点：
1）在模板匹配的基础上，我们可以检查图片中的元素是否出现来判断图片是否加载成功，也可以反向判断没有出现图4 所示的“裂图”图标，就认为图片加载成功。总之，判断逻辑是准确且丰富多样的。

2）如前文所述，模板匹配方法主要解决图标控件 XPath 频繁变更导致的定位不稳定问题。即只要对应的控件图标不更换，我们一次截图，对该控件的定位和识别是长期稳定使用的。

3.4 Scale：适配不同型号iPhone设备需要额外考虑的一点

由于硬件设备的不断发展，手机显示屏的清晰度越来越高，不同代的 iPhone 设备其截屏图片的 “倍率（scale，缩放率，尺度）” 有所不同。

1）早期的 iPhone 3GS 及以前的设备，其 scale 为 1，即物理像素值和逻辑像素值一致，这样的机器截屏图片的分辨率和屏幕一致。

2）iPhone 4 - 6代，其 scale 为 2，同理，这样的机器截屏图片的长度和宽度都是真机的2倍。

3）iPhone 6S 及以后的机器，其 scale 为 3，即截屏图片的长度和宽度都是真机的3倍。

图8 不同尺寸的iPhone设备模板适配逻辑
由于我们截取模板图片的手机和自动化执行的云机器并不相同，因此在模板匹配前需要先将图片统一对齐到一倍。如图8所示，我们在前期用一个scale为m的手机截取模板图，然后用下面的代码将其缩放到1倍，保存在项目中。在执行自动化测试时，对一个scale为n的执行机截取原图，然后用同样的方式将其缩放到1倍。然后用同为1倍的模板图和原图进行模板匹配。得到的坐标即可通过自动化框架直接点击，如图中的`(x, y)`。

	def resize(input_file_path,&nbsp;scale):
		"""
		缩放图片
		:param input_file_path: 图片文件的路径
		:param scale: 缩放的比例
		"""
		image = cv2.imread(input_file_path)
        
		width = int(image.shape[1] / (scale + 0.0))
		height = int(image.shape[0] / (scale + 0.0))        

		image = cv2.resize(image, width, height)
		cv2.imwrite(input_file_path, image)

四、引入OCR技术

为了解决通过XPath定位文字控件不稳定、有严重缺陷的问题，我们引入OCR技术。

4.1 用法

OCR（Optical Character Recognition，光学字符识别）是一种新兴的技术。其在自动化测试中可以用于解决上述文本控件的定位难题。如图9所示，通过OCR技术可以直接提取到“多选”二字的坐标，然后根据坐标直接点击该控件。只要这里的文字不发生变化，我们就可以无视XPath变更带来的定位问题。