IM场景的移动端UI自动化测试平台实践

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

1. 某些改动开发人员难以对改动内容评估到位；
2. 设计兼容性问题需求难以做出决策：比如在做基于系统TTS的Push内容语音播报过程中由于摸不清市面上哪些手机系统不支持中文TTS，无法做决策，自己找手机一个一个测试效率有太低，这个时候特别需要这么一个自动化的平台；
3. 基础库变更影响面大：比如要替换统一的网络库，有一百个接口涉及到了改动，对应到功能上可能是几百个功能点，对于QA的测试成本太高；
4. 封板前后case回归量大：IM系统做了几年的需求迭代，case数量已经相当庞大，每次发包前的功能回归工作量巨大；
5. 新APP内IM质量难以保证：团队内QA只负责公司主要APP内的IM功能，新APP接入IM后，IM模块属于”三不管“区域，有些必现问题会被直接带到线上。

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

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

1. UI变更频繁，Case维护成本高；
2. Case覆盖率低，性价比差；
3. 元素查找方式不稳定；
4. case执行结果分析困难，元素对比方式欠缺（尤其图片元素）。

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

• Android：UIAutomator
• iOS：UIAutomation
• 跨平台封装：Appium

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

1. 纯代码编写Case：缺点是对Case编写人员要求较高，Case编写效率低下；
2. 平台化工具：通过UI页面输入元素ID等变量，自动生成代码，缺点时平台开发成本以及平台学习成本；
3. 手机操作录制方式：手动操作手机，自动记录操作过程中点击的元素等，通过回放方式执行case。缺点是稳定性太差，尤其列表内随便一个顺序的变化都可能导致Case执行不成功。

基于纯代码与录制方式的劣势&#