转变元素定位方式的UI自动化测试

◆ 前言

在做UI自动化测试过程中，由Web端慢慢转移到移动端，虽对象不同，但是基本思路是一致。找到要操作的元素，通过相应的驱动（Selenium,Appium等）连接目标进行操作。

但最近遇到了移动App普通定位方式无法定位或定位不准确的元素，迫使我寻求新的解决方案。因此开始了解到图片文字识别和目标检测这两种方式，并进行部署实现。

◆ 传统的UI自动化测试元素定位

☞ 传统元素定位方法

Web端有号称八大元素定位方法，归结起来主要是Css和Xpath两种；

移动端也无外乎这两种，另加一个可坐标操作方式。

☞ 传统元素定位流程

Web端需要打开浏览器调试器查看对应元素位置，保存Xpath或者Css路径以供脚本进行元素查找；

移动端则需要借助一些工具（如: Appium, UIAutomator)连接设备，对屏幕截图并提供元素查看，而坐标则是开启手机本身的坐标显示功能，通过点击相应位置查看实时的坐标信息。

◆ 什么原因驱动着我去寻求新的方式

☞ 在进行UI自动化测试时，测试人员都需要学习这几种元素定位方式，能够根据工具给出的信息写出脚本能识别的位置信息，而当元素没有像id这唯一标识时，元素定位则更增加了难度。

☞ 当页面由于某些原因出现一些不可见的元素，之前的大部分绝对定位和部分相对定位方式都是失去作用，而需要重新给出正确的定位方式，而这“正确”的方式也未必是稳定的。

☞ 当页面出现变更，布局发生变化，元素位置也会相应的发生改变，开发发一版，测试脚本改一版。页面小改，测试脚本大改；页面大改，测试脚本重写。

☞ 像移动端页面复杂，包括出现图标以及图片某一区域，经常出现定位不到元素，或者元素位置与显示的位置错乱，这无疑是加大了元素定位的难度。

◇ 测试中难点

个人经历的测试难点：

☞ 某一阶段页面频繁小改，测试脚本跑一次失败一次，大都是因为元素又定位不到了，需要重新去找元素位置，工作的重心从测试缺陷转移到了适配脚本上。

☞ 在App的UI测试中，遇到了抓取不到当前页面的情况，最后选择后退一步重新载入才能抓取到此页面，于是改测试脚本，问题才算是解决，而当重新载入也无法抓取到页面时，只能另辟蹊径，转而采用坐标进行点击。

☞ 部分App页面不规范，元素可以定位到，但与页面显示位置相隔甚远，这种位置定位到了反而没有一个能正确操作的，转而也采用坐标操作。

☞ 当脚本采用了大量的坐标点击方式，脚本也不知道当前执行的步骤是否正确，会一直执行结束，并且针对页面响应速度这个因素，不得不为每一步操作预留极长的等待时间以待页面加载好。

综上，遇到规范的，容易定位的页面，测试脚本写的容易，维护也容易。遇到不规范的，难定位的页面，测试脚本写着难，维护起来更是不知耗费多少时间精力。强行实现的自动化脚本反而失去了最初自动化的目的。

◇ 由难点提炼出的需求

☞ 需要解决页面布局频繁变化，而测试脚本微变化甚至不变化。

☞ 需要解决页面不规范以及页面元素不稳定时的定位问题。

☞ 需要降低测试人员脚本编写成本，提高自动化效率。

◇ 因需求而定的方案

☞ 采用图片文字识别对页面可见文字元素进行识别

文字识别网上也看了很多开源框架，最终选择使用百度的PaddleOCR。因为初次搭建成功后测试效果让我惊艳。虽然搭建过程一波三折，但是效果让人欣慰（基本无错）。
如：
图二为部分坐标结果图。

虽最终使用的还是通过坐标点击来实现UI自动化操作，但此时的坐标是实时获取到的，而非手动点击获取后输入脚本中的坐标。而对脚本编写者而言，需关注的仅仅是要定位的文字是什么。相当于对UI自动化操作对象进行了再一次的抽象。

支持端侧部署，对于将脚本推到设备运行的方式，这种部署方式显然是十分适合的。

而我则选择了服务端部署，利用Flask提供接口，与平台进行交互。灵活性很高。

☞ 采用目标检测对页面可见非文字元素进行识别

目标检测，主要用于对页面可见非文字元素进行识别操作，或弥补文字识别不足的地方。通过与图片文字识别相结合，实现页面元素的精准操作。

目标检测具体实现方式还在测试研究中。

◆ 新方式的可行性

新方式的应用需要考虑搭建及维护成本，测试效果两方面来考虑。

如果成本过高那么强行实现也是得不偿失。当然最终都是为了简易自动化测试的实施，如果效果不行，实现了也是徒劳无功。

传统定位方式	新式定位方式
搭建成本低，一次搭建，长期可用	搭建成本高，需根据识别效果进行模型训练
易用性低，需学习工具使用及定位方式	易用性高，只涉及页面显示文字或图标
稳定性低，页面底层元素变化会导致定位失效	稳定性高，目标文字不变，脚本不变
定位准确率，视页面布局底层元素的规范性而定	定位准确率，视模型优劣而定

综上，可以看出这种新式元素定位方式会大大提高脚本的稳定性，可维护性，极大的降低了测试人员编写脚本的难度，提高了自动化效率。但同时对平台开发人员也是一种新的考验，如何部署、训练模型、提高准确率、提高识别速度，都是需要仔细考虑的。

对于整个自动化平台或框架来说，新增了一种脚本实现方式。提高了平台或框架的能力。

◇ 适用场景

☞ 页面布局及内部元素位置改动较多，但目标文字改动少。

对于页面变更极少，而测试人员本已熟悉各种定位方式，则两种方式都可。

相反，页面变更偏多，测试人员对定位方式尚不够熟悉的情况下，这种方式则提供了极大的便利。

☞ 页面不规范，或页面元素难以定位。

针对这种情况，选择图片识别则会更好的保证脚本的稳定性。

◇ 需优化部分

☞ 效率。

目前采用的使用CPU进行识别，识别时间一般耗费2s-4s，及来回图片传输，总时间达到了6s-8s。

☞ 准确率

对于颜色太过浅淡文字识别效果较差，以及不同目标文字间隔太小会被误识别为一个目标，而文字较小笔画太多的文字可能会出现识别错误。

☞ 易用性

大大简化了自动化脚本编写方式，但增加了底层服务安装部署成本，如何实现快速部署，模型训练。

✸ 入坑需谨慎，且学且珍惜！