导读：为了挖掘线上全量百度小程序的红线问题，保障线上生态和用户体验，提高审核效率同时发现一些人工审核难以发现的问题，百度小程序QA进行了百度小程序线上质量保障体系的建设。在建设过程中，研究并落地应用了很多AI相关的技术。本文将以百度小程序线上质量保障体系为切入，从百度小程序的智能遍历能力、页面异常检测能力和云真机集群建设三个方向展开，分享相关能力的建设思路和AI技术的落地方式。

一、整体背景

百度小程序的整体业务拥有数量多、宿主多、分发场景多三大特点。几十万内外部小程序运行在数十个开源宿主联盟APP上，每个宿主APP都有特定的分发方式和场景。这一系列业务特点给QA的质量保障工作提出了更高的要求。

在整个业务当中，QA所扮演的角色主要分为对内和对外两个方面。对内首先在业务快速迭代的节奏下，进行小程序开源框架的质量保障。同时，对内部的自研小程序进行智能交付能力的建设。对外保障线上小程序的整体质量，降低线上红线问题。同时参与小程序权益等级建设，为小程序分发助力。

为了更好的完成这两方面的目标，进行了如下的百度小程序生态质量保障体系的建设：

本文将以线上小程序质量保障体系为切入点，简单介绍AI技术在小程序生态质量保障方向的落地实践。

二、百度小程序线上质量保障体系

整个百度小程序线上质量保障体系的目的是为了挖掘线上全量小程序的红线问题，保障线上生态和用户体验，提高审核效率同时发现一些人工审核难以发现的问题，因此提出了一套自动化、智能化的方案：

整套流程当中，上图红框圈出中的小程序信息自动采集、智能检测的流程，显然是整套保障体系的核心和关键。为了实现这个流程，需要建设：

百度小程序自动化遍历能力：通过各种遍历算法，获取小程序检测的必要信息
页面异常检测能力：对采集到的小程序相关信息进行自动检测
集群化：用以解决线上大规模并行巡检的手机资源问题

本文接下来的分享，也将由这三个方向展开。

三、百度小程序自动化遍历能力的发展历程

3.1 建设基础：百度小程序自动化测试引擎

建设百度小程序自动化测试引擎主要是为了获取小程序自动控制能力，采集小程序的运行时信息。在分析百度小程序的内部机理的基础上完成了测试引擎的建设。

如图所示，betterAutoTest测试引擎由三个部分组成：

Bat Engine：测试引擎核心代码，通过热加载开关，动态注入到小程序运行时框架，用于同 Bat Agent 建立双向通信，并透出小程序的各项操控能力
Bat Agent：WebSocket Server，部署在 PC 本地，集成端操控实用工具，并同 Bat Engine 建立双向通信，提供多设备多小程序同步控制能力
Bat Driver：Client Lib 库，提供易用的 API，支持 NodeJS 引入使用，开发者无需关心底层通信细节，便可以编写操控小程序的用例脚本

引擎提供支持4端（真机、开发板、云手机、web化）+全部联盟宿主 APP上小程序的操控，遍历脚本、测试用例一处编写到处运行。自动化测试能力覆盖度达 90%，单指令耗时 100ms，经1000w+ 次云端任务执行统计，稳定性 99.9%。同时，在部署方面，仅4 步即可完成环境准备工作，支持多真机多小程序同步操控。

3.2 初步探索

随着巡检、预检等业务的进一步开展，通过对业务数据的分析，发现70%以上的问题都出现在非首页中，因此小程序深度遍历的需求被提上日程。说起遍历，自然而然第一时间想到的APP的自动化测试技术，在调研了业界常见的自动化测试技术之后，大体将其分为了三类，一类是monkey类的随机遍历，一类是基于历史信息的用户行为预测，还有一类是基于目标识别的控件识别遍历，因此也开始了探索的历程。

第一阶段，采用了monkey类的随机遍历，主要原因是这类方案在业界应用广泛，而且简单高效易实现，能够快速的应用到业务中去，收集效果。主要方案是通过百度小程序测试引擎，获取小程序的运行时dom。然后通过解析dom，获取含有点击属性的控件，再依次点击这些控件，进行深层的遍历。

