揭祕百度智慧測試在測試自動執行領域實踐

上一篇，介紹了測試活動測試輸入、測試執行、測試分析、測試定位和測試評估五個步驟中測試輸入智慧化研究和實踐，包含異常單測生成、介面用例生成、動作集生成等研究與實踐。本章節重點介紹測試執行環節的智慧化實踐。測試執行是指將測試生成的用例集、資料集利用手動和自動化的方式對這些集合執行，測試執行本質上不能提升揭錯水平，但如何高效穩定的執行完測試集合也是影響測試效果的關鍵。

測試執行智慧化通過將資料、演算法、工程等相關技術有機結合，一般包含測試用例推薦、測試流量篩選、測試任務排程、智慧構建、執行自愈等方面，在學術界和工業界均有非常優秀的研究和實踐。方法論上一般包含基於覆蓋率相關性選擇演算法、基於資料建模或兩者結合的方式。本章節將從多個實踐的角度，介紹相關領域的目標、思路、涉及到的技術點、效果，希望能給到大家一定參考。

01 基於風險的手工用例推薦

測試執行，因為程式碼變化、環境等因素，往往不需要執行全部的用例，如何在用例全集中找到最有可能揭錯的用例，是本方向的研究領域，也是業績研究最多的領域。

手工測試用例推薦主要指通過程式碼變更推薦出關聯手工用例，一個關鍵目標是希望能精選覆蓋度高的用例組合，儘早發現問題。直接使用程式碼覆蓋率關聯推薦，會出現公共函式關聯的多個用例將被冗餘推薦，執行效率低，也不利於問題的及時發現。因此引入基於風險的手工用例推薦，優先根據風險程式碼推薦用例，更為精準。首先，數字化度量程式碼，將程式碼抽象為語法樹，抽取了程式碼環路、分支信等21個可以反映設計複雜度和程式開發難度的指標；其次，選取合適的模型進行推理，獲取針對程式碼的有缺陷預測和無缺陷預測，獲取關聯的用例；最後，排序去重，選取預測有缺陷的結果和無缺陷中重要程度比較高的用例作為推薦結果。其中，缺陷推理可使用貝葉斯分類、SVM、KNN、邏輯迴歸等演算法，也可以向深度學習轉移，結合長短期記憶模型（LSTM）和深度神經網路（DNN）進行缺陷預測。落地該方案後，用例推薦比持續下降由50%壓縮到20%，迴歸天數由3天降低到1天，推薦發現bug的用例比例持續提高。

02 基於並行覆蓋率的流量篩選方案

在測試過程中，經常會遇到利用線上流量對系統進行diff、效能和壓測，如何從線上海量的流量選取最合適的流量進行測試，是本課題研究的關鍵。

並行覆蓋率的流量篩選方案，是為了能夠從海量的線上流量中，找出覆蓋最多測試場景較小的流量集，從而達到測試覆蓋場景，減少問題的漏出，保障系統的穩定性的目的。在傳統場景下，通常不可能把線上全流量的資料照搬到線下，因為量級太大，所以會有一些篩選方案；最常用的就是根據機房、時間等屬性隨機抽樣，儘量提升抽樣的覆蓋面，但是這樣隨機性太強，不確定最終業務和場景的覆蓋面。基於並行覆蓋率的流量篩選方案主要在覆蓋率的指引下，儘量減少流量的量級，提升業務的覆蓋。主要分為兩個步驟：通過對源日誌進行分析，進行流量初篩，經典場景有通過裝置，地域，使用者屬性等，篩選可以覆蓋這些場景的最小集，在第一步可以通過日誌初篩出大部分有意義的流量。第二步通過對於發壓流量的覆蓋率進行分析，使用貪心演算法，針對不同流量的覆蓋率進行分析，通過儘可能少的流量覆蓋儘可能多的場景。以上兩點，可以從業務實際場景和覆蓋率兩個方面結合一起提升流量篩選的覆蓋面。目前已經多個產品線和模組應用，在覆蓋率無損，甚至提升60%前提下，流量縮減了一半，提升效率的前提下也保證的流量的覆蓋。

03 智慧構建

智慧構建致力於在靜態CI任務編排中動態執行任務，實現任務精簡、任務跳過、任務取消、結果複用、自愈、自動標註等功能，保障測試任務高效穩定構建完成。在日常的變更中，可能經常遇到以下場景：

1、變更僅修改了日誌、格式或不重要的一些功能，這時是否有必要回歸全量測試任務；

2、程式碼反覆迭代，同一任務執行多次是否有必要；

3、同一次任務在分支和主幹階段是否有必要重複執行。

傳統做法是執行全量任務，但會導致測試構建效率低，資源消耗大。

