三方应用UI自动化的价值

从设备厂商的视角来看，Android App的UI实现方式错综复杂，采用的UI技术栈层出不穷，以及需要进行显示适配的新型场景（如平行世界、窗口模式、画中画、桌面模式和折叠屏）井喷式涌现。

大部分的三方应用测试通常仅关注UI功能、冒烟测试，测试流程枯燥、重复，且业界有成熟的UI自动化基础，因此通常在三方应用兼容性测试中接入一定程度的自动化测试。

在这个大背景下，相对于一方/二方应用而言，数量庞大、纯黑盒、架构复杂多样的三方应用，主要在以下几个场景中存在几个痛点。

更多资料： 公众号<Android苦做舟> 或 联系作者 领取这些Android进阶开发文档

1.Android高级开发工程师必备基础技能
2.Android性能优化核心知识笔记
3.Android+音视频进阶开发面试题冲刺合集
4.Android 音视频开发入门到实战学习手册
5.Android Framework精编内核解析
6.Flutter实战进阶技术手册
7.近百个Android录播视频+音视频视频dome

业务痛点

1. 技术、市场因素等构成的现状，决定了厂商对三方应用的兼容性的工作量是不自主的、单调增长的

三方应用UI测试投入不小，但在没有直接经济效益的前提下又不得不投入。不论测试方法以手工进行、自动化测试、混合进行，对QA资源的消耗都是巨大且不受控的。

2. 效率显著低于一方应用

高效的自动化要求QA掌握被测应用的业务、版本变更点，以及与QA配合的自动化测试友好的应用接口。

对于三方应用，业务的不透明决定了QA设计的case不能紧咬变更点，无法设计最符合业务逻辑的测试方案。

此外，被测三方应用可能没有自动化UI测试接口，或自动化测试接口本身就不易被非App自身人员使用。

就算条件成立，也不可能对成百上千的应用都勤力投入，通常舍弃覆盖程度

通常，高效的UI自动化测试会通过POA模型、Page Factory模型等，借助工业级的自动化框架和思想，由RD与QA配合，从设计-开发-测试形成闭环，产出可维可测性高的产品——但仅局限于一方应用之内，厂商和其他外部并不能从中受益，用起来自动测试。

相当一部分应用并未设计自动化基建，即使是应用方自身都需要花费大量精力才能用起自动UI测试

3. 测不到位或过度测试

三方应用并非自研，且属于纯黑盒，并在成本因素制约下，对三方应用的UI测试（包括UI自动化测试）追求高覆盖率是不现实的、不科学也不可能的，但是仍然尝试追求一定程度的覆盖。这个覆盖的程度难以衡量、覆盖率目标也难以估量制定，也不依靠分析和讨论得出。

三方应用在没有公开或共享其热点流程时，黑盒的UI测试（包括按照一定case进行的手工/自动测试、Monkey测试）通常不能拦截全部的关键流程。

当然，也有过度测试或冗余测试的情况。

总结来说就是测试覆盖目标、测试覆盖率、测到什么程度，是非曲直，难以论说

4. 投入产出不理想

在三方应用UI自动化测试场景下，有时QA或RD完成一组自动化case的设计、编码、验证后，发现花费的时间是手工测试的10倍甚至更多。这一投入产出比若是常态，则显然不可接受。

在紧急情况下，有时手工测试一把梭哈更加可靠，甚至可能废弃掉团队积累的自动测试方法。

这一“轻舟已过万重山”的寓景还不是最严峻的挑战，当三方应用更新后，迫于三方应用实现的多样性、厂商侧的自主性等不可抗力，自动化脚本/工具/case可能会很遗憾地失效，失去其“Once write, run forever”的愿景。

