在公司做了两三年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，比如音视频通话。
