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

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

1、总体背景

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

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

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

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

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

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

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

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

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

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

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实验室提供的基于图像的页面结构树逆向生成技术。大体步骤以下：

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

![图片](/img/bVcQUaj)

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

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

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

简单举例以下：

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

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

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

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

这一步骤的主要缘由是：

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

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

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

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

第六步：落地。

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

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

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

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、百度小程序真机集群建设

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

总体的机房结构以下：

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

5.1 机房1.0时期

在1.0机房时代，总体主要采用了大量多机型真机来进行机房搭建，以知足最基本的业务需求。优势是能够进行多机兼容性检测的能力输出，可是同时因为不一样机型手机的运维方式不尽相同，所以这时的机房主要采起人工运维的方式进行。

5.2 机房2.0时期

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

5.3 机房3.0时期

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

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

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

6、业务效果

最后简述一下业务效果：

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

推荐阅读

｜[](http://mp.weixin.qq.com/s?__b...百度智能小程序框架性能优化实践

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

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

百度架构师

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

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

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

欢迎各位同窗关注！