APP DIFF 自动化解决方案

8 月 7 日下午，爱奇艺技术产品团队举办了第 17 期“i 技术会”，本次技术会的主题是“智能化、精准化测试前沿探索”，本次沙龙与 TesterHome 社区联合举办。

其中，来自爱奇艺的技术专家齐文方、魏真真为大家带来了 APP  DIFF 自动化解决方案的分享。APP D IFF 方案利用 deeplink、mock 提升了 UI 自动化稳定率和效率，并结合 AUI 图像匹配算法，达到接近人工的验证效果，在收藏、card 等业务推进落地，以较低成本持续产生收益，在移动端 UI 自动化方向实现了突破与创新。

以下为“APP  DIFF 自动化解决方案”干货分享，根据【i 技术会】演讲整理而成。

本次分享将从背景介绍、方案设计、业务落地、未来规划四个方面展开，最后再对重点内容“AUI 智能自动化方案”进行着重介绍。

一、背景介绍

当前爱奇艺移动端自动化的现状可从元素识别、Case 转化、运行环境、应用场景四个维度予以概括。

（1）元素识别，包括 ID、TEXT、OCR、AI 识别。

（2）Case 转化，包括录制回放平台、数据模板、代码编写、智能遍历等。

（3）运行环境，经历了从最早期的本地到后来的 Jenkins、自研的云测自动化平台及公司流水线的转变。

（4）应用场景，则包括冒烟准入、灰度回归、插件验收、集成全量 case 等。

目前，爱奇艺的主要产品线如爱奇艺 App、随刻、泡泡 APP 及极速版 APP，都在不同场景下使用整个自动化框架。

但是在应用过程中也遇到了一些痛点和瓶颈。

痛点之一就是不稳定，主要原因是被测对象的变化，包括 ID、后端数据还有交互的变化、运行环境设备、网络的不稳定因素，自动化 case 步长放大影响稳定性等。

主要瓶颈则是校验能力，这主要是由于爱奇艺目前主要使用单点 ID、文本，验证点少，日志校验场景较为有限；并且，其对接的是通用 AI 模型训练，随着 UI 的改版，需要持续进行标注，成本较高。

以收藏 Case 为例，测试步骤是：（1）登录帐号（包含 5 个步骤）；（2）搜索目标影片，在搜索结果页进行播放；（3）回到首页点击收藏按钮；（4）验证半播页是否包含 a、b、c 某些核心的特征元素。

这是传统的自动化 case 编写步骤，其中存在一些典型问题。

首先，这个用例的步长过长，最终校验效果差，在我们的用例集合中是稳定率较低的。

爱奇艺从中梳理出了三个优化思路：

（1）缩短 case 步长，减少 case 对其他页面、模块的依赖；

（2）控制数据，提高稳定性；

（3）图像校验，使之接近于人工校验的效果。

二、方案设计

从这三个思路出发，爱奇艺设计了一个 APP DIFF 方案。这个方案基于 Uiautomator2 框架，结合 AUI、Mock、DeepLink 的能力，实现基准包、测试包使用相同测试数据，直接拉起目标页，对结果截图进行图像 Diff 校验，以达到更稳定、更高效、更接近人工校验的自动化解决方案。

下图右侧是 APP DIFF 的时序图，包含上下两个部分，其一执行 base 任务，其二执行被测任务。

以 base 任务为例，它主要用于收集和生产我们提供给测试任务的数据，主要流程包括：首先，启动 case 任务，执行自动化 case，期间会录制执行过程中的数据，执行结束后，将被验图片作为基准图片上传到公司的 AUI 服务。测试任务执行时，会使用 base 任务录制的数据，并把最终的结果图片和 base 任务的图片进行对比，完成自动化任务的校验。

这一整套方案有以下三个技术点。

（1）Deep Link，通过 Deep Link 可以直达被测页，提高任务的稳定性和效率。

（2）Mock，它能够在整个链路中减少数据变化带来的不稳定性。

（3）AUI，提升校验精准度，使其更接近人的主观判断力的验证能力。

这三点分别是如何做到的呢？下文将一一对其做出介绍。

（一）Deep Link 介绍

Deep Link（深度链接）是指把特定的参数通过 URL 的形式传递给 App，直接打开指定的内部页面，实现从链接直达 App 内部页面的跳转。

以下图中的场景为例，用户在爱奇艺 APP 内观看了某电影的宣传片，在影评中他可以通过点击一个 Deep Link 链接，直接跳转到豆瓣中查看影评。在豆瓣中他又可以通过 Deep Link 打开淘票票 APP 购买电影票，再到高德/滴滴打车去到电影院，在门店取票时还可以通过淘票票 APP 打开美团，购买爆米花。这是一个非常经典的 Deep Link 的使用场景。

