作者 | 劉道偉
導讀
基于風險驅動的傳遞是百度實踐智能測試——感覺智能階段非常重要的研究方向，基于風險驅動的傳遞，源于三個現狀：
一、不是所有的項目都有風險，80%以上的項目無任何的關聯bug和線上問題。
二、不是所有的測試任務都能夠揭錯，無效的品質行為（有bug發現的品質行為/所有品質行為）占比非常高。
三、測試人員也有誤判的可能，漏測一直存在。
通過以上三個現狀，可見如果能夠有方法逼近：測該測的項目、做該做的品質行為、評風險評得準，那麼對測試效能和召回都有極大的幫助。
接下來我們将持續刊登三篇文章，來揭秘百度實踐基于風險驅動的傳遞的冰山一角：
1、百度搜尋業務傳遞無人值守實踐與探索：從具體業務實踐的角度介紹風險評估在傳遞無人值守領域的關鍵作用。
2、AI技術在基于風險測試模式轉型中的應用：從測試全過程的角度介紹各環節以風險思維+AI技術加持的各種應用場景。
3、品質評估模型助力風險決策水準提升：從思路、方案和模型的角度介紹品質度模型的實作和挑戰。
本文先介紹第一篇：百度搜尋業務傳遞無人值守實踐與探索。
01 引子
提起傳遞無人值守概念，大部分人應該都比較陌生，出現下面這些疑問：
- 什麼是傳遞無人值守？
- 怎麼做到傳遞無人值守？
- 傳遞無人值守能帶來哪些好處？
本文就從以上幾方面入手，詳細介紹一下百度搜尋業務在傳遞無人值守上一些探索及實踐。
02 無人值守的源起
在介紹無人值守之前，可以先了解下傳遞模式的發展曆程，如下圖所示，随着工程能力的不斷發展，傳遞過程中的測試逐漸從純手工測試變為半自動化測試或自動化測試。同時在網際網路行業靈活開發模式持續發展，持續內建也随之開展起來，通過将自動化測試工具內建到流水線中，質效工作逐漸左移，大部分的需求研發人員可以通過流水線完成測試、上線工作。我們把這類研發人員不再需要通過測試人員手工測試，使用流水線即可完成全部測試過程的模式稱為研發自主測試，在搜尋業務中，DevOps已成為最主要的傳遞模式，部分業務需求自主測試比例達到了90%以上。
理想狀态下，既然大部分需求已實作自主測試，整個傳遞過程中應該是不需要耗費測試人員人力，但是理想很豐滿，現實卻很骨感。下圖是在自主測試模式下，測試人員的工作日常，可以看到在整體過程中測試人員工作量依然比較大：
1）研發人員流水線執行測試失敗，需要測試人員進行問題排查、修複任務穩定性問題、定位是否與代碼有關、與研發反複溝通；
2）研發流水線執行完成後，測試人員還需要确認研發的自主測試報告，分析需求風險，判斷是否可準入；
3）傳遞過程中，存在很多環節需要研發人員和測試人員的溝通及手工操作，如需求的報備、拉分支、釋出版本等工作。
能否有技術手段，把傳遞過程中這些耗費測試人員大量人力的工作由機器替代呢？這就是我們今天要介紹的無人值守出發點。
03 無人值守的方案
在目前傳遞過程中，主要有以下幾個環節對測試人員的依賴程度較大：
- 決策依賴人：CI代碼後需要執行哪些測試任務是靜态配置的或完全人工決策決定的。
- 流程依賴人：傳遞各環節流程流轉依賴研發或測試人員，溝通互動成本高。
- 結論依賴人：流水線無風險分析能力，測試任務無0/1化結論，準入準出的風險判斷依賴個人經驗。
是以要實作無人值守必須要通過技術手段解決這三個依賴問題，一句話概括就是 “通過智能執行和風險評估能力，實作失敗智能運維，過程自動流轉，風險智能揭露，整個傳遞過程無需測試人員人工幹預 ”。要真正實作這個目标，首先要滿足三個必要的條件：完備的測試能力、穩定的建構能力以及精準的評估能力，在這些能力的基礎上，建設資料采集、風險識别、風險控制、風險決策等智能化機制，最終實作全環節的無人化。
由于篇幅所限，本文下面先重點介紹三個依賴的基礎能力。
3.1 完備的測試能力
完備的測試能力是無人值守的基礎，完備即要求流水線的測試任務是全面且有效的。
怎麼了解全面？不同類型業務對于測試任務的需求是不同的，全面就是具備對應的業務類型需要的各種測試任務，以百度的工程能力地圖服務端要求為例，全面的測試能力即要求下圖所示的服務端的各環節的測試任務都具備，可以根據業務的實際需求進行一些變化。
全面測試能力的基礎上進一步是有效的，有很多情況下流水線雖然具備了某類型的測試任務，但是這個測試任務是不是能夠攔截問題還依賴測試任務的風險揭露能力，或者依賴測試人員對于測試報告的分析解讀能力。
以搜尋業務的DIFF測試類型為例，DIFF測試就是針對基線版本和測試版本，發送同樣的資料，對比傳回的資料的字段的不同，判斷測試版本是否符合預期，已經是目前接口測試和大資料測試中比較常見的方式。但是DIFF測試任務存在有效性問題，測試任務産出了diff的結果，可能是『噪音』導緻的不穩定，可能是代碼變化的預期内的，也可能是bug導緻的非預期結果，這個風險的判斷完全依賴研發和測試的人工分析。是以要提升DIFF測試有效性要解決噪音幹擾的随機diff問題和diff結果0/1分析問題，随機diff的消除通過後端mock、環境資料一緻性、随機diff智能識别與過濾政策等機制解決，本文不詳細展開論述，重點介紹下diff測試的拟人化分析能力。
拟人化分析就是把人工分析測試結果的能力轉化的自動化過程，是以要實作拟人化分析首先要清楚人在看到diff測試結果的時候是如何判斷的，經過實際調研發現，研發和測試人員在分析diff測試結果的時候，首先會看修改的代碼是否與産出的diff結果字段相關聯，如果是關聯比較大就認為是代碼導緻的，接着會分析這些字段的業務影響面是否是需求内預期的以及影響面大小，如果是預期内的影響且風險可控即可認為通過，是以拟人化分析也從下面兩個方面進行判斷：
1）根據白盒資料+模型+業務邏輯分析字段是否符合預期；
2）根據結合業務的資料分析，評估字段影響面風險。
這其中最重要的一點是如何将白盒資料與結果相關聯，目前主要采用了兩個手段，一個是比較正常的業務知識庫沉澱，通過對業務的知識的梳理及沉澱，将研發和測試的個人經驗轉化為可自動判斷的規則，如某些函數的變化可能引起某類的diff，優點是與業務關聯比較緊密，準确度更高，缺點是仍然過于依賴各個業務的人員的梳理，沉澱的效率較低，是以我們探索了第二個手段，通過任務執行的曆史資料，分析代碼變化與字段變化之間的關聯關系，離線的建設代碼及字段的關聯模型，線上階段通過模型判斷字段變化是否是代碼導緻，再結合字段的業務風險判斷最終給出diff測試結論。
通過上述一些手段，能夠大大的提升DIFF測試的有效性，也減少了DIFF測試的人工分析成本，類似的工作也在性能測試等其它場景開展，即通過技術手段提升測試任務的風險揭露能力和結果的分析能力，進而提升測試任務有效性。
3.2 穩定的建構能力
如果說完備的測試能力是實作無人值守的基礎，穩定的建構能力就是實作無人值守的保障。如果流水線建構頻繁失敗，就會導緻在自主測試過程中，測試人員需要不停的進行失敗問題的定位，修複，以及與研發人員的反複的溝通，是以穩定的建構至關重要。如何建設的穩定的建構能力呢？其實可以用線上服務的穩定性建設作為參考，線上服務通常有研發、運維的各種穩定性及監控建設，穩定性能夠達到幾個9以上，但是線下服務的穩定性通常隻有百分之八九十，那為什麼不使用線上穩定性建設的标準來進行線下測試能力的建設呢，是以我們以線上運維的标準，全面提升了線下建構的穩定性，主要包含以下主要工作：
- 基礎依賴治理：流水線穩定性離不開基礎依賴的穩定性，這些依賴包含機器、執行個體、測試代碼、測試資料、第三方服務等各個方面，是以要提升穩定性首先要治理這些依賴，如機器的統一管理，測試代碼和資料用線上代碼的标準管理，第三方服務的SLA保障及容災等措施。
- 全環節的穩定性保障：全環節即預防、發現、定位、恢複、閉環各個環節均建設對應的穩定性能力，如在預防環節，針對建構需要的環境、資料等進行監控，如出現不可用或缺失等問題提前報警，避免測試任務建構時才發現導緻失敗；定位環節規範錯誤碼，針對錯誤碼建設自動定位機制，如果定位問題能夠自動恢複即觸發自愈的政策自動觸發恢複手段，減少失敗的人為幹預。
- 建構數字化：通過對建構資料的數字化，實作建構的穩定性度量、刻畫、建議等工作。
3.1 精準的評估能力
有完備的測試能力和穩定的建構能力，傳遞的無人值守還有最後的環節需要解決：準入準出的風險如何判斷？傳統的流程上通常都是由人工評審測試報告的方式對風險進行把控，不僅耗費人力成本，而且判斷準确程度完全依賴個人的經驗，新人研發和測試同學經常會出現判斷錯誤導緻漏測。如何實作自動的風險評估能力呢，我們采用了基于品質度模型及規則結合的方法建設評估能力，品質度模型就是将可能影響風險的資料都抽象為特征，通過人工标記的曆史資料訓練為模型，在準入準出階段通過調用品質度模型的結果給出風險得分，再結合基于業務的規則判斷進行綜合判斷風險，如果風險低則可以自動準入不再需要人工分析，如果風險為高，再引入人工。
通常特征的包含傳遞過程中的各種資料如代碼白盒資料、研發人員畫像、研發過程資料、測試任務結果、覆寫率等，如下圖所示通過特征的抽象、模型訓練、模型評估等過程最終實作精準的評估能力，評估能力的準确性依賴于品質度模型選取的特征豐富程度以及人工标記的資料的準确性。