落地业务之后，却发现了问题。随着页面深层遍历的开展，同一业务，需要的运行设备数量和任务的执行时间都有大幅增长，然后发现问题的数量和深层页面异常检测的准确率都没有达到预期。针对这一业务现象，进行了初步的问题分析，发现落地业务之后，根据dom进行的monkey随机遍历存在页面跳转率低，无效点击多的情况。造成这一现象的主要原因是因为小程序线上环境复杂，外部开发者的一些开发行为不可控。

为了解决阶段一遇到的问题，开始阶段二的探索，主要是规避dom带来的问题，基于历史数据的用户行为预测。这一方案的优势是基于页面截图和用户历史数据，避免不规范开发带来的干扰。大体流程是通过插桩打点等方法，采集内部审核同学在审核过程中的行为数据和内部自研小程序QA通过在测试过程中的测试行为数据作为训练集，在此基础上，进行相关神经网络的搭建和模型训练，之后使用模型对输入的小程序页面截图进行可点击区域的预测，以此为依据进行深层遍历。

这部分没有展开的主要的原因是，用这种方案确实可以解决阶段一过程中页面跳转率和有效点击率较低的技术问题，但是仍然没有解决之前提及的发现问题的数量和深层页面异常检测的准确率没有达到预期的业务问题。对此进行了更进一步的业务分析，最后发现，小程序巡检、预检等一系列业务，并不能完全等同于APP的自动化测试。

以下列举几个差异点的例子：

从以上分析可以看出，在小程序线上质量保障体系这个具体的业务场景，无论是审核同学还是都应该更加关注每个小程序的重点控件和场景是否可以正常运行和使用，而不是全部的细节，因此也改变了方案，最终采取了对『全量小程序进行重点控件和功能的识别监控』和『对重点/内部小程序，采取录制case，巡检回放』的方式进行质量保障。本文主要通过对前者的简单描述来分享小程序智能遍历的第三阶段：从实际业务出发，基于目标识别的控件识别遍历。

3.3 最终方案——从实际业务出发：基于目标识别的控件识别遍历

整个实践的步骤如下展开：

第一步：重点控件/功能选择。

这类控件和功能场景主要的选择的依据来自于，运营同学制定的《线上红线问题标准》和分析审核同学人工驳回、下线的驳回原因，最终确认哪些控件和功能是需要进行重点识别的。

第二步：有了需要识别的目标之后，接下来就是通过技术手段进行实现。

在技术选择上，首先思考了，作为一个用户，他是如何感知这个小程序页面哪些区域是可以操作的，从调研来看，用户往往是根据控件的位置、文案、页面结构、区域特征、历史经验等等来进行判断的。这些信息的获取，对应QA内部uicheck实验室提供的基于图像的页面结构树逆向生成技术。大致步骤如下：

图像切分：利用像素扫描识别出图片内内容元素的边界。
文字识别：利用OCR技术识别出图片的的文本内容，包含文字内容以及每个文字的坐标信息。
图标识别：利用对象检测技术识别出图片内的图标信息，包含图标的类型以及对应的坐标信息。
色彩分析：分析图像切分得到的每个元素区块的噪点信息，颜色信息，用于后续辅助判断区域的类型。同时，也避免下图这种图片中含有文字的情况，对结构树的生成带来干扰。

  

![图片](/img/bVcQUaj)

元素属性判定：结合区域的文字信息，图标信息以及色彩信息判断元素区域的类型。
元素聚合：将切分较为零碎的本属于同一个元素的多个文本区域聚合为一个完整的区域。
区块划分：区域划分直线将图片划分成若干个独立的功能区域。
页面结构树生成：结合前面得到的一系列信息分析生成一个能够代表当前页面结构信息的JSON结构体。

△页面结构树生成过程示意图

第三步：在页面结构树的基础上，结合每类控件的特征进行重点控件识别。

简单举例如下：

利用区域内元素种类分布和元素间相对位置关系进行文章列表类控件的识别：

利用元素分布特征，发现存在的上方是图片，下方是文本且文本带有价格元祖，则判断为是商品卡片类控件：

利用OCR+元素特征，发现如果页面底部区域出现等距重复的元素，且图文结构高度相似，则判断为是底部tab控件：

第四步：在基于页面结构树控件识别之后的还引入了深度学习技术。

这一步骤的主要原因是：

