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

一、整体背景

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

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

为了更好的实现这两方面的指标，进行了如下的百度小程序生态品质保障体系的建设：

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

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

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

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

1. 百度小程序自动化遍历能力：通过各种遍历算法，获取小程序检测的必要信息
2. 页面异样检测能力：对采集到的小程序相干信息进行自动检测
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. 色调剖析：剖析图像切分失去的每个元素区块的噪点信息，色彩信息，用于后续辅助判断区域的类型。同时，也防止下图这种图片中含有文字的状况，对构造树的生成带来烦扰。

5. 元素属性断定：联合区域的文字信息，图标信息以及色调信息判断元素区域的类型。
6. 元素聚合：将切分较为系统的本属于同一个元素的多个文本区域聚合为一个残缺的区域。
7. 区块划分：区域划分直线将图片划分成若干个独立的性能区域。
8. 页面构造树生成：联合后面失去的一系列信息剖析生成一个可能代表以后页面构造信息的 JSON 构造体。

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

第三步：在页面构造树的根底上，联合每类控件的特色进行重点控件辨认。

简略举例如下：

1. 利用区域内元素品种散布和元素间绝对地位关系进行文章列表类控件的辨认：

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

3. 利用 OCR+ 元素特色，发现如果页面底部区域呈现等距反复的元素，且图文构造高度类似，则判断为是底部 tab 控件：

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

这一步骤的次要起因是：

1. 页面构造树能力在非纯色背景图片下的局限性；
2. 通过 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%+，更好的保障了这些流动的发展。

举荐浏览

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

浏览原文：https://mp.weixin.qq.com/s/NP…

———-  END  ———-

百度架构师

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

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

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

欢送各位同学关注！