【支付宝生态质量验收与检测技术】

如何验收和检测海量的支付宝生态小程序的质量，是一个很重要的课题。本次分享会简单介绍如何通过平台化的方式在小程序入驻环节进行准入验收，以及使用前端自动化测试技术和智能化算法对小程序质量进行检测。希望能对小程序质量的验收和测试提供参考。
讲师介绍

马亚明测试开发专家
主要负责支付宝行业生态小程序的质量保障工作。主要研究领域：前端自动化测试、云真机质量检测技术、小程序验收平台建设、行业生态质量保障平台架构设计等。2020 年加入蚂蚁金服，深耕行业生态质量领域，从事质量平台架构设计、研发工作。

背景

支付宝生态质量所负责的范围比较大，像政务、出行、医疗等等，各个行业的各种小程序以及它的细分行业有非常多。我们打开支付宝各种各样的小程序，其实都是我们生态质量要负责的范围，大家常用的健康码、场所码、地铁出行甚至点餐的那些麦当劳、肯德基餐厅相关服务等等。那么，面对这些生态质量小程序，我们质量要做的主要就是质量风险拦截和质量风险止损。质量风险拦截，也就是怎么发现问题，我会跟大家主要分享的是验收与检测两块技术。

一、生态质量验收

（一）什么是验收？

首先我跟大家介绍一下支付宝生态的质量验收，什么是验收？验收的概念和测试很接近，但是也稍有点区别。从上面这个流程可以看出来，我们的小程序由开发者开发完成，他们自己做完测试之后，需要交付到支付宝，那在这个之后我们的验收的环节就是对开发者开发的交付物根据交付的标准来进行质量的审核确认这样一个过程，当然验收这个环节在真正做的时候并不是一个人或者比较简单的一个点，它会比较复杂。

举个例子，比如健康码，这样一个小程序开发完成之后，要入驻到支付宝，那首先需要提交一些验收相关的物料，比如操作的一些视频图片给到支付宝。然后我们会有一系列的环节进行验收，比如说要首先进行功能上的验收，然后进行 UI 层面上的一些验收，最后可能产品还要再做验收。

而对于另一种，比如一些扫码点餐，那种餐饮类的小程序，要进到支付宝的话，就是另外一条不同的审核的流程。比如说因为扫码点餐会涉及一些支付，可能需要提交点赞的一些数据，那我们会校验这个数据的合法性，然后进一步看这次交易是否正确，最后还要从业务层面去看这个业务是不是符合我们的标准。

（二）支付宝生态质量验收现状

所以不同的业务、场景，不同的行业的小程序，验收的流程是完全不相同的。所以，我们支付宝生态质量验收面临的主要问题有：

第一是数量多。我们每周都有万级别的项目需要去验收，因此这么多的项目完全靠人去验，这显然是不现实的，所以我们必须要引入自动化验收的能力，来提升验收效率；

第二是业务多。上面其实只讲了两个例子，实际上我们形形色色的业务流程可能达到上百种上千种，那我们不可能针对每一种业务的验收流程去做定制化，所以我们必须抽象出一种通用的验收的框架能够支持各种业务的验收流程。

因此综合来说，我们生态质量的验收主要是要开发一种能够支持人工验收和自动化验收相结合的，能够动态适配不同验收流程的这样的一种验收的框架。

（三）验收框架

我们的验收框架主要分为 4 个步骤：定义验收标准、编写验收用例、编排验收方案、发起验收项目。

1.定义验收标准

首先第一步定义验收标准，因为标准是整个验收的一个起点，那我们会针对具体的验收对象，由业务、产品甚至质量同学一起去定验收的标准。

举个例子，比如某一个地铁出行相关的小程序，如果要进入到支付宝，我们要进行验收，那我们可能会先根据它的特性定一些标准。比如说：没有白屏、空白页的问题，没有页面报错，加载耗时要符合要求，没有功能异常，以及页面样式、业务类目信息正不正确等等。