爱奇艺在 Deep Link 的使用上自定义了“注册制”的概念，定义了从云端到业务的通信数据协议。

爱奇艺进行自动化框架接入时，首先基于此协议定义了一些 API，其中包括协议支持的业务、模块以及部分业务内部静态或动态的参数。然后对这些参数进行拼接，将其转化成爱奇艺自定义设置的协议，再通过一些方法把参数转化成可以直接拉起其他 APP 的 URL Scheme。安卓端是通过 intent 的方式，可以携带预置的参数拉起目标页面。

（二）数据构造

在直达被测页后，自动化用例中还会依赖本地数据及网络数据。同样以收藏操作为例，它包括本地缓存数据，还有网络数据。

一般来说，本地数据在安卓端的存储方式包括 SP、DB 还有文件等等。由于自动化使用的是 Uiautomaotr 框架，是一个独立的进程，如果要实现测试工程和和被测工程数据的可读写，需要满足两个条件：首先，两个工程的签名要保持一致，其次，需要指定相同的 ShareUserID，这两部分需要在编译的环节处理。

对于本地数据修改能力，爱奇艺在框架中进行了一些模块的封装，为不同的存储方式提供不同的基础库，然后基于爱奇艺特有的业务进行业务模块拆分。

对于上层业务使用涉及的一些设计如登入、登出接口等，使用者可以较容易地构造一些常见的本地数据。

完成本地数据构造之后，还有部分网络数据需要处理。

网络数据也包含两部分：首先是数据源的指定；其次是数据连通方式。

其中，数据源我们是使用 base 任务进行数据录制，执行测试任务时，回放这些数据，有些类似于服务端流量录制回放的概念。在连通方式上，爱奇艺基于安卓提供的 VPN Service 基础库开发了一个工具，实现了代理流程。整个流程从设备到 VPN 到 Mock 服务，包括录制和回放的过程，以此实现网络数据的 Mock。

（三）AUI 校验

AUI 是一个 Web 端的自动化解决方案，其中提供了图像对比的基础服务。爱奇艺借助 AUI 基础服务，实现了不同图片间的 DIFF 能力，这也是我们 APP DIFF 解决方案的关键所在。

AUI 算法提供了精准匹配、严格匹配、灰度匹配和布局匹配 4 种校验匹配方式，其中较为常用的是严格匹配和布局匹配。

严格匹配指的是对图片细节进行比较，特点是它的校验粒度更接近用户的真实感受。下图为严格匹配执行示意图，图中的第一和第二张图，只有点赞按纽有着细微差异，这种差异依旧可以通过严格匹配的算法识别出来。最后一张图是对比结果图，最终结果输出可以自定义阈值进行判断。

布局匹配的使用场景就是布局，它关注重点不是布局中的内容，而是 UI 没有错乱、布局没有错误。下图是布局匹配执行示意图，虽然 base 图和被测图在内容上差异很大，但在布局、样式上没有太大差异，因此是可以通过布局匹配算法验证的。

（四）编写规范

基于以上三种能力，自动化框架都进行了封装和集成，提供了比较易用的 API。在使用 Case 编写时，要遵守一些规范。因为通过安卓端进行本地数据 Mock 时，在 app 启动或活跃的状况下修改本地数据是不会生效的。因此，自动化编写时应在前置条件中构建本地数据，然后做 AUI 校验，最终结束时，进行数据恢复。下图是操作流程，其中的蓝色部分是编写者需要自定义编写的，灰色的部分是框架统一处理的。

下图依旧以收藏操作为例，从图中我们可以看出，原框架步长、路径较长。对于用户使用而言，新框架首先需要 API 构造登录态、收藏数据，之后通过 Deep Link 直接拉起收藏页，最后调用 AUI 接口完成验证；因为此页面不涉及动态图，选择严格匹配的方式即可达到最终的校验效果。

（五）插件化

为便于公司业务接入，提升自动化的灵活性，App Diff 对接了公司 CI/CD 平台。对于业务方而言，使用这套方案需要搭建一条流水线。搭建时，首先是基准包和测试包的编译，测试的对象包含这两个部分。其中比较重要的是通过修改代码保证基准包、测试包及工程之间的数据可以互相访问。接着，再对接到 APP DIFF 插件，通过配置要使用的设备 ID、用户信息、产品线信息、提交召回 BUG 的空间信息以及录制代理配置等。CI、CD 平台也能够提供结果展现能力，可以直接输出下图右侧的结果。

（六）整体架构

APP DIFF 的整体架构如下图：

图片最右侧是框架本身，中间部分是调度、对接到设备管理的自动化云侧平台以及自动化本身 Case 服务。QA 插件对接的是公司的 CICD 平台，是连接业务方和最终技术方的桥梁。