页面结构树能力在非纯色背景图片下的局限性；
通过step3完成了深度学习模型需要的训练集的自动标注，再结合step上线后，采集到的badcase进行人工标注样本，将两类样本相结合进行训练得出的模型可以对原有方案进行补充召回。在选型方便，调研了业界常用的一些目标识别的算法。

最后采用了YOLO V3，进行了模型的训练，得到了不错业务效果：

第五步：从单个控件到场景化的扩展。

随着业务的不断深入，在控件识别的基础上，进行指定场景的判断和遍历。例如登录场景，先是判断页面是否有进入登录场景的元素，再到是否有登录的button，再到点击后跳转的页面是否正常。

第六步：落地。

这部分相对比较常规，主要的遍历的模型都放在云端的策略中心，和遍历脚本之间通过网络通信交互。

以上简单的介绍了百度小程序线上质量保障体系中小程序遍历能力的一个发展历程。通过小程序遍历，可以采集到很多需要的小程序信息，比如截图、dom等等，有了这些信息，接下来需要做的就是对这些信息进行异常的检测。

四、百度小程序页面异常检测能力建设

4.1 简介

百度小程序页面异常检测能力的建设的背景和目的主要是为了辅助或者部分代替人工，自动化的识别和检测遍历采集到的页面中的红线问题、异常问题以及体验问题。目前检测的对象主要包括小程序的页面截图、页面文本、运行时dom和小程序源码。用到了包括计算机视觉、自然语言处理、源码检测在内的一系列技术。

以下是部分能力一览：

因为数量较多，就不一一展开，本文主要选择了一个比较有意思的策略进行分享。

4.2 百度小程序页面异常检测典型能力介绍之一——截图比对能力建设

4.2.1 问题简介

无论是录制回放还是下文会提到的小程序质量档案系统，都需要比较同一个页面的当前截图和标准截图或者历史截图是否有偏差和改动的能力。然而由于多次截图的设备不一定是同一台设备，不同品牌、系统、分辨率得到的截图，在使用传统的图片相似度算法时，发现会存在一定的无法同时兼顾业务准召率的问题：

传统相似度算法存在误报的典型类型有以下三类：

1. 页面元素多，页面内容相似，但各机型分辨率不同，传统算法度量结果为相似度低：

2. 页面元素少，有效特征较少，页面结构不相似，传统算法度量结果为相似度高：

3. 存在弹窗，内容和结构明显不同，传统算法度量结果为相似度高：

4.2.2 解决方案

整体解决思路是结合创新图片相似度算法和页面结构树的能力，来进行智能实现图片相似度判断。在图片相似度比较方面，采用深度卷积神经网络提取特征向量来进行相似性度量。该方法提供了拟人化的相似性度量，如下图特征图可视化，相似图片在特征维度上具有相似的，可类比的变化。

同时，为了解决动态元素干扰，从结构相似度入手，使用了前文提到的页面结构树技术实现相对位置检查，这里就不再赘述。

4.3 百度小程序页面异常检测典型能力介绍之二——泛白屏问题检测

4.3.1 问题简介

在分析小程序人审驳回和下线小程序原因的时候，发现出现最多的词可以就是『白屏』了，比如小程序存在XXX页面白屏/存在白屏/出现白屏/顶部区域空白等等。然而虽然都带有『白屏』两字，但是其实描述的场景并不一致。先进行了场景的细分，主要包含以下几类：

4.3.2 解决方案——初步

整体思路主要针对每类场景进行针对性的策略开发来进行识别。

全白屏/区域白屏/骨架屏：

针对这一类主要采用对原图进行区域切分，对每一区域进行色彩和图像复杂度的分析，最终得到一个页面白屏率，不同落地业务根据自身需要设置不同的阈值进行问题召回。

页面长时间加载：

针对这一类主要通过对加载中的特点图标和文案进行识别的方式进行。

部分图片加载失败：

针对页面中部分图片加载失败导致的部分白屏问题，采用了两种方案相结合的方式，一种是通过解析dom，获取页面中的图片资源列表，判断资源是否可获取。

一种是结合页面结构树的技术，识别出页面中的加载异常的图片。

4.3.3 解决方案——扩展

随着遍历的深入，也如上文所说，发现了在多级页面出现了泛白屏检测能力准确率下降的现象。造成这一现象的原因，主要是多级页场景更加丰富造成的。

