爱奇艺 APP 一键体检技术实践

背景

AndroidAPP 自动化测试目前包括很多测试专项，每一个专项都有很多创新内容，包括功能自动化测试、稳定性自动化测试以及性能自动化测试等，在日常的测试过程中以上的测试技术或者服务均会发现一些问题。

传统的稳定性自动化测试（Monkey 测试）主要是通过任意的点击、滑动等操作模拟用户行为，但存在覆盖率低、执行效率低的问题。性能自动化测试往往局限于固定的测试场景，无法捕捉固定场景外的内存泄漏问题。另外兼容性测试仍然依赖于人工手动测试来覆盖多系统版本、多机型的方式，并且需要尽可能保证 APP 在不同设备上的功能可用性，但是这种人工测试很难完全覆盖市场上主流的安卓机型。

对于快速迭代的新业务团队而言，功能自动化 case 脚本的维护成本较高，且人力投入资源也不多，尽管通过配置化或者 AI 技术等手段的介入，自动化测试技术产生的收益还是不够理想。因此希望能够降低脚本编写成本和脚本的复杂度，减少脚本维护内容，让尽可能多的遍历交给服务来执行，同时也能发现更多的问题。

为了达到这样一个目标，爱奇艺测试团队提出了一种轻量、简单、通用的 APP 一键体检方案，用户只需提交一个 APP 地址，就可以给 APP 一个多维度的健康体检，包括【APP 安全校验】、【UI 异常检测】、【性能数据分析】、【Crash 和 ANR 检测】等核心内容。

解决方案

主要通过开源工具 ATX 作为遍历引擎，集成 web 端的录制回放工具将定制化脚本无线方式分发到租赁的真机设备群，定向遍历基础上进行相关的控件遍历；从 APP 安装开始到最终遍历结束，最后自动卸载，时间段内任务完成。

任务分为 4 个阶段（安装、初始化、遍历、卸载），整个过程期间包含对日志采集、图片采集、视频录制、ANR 和 Crash 监听采集和过滤，服务端进行相关日志分析，数据聚合等处理。针对过程又加入丰富了对 APP 自动安装成功率的优化、启动耗时的度量方案、问题的 Bug 自动上报、UI 异常校验以及安全扫描等内容。

整体框架一键体检整体功能由手机云后端服务、场景服务、Worker 服务、分析监控服务四个模块组成。任务启动后，首先从移动真机设备资源池中租赁一部分设备或者指定设备，远程挂载到 Worker 中。如果 Worker 不够用则自动扩展再次挂载，当对应 Worker 收到任务消息后就进行任务下发，分配到这些设备中，下发任务根据定向脚本数和设备数进行匹配，初始化结束后就开启安全检测、APP 通用安装、执行遍历、数据抓取、图片抓取以及视频录制等服务，相关数据文件等按照结构化格式传输到日志服务平台。

一键体检整体框架

驱动内核

传统的功能自动化测试通常使用 Uiautomator2 框架编写 Android 脚本，然后打包作为一个 APP 安装到手机上，实现 APP UI 驱动。该框架可对控件进行遍历，也可定向运行指定功能测试，但是在公共统一设备资源池情况下，多团队租赁设备后就需要在手机上安装集成测试脚本的 APP，这样需要安装的 APP 就变得多了起来。

此外打包安装测试 APP 到运行任务，整个测试开发效率是非常低的。为了克服这样的问题，团队采用通过 http 方式，将执行的动作脚本传输到对应手机设备，实现无线遍历的方法。这样的好处是可以灵活实现定向遍历，手机端也无需再打包安装驱动引擎或者驱动测试 APP。团队使用的内部框架主要是基于开源项目 ATX 二次开发实现，包括对设备端的 atx-agent 稳定性升级，支持添加 ATX 的录屏，以及内部日志优化的处理等。

如下图，可以看到 py 代码可以转换成以 http 方式传输到手机端形成相应的指令，来执行相关的驱动目的。

说明：

【atx-agent】是一个 Go 编写的 ARM 程序，需要 adb shell 方式开启，收集来自客户端的 http 请求指令，分别分发到不同组件模块中对应执行。

【android-uiautomator-server】是 github 开源的一个项目被集成到了 ATX 中负责自动化操作比如点击，输入，滑动等的执行引擎。

【minicap】和【minitouch】分别是开源框架 open-stf 的设备实时屏幕图像和触屏事件的两个服务。如果设备安装 ATX app 的话这些组件内就会被自动推送过去。