所以我们会由产品和质量同学，共同去为交付的验收对象定制一系列的标准，以标准为起点来发现后面的验收的流程。

2.编写验收用例

那么有了标准之后，接下来就要到我们的执行层面，就是怎么去验收。因为真正的可执行的我们就称之为验收的用例，是把我们定的那些标准把它真正变成可执行的这样一个转换。

那标准和我们的验收用例其实并不是完全就是一对一的，比如说我们刚才这么多的标准，我们可能在真正做验收的时候，会把它拆成几个这种不同的验收用例。

比如说我们把白屏、空白页面报错这种标准我们可以用真机自动化的方式去做，我们会有一个真机自动化这种测试的用例；比如说功能异常这种，我们可能会有一个人工验收这种功能延伸的一种用例。所以它可能是一对多或者多对一这样一个关系，大部分情况我们的用户用例会由我们的质量同学去负责编写。

因为我们支付宝所验收项目很多，所以必须要用自动化的手段去集成验收效率，因此我们的验收用例同样的也会分为人工和自动化这两种主要的形式。

那这个验收用例的概念其实和我们的测试用例会比较像，但是又有区别，会更加的复杂。比如说我们的自动化验收常用的一些自动化的测试手段，如接口测试、功能测试等等。

那在验收这个层面上来讲，因为我们验收流程的业务种类非常多，所以我们的验收的自动化要更为灵活去支撑我们的业务，所以我们又加入代码组件这个概念来实现我们的自动化验收。

代码组件大致的形式就是一个代码的脚本，在这个脚本里面，我们可以做各种各样的逻辑，比如我们做一个接口测试，我们做一次数据库的查询，或者说我们会查一些离线数据日志等等，来实现我们的自动化的这样一个验收的逻辑。

当然我们自动化之后我们还会有一些不同的一些结果的判断，比如正则、比较、判空等等，来判断我们的自动化，判断我们验收的结果。

对于人工验收这一块，主要是由数据展示和交互操作组成的。那类比我们的测试用例的话，比如一个人工的测试用例，它主要就是会定义一些操作的步骤，然后有人工去执行。那对于验收来讲，它除了告诉验收的人应该怎么去执行（主要是数据展示部分）之外，它还会有一些交互的操作，比如最开始上面提到的那两个例子，验收的第一步往往是需要提交一些验收的物料，比如要上传一个视频，所以它有一个交互的过程在里面。

因此我们的人工验收的部分会涉及到数据展示与交互部分的大量的操作，所以我们的验收用例的整体结构，除了像验收用例名称等那些基础信息之外，它还需要有自动化配置与人工配置所结合起来，甚至说这两种可能是都会有存在的情况。

那比较具体的一些情况，比如说我们的真机自动化测试用例，它可能是需要配置一个自动化的颜色的组件，如加长一些自动化交易的规则，它就会形成一个真机自动化的用例。如果是一个人工的功能测试用例，那我可能需要去编排一些人工交互的界面，我会告诉你的验收步骤是什么，或者说给你一个入口链接，你照着去操作验收，然后你验收完之后，你可能要把你验收的这种视频截图，再把它给上传回来，所以还会有一些交互的这样一些空间去给验收人员去做一些交互。所以我们的验收用例是结合人工加自动化两部分，并且可以灵活选择你是人工的还是自动，或者是人工加自动化结合的这样一个情况。

那么当你有了验收用例之后，其实你还并不能直接去对某一个交付进行验收，还差了一层。比如我们针对出行小程序，列了很多的标准，把这些标准转化成一堆的演示的用例，但这些用例在真正执行层面并不是有一个人并行去执行的，它可能是有一些串接的这种顺序关系，或者说有不同的人去进行的。

比如说有些自动化用例，可以由系统自动化去执行，还有一些是质量同学负责这些质量相关用例。比如功能测试可能由质量同学去负责去验收。像一些视觉相关的，小程序的样式、视觉规范可能是由视觉相关同学去验收的。最后可能还有产品同学统一做一个产品层面的验收。

