蚂蚁金服终端实验室演进之路

0. 背景

作为国民级 App，支付宝客户端需要为亿级用户提供多元化的服务，因此应用的稳定性与可靠性面临巨大的挑战，需要不断地完善和优化。

今天，让我们站在服务质量的全方位监控与优化的角度，从蚂蚁终端实验室的演进之路展开探讨，从借助使用开源的自动化方案，到自研并逐步完善无线实验集群技术体系，支付宝内部经历了怎样的业务场景演练，以及相应的技术架构如何借助移动开发平台 mPaaS 对外输出。

1. 发展历程

总的来说，蚂蚁终端实验室从诞生到现在，一共经历过三个阶段（工具化、服务化以及中台化），其每个阶段都有特点和意义：

工具化阶段：

该阶段主要以使用市面上主流开源软件为主，如客户端开源软件 Appium，其覆盖的端为 Android 和 iOS；通过这种开源工具和 App 测试流程结合的方式，快速满足业务方的提测需求，从而帮助业务方完成一般意义上的自动化测试工作（如基本的功能测试、兼容性测试等）。

服务化阶段：

服务化阶段存在一个重要的背景：支付宝着手前后端研发流程分离，并逐步沉淀出独立的 App 端研发流程系统（研发协作流程与 App 构建流程）。在独立的 App 研发流程和系统的基础上，终端实验室以一种服务化的形式支撑 App 的研发和协作，处理满足日常用户自动化工作外，同时还担当着持续集成、日常发布前自动验包工作等；另外在日常发布发布提供质量数据支持，如客户端代码覆盖率统计等。

中台化阶段：

伴随着终端实验室的能力不断提升优化以及测试规模的逐步扩大，服务上不仅需要满足蚂蚁金服体系 App（支付宝、口碑、网商银行等）日常测试需求，而且还需要将能力扩散覆盖到整个阿里巴巴集团的业务。

随之而来的是实验室需要面临多样化的业务方需求和定制化功能，如何在多元复杂的业务环境中，与业务方或者说上游系统完成能力共建？带着这个问题，终端实验室逐步沉淀并着手建设中台化平台：一方面让通用服务不断下沉，另一方面抽象出标准 SDK 的方式，让业务方根据自身业务特点建设特定的能力。

此外，在建设平台化的同时，终端实验室贴合支付宝业务场景的发展，构建如网络实验室、扫码实验室等一系列真实实验室的能力。

经历了几年的不断发展，终端实验室逐步完成了中台化的转变，其端上覆盖了 Android、iOS 以及 IoT 设备，服务上覆盖了通用能力、小程序准入、研发流程建设、真机租用以及用例管控等。

2. 技术生态

在了解完终端实验室的历程之后，我们能够对其提供的服务有一个全面的认识。当我们去总结和分析这些服务时，可以把这些具体能力分为三大块：平台服务能力、客户端SDK 以及实验室能力。

平台服务能力

平台服务能力的目标是聚焦“如何把蚂蚁实验室构建成一个更为开放的平台”，因此我们需要考虑到如何让更多的业务方和上游系统一起参与能力共建，从而将平台的建设思路分为 2 大部分：设备实验集群和开放SDK。

1. 设备集群

蚂蚁实验室不仅包含数以千计的公用终端设备，覆盖市面绝大多数手机终端，帮助业务同学完成日常自动化测试工作，而且提供了用户自建实验室的方式：用户只需要根据自身业务场景特性进行设备采购、实验室部署，便具备在自有平台上运行自有设备的能力。

从平台的开放性与部署动态化角度看，目前设备集群能保证设备归属和业务场景做到充分隔离，保证各业务在平台使用上能相互独立。另外，面对阿里巴巴集团众多研发中心，设备集群在部署上也支持多地部署、相互隔离。

2. 开放SDK

为了给上游系统和用户提供更为开放的能力，帮助业务方根据自身需求完成能力建设。终端实验室提供开放的 SDK 能力：上游系统只需在自己服务上接入 SDK，就能够完成任务构建链路，从用例管理、设备选择、任务执行，到执行结果回调，在此基础上用户就能够根据自身业务特点将业务数据进行多维度组合，形成自己的能力输出。

客户端 SDK

终端实验室经过几个阶段的发展，不仅提供 UI 自动化框架能力，而且在一些复杂场景做了深入研究和落地的工作。在这里我们以令大家头痛的“App 兼容性验证”作为切入点，结合目前常用的几种机器学习方案，分析方案的优缺点，最终形成了终端实验室的解决方案。