Python 框架库里面有个 uiautomator2，引入后就可以像上图一样通过自动化脚本无线请求到设备执行自动化操作。

设备资源池

目前整个 Android 设备资源池通过 open-stf 框架已经成功搭建且有效运行，服务于公司多条业务线的测试和开发调试。现有近 100 台设备集中管理在实验室，通过 provider 实现 PC 托管多设备。由于地域设备管理和上层应用的技术发展需要，考虑一键 APP 体检本身的场景特殊，爱奇艺测试团队将其与底层设备的连接去 USB 化。

这里去 USB 化是要说明 ATX 首先需要获取 adbshell 权限，如果去 USB 连接，那么就需要 adbconnect 方式，才能无线挂载设备进行 ATX 初始化，当 atx-agent 被 adb 启动后驱动脚本就可以通过 http 方式定向指定，动态下发到设备中，对于其他的日志比如性能日志也就可以用 adb shell 相关的指令去获取。移动实验室提供了这样的基本租赁接口能力，同时分配端口和 provider 机器的 IP。

如下图，当然有特定的接口支持非 ui 形式，这里标记出来仅作直观说明。这样就可以解耦，供上层的技术实现特殊的应用场景，进行设备远程挂载。

APP 通用安装

Android 应用一键体检的第一步就是 APP 安装，但是目前市面上的手机安装过程并不一致，尤其是 vivo、OPPO 等品牌必须要输入密码并依次完成按钮的点击操作才能完成。

如上图，通过传统的控件找元素方式是很难点击到“安装”按钮的。因为安装和取消按钮实际是一张图片。

通过仔细可以观察发现所有机型安装过程中其实涉及到的关键词是有限的，主要包括：安装、确定、下一步、确认等，其实只要能够找出这些关键词并点击相应位置就可以实现点击，这个时候使用 OCR 查找关键词位置是最合适的。这里爱奇艺测试团队提出了一种基于 OCR 技术的 APP 通用安装解决方案。在 APP 安装过程中进行截图，然后将截图上传给后端接口，后端调用爱奇艺 OCR 服务获取截图内文字分布及坐标区域后，与通用安装关键词库进行比对，后端将匹配成功的关键词（e.g.安装）及其中心点坐标返回给移动端，手机设备点击该坐标即可。

到这里或许有人会说很多公司都是采用这种方法，有些甚至还采用深度学习的方式来实现。那为什么我们没有采用深度学习能力赋能呢？原因如下：

• 当多个关键词同时出现在截图中时，优先点击最靠画面底部的文字是考虑到弹窗可点击的引导按钮基本出现在偏下方且靠右边（当然也有靠左边的这类机型，过滤一下即可），以这样的策略选择唯一性文字坐标就可实现安装步骤的逐步点击。

• OPPP, vivo（以下简称 OV）手机系统的密码输入时机：厂商出于安全考虑在密码输入弹框出现时候，截图功能是被禁止的。因此 OCR 的文字识别就会失效，就连普通控件识别也是无济于事。因此团队想到这样一种方案：通过机型判断，当安装任务被触发后，通过 tab 键、回车键对 OV 手机统一的用户名密码进行认证（注明：仅 OV 测试机器上授权可用），后续操作截图不受影响，安装流程同 1)。

• 截图以 Minicap 方式避免某些品牌如小米手机在安装时有倒计时的超时要求，adb shell 的截图功能较耗时，会超过操作的超时要求。Minicap 截图也有自身问题，间隔时间需要控制得当，比如进入了 APP 内的业务弹框、授权弹框等重叠弹框出现也是需要通过特定策略进行去除的，否则点击时候失效，目前是通过执行点击后进行 OCR 识别文案再次匹配的方式进行判断是否重复出现，后期会通过图片相似度进行对比去除。

目前通过以上的方式 APP 安装的成功率高于 95%，基本满足了主流机型的 APP 安装自动化的要求。有些场景比如消息推送干扰，锁屏干扰，OV 的用户认证的网络通畅要求等异常情况出现时，这方面的解决方案仍在寻找中。以下截图也会在一键体检中将安装过程的快照给用户呈现，以便在碰到上述异常时，可以临时人为去干预调整。目前自动化安装 APP 服务已提供给其他一些技术专项使用。

图为爱奇艺姜饼短视频 APP 自动安装过程

APP 启动耗时

