爱奇艺 iOS 真机远程 APP 测试技术实践

阅读数:5926 2019 年 5 月 23 日 08:00

爱奇艺iOS真机远程APP测试技术实践

背景

iOS 多机远程控制技术目前业界初步也有了一些方案,可以让 APP 在远程 iPhone 上面安装操作,对于设备兼容性测试是一款很好的服务,但是就体验上还是存在 UI 截屏延迟,设备掉线,稳定性不高的问题,尤其对于远程手机桌面的滑动,长按操作,全屏视频播放等,成本上多数是通过一台 mac 挂载一台 iPhone 来提供服务,显然较为昂贵。另外,APP 除了业务功能测试外,还需要有一定时间段的稳定性测试,往往需要长时间在 APP 内部进行 UI 页面的遍历,这类遍历可以有一定的策略,也可能是无序的点击滑动等模拟行为,同时需要监控 APP 是否有产生 crash 等情况,行业内部叫做 Monkey 测试。

以上的测试服务在 Android 端目前有很多专业的开源工具如:Appium, minicap+minitouch, Macaca,uiautomator 等,基于成百上千的 Android 设备资源池,封装成服务实现租赁任务调度服务或者大规模的设备遍历测试服务。但是,在 iOS 端,目前要做到多设备并行长时间执行 UI 遍历测试,或者提供足够低成本良好的真机远程控制服务,还是较为困难,且不说设备量的问题,单是设备长时间连接的稳定性问题就有很多。因此,爱奇艺测试团队为此通过实践,将这类解决方案提供给大家,希望通过交流一起探讨。

解决方案

iOS 驱动内核及真机资源池搭建

不管是兼容性测试还是稳定性测试服务,首要的就是需要有 iPhone 真机设备,同时也可以为测试团队对于紧缺设备提供租赁服务。最佳的方法是提供远程租借能力,包括:用户注册登录,使用时长限制,APP 安装,远程桌面同步和流畅的 UI 操作体验。这在 Android 端有类似的开源项目 openSTF,当下是比较流行的,且也被用于大规模设备租赁使用。

驱动内核:在 iOS 端我们经过各类工具比对和调研,决定选择 Facebook 开源的 iOS 自动化框架 WebDriverAgent 作为 iOS 的驱动引擎,主要有两个原因选择这个驱动方案:

  • 能够支持一台 mac-mini 挂载多台 iOS 设备,成本降低。
  • 由于 Appium 开源自动化工具底层使用同样的 WebDriverAgent 或者说 xcuitest,可无缝对接,为日后业务线 ui 自动化测试提供服务。

这里我们也继承了鲁迅的“拿来主义”,针对 WebDriverAgent 简称:WDA 项目代码进行了深入优化,使用了苹果自有 API,放弃 Facebook 封装提供的 API,以及一些其他相关优化,具体如下:

a. 重写了点击 (Tap)、长按(TouchAndHold)、滑动 (Drag) 等手动操作方法;

b. 针对 home 键的优化,解决反应迟钝问题;

c. 对 screenshot 截图方法,我们也使用苹果自有 API: XCUIScreen 进行截图,修改截图自适应大小存储逻辑,大幅度提升延迟问题;

d. 解决视频全屏问题,由于视频类 APP 有全屏播放需求,WDA 在全屏播放上存在问题;

e.解决远程桌面操作中由于 xcode build 导致的断连问题,达到高稳定性的远程控制持续时间。

f . 解决 wda 心跳检测 status 请求超过最大连接数问题;

g.解决长时间运行后远程连接 UI 操作点击滑动等动作失灵情况下的屏幕 size 缺失问题;

等等。(要是读者有碰头其他情况未解决可公号内留言交流)

优化后效果:

手机 ui 桌面展示在 150ms 以内延迟的点击,滑动的响应,使得远程操作手机桌面更流畅。

爱奇艺iOS真机远程APP测试技术实践

驱动能力解决了,接下来就是桌面图像同步,由于这里使用的是截图功能如上 c)我们已经优化,同时去掉了一些 source tree 的内容,将图像呈现的速度控制在 150ms 的刷新能力。

代码片段如下:

爱奇艺iOS真机远程APP测试技术实践

为了能让用户可以 http 访问 UI 桌面,这里我们使用了 wdaproxy 开源项目,源码中已经支持了 iproxy 的 Mac 和 iOS 的 USB 端口映射并与 http 协议转换绑定能力,使得可以对 iPhone 手机 UI 桌面操作。但是对于团队测试使用的时候一般都是安装企业 debug 的 APP,这就需要将指定设备安装功能集成到 wdaproxy 内提供给用户使用,对于多设备情况下指定 APP 安装就提出了任务管理尤其对于稳定性测试服务的搭建也是必须的基础能力。

资源池搭建 - 任务分发和中转服务

目前爱奇艺测试团队是在封闭的设备室内,搭建配置集群节点,考虑到设备耗电和充电情况设置,标配是一台 mac-mini 对接 3 台 iPhone。

由于 Mac-mini 端需要通过 XCode 编译安装有统一开发者证书的 WDA APP 到手机端,首次搭建均需要人工参与。对于之后手机重启,热插拔的设备状态识别以及 WDA 异常奔溃,我们都有通过自动化手段去重试,监控和及时报警。保证服务长时间在线,同时便于异常问题追踪和及时修复。

我们看一下,如下图,整体框架:

爱奇艺iOS真机远程APP测试技术实践

任务管理后端,都是按照标准的容器化搭建,通过 MQ 消息触发的方式到达对应的 Mac-mini 的 worker 内,过程中的日志我们基于 logstash 将数据实时输出到后端日志管理平台,以便后期运维期间问题定位,排查使用。对于 Monkey 遍历所产生的实时截图我们存储这边统一输出到对象存储系统中,同时对图片设置有时效性。

Worker 的 mac-mini 端集群,承载两块内容:一块是对 iPhone 插拔状态的及时更新和 WDA 编译启动后端服务常驻;另一块是对设备挂载和释放时进行端口随机分配和作废,避免释放设备时端口始终被用户占用情况,同时调用中转服务,这里目前有 APP 安装服务,之后会介绍 Monkey 任务服务以及通过 instruments 获取性能日志的服务,后面会讲到。

以下是实际设备资源池租赁的效果图

爱奇艺iOS真机远程APP测试技术实践

爱奇艺iOS真机远程APP测试技术实践

资源池提供的远程控制服务,可以满足业务线在急需设备情况下登录平台可租赁使用,满足日常产品在不同手机的兼容性测试需要,如果大家对上面有疑问也可在公号内留言,我们会关注。

APP 稳定性测试

有了 iPhone 资源池作为底层的稳定基石,上层的 Monkey 服务就可以搭建起来了。

搭建 Monkey 服务一定碰到有几个基本问题:

  1. APP 遍历的策略和覆盖率

  2. 崩溃产生后,追查的方式

  3. 弹框监听和去弹框能力

上面三个问题是比较棘手的,对于 iOS 的稳定性测试也是最基本的,当然我们还有一些需要解决的其他问题比如账户登录,iOS 稳定性长时间运行后远程控制卡死等这些都是实践中我们也需要解决的。目前就上面主要也是基本问题谈谈:

如下图,是整个稳定性测试框架,和上图的 Worker 关联起来,与 APP 安装服务是同等级的。

爱奇艺iOS真机远程APP测试技术实践

整个遍历过程通过主线程控制任务时长,透传相关设备列表信息到 Monkey 子线程中执行 ui 遍历,在设备或者 WDA 异常情况时,能及时中断任务和释放设备,抛出异常日志排查定位问题。

遍历主体内部支持 Alert 弹框的监听,对于“确认”,“同意”,“好”等关键文案锁定点击去除,也包括系统弹框。一些前置场景或账户登录,目前是准备通过平台根据业务线配置步骤下发,后期也会通过 OCR 或 APP 类型匹配基于深度学习来进行主动策略性驱动。同时,我们通过图片的相似度来计算图片的去重率,低于一定比例后就进行驱动干预保证遍历的深度和广度,提高测试的覆盖率。

遍历周边服务

UI 检测服务:这里截图频率是根据关键 Monkey 执行步骤为起点每 1s 一次截图,输出到后端 UIChecker 服务,主要用来对 UI 图片上的乱码,错误弹框,黑白屏等深度检测,主动发现问题,UI 检测服务基于 YOLOv3(You Only Look Once) 深度学习模型,该模型网络层数少,只有 52 个卷积层和 1 个全连接层,YOLO v3 在保持其一贯的检测速度快的特点前提下,性能能上有很大提升,其中 Darknet-53 采用了 ResNet 这种跳层连接方式,性能完全比 ResNet-152 和 ResNet-101 这两种深层网络好。如下图参考,具体也可官网查询:

爱奇艺iOS真机远程APP测试技术实践

UI 检测模型训练了 6 种 UI 异常分类,能够在 20-50ms 内完成对一张手机截图的推理,且在模型推理后期做了适当的优化,可以保证较高的准确率和召回率。如下实际效果图:

爱奇艺iOS真机远程APP测试技术实践

性能日志获取服务:支持被测 APP 的 CPU,内存,流量数据获取(后期加入 FPS 等常用指标)。 通过启动 instruments 每秒获取一次 CPU 和内存数据,每次请求获取一次上下行流量,对于产生的 trace 文件进行明文解析生成可读文件。性能日志生成后投给后端日志分析平台进行曲线图绘制和其他日志一并存于 bug 管理平台内。这里由于 instruments 长时间运行会有数据缺失情况,目前还没很好的解决方案,为保证数据能在时间段内有足够的采样数据,我们会对 instruments 间断性重启。

崩溃监听分析服务: 我们通过 idevicesyslog 输出并过滤出 APP 的相关 syslog 日志交给后端分析产生 URL,并实时通过 idevicecrashreport 获取 crash 原始二进制日志,对于 crash 原始日志还需要用 symbolicatecrash 结合 dsym 文件进行分析输出明文。

最后我们将上面所有信息汇总到 bug 管理平台中自动给业务线对应负责人创建一个 bug 单,信息包括任务设备,行为轨迹图片,crash 的分析日志,APP 端日志以及 SDK 内部日志,后期加入性能日志曲线图等用于排查出现 bug 时刻的全部参照。

未来规划

寻找 Xcode 编译过程中由于系统弹框出现导致自动化编译失败问题的解决方案。

通过深度学习平台智能决策 APP 遍历的深度和广度。

本文转载自公众号爱奇艺技术产品团队

原文链接

https://mp.weixin.qq.com/s/lebDmm1OnxVx6bjz2wxLlg

评论

发布