3.编排验收方案

所以不同的验收用例是需要有一个编排的过程，最终才会形成一个适用于我们业务的验收流程的这样一个验收方案，所以我们还有一层概念叫验收方案，它主要做的工作就是把我们之前的验收用例做一个编排。

比如说像这么多验收用例，我们经过编排之后，可以把它变成 4 个节点，我们可以先跑自动化，自动化跑完之后我们再由质量和视觉并行，之后再由产品去做最后的一个验收。

所以在验收方案这个层面，我们就可以实现验收用例的灵活编排和组装，以此来适配不同的业务，比如我们提到的成千上百种不同业务的这样一个验收的流程。

4.发起验收项目

那么当有了验收方案之后，实际上我们最后把这验收方案实例化，就形成了我们最终的验收的项目。所以可以得出，我们最后的产物其实就是验收的方案，我们把一个交付应用到验收方案上就会变成一个实际的验收项目。

举个例子，比如一个项目它会有一些具体的验收任务，那点进去执行就会有一些具体的执行的界面，由验收人员或者说自动化去完成，那这样一种验收的框架的话，我们就把它覆盖到我们整个生态，覆盖政企、教育、文体等很多行业，每周都有近万的验收项目是通过这套验收框架去完成验收的。

那在实际上应用层面的话，比如纯自动化的验收或者纯粹的人工验收，以及常用这种半自动化人工计较参数和自动化验收，或者说自动化产出一些验收物料和人工判断注册方式，都可以通过这种方式去实现，这就是我们应对验收的问题的验收框架。

二、生态质量检测

（一）生态质量检测的作用

什么是检测？其实刚才提到的我们在验收的过程中，会使用很多自动化的方式，那这个自动化其中有一块就是我们的自动化检测的技术。

检测是自动化去发现问题的手段，当然除了在验收这个环节之外，小程序通过验收进入到支付宝之后，因为小程序还会不断更新迭代，会产生各种各样的线上问题，所以我们的检测也可以用于事后去主动发现问题。

比如一个小程序上线之后，会出现各种各样的情况，像域名不存在、停止服务等等，这些问题在验收之后也会出现的，所以我们也可以通过自动化检测的手段去发现。

（二）支付宝生态质量检测现状

1.挑战

那么我们支付宝生态质量检测所面临的主要挑战就是数量的问题。因为刚才提到了每周万级
这样一个量级的小程序需要去检测，这对自动化来说也是一个非常大的挑战。我们常规的一些测试往往是会盯着几个我们自己小程序去做的，但现在不一样，我们负责的量级在几十万这个量级，因此我们的自动化检测的技术也会在量上面去做一些适配。

但除了量之外，还有就是我们的标准，除了大家一些常见的像什么黑白屏、页面异常之外，其实我们会有几十种不多种业务所定义的这种异常，因为它所有跟我们的验收标准去匹配的话，我们的标准有很多有几十种，所以我们在发现问题的方式上也需要根据业务产出几十种不同的发现问题的手段。

2.解决方案

我们的解决方案最核心还是会使用我们业界常用的真机自动化测试的手段，使用自动化引擎去驱动上千台的真机模拟器去执行自动化测试。

那么在测试执行的过程中怎么去测一个小程序，那就有操作路径这样一个问题，我们会提供像用例编写、遍历、智能动线等多种执行方式去执行测试的操作。

在测试完成之后怎么去判断有没有问题，我们可能需要去结合业务做一些业务异常的理解，我们这里会使用一些 AI 的算法去理解页面内容来识别业务相关的一些异常。

（1）真机自动化测试

首先会跟大家讲一下真机自动化测试的一个框架，它主要分为服务端和客户端两部分。

服务端首先就会有任务的调度和设备的调度，那我们现在每天大概会有 30 多万的质量检测的任务量会需要通过任务去调度，而我们的设备有三种主要的资源：真机、模拟器、虚影机。

