AI技術在基於風險測試模式轉型中的應用

基於風險驅動的交付是百度實踐智慧測試--感知智慧階段非常重要的研究方向，基於風險驅動的交付，源於三個現狀：

透過上訴三個現狀，可見如果能夠有方法逼近：測該測的專案、評風險評得準，那麼對測試效能和召回都有極大的幫助。

本文先介紹第二篇：AI技術在基於風險測試模式轉型中的應用。

在測試內部有一個比較有趣的“Q3”現象， 每年Q3是業務線上問題頻發的時間節點， 究其根本原因：除Q3是每年需求交付量較多多，倒排期多等原因， 另一個重要原因是：校招新人開始大量參與專案研發和測試，可能會出現線下和線上質量問題較多。

另外還有一個常見現象與之類似，即公司架構調整， 業務交接， 人員調整之後，線上問題也會高頻發生。

這兩個導致問題頻發的現象，表面是人員流動帶來研發測試同學對業務不熟悉，流程規範落地在團隊中衰減等原因造成，但問題的本質是什麼呢？我們試著從測試過程角度分析軟體專案整個交付過程，列舉新人/業務交接後需要面對的問題。

透過分析，不難看出研發測試過程受人的主觀因素影響太大，即研發測試人員的個人能力、經驗，對專案的交付質量和效率有很大影響，人判斷不準確和執行偏差導致上面2種現象不斷重複。

為了減少或避免此類問題，我們試著引入基於風險的全流程智慧決策，提高機器決策佔比，從而用較小代價完成測試任務，減少對人能力、經驗主觀依賴，整體提升決策水平和召回能力。思路如下：

基於這個思路， 我們做了如下方案設計：

首先，構建類似大腦的智慧決策系統，這個系統可以支援知識、工具的結構化註冊，觸發引擎，任務執行排程，互動反饋。但只憑該系統整個生態是無法運轉起來的。我們需要從歷史專案中，採集並結構化我們的經驗、業務知識、方案、工具能力等相關資料。以下是幾個較為經典的決策場景：

對於刷庫， 資料遷移， 報表， 小流量， 聯調等特定場景相關的需求，其對應的子系統一般都有對應的處理邏輯（經驗），如若存在小流量，是否隻影響web層，還是會影響api和第三方，經驗少的產品（經驗多的也會）經常會漏相關需求評審。特別地，1.0大專案會有特殊的上線流程，要求更完備的測試方案。對於新人，即使文件組織得再好，這些碎片化的知識、經驗，也很難被看到並在需要用到時能識別出來，丟失或衰減是大機率事件。

此外，大量開發好但散落在各處的資料構造指令碼，無法被大規模複用，其價值也就不能被最大化發掘來，可能出現重複造輪子。若這些指令碼支援的場景或介面可以結構化註冊，當相關場景(介面)升級時，就可自動推薦相關指令碼工具給使用者複用。

同理，環境或測試平臺的自檢自愈， 問題定位， 專案風險識別等能力都可以沉澱為這個智慧交付生態能力項。

有了這些基礎能力儲備，當增量專案進入研發階段時，可以透過工具鏈實時資料採集能力，對專案進行精準刻畫，抽取需求，開發，測試，上線各個階段專案特徵進行建模，智慧決策系統對專案建模進行實時評估決策，將計算結果按不同的場景進行決策，分發，同時將決策結果透過反饋系統實時通知到專案人員。

當然，智慧交付系統建設不是一蹴而就的，需要在系統線上化的基礎上，實現專案交付的數字化（具備實時資料採集能力，尤其白盒），有簡單、易用的閉環系統可以將碎片化的業務，工具指令碼等結構化入庫，環境和自動化等能力具備高可能性，這些都是引入智慧決策的系統基礎。

在需求評審階段，首先需要面對的是誰來跟進專案測試問題。在專案交付過程中，業務介面人需要花費大量的精力來review需求，與產品、研發溝通，透過對需求大小、複雜度、風險判斷，結合已有的專案排期人力分配情況，確定將新增專案分配給哪個同學，費時耗力。

為解決這個問題，我們首先基於歷史資料，構建測試的人員畫像，如該同學角色劃分（是外包，正式，業務測試還是專項測試同學），經常對系統某A功能進行測試，或經常與某RD搭配進行專案交付，測試同學大專案的交付經驗，測試任務分配型別（如手工， 自動化，效能測試等），測試質量和效率等等。當新需求提出評審時，可以實時提取專案特徵，如需求特徵標籤，卡片關鍵欄位資訊，專案型別特徵，研發同學畫像，程式碼，配置或詞表變更等資訊，對專案進行實時專案建模，再結合人員畫像，空閒係數等資訊決策，實現測試專案的分發，即專案是否可以完全自動化，是否需要引入眾測， 是否可獨立分發給外包，或外包正式搭配， 是否引入專項測試等決策，大幅減少業務線介面同學在高頻的專案review，溝通中的成本，也能提升機器決策水平。

到測試階段，通常要先與研發同學共同確認測試方案和測試範圍。測試方案，如前面提到對於刷庫， 資料遷移， 報表， 小流量， 聯調等特定場景相關的需求，其對應的子系統一般都有對應的處理邏輯（經驗），而經驗很碎片化，丟失或衰減是大機率事件。

對於測試範圍評估但面臨的問題是——評估不準確，要麼少評估，導致漏測，影響質量；要麼多評估，做不必要的迴歸，影響研發效率。

