寫在前面
質量是企業長遠生存的根基，是企業競爭的免死金牌。作為質量控制團隊的一員，保障和提高所負責系統的質量，是工作的核心。而完善的測試覆蓋，是保證質量的有效手段。
測試按型別來分，分為功能測試和效能測試。功能測試，按照測試金字塔模型，又分為三種：單元測試、介面測試和 ui 測試。單元測試是方法級別的測試，是保證**質量的基礎，一般由開發同學自行完成。介面測試和 ui 測試是端到端的測試，需要覆蓋完整的業務場景，一般由測試同學通過自動化的方式來完成覆蓋，並加入持續整合中，保證所有提交的**都不會影響產品的正常功能。
但介面測試和 ui 測試無法覆蓋所有測試需求，比如演算法。演算法作為機器學習和人工智慧的基礎，其有效性至關重要，特別是在集團智慧型化運維的大潮下，各種演算法層出不窮，尋找有效的方法對演算法的優劣進行評測就成了測試團隊的職責。但是演算法不需要驗證介面，也不需要測試 ui，而是需要建立一套有針對性的評測指標，並想辦法得到被測算法的各項指標值來對演算法進行評價。
演算法測試
演算法測試的流程其實很簡單，只有三步：
把演算法作為乙個黑盒，測試需要做的就是完成第一步和第三步。其中最重要的又是第一步，因為輸入確定了，輸出基本就是確定的，不同點只是在於你如何分析而已。那麼如何構造輸入呢？有兩種方法，一是手工構造資料集，優點是較簡單，可以隨意構造，缺點是無法反應線上的真實情況，會出現大量的漏測場景。還有一種方式是直接使用線上的資料，優點是場景覆蓋全面，缺點是資料收集較為耗時。如果能構造乙個測試系統，使得線上資料的收集＝》演算法執行＝》輸出評價成為乙個完全自動化的流程，那麼可以極大的提高演算法測試的效率和有效性。
下面將以無人值守發布系統的演算法測試為例，介紹一下上述測試思路的一種實現方法。
無人值守發布
無人值守發布（riskfree）著力與解決快速分析新版本的應用的各項指標以識別異常，攔截有問題的發布，降低發布導致的故障率。無人值守發布系統的輸入主要有三個：ali360 的系統監控和基礎監控資料、sunfire 的業務監控資料、a3 的日誌分析資料。通過演算法對這三個系統的輸入資料進行分析，得到異常分，對於異常分較高的應用觸發攔截。
故障回放測試
要對無人值守發布系統進行測試，除了保證其基本功能外，最重要的是要對其演算法的有效性進行驗證，主要落在兩個指標上：準確率和召回率：
測試需要構造乙個資料集，使得通過該輸入得到的輸出可以正確的反映演算法的準確率和召回率。給開發乙個準確的參考，驗證自己的優化是否有效。
所以最有效的方法就是直接錄製線上的監控資料，並用該資料集做回放來驗證演算法的效果。而且為了提高測試效率，解放雙手，需要將資料的選擇、收集、回放、結果展示做成乙個自動化流程，使得開發可以一鍵觸發，選擇任意想要的資料集進行回放。
對於無人值守發布系統來說，一次發布對應乙個 plan。所以基本思路就是錄製該 plan 執行過程中三個監控系統產生的所有資料，並分別存放在三個表中。然後呼叫 riskfree 提供的通過 planid 觸發分析的回放介面，返回對應的錄製資料，完成回放。最後在 plan 分析結束後收集結果，進行展示。下面將錄製和回放模組分開做詳細講解。
錄製流程
第一步是選擇想要錄製的 plan。本文中選擇的是所有在發布過程中觸發了攔截的 plan。為了計算回放之後的準確率和召回率，需要對這些 plan 進行打標，標記哪些是有效攔截，哪些是誤攔截。標記標準為：無人值守觸發攔截 && 發布單被手工關閉或回滾＝有效攔截，其他的都是誤攔截。這種方法理論上可以保證標記的準確性。該任務由定時任務來完成，在每天的零點對前一天的發布單進行過濾，通過對無人值守發布和海狼的資料庫的資料分析，計算出需要選擇的 plan 和對應的標記，儲存到本地的資料庫中。
選好 plan 之後，需要將該 plan 分析過程中獲取的三個監控系統的資料拉取下來並分別儲存。流程很簡單，只要把在分析過程中獲取到的監控資料全部儲存下來即可。由 riskfree 提供錄製介面，通過 planid 來重新觸發分析，在分析過程中將得到的監控資料通過錄製模組提供的 api 儲存到錄製模組的 db 中。因為監控系統會儲存乙個月左右的歷史資料，所以只要錄製及時，所有對應得監控資料都可以獲取到。錄製和回放可以使用同乙個介面，通過配置項來判斷本次觸發是錄製還是回放。當然錄製模組需要做好冪等操作，確保不會有重複得資料被插入到資料集中。
錄製模組提供了兩種觸發錄製的方式。一是定時任務，會在每天的凌晨一點將第一步中篩選出的 plan 的監控資料收集下來；二是介面觸發方式，可以指定某些 plan 或某個時間段內的 plan 進行錄製，主要是重新錄製在定時任務中錄製失敗的 plan。
回放流程
1.錄製完成以後，本地的 db 裡會包含各個 plan 對應的所有監控資料，回放時只要將這些資料準確的返回給 riskfree 系統即可。為了完全擬合對監控系統的呼叫方式，需要提供乙個 mock 層，分別 mock 對基礎監控、業務監控和日誌監控介面的呼叫。同樣的輸入，mock 介面和線上真實介面返回的資料必須完全一致。實際回放時，在 aone 的配置項裡將監控系統的 url 替換成 mock 層的 url 即可。
2.riskfree 的上層是執行層。執行層封裝了各種回放模式，包括按 planid 回放、按監控型別回放、按時間段回放、快速回放等等。開發可以通過介面對各種回放模式進行一鍵觸發。執行層的底層是乙個併發層，可以配置併發回放 plan 的個數。通過併發的方式不僅可以壓縮回放時間，提高測試效率。而且可以驗證在高併發的情況下演算法的效能表現。
3.最上面一層是展示層，展示方式包括釘釘提醒、測試報告和趨勢圖。每一次回放的開始和結束時會有釘釘提醒，結束時的釘釘提醒包含測試報告的鏈結。測試報告分為概述和詳細資訊兩個部分。概述部分包括回放工單總數、有效攔截數、誤攔截數、漏攔截數、準確率和召回率，六個指標，每乙個指標都是乙個錨點，可以直接跳轉到詳細資訊中的對應位置。詳細資訊包括五個部分：漏攔截 plan 詳情、誤攔截 plan 詳情、與上次回放結果不同的 plan 詳情、與線上執行結果不同的 plan 詳情以及全部回放的 plan 詳情五個部分。每乙個詳情部分都是乙個**，包括線上 planid、回放後產生的線下 planid、本次執行結果、上次執行結果、本次回放耗時、上次回放耗時、對應發布單狀態等等多個字段。概述資訊和詳細資訊中的各個對比字段使得開發可以迅速準確的得到本次優化的結果，並快速定位問題。下圖是某次回放結果的部分截圖。
4.為了直觀的展示歷次演算法優化的效果，對相同資料集、相同監控型別的回放結果自動生成趨勢圖，並在測試報告中生成對應的鏈結。下圖是歷次對 11-03 到 11-10 時間段的 a3 日誌分析資料進行回放的趨勢圖。
寫在最後
演算法測試的重中之重是構造資料集，而線上真實的資料集往往比手工構造的資料集更有代表性。上文提到的錄製＋回放的方法只需稍加變通即可應用在各個演算法評測專案中。只要將錄製和回放串成乙個自動化的流程，即可一勞永逸，不必再擔心資料集的構造和更新了。
作者介紹
李朝陽，阿里巴巴研發效能事業部運維域，高階測試開發工程師。2016 年加入阿里，作為質量控制團隊的一員，負責混合雲、集團 docker 全鏈路、無人值守發布系統的質量保證。
雲效新品體驗：
乙個智慧型運維演算法測試方法
摘要 質量是企業長遠生存的根基，是企業競爭的免死金牌。作為質量控制團隊的一員，保障和提高所負責系統的質量，是工作的核心。而完善的測試覆蓋，是保證質量的有效手段。寫在前面 質量是企業長遠生存的根基，是企業競爭的免死金牌。作為質量控制團隊的一員，保障和提高所負責系統的質量，是工作的核心。而完善的測試覆蓋...
乙個智慧型運維演算法測試方法
寫在前面 質量是企業長遠生存的根基，是企業競爭的免死金牌。作為質量控制團隊的一員，保障和提高所負責系統的質量，是工作的核心。而完善的測試覆蓋，是保證質量的有效手段。測試按型別來分，分為功能測試和效能測試。功能測試，按照測試金字塔模型，又分為三種 單元測試 介面測試和 ui 測試。單元測試是方法級別的...
乙個智慧型運維演算法測試方法
摘要 質量是企業長遠生存的根基，是企業競爭的免死金牌。作為質量控制團隊的一員，保障和提高所負責系統的質量，是工作的核心。而完善的測試覆蓋，是保證質量的有效手段。寫在前面 質量是企業長遠生存的根基，是企業競爭的免死金牌。作為質量控制團隊的一員，保障和提高所負責系統的質量，是工作的核心。而完善的測試覆蓋...