举个简单的例子就是，如果一个页面的白屏率是80%，即一个页面如果80%以上都是纯色的，那这个页面一定是问题页面嘛？如果是首页，考虑到首页的定位或者功能性，那么80%以上区域都是纯色的首页，大概率是一个问题页面。但是如果是多级页，考虑到具体的功能和场景，比如没有物品的购物车、没有历史记录的浏览历史页面，这些页面虽然出现了大面积的空白，但是也是符合用户预期的，是完全可以接受的，也因此给带来了大量的误报。为了解决这一问题，主要采用了两种方案相结合的方式来解决这一问题。

第一类方案是纯技术的方案：异常策略检测的场景化。

不仅仅对页面截图进行检测，还要判断出截图页面所处的场景。场景化判断的实现主要通过两种方法。一种是根据当前页面中的一些特定判断，当前页面属于哪种场景。

比如上图就是通过一些特定文案进行的场景判断。

另一种则是异常检测策略的输入对象不光只有页面截图，还有上下文信息，即还需要知道是如何进入这个页面的。例如：

如果是通过点击购物车的button进入的话，那么当前页出现大面积的空白也是可以接受的。

第二类方案则是技术和业务流程相结合的方案。为每一个小程序都建立的独立的档案系统。因为造成误判的一个重要原因就是那个写死的阈值80%，而改进后的流程，则是每次得到检测值之后，不会只和一个固定的阈值进行比较，还会和这个页面的历史采集到的阈值以及阈值变化的趋势进行比较：

通过这两类方案相结合的方式，可以很好的规避多级页的误判情况。

五、百度小程序真机集群建设

在拥有了百度小程序的遍历能力和页面截图异常检测能力之后，接下来要做的就是建设一个能够承载以上两个能力落地的真机机房。

整体的机房结构如下：

在机房的建设过程中，也经历了多次的迭代。进行迭代的主要原因是由于小程序的数量逐步增长，希望能够拥有更多的设备来进行检测。但是一方面预算有限，一方面更多的设备意味着更高的运维成本。为了解决这一矛盾，进行了多次机房升级。

5.1 机房1.0时期

在1.0机房时代，整体主要采用了大量多机型真机来进行机房搭建，以满足最基本的业务需求。优点是可以进行多机兼容性检测的能力输出，但是同时由于不同机型手机的运维方式不尽相同，因此这时的机房主要采取人工运维的方式进行。

5.2 机房2.0时期

在2.0机房时代，使用统一的开发板来逐步代替真机，进行小程序的遍历。之所以采用开发板，一方面是因为兼容性部分根据小程序业务本身的特点，交由了别的业务线进行保障(比如最开始架构中提到的CTS业务线)，一方面也是为了不影响现有检测能力和策略的情况下，大规模部署的同时还可以控制成本。由于开发板的统一定制，机房已经可以采用半自动化的方式进行运维，但是还是免不了一些日常的人工简单维护。

5.3 机房3.0时期

△云手机运行效果图&新引擎方案

在3.0机房的时代，使用百度云提供的云手机服务来进行。根据百度云提供的服务，我们升级了测试引擎，使得不足10行代码即可自动化操控百度云云手机，所有能力同真机、开发板完全对齐。与此同时，迁移云手机之后更是使得机房设备成本大幅下降。在此基础上，更是实现了云手机相关的全自动化运维。

从以上的迭代过程来看，整体实现了机房搭建成本和运维成本均持续下降。

六、业务效果

最后简述一下业务效果：

系统承载日均各级真机检测任务量级20W+，任务执行成功率在99.3%+；
对线上全量小程序和重点头部小程序的红线问题都能及时召回，把对线上全量小程序的质量保障从不可能变为了可能。建立起小程序提审时自动预检，上线后不间断巡检的一整套线上质量保障体系，形成对线上小程序的实时全面管控；
上线以来各阶段累计发现召回的问题数量10W+，累计处理/干预的小程序数量8w+
线上部分真机自动化发现的问题当前已占全部问题召回的82%+，其中大部分的问题已经实现自动处理，无需人工干预；
支撑内部十多个专项运营活动项目的系列小程序监控，问题召回率在85%+，更好的保障了这些活动的开展。

阅读原文：https://mp.weixin.qq.com/s/NP...

---------- END ----------

百度架构师

百度官方技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢迎各位同学关注！

AI技术在小程序生态质量保障方向的落地实践