Martin Flower：“GUI测试用例还很脆弱，如对系统的一些修正可能导致很多用例的失败，这时候你需要重新录制。你可以放弃录制的方法来解决这个问题，通过写GUI测试代码，但是这样效率非常低。就算你已经很精通了GUI测试代码的编写，端到端的GUI测试用例也很容易出现不可预期结果的问题，因此，基于GUI的自动化测试是脆弱、耗时（包括用例维护和执行）的。GUI测试用例能覆盖到主业务流程即可。”

5. 边际效益递减

根据敏捷开发模型，也出于对三方应用UI测试的展望，随着UI自动化的加深，其收益是边际递减的。

参考Mike Cohn，自动化金字塔模型

事实上，三方应用UI测试的收益曲线更加复杂，它可能不是单调简单的，对三方应用UI测试投入地更多，最终综合效率和成果的收益可能不增长甚至反而下降。

6. 支撑自研应用商店

应用合规分析（静态、动态分析）、自动审核/上架、UI自动化测试是应用商店运营的重要支撑。此时UI自动化测试将从研发质量、兼容性的范畴扩展到运营、对接层面。

除此之外，三方应用的UI测试与一方二方应用的UI测试的特点无异：

1. 枯燥，重复
2. 成本，时间
3. 扩展，重用
4. 探索性case的测试

一方：指的是本团队的项目，如内置应用（易于进行白盒/黑盒测试） 二方：一方使用的可能是其他部分研发的、外部引入的应用/包/库（不难进行白盒/黑盒测试，通常集成到一方后进行测试） 三方：第三方的应用，如应用市场下载的应用（几乎没有通用的白盒方法，黑盒测试囿于复杂性难以实现通用化；不熟悉主程；难以衡量覆盖率；迭代不可控、测试节奏不自主）

三方应用UI自动化的技术难题和隐患

实现对应用的UI自动化测试将给团队带来效率和体验的提升、研发质量的改善，基于这一类的愿景，业界提出了大量的测试思想，落地了强大了工具、框架。

但是对于三方应用UI自动化测试的实现，主要受限于纯黑盒的环境、数量众多的各三方App，以及有限的成本预算、紧迫的时间，尚无简单高效的方案可供直接使用或参考。

本节总结三方应用UI自动化测试的难点，并铺垫下文对三方应用UI自动化方案的探索。

App UI自动化测试的一般实践

UI自动化测试通常要求App具有如下内在特点：

1. 软件需求变动不频繁 否则建议在UI测试（包括对自动化的开发）中投入占比不超过20%（因为（半）手工方式更快，具体方案见敏捷类方法）
2. 产品更新维护周期长 否则跑UI自动化的次数不够多，收益不够大
3. 比较频繁的回归测试 根据自动化金字塔，UI测试属于（相对于金字塔底层的接口测试、单元测试而言）执行效率低、复杂度高（脆弱）、问题出现后分析链路长的一般在回归测试时进行的测试
4. 自动化测试脚本可以重复使用、易于回放 脚本如果不能重用，无法”回本”，即得不偿失

也就是说，UI测试是分场景的，场景决定了UI自动化测试是否值得。

测试金字塔是一个理想状态下软件测试模型。三层分别是UI测试、集成测试和单元测试。金字塔从下往上，可维可调性越差，效率越低。越接近底层所能达到的覆盖率越高。

UI测试应该投入的资源就如金字塔塔尖一样，占比最小，且靠后进行

对三方应用的UI自动化测试无法像一方应用那样易于进行，投入占比也很难有成熟的模型来衡量。但三方应用本身的“三方”特性，我们可以肯定，三方应用相关的UI自动化测试代码越少越好，总体投入越少越好。

对于三方应用UI自动化的场景，其更加尖锐的效率要求、恶劣的自动化条件（业务是黑盒、逻辑是黑盒、Apk内建自动化接口是黑盒），使之具有了象征更高要求的特点：

1. 自动化设施必须是跨UI技术栈的 要满足各种UI技术栈，不像单个应用的UI自动化那样支持单一的特定的自动化框架即可。
2. 低代码乃至于无代码 三方应用众多且迭代不受控，自动化代码越多，其保值能力就越脆弱。

