干货|爱奇艺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以内延迟的点击，滑动的响应，使得远程操作手机桌面更流畅。
驱动能力解决了，接下来就是桌面图像同步，由于这里使用的是截图功能如上c）我们已经优化，同时去掉了一些source tree的内容，将图像呈现的速度控制在150ms的刷新能力。
代码片段如下：
为了能让用户可以http访问UI桌面，这里我们使用了wdaproxy开源项目，源码中已经支持了iproxy的Mac和iOS的USB端口映射并与http协议转换绑定能力，使得可以对iPhone手机UI桌面操作。但是对于团队测试使用的时候一般都是安装企业debug的APP，这就需要将指定设备安装功能集成到wdaproxy内提供给用户使用，对于多设备情况下指定APP安装就提出了任务管理尤其对于稳定性测试服务的搭建也是必须的基础能力。
资源池搭建-任务分发和中转服务
目前爱奇艺测试团队是在封闭的设备室内，搭建配置集群节点，考虑到设备耗电和充电情况设置，标配是一台mac-mini对接3台iPhone。
由于Mac-mini端需要通过XCode编译安装有统一开发者证书的WDA APP到手机端，首次搭建均需要人工参与。对于之后手机重启，热插拔的设备状态识别以及WDA异常奔溃，我们都有通过自动化手段去重试，监控和及时报警。保证服务长时间在线，同时便于异常问题追踪和及时修复。
我们看一下，如下图，整体框架：
任务管理后端，都是按照标准的容器化搭建，通过MQ消息触发的方式到达对应的Mac-mini的worker内，过程中的日志我们基于logstash将数据实时输出到后端日志管理平台，以便后期运维期间问题定位，排查使用。对于Monkey遍历所产生的实时截图我们存储这边统一输出到对象存储系统中，同时对图片设置有时效性。
Worker的mac-mini端集群，承载两块内容：一块是对iPhone插拔状态的及时更新和WDA编译启动后端服务常驻；另一块是对设备挂载和释放时进行端口随机分配和作废，避免释放设备时端口始终被用户占用情况，同时调用中转服务，这里目前有APP安装服务，之后会介绍Monkey任务服务以及通过instruments获取性能日志的服务，后面会讲到。
以下是实际设备资源池租赁的效果图
资源池提供的远程控制服务，可以满足业务线在急需设备情况下登录平台可租赁使用，满足日常产品在不同手机的兼容性测试需要，如果大家对上面有疑问也可在公号内留言，我们会关注。
APP稳定性测试
有了iPhone资源池作为底层的稳定基石，上层的Monkey服务就可以搭建起来了。
搭建Monkey服务一定碰到有几个基本问题：
1) APP遍历的策略和覆盖率
2) 崩溃产生后，追查的方式
3) 弹框监听和去弹框能力
上面三个问题是比较棘手的，对于iOS的稳定性测试也是最基本的，当然我们还有一些需要解决的其他问题比如账户登录，iOS稳定性长时间运行后远程控制卡死等这些都是实践中我们也需要解决的。目前就上面主要也是基本问题谈谈：
如下图，是整个稳定性测试框架，和上图的Worker关联起来，与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这两种深层网络好。如下图参考，具体也可官网查询：
UI检测模型训练了6种UI异常分类，能够在20-50ms内完成对一张手机截图的推理，且在模型推理后期做了适当的优化，可以保证较高的准确率和召回率。如下实际效果图：
性能日志获取服务：支持被测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遍历的深度和广度。
end
也许你还想看
扫一扫下方二维码，更多精彩内容陪伴你！
爱奇艺技术产品团队
简单想，简单做