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

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执行不成功。

基于纯代码与录制方式的劣势,我们选择UI自动化平台方案。

2. UI自动化平台介绍

市面上的UI自动化平台基本上都是大同小异,把查找元素的方法抽象到一个下拉列表,再通过输入框输入要查找元素ID,查到到元素对应做一些动作。今天以opendx为例介绍一下UI自动化平台能力(它的页面和架构相对更人性化)。

2.1 操作界面

可以先选择一款调试设备,用于在网页内直接查找元素和调试case:

0474cb1efa7e2a280f670c65dffaa05b.png

提供了一系列常用的基础Case:

d9d81190c22e74a5708f3a66c4ad6ad6.png

选择执行动作并填入参数值:

73d78bf345d305cd590820221ff99a81.png

2.2 平台系统架构

如下图所示,整个系统分了两大模块:Server与Agent。

  • Server负责与数据库交互,提供供浏览器访问的网页内容,并管理Agent;
  • Agent连接负责执行Case的手机,每个Agent都跑着一个Appium服务,浏览器通过与Agent的长连接,可以直接调试Case。

这样设计的好处了,大家可以共用一个库,一个服务,然后各自在各自的机器运行Agent,达到并行执行效果。

image-20211024223911653.png

image-20211024223928647.png

2.3 数据库表设计

这个系统包含下列数据库表:

image-20211024224305821.png

有用户管理,设备管理,项目管理的概念,除了这些主要就是action以及测试任务,测试集,测试计划的概念。action可以理解成是一个具体case,一个action又可以是多个基础action组成。一系列action组成测试集,测试集可以组合成测试计划,某个测试计划生成对应的一个个测试任务。

下面是具体的action表结构:

image-20211024224316020.png

我们可以把action看成是我们用代码执行测试case时的测试函数,有函数名,函数返回值,函数参数等。

总结成下列流程:

image-20211024224813081.png

生成对应代码示例:

image-20211024224826755.png

下面是系统系统了的基础的action:

  1. 执行Java代码;
  2. 休眠;
  3. 下载文件;
  4. 删除文件;
  5. 点击;
  6. 查找元素;
  7. 查找元素列表;
  8. 输入;
  9. 设置隐式等待时间;
  10. 等待元素可见;
  11. 等待元素出现;
  12. [web]访问url;
  13. [web]切换窗口;
  14. [web]点击(By JS);
  15. 元素是否显示;
  16. 等待元素可见;
  17. 获取当前时间;
  18. accept对话框;
  19. 异步accept对话框;
  20. dismiss对话框;
  21. 异步dismiss对话框;
  22. 安装app;
  23. 卸载app;
  24. 滑动屏幕;
  25. 滑动屏幕查找元素;
  26. 容器内滑动;
  27. 容器内滑动查找元素;
  28. 长按元素;
  29. 清楚apk数据;
  30. 启动/重启app;
  31. 执行adb shell命令;
  32. 窗口最大化

##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,比如:

  1. 网络请求action:我们可以在action端执行http请求,验证消息是否到达服务端或者解决常见的登录注册问题,登录需要验证码的时候我们一般无法自动获取验证码,这次我们通过服务端暴露的接口来请求获取验证码;
  2. 支持条件语句:比如判断某个执行结果,如果符合预期则指令A Action, 不符合则执行B Case。

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

  1. 发送/接收各种类型消息
  2. 会话列表显示点击
  3. 会话详情页吸顶条
  4. 会话详情页加号配置
  5. 各类型消息点击
  6. 各类型消息长按
  7. 消息未读已读

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


欢迎在评论区讨论,掘金官方将在掘力星计划活动结束后,在评论区抽送100份掘金周边,抽奖详情见活动文章

文章分类
Android
文章标签