在尽可能满足以上几点要求、兼顾低代码、高效率，可以推导出符合三方应用UI自动化测试需求的方案应该满足以下几点：

1. 具备识别各类型UI的能力：原生、WebView、Flutter、Cocos、Unity、React…
2. 具备各类型UI的点击能力
3. 对三方应用，不关注业务流程，只关注一定程度的不要太低的覆盖率（“界面点点点的深度、广度”）：要有自动“点点点”的能力，能划屏更佳
4. 低代码，不/少写保质期短、制作耗时的测试脚本

那么总结来说，这个工具应该是自动遍历各类界面并点点点。

Android单个应用的UI自动化具有完善的工业级技术，我们看看这些基础技术能否使用或参考。

App UI自动化的基础技术

Android UI自动化框架的主要能力是界面感知和界面操作。一个完整的自动化UI测试操作是首先完成待点击、滑动区域的识别，然后完成界面操作和导航。

对于业界先进的方案，主要如下。

UI自动化测试中重要也是耗费精力的一环，就是借助UI技术提供的机制编写代码、操作、录制，实现UI感知，即UI控件识别、定位。主要分为如下两种类型的实现。

兼容能力：Android UI技术栈众多，UI自动化测试得以进行的基础是这个UI技术栈维护的ViewTree或DOM易于获取、解析。多种不同技术栈之间差异较大，主要分为原生、WebView、React、Cocos、Unity、Flutter等。

应用侵入：为了满足自动化测试，必须注入到应用进程中，或者要求应用接入SDK

三方App UI自动化的侧重

从上文两类界面感知方法及其配套的界面操作方法各有千秋，在不同的场景下各有优劣。在这些特性的基础上，三方应用UI自动化实际上更依赖于以下几个特性来确保效率。

• 跨UI技术栈的兼容性
• 低代码
• 自动遍历Clickable、Scrollable控件并完成操作
• 进行的UI测试具有一定的深度、广度，能够测试到足够多的UI界面

对于图像技术而言，实现上述功能在整体难度上暂且不表，而逻辑上则较简单——即通过图像技术分析画面，分类出符合的控件，并按照一定逻辑组织自动测试（深度优先、广度优先）流程。

前面分析过，图像技术本身的原理以及对UI的实现技术栈的独立性，天生就决定了其在跨UI技术栈兼容性会表现更佳，且模型的成熟度影响测试深度、广度。此外，由于图像分析避免了原生定位中要求的繁琐代码实现，因此其低代码属性也是与生俱来。

对比来看，在针对三方应用UI自动化而言，由于客观上UI技术的多样性、碎片化，以及主观上对原生定位接口即自动化脚本的开发具有脆弱性，原生定位方案在跨UI技术栈兼容性这一方面较弱，同时针对一个应用的一个场景，所投入的资源、产出的代码量也较大，不适合与大量三方应用的场景。

为了在三方应用UI自动化这种要求低代码、高兼容性的黑盒场景中取得更高的效率、更低的投入，要求自动化设施必须具有下面这些特性。

小结：放弃xpath等“精确定位”的编码工作，通过自动遍历实现低代码；结合机器学习、机器视觉提高对多种UI技术栈的兼容性。

三方应用UI自动化的选型

在常规的传统的UI自动化测试的基础上，由于原生定位能力相关的技术较完善成熟，对三方应用的UI自动化重点关注“自动遍历”和“图像技术”辅助。

1. 自动遍历

对于非图像处理技术的定位方案，通常自动化测试的主要投入是对界面的分析工作、对界面的自动化编码。这两大步骤是UI自动化测试中最大的投入之一，同时也是“脆弱性”即自动化脚本时效性的来源。

事实上，App的界面和控件可以被抽象成树型结构。