启动耗时数据采集：APP 安装过程将会被记录安装耗时，APP 启动也会采用屏幕录制功能进行记录，然后通过视频解析服务平台对图片 RGB 变化率绘制的波形图，找到匹配每个业务线提供的特征值计算耗时。

上图的 st:（1,0,20）代表 APP 打开的起始计算点，从第 1 个波形图的左边起始点开始，20 表示业务线设定的阈值，如超过阈值的数据表示一个波形。ed：APP 首屏打开的终止点，特征值意思和 st 一致。

有了这样的后端视频解析服务平台，对于一键体检提供的视频就可以度量一个 APP 的启动耗时情况，另外需要说明的是视频的录制功能，团队使用传统的方案 adbshell screenrecord， 但是华为手机不支持该 adb 命令，为了应对华为手机，在 ATX APP 中集成 MediaRecorder，设置封装了对 APP UI 的起播停止操作的视频录制。

由于要标准地输出上面的类似波形图，尤其在 st 点保证第一个波形的第一个起始点就是 APP 启动的计时点，因此需要对录制好的视频文件，使用工具 ffmpeg 适配裁剪一段白屏内容， 因为 MediaRecorder 被调用时会有启动集成在 ATX 内的空白 Activity，需要剔除这部分因工具产生的干扰因素。这样耗时统计测试是精准的，且投入的自动化方式也更稳定和通用。

UI 的异常校验

相关文章《干货丨爱奇艺iOS真机远程APP测试技术实践》中介绍过 UI 异常校验能力，主要是基于深度学习方法检测。我们同样也把这样的技术运用到 APP 的体检里面，并提高了异常的判断结果回传速度，保证所有图片的异常判断在体检的规定时间内完成，APP 遍历操作运行过程中，目前是每 1s 会执行 3~5 次截图，且图片下会显示截图时间戳，后端根据时间戳进行排序，输出给前端展示，便于 UI 异常发生后，复现定位问题。

APP 安全校验

APP 安全校验由爱奇艺安全云团队提供技术支持，目前主要通过两类分析引擎完成，分别是基于 smali 代码的漏洞规则匹配引擎，和基于 FlowDroid 的静态污点分析引擎。前者可以快速定位特征明显的 API 参数误用等漏洞。后者通过污点分析技术可以检查出更深层次的数据泄露以及权限泄露漏洞。

这里重点介绍一下静态污点分析引擎，在 FlowDroid 的基础上，增加了多种通用漏洞规则，修复了大量数据流处理的 BUG，扩展了数据流追踪范围，同时增加了分析精准度。对于报告输出，提供了详细的漏洞位置或数据泄露路径相关代码，方便使用者对相关问题进行排查。

如上图，这里有基本安全风险以及 Manifest 权限分析，对于基本安全风险，如果要排查问题，可以点击查看定位到具体 APP 代码文件路径，非常方便。

组合事件驱动

一键体检中的遍历操作事件主要分为基础随机事件和操作场景事件，这两类事件相互补充，保证遍历操作可以覆盖用户的正常操作行为。基础随机操作里面的点击滑动类事件主要包括单击、长按、双击、全向滑动等，而操作场景事件里面添加了连击、点击等待、定向滑动、识别滑动等操作，在不同场景实现不同操作。除了普通的文本输入功能，操作场景事件涵盖了文本框识别、键盘呼出收起等功能。

手机的基本操作包括设备唤醒、点击 home 键、点击物理返回键等，这里为了适配爱奇艺播放器兼容性测试情况，加入了旋屏、半屏全屏切换等功能，有时为了防止遍历崩溃或者遍历走出业务线范围，也对应加入了对 APP 进行重启或者返回主动干预操作，并支持 APP 在前后台切换。

如上图，具体的遍历策略为，解析当前控件树 xml 文件，由控件树确定当前点击控件的坐标集，然后根据本次步骤获取的控件操作属性特点，来决定相应坐标的点击、长按、文本输入以及返回等可能的操作，考虑到需要控制一些遍历范围，方案会在任务触发的时候让业务线配置好业务的 Activity 白名单 list，这样发生遍历外出就会监听到并及时返回矫正。

另外在遍历测试过程中，难免会遇到一些权限弹框、确认弹框、异常弹框等，在遍历运行过程中体检方案会进行弹窗的监听并做相应的点击处理，避免阻塞遍历运行。基于控件树本身还有自身缺陷，比如 RN 或者小程序 UI 的识别，控件树缺失，这块目前已经有了方案还在升级优化。

