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

作者 | 韓照光

導讀 

introduction

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

一、不是所有的專案都有風險，80%以上的專案無任何的關聯bug和線上問題；

二、不是所有的測試任務都能夠揭錯，無效的質量行為（有bug發現的質量行為/所有質量行為）佔比非常高；

三、測試人員也有誤判的可能，漏測一直存在。

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

1、百度搜尋業務交付無人值守實踐與探索：從具體業務實踐的角度介紹風險評估在交付無人值守領域的關鍵作用。

2、AI技術在基於風險測試模式轉型中的應用：從測試全過程的角度介紹各環節以風險思維+AI技術加持的各種應用場景。

3、質量評估模型助力風險決策水平提升：從思路、方案和模型的角度介紹質量度模型的實現和挑戰。

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

GEEK TALK

01

背景

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

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

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

1、是需求評審階段，誰來測的問題：

• 自動化測試還是人工介入?

• 若人工介入，外包可以獨立完成還是需要正式幫助，以及具體分配給誰？

• 需要引入眾測嗎？

2、是測試階段，怎麼測的問題：

• 本次測試範圍是哪裡？

• 要執行哪些測試用例？

• 遇到問題，該怎麼解決？

3、是準出上線階段，測得怎樣的問題：

• 執行完測試活動後，被測系統是否還存在問題？

• RD自測專案，如何判斷RD是否進行有效的測試？

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

GEEK TALK

02

解決思路和技術方案

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

（1）基於專案風險特徵做任務分配、分發，最大程度提升人效，解決誰來測的問題。

（2）透過把專案經驗結構化、程式碼分析，機器決策代替人工分析，就可以精確分析測試範圍，提升測試效率同時減少漏測。

（3）透過程式碼白盒分析，用例精簡，可以較小代價，高質量高效完成測試工作。當遇到問題時，引入問題智慧定位/輔助，擬人化決策，減少人工介入頻率，降門檻，風險預警。

（4）在準出階段引入專案質量度模型，讓質量可見，從風險維度根據測試活動和變化預估專案質量風險，用客觀資料支撐準出決策。

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

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

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

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

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

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

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

GEEK TALK

03

方案實現

3.1 任務自動分發系統

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

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

3.2 測試範圍精準分析

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

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

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

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

3.3 智慧化測試，用最小代價完成測試執行

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

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

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

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

3.4 問題排查智慧定位

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

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

3.5 基於風險評估的準出

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

（1）測試範圍評估時，若只有需求變更，RD並未介入開發，評估是否靠譜？

（2）專案較小，變更相對較小並由研發自測的專案，自測覆蓋怎樣，如何度量？

（3）非自測的小專案，若RD自測充分，能否裁剪QA測試，減少重複測試？

（4）非自測專案覆蓋提前達標，能否提前準出；若測試同學覺得測試比較充分了，但到底覆蓋怎樣，有沒有風險，如何消除？

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

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

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

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

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

GEEK TALK

04

總結

本文的問題背景：如何降低專案交付過程中效率質量對人的主觀依賴，用較小代價實現高質量高效率交付。

解決問題思路：在專案交付過程引入全流程的智慧(AI)決策系統，減少對人的主觀依賴，最大程度的減少人工介入，提升決策水平，從而提升交付效率和質量。

方案實現基礎：統一研發流程並線上化，在提升效率的同時讓研發資料實時靜默採整合為可能；另外需要有極致的基礎能力建設，環境和自動化需要具備高可用性和高實效性。

突破：以智慧化測試為引領，線上化基礎上實現全研發過程數字化為引入智慧策略提供資料底座，基於不同場景建設白盒分析+模型相結合的智慧決策系統，提升機器決策在交付全過程佔比。