对于 APP DIFF 而言，爱奇艺整体改造方案是从最右侧基础 API 层封装了 Mock、AUI、Deep Link 这些能力，然后在 Case 调度上的 Runner 部分实现由原来单一链路到现在二次执行的调整。APP DIFF 插件可以灵活支持业务方，简单配置更便于接入。

（七）小结

APP DIFF 方案有着以下几点优势：

（1）运行效率有所提升。对于收藏、历史记录这样的 Case 而言，原来的步长较长，即使改变后需要执行两遍，但与之前相比，效率仍有提升。

（2）Case 执行的稳定性提升。此方案依旧会受到协议较大变更影响，但相比于 UI 交互还有后端下发数据变化所受到的影响要小，较之前稳定性有所提升。

（3）验证效果提升。校验范围由点到面，更接近主观感受。

APP DIFF 也存在劣势，如编写 case 需要对业务相关存储、后端协议深入了解，转化成本相对较高，但这样可以加深业务理解。

整体上看，此方案对存储、协议改动相对较小的稳定产品或者模块收益更大，通过 Deeplink、数据构造、AUI 验证，完成 Case 的一次转化，能够较低成本地维护，取代 Case 执行。

三、业务落地

（一）模块拆分

在落地之前，我们对客户端业务按照数据依赖强弱、Case 层级深浅两个特征进行拆分。对于数据依赖性强的 Case，应利用录制回放，保证数据的可控性；对于 Case 层级深的类型，则使用 deeplink 拉起。最终选择业务落地收益成本比最高的方案执行即可。

（二）爱奇艺极速版 APP 落地成果

在爱奇艺极速版 APP 中，收藏、历史记录模块稳定率相比之前提升 20%，运行时间缩短一半，结果置信度也实现了大幅提升。下图是历史记录未登录情况下，收藏不同时间段的数据验证。

在完成这部分的转化后，爱奇艺尝试对首页（频道+历史+榜单+片库）进行转化，其中部分需要研发支持。

结果显示，首页相比之前提升有限，录制和回放流量时仍然不可控，无法指定数据类型，说明方案仍旧存在一些局限性。

（三）Card 业务介绍及其自动化

基于以上原因，爱奇艺测试团队对首页模块进行了拓展。

为更灵活地支持业务需求迭代，爱奇艺首页频道业务采用 Card 业务类型，在前后端协同开发时，定义一套协议和规范。一般而言，Card 业务执行有三个环节即资源配置、策略配置、前端展示。

如上图所示，在每个首页 Page 中，有多个 Channel，每个 Channel 下又有不同的 Card。如此繁复的 Card 类型使得回归测试的工作量大大增加。

此外，爱奇艺业务中存在大量的 AB 实验，产品随时上下线，有时并不会及时通知到测试团队，这就导致测试数据构造成本大、测试有效率较低。同时，Card 测试中近五成用例属于展示和点击类。

基于 Card 业务以上特性，爱奇艺根据 APP DIFF 方案对 Card 业务自动化能力进行了设计，通过真实用户数据的拉取，清洗出单个 Card 数据并存储，利用 App Diff 能力，Mock 指定 Card 数据实现 Card 业务自动化测试。

具体实现方案是：首先进行 Card 数据抓取、数据清洗，然后进入 Card 自动化服务。原来的自动化框架支持以数据驱动生成代码，利用 FTL 编写 case 模板，通过后端数据返回生成代码。然后运行 Case，连接 mock，运行设备上生效的 card 数据，进入指定 card 频道，再进行 AUI 验证，最后断开 mock。我们的 case 整体由数据、模板、遍历、校验四个部分组成。

（四）Card 业务落地

Card 业务落地，主要包含 Card 数据生产、Card 数据服务、Case 生成，APP DIFF，Mock 服务五个部分。

Card 自动化落地后，取得了系列成效。在覆盖率方面，每版本拉取 70%以上线上 Card 类型；在稳定率方面，非 UI 驱动，频道 Case95%+；有效率上，真实用户请求，相比全功能准确度提升；转化成本上，Case 根据线上 card 数据生成，无编写成本。

四、未来规划

未来爱奇艺将持续完善低维护、深入业务的自动化解决方案。

当前规划主要包含两个部分：（1）精准遍历，目前爱奇艺落地的是仍是展示验证，之后将致力于优化现有的遍历算法，实现高效、精准的点击。如利用图像模板匹配、元素树的特征挖掘去重，建立维护平台负反馈机制，兼容业务差异化。（2）智能分析，对其他不稳定的用例实现智能分类，降低维护成本。如完善对网络、设备、依赖服务的监控，依据收集的各类信息建立失败问题的标签体系，以便后续精准维护 Case。

