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  ----------

百度架構師

百度官方技術公衆號上線啦！

技術乾貨 · 行業資訊 · 線上沙龍 · 行業大會

招聘信息 · 內推信息 · 技術書籍 · 百度周邊

歡迎各位同窗關注！