场景定制化

一键体检支持定制化场景脚本执行，例如可实现：可配置支持登陆、特定垂线业务及小程序入口等。目前定制化场景任务脚本由各业务线自行维护，执行一键体检任务前如果需要指定前置场景的操作，则在通用安装模块运行结束后自动执行定制化脚本，到达指定入口，再进行相关的策略遍历。

另外，对于一些轻量的业务遍历需求，爱奇艺测试团队将脚本开发效率提升到录制回放层面，减轻业务线人员的技术投入，只要对 APP 进行相关的录制回放即可实现功能的自动化驱动。

如上图，通过 web 页面租赁到一台设备后，就可以进入这样的 webIDE，实现针对手机端 APP 的录制回放，有点像 airtest 工具，不过这里是 Web 端的 IDE, 爱奇艺测试团队开发这样的工具主要考虑用户在客户端需要配置大量的环境设置或者工具兼容性问题，避免导致维护成本较高或者开发效率较慢。目前支持 python，脚本可提交到云端，后面集成到一键体检就可以实现多设备的批量回放了。如下图可以选择“前置任务名称”的脚本。

BUG 提交上报

在遍历任务启动以后，体检方案会持续地监听安卓设备的 logcat 日志，并过滤出 APP 相关的 Crash、ANR 等关键错误信息日志。在捕捉到 Crash、ANR 相关关键词时，会取出发生问题前一段时间内的截图，并在截图上绘制行为轨迹图，把这部分作为上报 Bug 的一部分关键信息。除了行为轨迹图以外，在提交上报 Bug 单中会附上详细的设备日志信息、当前的测试包下载地址、当前测试包对应的 mapping 文件、全量 logcat 文件，且 Bug 的标题会取崩溃或者 ANR 的关键信息。

对于 ANR 错误，如果有权限抓取设备的 traces 文件，这时 traces 文件也会作为附件加入到 Bug 单中，但是目前很多设备不支持直接拉取 traces 文件，那么我们会获取 Android 提供的 BugReport 文件附于 Bug 单中，最大程度地为开发同学提供有效信息。

Bug 信息中的对应行为轨迹图

另外需要特别指出的是，在提 bug 的过程中，可能会发现重复 bug 的问题，比如多次出现同样的 crash。考虑到重复提 bug 的问题，在提 bug 的过程中进行了一次后端过滤，对于错误原因相同的 bug，由后端判定这是一个重复的 bug，将相关错误信息落库后，不再执行后面的 bug 上报流程。同时也会把之前产生的 bug 单再次在用户任务结束后附录告知，说明是有遍历出现了相同的问题，请及时修复。

具体判定规则为：需要统一剔除 logcat 中的字符【如下图日志红框标注】， 然后以统一版本维度将本次任务对比库存 Bug 内容，发现匹配后则认为有重复 bug，不会再次提出相同的 bug。

日志分析服务

一键体检的任务默认运行设备 15 台左右，时长默认为 30 分钟，并行多业务线。因此处理的数据量巨大，包括对性能数据，图片数据以及日志数据的处理，同时还包括问题定位数据间的关联处理等。后端日志分析如下：

这里介绍一下这几个部分：

• 数据源：接入日志服务的数据，包括但不限于日志、图片数据、性能数据等，目前一键 APP 体检的数据产出主要包括这三个内容的业务形态。

• 数据接入：按照约定好的数据格式和通讯协议将数据上传至日志服务。

• 数据采集和存储：将数据采集、解析、存储，此时是一些原子的、结构化的数据

• 数据计算：根据业务场景，将原子的数据进行加工、计算，并存储

• 数据服务：提供开放接口，将数据输出

• 数据应用：基于数据开发前端，供用户使用

实际效果图如下, 也即一个完整的报告，包括了上面介绍的一些内容。当然由于篇幅要求，部分情况未能介绍，如性能分析数据等是由后端测试团队性能分析平台进行科学化的去噪统计汇总给出的数据，集成到一键体检中提供更周详的参考内容。

结束语

一键体检目前已经用于爱奇艺内部很多 APP 的新产品和新业务线中，能帮助它们及早地、全面地发现线下问题，减少人力投入，减少对接使用的复杂度。只要一些简单的配置就可以触发多台设备执行，还可以对接到持续集成中。未来，除了在覆盖率上做优化外，还会丰富体检的其他专项指标，同时也会在遍历的场景多样化上做升级。