这几种不同的资源需要通过我们的设备管理，去动态分配，包括结合我们的调度，把任务分配到不同的渲染引擎上去，所有这些有一个渲染引擎的决策和切换这样一个模块，去负责使用不同的执行成本的设备去执行任务。

而在客户端我们可以看到，虚拟机和真机是比较像的，所以我们会统一使用我们蚂蚁自研的叫 Totoro 的框架，主要作用就是驱动我们的真机设备去完成自动化的执行这个层面。

而我们的模拟器更多的其实就是一个前端的一个渲染，所以它驱动引擎是不一样的，它是用 JavaScript 驱动去实现的。

关于操作路径的问题，那我们在测试的过程中，除了遍历等方式，我们还会一些自动化的手段，比如说一个小程序到了一个页面上之后，我下一步应该做什么，会有一个决策的一个链路来实现，那这一块的话我们也会跟服务端有交互，会把当前页面传到服务端，让服务端去分析你下一步应该点什么，所以服务端会有一个业务链路预测的这样一个模块。

而在执行端我们把整个测试做完之后，会把这个执行的过程的截图、日志甚至录屏数据回传到服务端，然后用服务端去判定这一次测试有没有问题，发现哪些问题，那么从整体的量上来看，我们每天 30 万的这样一个任务量，稳定性能够达到 99% 以上。

那么提升稳定性的主要的方式，第一块就是我们的任务调度和设备分配，产生稳定性的主要的问题其实大部分还是在硬件或者说设备这个层面，所以我们在设备的管理这一块会结合调度，在任务分发前会先检测设备是否处于一个可用的状态，设备可用之后，我们才会把这个任务调度上去。

此外，我们在调度上面还有一些重试的逻辑，比如某一个模拟器跑任务失败了，那我们可能会用真机去再重试一次，如果真机重试失败了，我们可能会换台设备去重试，来提升我们任务的整体的稳定性。

另一个是我们的设备使用率，因为我们每天跑的任务量很大，那为了有效提升设备的资源，我们会很关注设备使用率这样一个指标。怎么去提升设备使用率，这块的话首先是在硬件层面我们的真机资源比较稀缺，那我们会去使用相对比较稳定的真机设备的类型，比如会使用安卓原生的系统为谷歌类型的这种系统的手机去跑真机测试，然后我们在运维层面我们的硬件设备都是蚂蚁自研的这样一套硬件的技术，以此提升整体设备的稳定性，从而提升设备使用效率。

（2）定义操作路径

那么我们使用真机自动化技术，去驱动众多设备执行测试，那到底测什么，我们提供了 3 种不同的操作路径来匹配不同的业务需求：

A.最常用的就是编写验收用例，它比较适用于像健康码、场所码等等这种动线比较简单的单一场景，那当然它也有缺点，就是我们需要有人去维护这个用例，所以这块是有比较大的人工成本在里面。

B.第二种就是遍历，对于一些没有固定动线的这种场景，我们通常会采用遍历的方式去测，比如这个小程序打开之后有很多的组件，那我们会一个一个的去遍历，当然遍历 1 层或者两层判断它有没有问题，我们会把遍历过程的数据记录下来，那么这个使用场景也比较广泛，主要针对的就是各种各样的我们没有精力去一个个编写动线用例的一种场景。

C.第三种是智能动线，也是我们目前在探索和实践的。以为遍历的缺点也很明显，它的耗时会非常长，没有目的，效率会比较低，因此我们在尝试把 AB 两种方式去结合起来，采用深度学习或者一些 AI 的算法去预测用户的行为，从而能够自动的生成一些动线。比如说，一个页面上有很多可点击的元素，我们会通过算法计算哪一些元素是用户比较常用的，我们会把算法推测出来的，这样一些链路自动生成动线，以此来节省操作路径的耗时，通过动线能够精准发现问题。