針對測試方案設計，我們可以透過離線挖掘針對不同業務、場景專案資訊，把需求關鍵字資訊標籤化，從需求卡片抽取關鍵資訊，同時獲取人為標註補充資訊。結合針對當前場景、特徵採取的有效措施和經驗、風險預案、工具指令碼等，形成一套完整的知識庫。當新增專案分配時，基於專案特徵，關鍵字資訊推薦適合的測試方案，風險點處理預案，工具指令碼，從而實現知識，經驗的傳承。而非靠人的能力和經驗去消除潛在的專案風險。

針對測試範圍分析，非常重要的是根據改動程式碼評估出複雜的測試範圍。對於後端來說， 可以離線獲取方法間、模組間、系統間的呼叫關係鏈路；對於前端元件化開發，可以透過離線獲取元件間、元件頁面間的呼叫關係，獲取完整的元件呼叫關係，有完備的方法呼叫鏈或元件呼叫鏈關係，當底層程式碼發生變更時，我們便可以透過這個鏈路關係反查到，底層方法會對哪個介面或第三方或頁面有影響，便可以建議測試同學精確迴歸相關介面和頁面，防止漏評估或多評估迴歸。

在測試執行階段，持續整合是專案高質量交付的迴歸場景下提效的重要手段，減少大量的無效任務或無效用例，篩選能發現問題的任務，是我們的核心目標。比如RD只增加了日誌列印邏輯方便問題定位，便無差別的執行流水線上所有的安全掃描，靜態程式碼掃描，壓測，前後端自動化等任務；亦或只修改了1個方法做bugfix，流水線無差別執行全量的後端自動化用例。無論從任務還是用例層級，這種無差別的執行，一是會導致執行效率大幅下降，二是會帶來非常龐大的排查維護成本，持續整合帶來的ROI可能是負向的，這也是持續整合在很多公司無法成功被質疑的重要原因。針對這個問題，我們分別在任務和用例層級進行改進。

在任務層級，透過進行流水線模組，腳手架配置，測試能力外掛化，執行容器池化等基礎能力建設，當RD有程式碼提交，基於白盒分析，動態建立流水線，只建立需要執行的任務，並智慧排程容器資源池，提高測試任務併發度，動態執行建立測試任務。

在測試用例層級，也是基於程式碼，配置變更以及離線收集用例程式碼對映資訊庫等輸入，對前後端，手工用例進行篩選，去重，並做組合排列，將要執行用例集合在有效的前提下，降到最小。這樣便將任務和用例2個層級無差別執行轉換為按需執行，提升執行效率的同時，大幅提升持續整合的穩定性，減少大量的排查維護成本。

透過任務和用例2個層面最佳化，在任務無漏觸發，用例無漏篩選的情況下，業務級將任務執行次數減少2/3， 用例執行量級縮減為原來10-50%，全量自動化用例4000+的情況下，任務穩定性達到85%以上，同時任務執行效率也有大幅提升，從原來90分鐘縮減到30分鐘以內。

在測試執行過程中，測試同學尤其新人或外包會遇到各種各樣的問題，這些問題基本上是圍繞測試環境的問題來展開的，如環境不通， 或某介面依賴的第三方服務不穩定， 依賴redis，mysql等中介軟體連線失敗，甚至要確認該問題是否是bug, 都需要做各問題定位，對外包或新人來說有較高的門檻，因為問題排查造成阻塞、測試低效的主要原因。

同樣地，問題排查的經驗尤其是常見高頻的問題，也是可以沉積積累下來，可以將這些排查的過程，思路， 問題現場做一層規則抽取，抽象成不同維度的問題定位規則庫，拆分為業務層規則，中介軟體層規則，pass層規則，例項層規則等，以完成經驗或知識沉澱。當出現新問題， 用這些規則為基準、知識， 檢測當前環境中可能存在的問題，結合對被測環境實時採集的程式碼變更，配置詞表變更，部署資訊，日誌，trace等各種資訊的實時採集，然後將不同維度多個問題做優先順序排序，merge, 形成0/1化結論，反饋給使用者。若系統中對於這個結論存在對應的恢復策略，觸發對應的恢復策略，以減少各種排查，溝通成本，最大程度減少人的介入。

最後到專案準出和上線階段，圍繞不同規模專案的測試執行效果和風險評估，一般會遇到下列場景：

網際網路金融有可以借鑑的場景：貸前稽核環節藉助大資料風控模型，對貸款人基礎資訊，網購，支付等資訊進行更全面細緻評估，來替代原銀行漫長的表單提交+人工稽核模式，在大幅降低違約風險的同時，提升稽核效率。類似地，針對不同專案(貸款人)想到快速達到準出（無違約風險）標準並上線，也可透過獲取專案各個維度資訊（貸款人資訊），選取合適模型（風控模型）對其進行更加精準客觀的評估，以達到快速交付的目的。

基於以上思路，我們在測試準出階段引入專案質量度。將歷史交付資料，以專案維度聚合專案涉及的模組，程式碼，分支，測試覆蓋，bug，專案狀態等基本資訊，這些資料一部分透過公司通用研發工具鏈進行採集，測試覆蓋相關資料透過被測環境採集，有了這些基礎資料，再透過特徵工程，對基礎資料做缺失異常值處理，資料分箱，歸一化，用歷史資料訓練質量度模型，達到可用標準後部署應用。這樣當增量專案進入研發階段後，線上化一站式平臺可實時收集當前專案特徵資料，在收集到模型需要專案特徵後請求策略中臺，獲取打分結果和報告，在人工確認並標註後，同時也可將增量專案樣本推送到資料中臺，用標註資料分迭代最佳化模型。

目前專案質量度已在百度內部大範圍落地，

質量：2022Q3共識別1123個不可準出專案，共攔截318個bug；

效能：2022Q3共轉化4345個自主測試專案，約節省2172人天；可自測專案評估等待時間得到大幅降低：從50H降到2H。