移动端UI自动化过程中的难点及应对策略

阅读本文大约需要2.1分钟。

前言

在之前的文章《自动化质量评估维度》中，我们探讨了衡量自动化稳定性的误报率指标，今天重点针对移动端UI自动化过程中导致误报的几个难点进行展开分析并给出相应的解决方案。

被测应用不稳定

问题1：自动化测试介入时机太早

对于移动应用来说，我们需要准确把握介入时机，不要在项目早期介入UI自动化测试，应该等版本相对比较稳定成熟后再开展UI自动化测试，不然每次业务UI变更带来的自动化用例维护成本会非常高。

问题2：自动化用例设计及选择不合理

在确定要开始做UI自动化测试后，需要先拆解手工测试用例，因为大多数的测试用例都是基于手工测试编写的，在自动化环境下，在流程编排和结果校验方式上需要做适当调整，并且在拆解过程中要优先实现核心模块较稳定的测试用例，因为不稳定的测试用例会给后期的维护和排查问题带来巨大的成本。

问题3：被测应用Debug调试信息阻断测试执行

为了提高研发调试效率，通常移动APP都会在Debug模式下提供很多方便调试用的工具集，比如leakcanary、内存信息Toast等，这些内容在UI自动化过程中反而成了影响稳定性的一个比较大的因素，比如因为leakcanary工作时dump内存导致页面卡顿从而影响执行的稳定性。

对此我们可以增加打包参数通过自定义打包服务来去除Debug相关的工具集，如果有些Debug信息无法提供开关控制，我们可以通过从master上开一个新的分支然后修改源码，每次去rebase主干的方式来关掉相应的Debug调试信息。

有人可能会问干嘛不直接用Release包，主要是因为Release包一般会存在证书信任问题导致无法使用Mock Server。

测试框架不稳定

这里我是基于Appium去做的UI自动化，所以下面有些策略仅适用于Appium。

问题1：手机连接会出现Offline的情况

针对这种情况我们可以通过在每次任务开始前Reset USB来彻底解决，参考：

https://chromium.googlesource.com/chromium/src/build/+/293b55887f2f0bcc9e2ed66b24bc6a2b62bbd556/android/devil/utils/reset_usb.py?spm=ata.13261165.0.0.366044cdRdK3m7&file=reset_usb.py

问题2：An unknown server-side error occurred while processing the command. Original error: Could not proxy command to remote server. Original error: Error: read ECONNRESET

遇到这种问题时，建议在执行测试前重置Appium的Agent，也就是删掉下面跟Appium有关的应用，让Appium重新自动安装：

adb uninstall io.appium.uiautomator2.server
adb uninstall io.appium.uiautomator2.server.test
adb uninstall io.appium.unlock
adb uninstall io.appium.settings

问题3：WIFI断开及连到其他WIFI的情况

针对这种情况，我们可以自己开发手机Agent应用来控制连接指定WIFI并且在断开连接后自动重连，具体实现我会在后续文章中讲解。

问题4：应用通知栏信息打断测试执行

在自动化测试执行过程中经常会由于其他应用或者本应用的通知弹框阻断测试的执行，对此我们需要禁用通知栏来避免此类问题的发生，具体实现我会在后续文章中讲解。

问题5：Appium并行测试不稳定

在基于Appium做并行自动化测试的过程中会在一台宿主机上同时监听多个端口，这时我们可以通过官方提供的appium-docker-android来为每个设备提供相对独立的测试环境，具体实现我会在后续文章中讲解：

https://github.com/appium/appium-docker-android

问题6：由于随机的页面延迟造成的控件识别失败

我们可以首先通过隐式等待增加Appium服务端的超时时间，其次通过增加重试机制来避免，重试可以是步骤级别的比如显示等待，也可以是页面级别的，甚至可以是业务流程级别的。

问题7：非预期的弹出对话框

这里包括系统弹框和应用内业务弹框，针对系统弹框，我们可以通过无障碍服务来实现智能点击处理，对于应用内业务弹框，如果是可以通过接口控制的，我们可以Mock掉这个接口，否则我们可以通过watch机制来解决，具体实现我会在后续文章中讲解。

问题8：页面控件属性的细微变化导致识别失败

对于有明确ID的控件可以用ID来直接定位，对于没有ID的控件建议可以通过XPATH模糊匹配来定位，或者可以通过封装组合属性查找来定位，这样可以进一步提高控件的识别率，具体实现我会在后续文章中讲解。

测试脚本不稳定

问题1：缺少等待时间导致断言失败

可以加入一些判断条件，确保页面加载完成再进行UI操作，另外尽量使用逻辑验证，减少数据验证，数据验证更适合接口测试。

问题2：缓存问题

有些case在修改配置后,需要应用冷启动才能生效，我们可以在执行前清除应用缓存数据。

问题3：控件查找超时

Appium默认情况下每个执行请求都有超时时间包括查找控件，有时候由于设备性能太差导致执行时间过长，从而导致Appium Server断开连接，这时需要通过修改Appium Capabilities中的newCommandTimeout字段的值来增加超时时间或者更好新一点的设备。

问题4：手机屏幕分辨率问题

由于测试设备品牌型号各异，我们写自动化脚本的过程中需要针对不同机型做适当的适配，比如曲面屏、全面屏等。

测试环境不稳定

问题1：动态类的数据导致页面总是变化

有些非工具型应用，会有很多AI推荐类的信息流，这时我们可以借助Mock来提供稳定的数据环境。

问题2：测试账号被修改

可以通过账号保护服务或者在测试执行前通过接口重置账号状态来解决自动化测试账号被滥用更改的情况，另外我们自动化测试脚本中可能会有涉及测试账号状态操作的Case，这时候最好给这个模块提供独立的自动化测试账号，做隔离避免互相干扰。

问题3：测试账号被风控

我们的测试账号在使用过程中经常会由于中了风控的策略弹出各种验证码弹框，导致测试执行失败，这时我们需要将自动化测试账号加到白名单中来避免，另外还要注意白名单的有效期，最好可以申请时间长一点或者提供到期提醒避免再次被风控拦截。

问题4：网络环境不稳定

有时候在办公网环境下做自动化会遇到AP连接数太多导致自动化设备的网络出现抖动，这时我们可以通过增加独立AP的方式来解决。

问题5：代理IP变更

如果我们使用了MockServer，经常会由于MockServer的IP地址变更导致测试执行失败，一般情况下代理都是我们手工配置在手机的WIFI设置中的，针对这种情况我们需要动态更改设备代理信息，具体实现可以参考《Android自动化中动态设置网络代理》。

今天就先分享到这里，后续会针对文中的一些具体问题做详细方案的讲解，欢迎有兴趣的同学跟我讨论。