IM 场景的移动端 UI 自动化测试平台实践
在公司做了两三年 IM 平台开发，基本上把 IM 的所有能力都搭建齐全了：单聊、群聊、文本消息、语音消息、视频消息、卡片消息、音视频通话等，而且把整个聊天页面各个区域都开放了出去。整个 IM 系统的框架以及开发流程都规范了下来，但是唯独在自动化测试领域有所欠缺，在有故障发生复盘的过程中，想到通过 UI 自动化帮助我们解决一些痛点问题。同时呢，接入 UI 自动化对我们在涉及底层改动，以及涉及兼容性的功能点时，可以为我们做一层兜底。总结下来我们在整个 IM 系统的开发过程中面临以下几个问题：
某些改动开发人员难以对改动内容评估到位；
设计兼容性问题需求难以做出决策：比如在做基于系统 TTS 的 Push 内容语音播报过程中由于摸不清市面上哪些手机系统不支持中文 TTS，无法做决策，自己找手机一个一个测试效率有太低，这个时候特别需要这么一个自动化的平台；
基础库变更影响面大：比如要替换统一的网络库，有一百个接口涉及到了改动，对应到功能上可能是几百个功能点，对于 QA 的测试成本太高；
封板前后 case 回归量大：IM 系统做了几年的需求迭代，case 数量已经相当庞大，每次发包前的功能回归工作量巨大；
新 APP 内 IM 质量难以保证：团队内 QA 只负责公司主要 APP 内的 IM 功能，新 APP 接入 IM 后，IM 模块属于”三不管“区域，有些必现问题会被直接带到线上。
1. 移动端 UI 自动化行业现状
UI 自动化测试一直是整个移动端的难题，因为它面临下面问题：
UI 变更频繁，Case 维护成本高；
Case 覆盖率低，性价比差；
元素查找方式不稳定；
case 执行结果分析困难，元素对比方式欠缺（尤其图片元素）。
我们市面上常用的移动端 UI 自动化测试工具主要有：
Android：UIAutomator
iOS：UIAutomation
跨平台封装：Appium
日常 UI 自动化测试的方式主要有：
纯代码编写 Case：缺点是对 Case 编写人员要求较高，Case 编写效率低下；
平台化工具：通过 UI 页面输入元素 ID 等变量，自动生成代码，缺点时平台开发成本以及平台学习成本；
手机操作录制方式：手动操作手机，自动记录操作过程中点击的元素等，通过回放方式执行 case。缺点是稳定性太差，尤其列表内随便一个顺序的变化都可能导致 Case 执行不成功。
基于纯代码与录制方式的劣势，我们选择 UI 自动化平台方案。
2. UI 自动化平台介绍
市面上的 UI 自动化平台基本上都是大同小异，把查找元素的方法抽象到一个下拉列表，再通过输入框输入要查找元素 ID，查到到元素对应做一些动作。今天以 opendx 为例介绍一下 UI 自动化平台能力（它的页面和架构相对更人性化）。
2.1 操作界面
可以先选择一款调试设备，用于在网页内直接查找元素和调试 case：
提供了一系列常用的基础 Case：
选择执行动作并填入参数值：
2.2 平台系统架构
如下图所示，整个系统分了两大模块：Server 与 Agent。
Server 负责与数据库交互，提供供浏览器访问的网页内容，并管理 Agent；
Agent 连接负责执行 Case 的手机，每个 Agent 都跑着一个 Appium 服务，浏览器通过与 Agent 的长连接，可以直接调试 Case。
这样设计的好处了，大家可以共用一个库，一个服务，然后各自在各自的机器运行 Agent，达到并行执行效果。
2.3 数据库表设计
这个系统包含下列数据库表：
有用户管理，设备管理，项目管理的概念，除了这些主要就是 action 以及测试任务，测试集，测试计划的概念。action 可以理解成是一个具体 case，一个 action 又可以是多个基础 action 组成。一系列 action 组成测试集，测试集可以组合成测试计划，某个测试计划生成对应的一个个测试任务。
下面是具体的 action 表结构：
我们可以把 action 看成是我们用代码执行测试 case 时的测试函数，有函数名，函数返回值，函数参数等。
总结成下列流程：
生成对应代码示例：
下面是系统系统了的基础的 action：
执行 Java 代码；
休眠；
下载文件；
删除文件；
点击；
查找元素；
查找元素列表；
输入；
设置隐式等待时间；
等待元素可见；
等待元素出现；
[web]访问 url；
[web]切换窗口；
[web]点击（By JS）；
元素是否显示；
等待元素可见；
获取当前时间；
accept 对话框；
异步 accept 对话框；
dismiss 对话框；
异步 dismiss 对话框；
安装 app；
卸载 app；
滑动屏幕；
滑动屏幕查找元素；
容器内滑动；
容器内滑动查找元素；
长按元素；
清楚 apk 数据；
启动/重启 app；
执行 adb shell 命令；
窗口最大化
##3. IM UI 自动化挑战
市面上的所有的 UI 自动化平台均面临一个问题：只能对单个手机进行测试，但是 IM 场景有些 Case 至少需要两个手机：一个用于发送消息，另一个用于接收消息，当用户 A 发送消息成功，并且用户 B 接收消息成功才能算一个完整的 Case。
不过好消息是 IM 的页面在迭代工程中改动较少，这样大大降低了 IM 场景 UI 自动化的 Case 维护成本。
至于元素比较，结果校验我们可以通过接入一些基于 AI 的智能方案来解决。
4. IM UI 自动化测试解决方案
基于 opendx 的能力，我们提供在 Action 结构中加入设备列，标识该 Action 是在哪个设备执行。这样就可以完美解决平台化无法支持多个设备的问题。
我们可以将设备在平台上定义为全局变量，这样每次执行 case 的时候可以通过修改全局变量来变更设备。
5. 总结
今天介绍了移动端 UI 自动化测试的一些方案和问题，以及 UI 自动化平台在 IM 场景的解决方案。先解决还是在平台搭建阶段，首先我们要基于 opendx 提供提供一些符合我们业务场景的基础 Action，比如：
网络请求 action：我们可以在 action 端执行 http 请求，验证消息是否到达服务端或者解决常见的登录注册问题，登录需要验证码的时候我们一般无法自动获取验证码，这次我们通过服务端暴露的接口来请求获取验证码；
支持条件语句：比如判断某个执行结果，如果符合预期则指令 A Action， 不符合则执行 B Case。
平台搭建成功后我们优先覆盖 50%的核心 Case，比如：
发送/接收各种类型消息
会话列表显示点击
会话详情页吸顶条
会话详情页加号配置
各类型消息点击
各类型消息长按
消息未读已读
后续再看了边界 Case，比如点击卡片跳转某个业务页面；最后再重点解决特殊 Case，比如音视频通话。
版权声明: 本文为 InfoQ 作者【轻口味】的原创文章。
原文链接:【http://xie.infoq.cn/article/a2cdc9bd91d41e2683206f87c】。文章转载请联系作者。
🏆2021年InfoQ写作平台-签约作者 🏆 2017.10.17 加入
Android音视频、AI相关领域从业者，开源RTMP播放器：https://github.com/qingkouwei/oarplayer
评论