一方面伴随着移动互联网的快速发展，目前市面上手机的品牌和型号层出不穷，如何快速准确的验证 App 的功能在不同类型手机上运行有效性与稳定性，的确是件困难的事情；另一方面，目前针对图片的机器学习技术日益成熟，其图识别的准确性也完全能够满足日常兼容性的要求。

通常来说兼容性测试会采用两种方式：1.图像相似度计算；2. 无监督的异常点聚类。这两种方式在使用方式和结果输出都有其优缺点：

对于“图像相似度计算”来说，其异常图片的识别成功率非常高，但其前提条件比较苛刻：用户需要对每一版 App 以及每一个业务点进行图片搜集和上传，而往往每条用例可能会包含少则几张图片多则十几张图片，对于几百、甚至几千条测试用例来说，就算是一版 App 的期望图片搜集工作都是巨大的，何况目前移动互联网普遍都是快速迭代发布，所以导致了这种预先处理图片的方式是不太可行的，下图是一般意义以图搜图的数据流：

另一种常用的方案是直接将同一业务场景下不同手机的一组截图交给无监督的异常点聚类算法处理，这种方案的优点比较明显：对于用户和平台来说，没有增加的额外的工作量，操作简单，但带来的问题是，计算出来的结果并不完全可信，特别是在一些极端情况下（如某一类异常图片总数较多的情况），少数正常的图片反而会被识别成异常图片，告知给业务方。

对比以上两种技术方案，终端实验室在兼容性异常图片发现上采用了更加灵活的方案，通过手机端“异常目标检测”和服务端“异常点聚类”相结合的方式完成目标。

首先，平台搜集常见异常图片，并训练成模型，植入手机端。

其次，当用户执行兼容性测试的时候，在手机端完成一部分“常见异常图片”的发现工作。

再次，当任务执行完后，服务端将剩下一部分图片交给““异常点聚类”处理，并进一步是被不同的图片。

最后，在整个执行任务结束后，平台就能有效识别异常图片，另外当异常图片未被有效识别的情况下，又可以在平台上快速提交异常图片，并交给算法逻辑继续学习，形成新的模型，从而在下一次任务执行过程中，就能把这种新发现的异常捕获住。

通过这种灵活的方案，一方面大大提升了异常图片检测结果的准确度，另一方面在整个异常图片的发现上形成了闭环，大大提升的兼容性测试的效能。

实验室能力

为了应对日益复杂的用户使用环境和不稳定的运行环境，终端实验室不断去构建各种专项实验室，尽可能在实验室环境里就把问题发现并推动研发流程去解决。同时伴随着 IoT 时代的到来，面对种类繁多的终端设备，如何能够通过实验技术的手段帮助研发同学提升效能，是一个新问题也是一个比较有挑战的问题：终端实验室通过托管 IoT 设备的方式，让用户快速方便寻找设备，并进行功能验证。具体技术方案是在原有的 Android/iOS 真机租用方案的基础上做了能力升级。

第一，将终端实验室上某一款手机和 IoT 设备做关联，保证当浏览器通过 WS 远程操作手机打开摄像头就能够看到对应的 IoT 设备；

第二，通过 WS 读取 IoT 串口的 trace 信息，并将数据以 WS 的形式推送到用户浏览器端；

第三，在宿主机上集成 IoT 设备操作的 SDK，保证宿主机能够通过命令行或者 HTTP 方式操控 IoT 设备；

第四，宿主机集成语音转文字 SDK，这样当 IoT 设备发出声音时，就能够在页面上以文字的方式告诉用例。

通过这种远程 IoT 租用的方式，用户就能够快速做作一台远程设备，另外在给 IoT 设备发送指令的同时，可以看到设备的相应信息（视觉展示、声音展示以及实时日志信息），从而达到快速验证的目的。

机械臂扫码测试：

智能机柜支持真机云测

3. 借助 mPaaS 对外输出

以上介绍的蚂蚁金服终端实验室相应能力的构建与实践，目前已经通过移动开发平台 mPaaS 对外输出一部分能力。

在 mPaaS 平台上，我们将自动化测试框架，真机调度管理，场景化测试方案以及详尽的测试报告方案整合外部客户的现有业务场景和系统，从而覆盖 App 开发期的各个阶段，确保应用上线前获取充分测试，发现 bug，减少线上问题，提高整体用户体验。

目前，终端实验室不仅对内服务了包括蚂蚁金服体系下的支付宝 App、网商银行、口碑商家等，同时借助 mPaaS 与大量生态合作伙伴一同共建能力，包括常熟农商行、西安银行、泰隆银行等。由于篇幅限制，很多技术要点我们无法一一展开，欢迎大家通过技术文档或点击“阅读原文”进一步了解 mPaaS ：https://tech.antfin.com/docs/2/49549