利用智慧構建就可以根據變更場景動態調整構建任務，有效縮短構建時間，提升構建效率。具體來說，智慧構建可拆分為分析和決策兩部分，分析是針對業務程式碼庫，以及本次變更(如git diff)，利用工具算出進行本次變更的特徵分析(變更程式碼行數、變更程式碼的具體函式、變更程式碼的呼叫鏈資訊等等)；決策任務是否執行/等待/重啟/取消等行為，做出最終的決策，比如業務設定業務相關的的白名單，若分析特徵全命中白名單則可跳過指定任務；智慧構建是在保障測試用例揭錯能力的前提下，利用有限的資源滿足使用者對時效性的需求。目前百度已建立包含策略開發、外掛方、業務線在內的智慧構建體系，其中策略開發者按照構建系統介面規範開發策略，並將策略註冊進入構建系統，構建系統開放策略給業務方使用；外掛通過構建策略進行響應操作，如無效任務的取消執行、偶發任務的自愈、流程管控任務的攔截等；業務方則通過構建系統進行流水線上策略的配置；目前智慧構建已輻射3000+個模組。

04 基於任務優先順序的演算法排程

本方向研究的是如何在有限的資源情況下，根據穩定性和揭錯能力排程測試任務。

在測試執行階段，在有限的資源下大量的並行測試任務排程困難，由於使用者感知的等待時間是所有測試任務的排隊時間和執行時間，不合理的測試排程會導致測試效率的低下。因此探索一種基於任務優先順序的演算法排程策略用以解決上述問題。

在移動端測試中，針對大量並行任務提交，建立任務優先順序佇列。根據任務重要程度，等待時間，資源需求，生成了有益於降低重點任務排隊時間的優先順序公式。基於公式分析結果，優化測試任務排程。在保證平均排隊時間的情況，降低重點任務的平均排隊時間。

針對單個case任務的執行效率，最初我們基於離線歷史任務分組的時長，單位時間覆蓋率等資料，尋找最優收斂點用以預測任務的最佳停止時間，優化測試任務執行時長。效果上，核心產品線在覆蓋率，問題發現數量未退化的情況下，執行時長縮短了10%，但仍存在無法感知任務實時狀態問題，因此在此基礎之上，建立停止決策模型，通過實時監控任務的執行情況，基於執行時間，截圖數，測試控制元件覆蓋變化率等特徵，實時決策任務是否可達到停止狀態，並識別出執行效果不佳的任務，提前終止，降低無效執行的耗時。在優化效果上，在測試覆蓋率提高10%的同時，執行時長減少12%。

05 UI自動化自愈

App自動化用例在執行過程中，上下文環境會遇到各種非預期的複雜情況，如，App觸發升級彈窗、頁面載入緩慢出現白屏、頁面xpath路徑變更等。現有自動化執行機制，不具備處理這些異常邊界情況的能力，導致Case執行中斷而失敗。這些自動化穩定性問題，帶來自動化用例維護成本的增加，大大降低了自動化工作的ROI。我們分析現有自動化任務top失敗原因，使用3類通用Case執行自愈技術，提升case執行穩定性，降低維護成本。

1、異常彈窗處理，當自動化執行遇到彈窗而失敗後，使用彈窗檢測技術去除彈窗後繼續恢復執行。面對彈窗種類多樣的難點，使用物件檢測技術，實現泛化的彈窗及彈窗關閉控制元件的識別；面對不同語境下推薦動作不一致難點，利用基於頁面文案進行彈窗分類的技術，實現不同場景下的彈窗都能夠被準確理解，並推薦正確動作去除。

2、原子等待技術，自動化執行過程中的非同步載入等待技術屬於領域裡公認技術瓶頸，我們利用視覺UI理解技術，在Case執行過程中，使用高效的影片流並行採集，以及影象識別演算法對連續圖片分析，實現頁面穩定態和非穩定態的智慧判定，指導Case實時的智慧延遲等待和智慧縮短等待時間，保證Case穩定高效執行。

3、通用Case自愈技術，提供基於時空上下文的Locator，去彈窗，影象等識別方式按順序進行識別自愈，具體來講，將歷史執行成功時刻的xpath，icon圖片等資訊記錄下來，當出現失敗時，嘗試用歷史成功過的元素型別依次進行重試。

通過以上Case執行自愈的技術，在我們自動化執行實踐過程中，實現了51%的Case自愈修復效果，有效提升自動化用例執行穩定性。

推薦閱讀【技術加油站】系列：

揭祕百度智慧測試在測試自動生成領域的探索

【技術加油站】淺談百度智慧測試的三個階段

【技術加油站】揭祕百度智慧測試規模化落地