• App的所有UI界面可以抽象成树，界面之间的跳转即树的连接路径，各个界面为叶子或根节点
• App的一个UI界面中的所有控件是树形结构组织的（ViewRootImpl树），各个控件总是能够从父节点经过路径到达
• 部分UI技术提供的“树”可能需要结合图像技术才能完整确定

基于原生定位能力实现的自动化设施主要的耗时点（尤其是针对三方应用）在于分析该UI树，找到关键控件的关键信息，编写自动化脚本完成定位、操作和导航。

自动遍历的核心在于忽略“树”的细节，从根节点开始，遍历整个UI树和控件树，在摒弃自动化脚本的同时实现对UI的遍历，达成和自动化脚本接近的自动操作效果。

从策略上看，遍历通常有DFS（深度优先）和BFS（广度优先）。对大多数应用而言，DFS效率更高，需要跳转界面的频次较低。

从方案上看，由于原生定位能力和图像技术均能建立抽象UI树，因此自动遍历也有这两种方案。一般而言，原生定位能力实现的难度较低（因为UI树是App现成的自带的），但是考虑到UI多样性和跨UI栈兼容能力的脆弱性，图像技术是很重要的补充（尤其是针对三方应用）。

2. 图像技术

图像技术最直接的作用是支持那些无法被原生定位能力所支撑的应用的自动化测试。但实践来看，图像技术对测试效率的提升、测试时长方面有显著的优势，这超出了其增强UI兼容性的最基本需要。

出于原生定位能力自身的局限、三方应用UI的脆弱性（技术栈多、保质期短、自动化不友好），为了提升原生定位能力不够用的多技术栈兼容能力，通过图像技术来识别和分析界面的研究已经在业界取得众多成果。

图像技术超脱了UI技术实现的细节，因而摆脱了基于原生定位能力的自动化设施的脆弱性。在针对数量广大的三方应用的自动化测试场景中不可或缺，决定了自动遍历阶段的输入的完整性和高效性。

同时，图像技术在辅助甚至主导界面感知之外，还可能提供不菲的效率提升。原生定位能力所提供的界面感知能力的优点是精细，适合一方应用开发使用。在数量众多的三方应用的自动化测试方面，除了存在效率、脆弱性等隐患以外，其测试速度也较低。

原生定位能力基于UI树来进行界面感知、界面点击。由于对树（或图）的分析非常耗时（对树的节点们都进行分析若干个属性），且在设备端无障碍服务需要通过IPC（Binder）来与App交互。因此，从原理上（树的分析）和工程上（IPC）导致其效率不高。实践数据来看，其测试速度慢于图像技术。分部分来看，其界面感知速度较慢（树的分析慢于图像分析），操作速度也慢于直接发送触摸事件。

原生定位能力对混合应用存在较大兼容问题。如React虚拟DOM的情况，每当页面更新会触发生成新的DOM，导致UI树变化，需要重新进行分析。

小结

三方应用的自动化测试工具，通过同时支持原生定位能力和图像能力作为界面感知技术来应对三方应用UI自动化的脆弱性，并在界面操作方面通过自动遍历来实现低代码，解决在投入产出比、效率方面的隐患。

参考工具

对于原生定位能力、图像技术、自动遍历等技术，较适合三方应用场景的有如下几个工具。

更多资料： 公众号<Android苦做舟> 或 联系作者 领取这些Android进阶开发文档

1.Android高级开发工程师必备基础技能
2.Android性能优化核心知识笔记
3.Android+音视频进阶开发面试题冲刺合集
4.Android 音视频开发入门到实战学习手册
5.Android Framework精编内核解析
6.Flutter实战进阶技术手册
7.近百个Android录播视频+音视频视频dome

参考

1. RD: 研发
2. QA: 质量（包括测试、测开）
3. 《Succeeding with Agile: Software Development using Scrum 》(Scrum敏捷软件开发) Mike Cohn

作者：飞起来_飞过来
链接：https://juejin.cn/post/7163241561755992071
来源：稀土掘金