五、AUI 智能自动化方案

（一）智能自动化背景

当前，我们可以将智能自动化定义成以下 5 个等级：

（1）无自动化，依赖于纯手工；

（2）Code/Script 简单自动化。在这一阶段会引入一些简单的代码和脚本，但由于只是初级阶段，在自动化指标上差强人意，一般需要介入一些大量的人力进行维护，自动化收益有限；

（3）CodeLess 方式｜录制回放。这一阶段一般已经有着较为完善的自动化流程了，采用一些 CodeLess 方式或者测试工具来提升自动化技术含量，典型代表有录制回放以及 EGGPLANT 工具；

（4）用 Monkey 能力进一步降低成本并应用到代码智能修复；

（5）接近于完全自动化，可以自动生成智能脚本，同时对结果进行智能分析和校验。

（二）AUI 概述及其架构设计

AUI 是爱奇艺在智能自动化方面的一个探索，指的是借助 AI 及图像处理能力，提供给测试用户“所见即所得”使用体验的高效率前端自动化解决方案。“所见即所得”就是直观地告诉用户我的预期和结果差异，并将其标记出来，AUI。目标是实现 LV4 到 LV5 的智能工具。

那么如何达成这个目标呢？

第一，提升脚本的自动化水平。包含两种类型，一是操作类脚本，二是断言脚本。我们目前重点在于断言脚本，抛弃之前的元素及 css、数据级别的间接校验，基于图像 APP DIFF，直接校验“预期 VS 实际”展示差异；

第二，提升自动化流程效能；

第三，提升平台化能力的同时，为第三方单独提供部分服务。

下图是 AUI 整体架构设计。最下层是平台依赖的底层技术，在此之上是对外提供服务能力包括图片 DIFF、模板匹配、目标检测、异常检测等等。另外就是基于前端各种自动化框架的 SDK 封装，主要目的是快速生成用例，同时便捷地对服务进行调度。最上层是前端 Web 平台，功能有任务管理、用例展示 &维护、结果分析、邮件报警等等。

（三）AUI 算法设计及迭代

算法服务是 AUI 平台最核心的能力。算法设计共有精确匹配、严格匹配、灰度匹配、布局匹配 4 个级别，从爱奇艺业务中抽象而来。

精确匹配是指利用图像矩阵差对两张图不同的像素级别进行结果校验，实际应用场景相对较少。严格匹配指的是采用结果相似度算法，对比出肉眼可见的差异性，适用场景更多。灰度匹配则是在严格匹配的基础上刨除部分背景色差，因为当下流行的沉浸式样式对严格匹配造成了困扰，所以利用高斯模糊等技术手段对这些差异进行处理。最后是布局匹配，算法级别最为复杂，同时用到图像算法和深度学习技术，适用于动态内容、多语言环境等区块，如爱奇艺首页经常变更素材，这时就可以用布局匹配检测布局位置变动，而忽略内容的改动。

爱奇艺通过自己的技术能力对布局算法进行了优化升级。布局算法的第一阶段是对图像进行边缘检测，突出轮廓。具体实现过程是：首先对图片进行预处理，在此基础上进行边缘检测，得到清晰的边缘，再进行图像形态学处理，得到更加清晰的布局。随后做矩形检测，就会得到下图左下侧绿色所示的结果图。其优势是适用于爱奇艺大部分业务场景，尤其是 Card 类型业务，同时用到的算法比较简单，因此性能较好。但缺点是对于元素间距离较近的场景，支持度不好，尤其是小于 1.5PM 像素时会出现黏连问题。

针对此问题，爱奇艺对布局匹配算法进行了二次迭代，开发出投影算法。大致处理流程是对图片进行预处理和边缘检测后，分别在 Y 轴和 X 轴上进行投影，得到有效区域集合，持续迭代，直到没有子元素输出。同时对整张图片进行 OCR 识别，得到元素集合后进行基础分类检测。目前投影算法可以识别出的分类有图片、按钮、文字 3 种。

但由于其只借助了图像能力，能够进行的分类检测较为基础。在此之上，爱奇艺又引入智能检测，目前已经能够检测出 50+分类，切割边缘效果也较为精准。

（四）AUI 落地及规划

AUI 算法在业务线落地后，在 job 稳定性基本持平的情况下，执行效率提升、用例编写成本降低、代码量下降、维护成本降低 40%。

未来，爱奇艺还将持续致力于降低用例编写成本，进一步提升平台化能力，在现有基础上提升算法准确率及算法性能；结合深度学习手段，丰富目标检测分类的多样性，以适应各业务线场景；同时，基于目前 AI 技术能力，拓展非 DIFF 解决方案，发挥智能测试优