一、背景说明

目前所在项目组的客户端采用的是敏捷开发模式。该模式通常是在生产后部署快速修复程序，然后再次进行回归测试。整体回归的测试而言非常耗时，很多时候是无法确定修改部分功能导致的影响范围到底多大，在这种情况下，很可能陷入了恶性循环。在这之前测试团队都是手动回归测试，测试人员都必须重复大量的测试用例，一遍又一遍地执行相同的测试，不仅要花费更多的时间，而且还会降低测试的整体效率。

因此开发同事帮助测试团队调研了自动化测试技术方案——ATX（Automotive Test Exchange Format））自动化。自动化测试可以加快测试周期，不必每天重复执行单调的测试用例，节省出来的时间用来提出更好的测试用例场景。接入此项目后初学自动化，对此技术方案进行了学习，相关介绍如下。

二、技术方案

关于 APP 的 UI 自动化，基本上都是采取的 pom 模式（Page Object Model）加上关键字驱动、数据驱动、实现测试数据分离。

POM 模式是将 APP 每个页面当作是一个对象类进行分层管理，一个类就是一个模型，通过模型生成页面对象。分为三层模型，第一层为基础页面层，包含一些基础的公共方法的公共属性，比如元素定位和输入点击等操作；第二层为测试用例层，包括具体操作流程的用例，第三层里是用例数据，调用的是第二层内的方法。此模式相当于是将页面内的 UI 元素对象、逻辑、业务、数据等分离开来，让测试逻辑更加清晰，如果后期客户端的 UI 进行了调整修改，也不需要更改测试脚本，只要更改页面对象中的代码就可以，可维护性也很高。

数据驱动是通过 excel、csv、yaml 和数据库等读取输入和输出的数据，然后通过变量传入自动化测试用例中，在整个过程中，数据的读取，测试状态，测试信息全部在测试用例里面。关键字驱动，关键字是将同样的业务逻辑会封装成一起的函数的名称，业务逻辑可以通过调用关键字来实现。

调研 App 自动化测试技术方案，调研前考虑框架需要很强的跨平台能力（支持：Android、IOS、H5），有强大的第三方库，编写脚本更有效率，配置简易启动迅速，最后选择 ATX+python 组合。

ATX 的 python 库 openatx 被拆分成了 20 多个库，便于维护和集成。其中 uiautomator2 主要用来做 Android 端的自动化，facebook-wda 用来做 IOS 端的自动化，adbutils 库是用来和 adb 做交互，但不是简单的做个交互，而是通过协议程序去和 adb 进行交互，但是这块只支持 python3.6+。

在执行 APP UI 自动化测试时，需要使用到元素定位，通常我们会直接使用 appium Desktop 的 Inspector。这里有另外一种方法，ATX 抓取页面元素使用的控件为 WEditor 能够提供辅助编写脚本，定位元素，调试代码等功能，是基于 python 的一个查看 APP 元素的工具，此工具的使用可以减少 atx 频繁的启停。以下是 Appium 和 ATX 中的 uiautomator2 一些对比情况：

相较于 Appium，可以看出 ATX 的上手难度以及配置会比较简单，而且启动和运行的速度会更快，只是支持的编程语言会比较单一，ATX 只支持使用 Python 语言。除此之外，appium 实现跨应用操作很困难，但是 ATX 可以实现混合 APP 的 UI 自动化并且生成测试报告。询问了相关开发人员选择此方案还有一个原因，就是使用 OTX 标准化工具，可以支持多种测试硬件，减少测试软件兼容性问题，可以使得 APP 自动化和固件脚本命令、python 可视化页面等固件自动化同时进行。

三、实现过程

简单记录一下安装部署的步骤，在配置好 python3 的环境后，首先 pip 安装适配于安卓的 uiautomator2 后对手机进行初始化，其次 pip 安装 weditor，每次测试前都需要先启动这个。最后进行脚本设置，配置项目根目录下 conf.json 文件后就可以执行运行命令了。

环境配置完成后，已安装 Android 的 sdk，adb devices 检查移动设备后出现 List of devices attached，是由于设备连接失败，排查后检查原因有以下两点：（1）检查是否已安装手机驱动，电脑→管理->设备管理->Andriod Phone 项；（2）检查手机的 usb 是否已打开开发模式，usb 调试。连接成功后执行 update 后会生成设备对应路径下的文件，此时打开 weditor 浏览器页面访问地址，输入 adb devices 查询到的序列号，点击 connet 便可以进行实时监控。安装、设备初始化以及配置文件配置完后可以进行代码操作了，常见的代码如下。

由于项目是需要和硬件进行交互的，客户端的具体测试操作是体现在具体设备的功能实现上，固件设备连接串口后可以通过串口给设备发送配置数据，也可以实时输出日志打印，校验客户端指令是否发送成功并确保实际操作成功无误。故在实现 APP 操作自动化的同时也实现了固件自动化，这也是开发人员调研方案后选择 ATX 自动化方案的原因之一。

实现了固件和 APP 结合的自动化测试之后，每次进行测试需要手动选择设备具体的串口号后打开串口，并且需要输入指令来启动流水操作的具体执行，故考虑可以做个有功能按钮的简单的可视化页面，来完成以上启动测试的准备操作。实现的操作可视化页面包含以下 4 个有关流程的元素：
◆ 选中串口号
◆ 点击 “打开串口” 按钮
◆ 点击 “接收设备日志” 按钮，查看是否有数据显示
◆ 点击 “开始快连测试” 按钮

操作可视化是使得每次进行测试时的步骤变简易的最简单有效的方式，并且实时输出日志打印并保存到本地可以便于更好地分析数据，其中有关固件交互部分的串口值处理的具体实现代码如下图所示，从串口工具中获取到可读取到的所有有效的串口号，将其全部存储在串口列表的数组中，后续完善页面的显示控件后检测到 button 的 down 操作时对读取到的串口值进行处理，获取到有效串口后调用串口打开函数，此时只需要检查保证串口输出的日志打印为此设备的日志即可开始后续的客户端用例的自动化执行了。

四、总结

客户端的 UI 自动化测试除了常见常用的 appium 之外，对于一些使用 python 语言的客户端自动测试，ATX 也是个很不错的自动化测试方法，不仅可以实现混合 APP 的 UI 自动化，而且配置简单、运行速度快，其中的 OTX 的标准化工具，可以支持多种测试硬件，减少测试软件兼容性问题，非常适合和固件自动化进行兼容使用，十分推荐！
但是需要注意的是 appium 和 ATX 的 weditor 框架不兼容，运行 2 个程序时会导致无法正常运行