在公司做了两三年IM平台开发，基本上把IM的所有能力都搭建齐全了：单聊、群聊、文本消息、语音消息、视频消息、卡片消息、音视频通话等，而且把整个聊天页面各个区域都开放了出去。整个IM系统的框架以及开发流程都规范了下来，但是唯独在自动化测试领域有所欠缺，在有故障发生复盘的过程中，想到通过UI自动化帮助我们解决一些痛点问题。同时呢，接入UI自动化对我们在涉及底层改动，以及涉及兼容性的功能点时，可以为我们做一层兜底。总结下来我们在整个IM系统的开发过程中面临以下几个问题：

1. 移动端UI自动化行业现状

UI自动化测试一直是整个移动端的难题，因为它面临下面问题：

我们市面上常用的移动端UI自动化测试工具主要有：

• Android：UIAutomator

• iOS：UIAutomation

• 跨平台封装：Appium

日常UI自动化测试的方式主要有：

基于纯代码与录制方式的劣势，我们选择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：

##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，比如：

平台搭建成功后我们优先覆盖50%的核心Case，比如：

后续再看了边界Case，比如点击卡片跳转某个业务页面；最后再重点解决特殊Case，比如音视频通话。