隨著最近幾年數(shù)據(jù)計算力與機器智能算法的興起，基于大數(shù)據(jù) AI 算法的應(yīng)用愈來愈熱，大數(shù)據(jù)應(yīng)用在各個行業(yè)也不斷涌現(xiàn)。測試技術(shù)作為工程技術(shù)的一部分，也隨著時代的不斷變化在同步演進，在當下 DT 時代，如何測試和保障一個基于大數(shù)據(jù)的應(yīng)用的軟件質(zhì)量，成為測試界的一個難題。
本文通過系統(tǒng)性地介紹阿里巴巴 AI 中臺的技術(shù)質(zhì)量體系——搜索推薦廣告應(yīng)用的質(zhì)量是如何測試的，來嘗試回答一下這個問題，希望能給大家?guī)硪恍┙梃b，歡迎斧正，以便改進。
一 前言
最近十年來，隨著移動互聯(lián)網(wǎng)和智能設(shè)備的興起，越來越多的數(shù)據(jù)被沉淀到各大公司的應(yīng)用平臺之上，這些包含大量用戶特征和行為日志的數(shù)據(jù)被海量地存儲起來，先經(jīng)過統(tǒng)計分析與特征樣本提取，然后再經(jīng)過訓練就會產(chǎn)出相應(yīng)的業(yè)務(wù)算法模型，這些模型就像智能的機器人，它可以精準地識別和預測用戶的行為和意圖。
如果把數(shù)據(jù)作為一種資源的話，互聯(lián)網(wǎng)公司與傳統(tǒng)公司有著本質(zhì)的不同，它不是資源的消耗者，而是資源的生產(chǎn)者，在平臺運營的過程中不停地在創(chuàng)造新的數(shù)據(jù)資源，并且隨著平臺的使用時長和頻率的增加，這些資源也在指數(shù)級地增長。平臺通過使用這些數(shù)據(jù)和模型，又反過來帶來更好的用戶體驗和商業(yè)價值。2016 年，AlphaGo，一個基于深度神經(jīng)網(wǎng)絡(luò)的圍棋人工智能程序，第一次戰(zhàn)勝圍棋世界冠軍李世石。這個由谷歌（Google）旗下 DeepMind 公司開發(fā)的算法模型，背后使用的數(shù)據(jù)正是人類棋手所有的歷史棋譜數(shù)據(jù)。
阿里的搜索、推薦和廣告也是非常典型的大數(shù)據(jù)應(yīng)用的場景（高維稀疏業(yè)務(wù)場景），在談如何測試之前我們需要先了解一下平臺處理數(shù)據(jù)的工程技術(shù)背景。搜索、推薦、廣告系統(tǒng)在工程架構(gòu)和數(shù)據(jù)處理流程上比較相近，一般分為離線系統(tǒng)和在線系統(tǒng)兩部分，見下圖 1（在線廣告系統(tǒng)一般性架構(gòu)，劉鵬《計算廣告》）。離線系統(tǒng)負責數(shù)據(jù)處理與算法模型的建模與訓練，而在線系統(tǒng)主要用以處理用戶的實時請求。在線系統(tǒng)會使用離線系統(tǒng)訓練產(chǎn)出的模型，用以實時的在線預測，例如預估點擊率。
用戶在訪問手機淘寶或者其他 app 的時候會產(chǎn)生大量的行為數(shù)據(jù)，包括用戶的瀏覽、搜索、點擊、購買、評價、停留時長等，加上商家商品維度的各類數(shù)據(jù)（廣告還需要增加廣告主維度的數(shù)據(jù)），這些數(shù)據(jù)經(jīng)過采集過濾處理之后再經(jīng)過特征提取之后生成了模型所需的樣本數(shù)據(jù)，樣本數(shù)據(jù)在機器學習訓練平臺上經(jīng)過離線訓練之后就可以產(chǎn)生用以在線服務(wù)的各類算法模型（例如深度興趣演化網(wǎng)絡(luò) DIEN、Tree-based Deep Model、大規(guī)模圖表示學習、基于分類興趣的動態(tài)相似用戶向量召回模型、等等）。在線系統(tǒng)中最主要的功能是數(shù)據(jù)的檢索和在線預測服務(wù)，一般使用信息檢索的相關(guān)技術(shù)，例如數(shù)據(jù)的正倒排索引、時序存儲等。
搜索推薦廣告系統(tǒng)在使用了上述維度的大數(shù)據(jù)，經(jīng)過深度學習之后，成為一個千人千面的個性化系統(tǒng)。對于不同的用戶請求，每次展現(xiàn)的商品和推薦的自然結(jié)果和商業(yè)結(jié)果都不盡相同，即便是同一個用戶在不同的時刻得到的結(jié)果也會隨著用戶的實時行為的不同而改變，這些背后都是數(shù)據(jù)和算法模型的魔力。
圖1 在線廣告系統(tǒng)一般性架構(gòu)圖
二 大數(shù)據(jù)應(yīng)用測試質(zhì)量域的六大挑戰(zhàn)
在思考搜索推薦廣告系統(tǒng)是如何測試的之前，我們首先要定義問題域，即要解決的測試問題是什么，我們的思路從以下幾個方向展開。
1 功能性測試與驗證
除了正常的請求與響應(yīng)的檢查之外，大數(shù)據(jù)的“大”主要體現(xiàn)在數(shù)據(jù)的完整性和豐富性。一個搜索推薦引擎的好壞很大程度上取決于其內(nèi)容是否足夠豐富，召回是否足夠多樣。另外，算法帶來搜索推薦結(jié)果的不確性，但也給我們的測試驗證工作造成了麻煩。所以，數(shù)據(jù)的完整性和不確定性校驗也是功能測試的要點。
2 數(shù)據(jù)更新的實時性如何測試
總所周知，對于一個搜索或者廣告的在線計算引擎，其內(nèi)部的數(shù)據(jù)在不停地發(fā)生更新，或者出于商家在商品信息上的變更，也可能是因為廣告主在創(chuàng)意甚至投放計劃上的變化，這些更新需要實時反饋在投放引擎，否則會出現(xiàn)信息不一致甚至錯誤。如何測試和驗證這些變更的及時性，即保證一定的并發(fā)帶寬又保證更新鏈路的響應(yīng)時間，這是需要測試重點關(guān)注的一個問題。
3 數(shù)據(jù)請求響應(yīng)的及時性如何測試
在線服務(wù)都要求低延遲，每次 query 服務(wù)端需要在幾十毫秒內(nèi)給出響應(yīng)結(jié)果，而整個服務(wù)端的拓撲會有大概 30 多個不同模塊構(gòu)成。如何測試后端服務(wù)的性能和容量就變得至關(guān)重要。
4 算法的效果如何驗證
搜索推薦甚至廣告的返回結(jié)果需要與用戶的需求和興趣匹配，這樣才會保證更高的點擊率與成交轉(zhuǎn)化，但如何驗證這種需求與結(jié)果的相關(guān)性，或者如何測試一個算法的效果，這是一個非常有趣且有挑戰(zhàn)的話題。
5 AI 算法系統(tǒng)的線上穩(wěn)定性如何保證
線下發(fā)布之前的測試是對代碼的測試驗收，并隨著缺陷的發(fā)現(xiàn)與修復，提升的是代碼質(zhì)量。而線上的穩(wěn)定性運營是為了提升系統(tǒng)運行的穩(wěn)定性，解決的問題是：即便是一個代碼質(zhì)量一般的系統(tǒng)，如何通過技術(shù)運維的方法來提升系統(tǒng)的高可用性與魯棒性，并降低線上故障的頻次與影響，這一部分也被稱為線上技術(shù)風險領(lǐng)域。
6 工程效率方向
這是對以上幾個部分的補充，甚至是對整個工程研發(fā)體系在效率上的補充。質(zhì)量與效率是一對孿生兄弟，也是同一個硬幣的兩面，如何平衡好兩者之間的關(guān)系是一個難題，質(zhì)量優(yōu)先還是效率優(yōu)先，不同的產(chǎn)品發(fā)展階段有不同的側(cè)重點。我們的工程效率，力在解決 DevOps 研發(fā)工具鏈路，用以提升研發(fā)的工程生產(chǎn)力。
自此，我們基本定義完畢大數(shù)據(jù)應(yīng)用的測試問題的六大領(lǐng)域，有些領(lǐng)域已經(jīng)超過了傳統(tǒng)的測試與質(zhì)量的范疇，但這也正是大數(shù)據(jù)應(yīng)用給我們帶來的獨特質(zhì)量挑戰(zhàn)，下面我們圍繞這六個問題展開講一講。
三 大數(shù)據(jù)應(yīng)用測試六個問題的解法
1 AI 應(yīng)用的功能性測試驗證
功能測試主要分三塊：端到端的用戶交互測試、在線工程的功能測試、離線算法系統(tǒng)的功能測試。
1） 端到端的用戶交互測試
這是涉及到搜索推薦廣告系統(tǒng)的用戶交互部分的測試驗證，既包括買家端（手機淘寶、天貓 app 和優(yōu)酷 app 等）的用戶體驗和邏輯功能的驗證，也包括針對廣告主和商家的客戶管理平臺（Business Platform）上業(yè)務(wù)流程邏輯的校驗，涉及廣告主在廣告創(chuàng)意創(chuàng)作、投放計劃設(shè)定、計費結(jié)算等方面的測試。端到端的測試保證了我們最終交付給用戶和客戶使用的產(chǎn)品質(zhì)量。端上的測試技術(shù)和工具，主要涉及端到端（native/h5）app/web 上的 UI 自動化、安全、性能穩(wěn)定性（monkey test/crash 率）、流量（弱網(wǎng)絡(luò)）、耗電量、兼容性和適配，在集團其他團隊的測試技術(shù)和開源技術(shù)體系的基礎(chǔ)上我們做了一些改進和創(chuàng)新，例如將富媒體智能化驗證引入客戶端自動化測試，完成圖像對比、文字 OCR、局部特征匹配、邊緣檢測、基于關(guān)鍵幀的視頻驗證（組件動畫、貼片視頻）等，解決了廣告推薦在客戶端上所有展現(xiàn)形式的驗證問題。另外，針對 Java 接口和客戶端 SDK 的測試，除了常規(guī)的 API Service 級別測試之外，在數(shù)據(jù)流量回放的基礎(chǔ)上使用對比測試的方法，在接口對比、DB 對比、文件對比、流量對比的使用上有一些不錯的質(zhì)量效果。端到端的測試驗證，由于 UI 的改版速度非?？?，測試策略上我們把自動化的重點放在接口層面，UI 的 automation 只是簡單的邏輯驗證，全量的 UI 驗證回歸（功能邏輯和樣式體驗）還是通過手動測試，這里我們使用了不少的外包測試服務(wù)作為補充。
2） 在線工程系統(tǒng)的測試
這一部分是整個系統(tǒng)的功能測試的重點。搜索推薦廣告系統(tǒng)，本質(zhì)上是數(shù)據(jù)管理的系統(tǒng)，數(shù)據(jù)包括商品維度、用戶維度、商家和廣告主維度的數(shù)據(jù)。把大量的數(shù)據(jù)按照一定的數(shù)據(jù)結(jié)構(gòu)存儲在機器內(nèi)存之中，提供召回、預估、融合等服務(wù)，這些都是在線工程要去解決的問題。這部分的功能測試，基本原理是通過發(fā)送 Request/Query 請求串、驗證 Response 結(jié)果的模式，在此基礎(chǔ)上使用了比較多提升測試用例生成效率和執(zhí)行效率的技術(shù)?；诳梢暬⒅悄芑燃夹g(shù)（智能用例生成、智能回歸、失敗智能歸因、精準測試覆蓋、功能 A/B 測試），把測試方法論融入其中，解決了大規(guī)模異構(gòu)的在線工程功能測試 case 編寫成本高、debug 難、回歸效率低的問題。搜索推薦廣告的在線服務(wù)工程基本上由 20 - 30 個不同的在線模塊組成，測試這些在線服務(wù)模塊極其消耗時間，用例的編寫效率和回歸運行效率是優(yōu)化的主要目標，在這個方向上，我們在用例生成方面通過用例膨脹和推薦技術(shù)、基于遺傳算法動態(tài)生成有效測試用例、在用例執(zhí)行階段使用動態(tài)編排的回歸技術(shù)，通過這些技術(shù)極大地提升了在線模塊的功能測試的覆蓋率。
此外，我們比較多地使用線上的 Query 做對比測試的方法，用以驗證功能變更的差異，分析即將發(fā)布的系統(tǒng)與實際線上系統(tǒng)之間的結(jié)果一致率和數(shù)據(jù)分布可以很好地找到系統(tǒng)的功能性問題。在線上測試領(lǐng)域，除了對比測試，我們把近期 Top-N 的 Query 在線上定時做巡檢監(jiān)察，一方面起到功能監(jiān)控的作用，另一方面 Query 量級到一定程度（例如最近一周 80% 的長尾 Query），可以很輕松地驗證引擎數(shù)據(jù)的完整性和多樣性。最后，這一部分的測試策略也需要強調(diào)一下，由于算法的邏輯（例如召回和排序的業(yè)務(wù)邏輯）非常復雜，涉及不同的業(yè)務(wù)和分層模型，這些邏輯是算法工程師直接設(shè)計實現(xiàn)的，所以算法邏輯的測試用例的設(shè)計和執(zhí)行也是由算法工程師來做，只有他們最清楚模型的功能邏輯和如何變化。結(jié)合著線上 debug 系統(tǒng)的使用，算法工程師可以很清楚目前線上運行的算法和線下即將上線的算法之間的邏輯差異，測試用例也就比較容易編寫。測試工程師在其中主要負責整個測試框架和工具環(huán)境的搭建，以及基本測試用例的編寫與運行。這個測試策略的調(diào)整，在本文最后關(guān)于測試未來的預判部分也有介紹。
3） 離線系統(tǒng)的測試，或者算法工程測試
從數(shù)據(jù)流程的角度看，算法工程包括算法模型的建模流程和模型訓練上線兩部分，從特征提取、樣本生成、模型訓練、在線預測，整個pipeline離線流程到在線的過程中如何驗證特征樣本的質(zhì)量和模型的質(zhì)量。所以算法測試的關(guān)鍵在于三個地方：
樣本特征質(zhì)量的評估
模型質(zhì)量的評估
模型在線預估服務(wù)的質(zhì)量保障
a 和 b 涉及數(shù)據(jù)質(zhì)量與特征功效放在一起在第四部分介紹，主要使用數(shù)據(jù)質(zhì)量的各種指標來評估質(zhì)量。
這里重點說一下 c，算法在線預估服務(wù)上線前的測試，因為其涉及到模型最終服務(wù)的質(zhì)量，比較重要。我們這里使用了一種小樣本離線在線打分對比的方法，可以最終比較全面地驗證模型上線質(zhì)量的問題。詳細過程是：在模型上線正式服務(wù)之前，需要對模型做測試驗證，除了準備常規(guī)的 test 數(shù)據(jù)集，我們單獨分離出一部分樣本集，稱之為小樣本數(shù)據(jù)集，通過小樣本數(shù)據(jù)集在線系統(tǒng)的得分與離線分數(shù)的對比的差異，驗證模型的在線服務(wù)質(zhì)量，這種小樣本打分實際上也提供了類似于灰度驗證的能力。流程見下圖 2。
圖2 小樣本測試
關(guān)于離線系統(tǒng)的測試，我們同時在深度學習訓練平臺的質(zhì)量保障上也做了一些探索，目前深度學習平臺質(zhì)量主要面臨三大難點：
由于種種復雜狀況，在集群上訓練的模型存在訓練失敗的風險，如何提前預警深度學習平臺當前存在的潛在風險。
由于神經(jīng)網(wǎng)絡(luò)天然局部最優(yōu)解基因和 Tensorflow Batch 的設(shè)計思路，每次訓練的模型，如何保障它是否滿足上線的質(zhì)量要求。
如何驗證在大規(guī)模數(shù)據(jù)集和分布式系統(tǒng)下深度學習平臺提供的各種深度學習功能的準確性。
針對這三大問題，我們嘗試了三個解法：
實驗預跑法，設(shè)計特別的模型和訓練數(shù)據(jù)，15 分鐘內(nèi)訓練完畢?？梢钥焖侔l(fā)現(xiàn)和定位訓練平臺的問題，在大規(guī)模的生產(chǎn)模型正式訓練之前就發(fā)現(xiàn)問題。
Model on Model 的模型驗證法，把模型生產(chǎn)的中間數(shù)據(jù)指標（除 auc 之外，還包括神經(jīng)元激活率、梯度在各層傳到均方差等）透傳加工建模，監(jiān)控生產(chǎn)模型的質(zhì)量。
Model Based 功能校驗法，針對性地設(shè)計樣本格式和測試模型網(wǎng)絡(luò)，使模型 variable 的理論值能夠精確計算出，根據(jù)訓練模型的結(jié)果驗證平臺的質(zhì)量。
2 數(shù)據(jù)更新的實時性如何測試的問題
這一部分主要包含兩個子問題：
1） 引擎數(shù)據(jù)的實時更新鏈路的測試
對于一個實時更新鏈路，從上游的數(shù)據(jù)源/數(shù)據(jù)表（TT/MetaQ/ODPS，阿里的消息中間件與離線數(shù)據(jù)表）讀取數(shù)據(jù)，經(jīng)過 Streaming 計算平臺（Bayes 引擎、Blink 等，阿里的實時計算平臺）的實時計算任務(wù)處理產(chǎn)出引擎可以接受的更新消息，引擎在收到此類消息之后再做數(shù)據(jù)的更新操作。這個鏈路主要驗證的點在于：
數(shù)據(jù)的正確性驗證
數(shù)據(jù)的一致性驗證
數(shù)據(jù)的時效性驗證
數(shù)據(jù)的并發(fā)性能測試
在這幾個問題的解決上，我們使用了流式數(shù)據(jù)實時對比、全量對比可以解決數(shù)據(jù)的正確性和一致性驗證的問題；數(shù)據(jù)的時效性更多地依賴計算平臺底層的資源來保證毫秒級別的更新速度，我們這里通過記錄更新時間戳來驗證更新的時效性；性能測試通過偽造上游數(shù)據(jù)和流量復制來驗證整個鏈路的響應(yīng)時間和并發(fā)處理能力。
2） 模型的實時更新（Online Deep Learning）鏈路如何測試
為了拿到實時行為帶來的算法收益，Online Deep Learning（ODL）最近兩年興起，用戶實時行為特征數(shù)據(jù)也需要實時地訓練到模型之中，在 10-15 分鐘的時間間隔里，在線服務(wù)的模型會被更新替代，留給模型驗證的時間最多只有 10 分鐘的時間，這是 ODL 帶來的質(zhì)量挑戰(zhàn)。解這個問題，我們有兩個方法同時工作。
（1）最主要的方法是建立 ODL 全鏈路質(zhì)量指標監(jiān)控體系，這里的鏈路是指從樣本構(gòu)建到在線預測的全鏈路，包括樣本域的指標校驗和訓練域指標校驗。
指標選取上主要看是否跟效果相關(guān)聯(lián)，例如對于 ctr 預估方向，可以計算測試集上的 auc、gauc（Group auc，分組后的 auc）、score_avg（模型打分均值）等指標，甚至計算train_auc & test_auc，pctr & actual_ctr 之間的差值（前者看是否過擬合，后者看打分準度）是不是在一個合理的范圍內(nèi)。這里也有一個關(guān)鍵的點在于測試集的選取，我們建議測試集除了取下一個時間窗口的數(shù)據(jù)（用未見的數(shù)據(jù)測試模型的泛化性能），還可以包含從過去一段時間（比如一周）的數(shù)據(jù)里面隨機抽樣的一部分數(shù)據(jù)（用已見但全面的數(shù)據(jù)測試模型是否跑偏）。同時，這也降低了局部的異常測試樣本對評估指標帶來的擾動影響。
（2）除了指標體系之外，我們設(shè)計了一個離線仿真的系統(tǒng)，在模型正式上線之前在仿真環(huán)境模擬打分校驗。
簡單來說就是把需要上線的模型，在線下測試環(huán)境利用線上流量通過在線服務(wù)的組件打分模塊進行一個提前的預打分，在這個打分過程中出現(xiàn)任何錯誤都算校驗不通過，打分正常的模型再對分數(shù)進行均值和分布的校驗，打分校驗不通過會直接拒絕上線。通過以上兩種方案，結(jié)合樣本與模型的監(jiān)控與攔截，可以極大概率低降低 ODL 的質(zhì)量風險。
3 性能壓測
對于由離線、在線兩部分構(gòu)成的AI系統(tǒng)，在線是響應(yīng)的是用戶實時訪問請求，對響應(yīng)時間要求更高，在線系統(tǒng)的性能是這一部分的重點。離線的性能很大程度上取決于訓練平臺在計算資源方面的調(diào)度使用，我們一般通過簡單的源頭數(shù)據(jù)復制來做驗證。對于在線系統(tǒng)，分為讀場景和寫場景的性能測試，寫場景的性能在第二部分實時更新鏈路的時效性部分已有介紹，這里主要講一下在線場景的讀場景的性能容量測試。
在線系統(tǒng)一般由二三十個不同的引擎模塊組成，引擎里的數(shù)據(jù) Data 與測試 Query 的不同都會極大的影響性能測試結(jié)果，同時也由于維護線下的性能測試環(huán)境與線上環(huán)境的數(shù)據(jù)同步工作需要極大的代價，我們目前的策略都是選擇在線上的某個生產(chǎn)集群里做性能容量測試。對于可以處理幾十萬 QPS（Query Per Second）的在線系統(tǒng)，難點在于如何精準控制產(chǎn)生如此量級的并發(fā) Query，使用簡單的多線程或多進程的控制已經(jīng)無法解決，我們在這里使用了一個爬山算法（梯度多倫迭代爬山法）來做流量的精準控制，背后是上百臺的壓力測試機器遞增式地探測系統(tǒng)性能水位。
另外一個建設(shè)的方向是整個壓測流程的自動化以及執(zhí)行上的無人值守，從基于場景的線上 Query 的自動選取、到壓力生成、再到均值漂移算法的系統(tǒng)自動化校驗工作，整個壓測流程會如行云流水一般的按照預設(shè)自動完成。配合著集群之間的切流，可以做到白+黑（白天夜間）的日常壓測，對線上水位和性能瓶頸的分析帶來了極大的便利。
4 效果的測試與評估
這是大數(shù)據(jù)應(yīng)用算法的重頭戲，由于算法的效果涉及到搜索廣告業(yè)務(wù)的直接受益（Revenue & GMV），我們在這個方向上也有比較大的投入，分為以下幾個子方向。
1） 特征與樣本的質(zhì)量與功效評估
通過對特征質(zhì)量（有無數(shù)據(jù)及分布問題），以及特征效用（對算法有無價值）兩個角度出發(fā)，在特征指標計算上找到一些比較重要的指標：缺失率占比、高頻取值、分布變化、取值相關(guān)性等。同時，在訓練和評估過程中大量中間指標與模型效果能產(chǎn)生因果關(guān)系，通過系統(tǒng)的分析建模張量、梯度、權(quán)重和更新量，能夠?qū)λ惴ㄕ{(diào)優(yōu)、問題定位起到輔助決策作用。
而且，通過改進 AUC 算法，分析 ROC、PR、預估分布等更多評估指標，能夠更全面的評估模型效果。隨著數(shù)據(jù)量級的增加，最近兩年我們在建模和訓練過程中使用了千億參數(shù)、萬億樣本，Graph Deep Learning 也進入百億點千億邊的階段，在如此浩瀚的數(shù)據(jù)海洋里，如何可視化特征樣本以及上述的各種指標成為一個難點，我們在 Google 開源的 Tensorboard 的基礎(chǔ)上做了大量的優(yōu)化與改進，幫助算法工程師在數(shù)據(jù)指標的可視化、訓練過程的調(diào)試、深度模型的可解釋性上給與了較好的支持。
2） 在線流量實驗
算法項目在正式上線之前，模型需要在實驗環(huán)境中引入真實的線上流量進行效果測試和調(diào)優(yōu)，在第一代基于Google分層實驗架構(gòu)的在線分層實驗（原理 Google 論文“Overlapping Experiment Infrastructure More, Better, Faster Experimentation”）的基礎(chǔ)上，我們在并發(fā)實驗、參數(shù)管理、參數(shù)間相互覆蓋、實驗質(zhì)量缺乏保障、實驗調(diào)試能力缺失、實驗擴展能力不足等方面做了很多的改進，極大地提升了流量的并發(fā)復用與安全機制，達到真正的生產(chǎn)實驗的目的。在效果上，通過在線實驗平臺引入的真實流量的驗證，使得模型的效果質(zhì)量得到極大的保障。
3） 數(shù)據(jù)效果評測
這里分兩塊：相關(guān)性評測與效果評測。相關(guān)性是相關(guān)性模型的一個很重要的評估指標，我們主要通過數(shù)據(jù)評測來解決，通過對搜索展示結(jié)果的指標評測，可以得到每次搜索結(jié)果的相關(guān)性分數(shù)，細分指標包括：經(jīng)典衡量指標 CSAT (Customer Satisfaction，包括非常滿意、滿意、一般、不滿意、非常不滿意)、凈推薦值 NPS (Net Promoter Score，由貝恩咨詢企業(yè)客戶忠誠度業(yè)務(wù)的創(chuàng)始人 Fred Reichheld 在 2003 年提出，它通過測量用戶的推薦意愿，從而了解用戶的忠誠度)、CES (Customer Effort Score，“客戶費力度”是讓用戶評價使用某產(chǎn)品/服務(wù)來解決問題的困難程度)、HEART 框架（來源于 Google，從愉悅度 Happiness、Engagement 參與度、Adoption 接受度、Retention 留存率、Task success 任務(wù)完成度）。
效果評估方面，我們采用了數(shù)據(jù)統(tǒng)計與分析的方法。在一個算法模型真正全量投入服務(wù)之前，我們需要準確地驗證這個模型的服務(wù)效果。除了第一部分介紹的離在線對比之外，我們需要更加客觀的數(shù)據(jù)指標來加以佐證。這里我們采用了真實流量的 A/B 實驗測試的方法，給即將發(fā)布的模型導入線上 5% 的流量，評估這 5% 流量和基準桶的效果對比，從用戶體驗（相關(guān)性）、平臺收益、客戶價值三個維度做各自實際指標的分析，根據(jù)用戶的相關(guān)性評測結(jié)果、平臺的收入或者 GMV、客戶的 ROI 等幾個方面來觀測一個新模型對于買家、平臺、賣家的潛在影響到底是什么，并給最終的業(yè)務(wù)決策提供必要的數(shù)據(jù)支撐。流量從 5% 到 10%，再到 20% 以及 50%，在這個灰度逐漸加大至全量的過程中，無論是功能問題、還是性能的問題，甚至效果的問題都會被探測到，這種方法進一步降低了重大風險的發(fā)生。這是一個數(shù)據(jù)統(tǒng)計分析與技術(shù)的融合的方案，與本文所介紹的其他技術(shù)方法不同，比較獨特，但效果甚佳。
5 線上穩(wěn)定性
與其他業(yè)務(wù)的穩(wěn)定性建設(shè)類似，通過發(fā)布三板斧（灰度、監(jiān)控、回滾）來解決發(fā)布過程的質(zhì)量，通過線上的容災演練、故障注入與演練（我們也是集團開源的混沌工程 Monkey King 的 C++ 版本的提供者）、安全紅藍對抗攻防來提升系統(tǒng)線上的穩(wěn)定性和可用性。另外在 AI Ops 和 Service Mesh 為基礎(chǔ)的運維管控方向上，我們正在向著智能運維、數(shù)據(jù)透視分析、自動切流、自動擴縮容等方向努力。我們預測結(jié)合 Service Mesh 技術(shù)理念在 C++ 在線服務(wù)的演進，系統(tǒng)會具備對業(yè)務(wù)應(yīng)用無侵入的流量標定及變更標定的能力，也就能夠?qū)崿F(xiàn)流量調(diào)度能力和隔離的能力。另外，紅藍攻防也將進一步發(fā)展，自動化、流程化將逐步成為混沌工程實施的標準形式。由于這一部分尚處于起步階段，這里不再過多介紹還沒有實現(xiàn)的內(nèi)容，但我們判定這個方向大有可為，與傳統(tǒng)運維工作不同，更接近 Google 的 SRE（Site Reliability Engineering）理念。
6 AI 應(yīng)用的工程效能
主要解決在測試階段和研發(fā)階段提升效率的問題，這個方向上我們以 DevOps 工具鏈建設(shè)為主，在開發(fā)、測試、工程發(fā)布、模型發(fā)布（模型 debug 定位）、客戶反饋（體感評估、眾測、客戶問題 debug）整個研發(fā)閉環(huán)所使用到的工具方面的建設(shè)。在我們設(shè)想的 DevOps 的場景下，開發(fā)同學通過使用這些工具可以獨立完成需求的開發(fā)測試發(fā)布及客戶反饋的處理。鑒于這個方向與測試本身關(guān)系不大，篇幅原因，這里也略過。
四 大數(shù)據(jù)應(yīng)用測試的未來
至此，關(guān)于大數(shù)據(jù)應(yīng)用測試的幾個主要問題的解法已經(jīng)介紹完畢。關(guān)于大數(shù)據(jù)應(yīng)用測試的未來，我也有一些自己初步的判斷。
1 后端服務(wù)測試的工具化
這涉及到服務(wù)端的測試轉(zhuǎn)型問題，我們的判斷是后端服務(wù)類型的測試不再需要專職的測試人員，開發(fā)工程師在使用合理的測試工具的情況下可以更加高效地完成測試任務(wù)。專職的測試團隊，未來會更多地專注于偏前端與用戶交互方面產(chǎn)品質(zhì)量的把控，跟產(chǎn)品經(jīng)理一樣，需要從用戶的角度思考產(chǎn)品質(zhì)量的問題，產(chǎn)品的交付與交互的驗證是這個方向的重點。多數(shù)的服務(wù)端的測試工作都是可以自動化的，且很多 service 級別的驗證也只有通過自動化這種方式才能驗證。相比較測試同學，開發(fā)同學在 API 級別的自動化代碼開發(fā)方面能力會更強，更重要的是開發(fā)同學自己做測試會減少測試同學與開發(fā)同學之間的大量往返溝通的成本，而這個成本是整個發(fā)布環(huán)節(jié)中占比較大的部分。再者，第一部分介紹過，算法工程師在業(yè)務(wù)邏輯的理解上更加清晰。
所以，我們更希望后端的測試工作由工程或者算法工程師獨立完成，在這種新的生產(chǎn)關(guān)系模式下，測試同學更加專注于測試工具的研發(fā)，包括自動化測試框架、測試環(huán)境部署工具、測試數(shù)據(jù)構(gòu)造與生成、發(fā)布冒煙測試工具、持續(xù)集成與部署等。這種模式也是目前 Google 一直在使用的測試模式，我們今年在這個方向下嘗試了轉(zhuǎn)型，在質(zhì)量變化和效率提升方面這兩方面效果還不錯。作為國內(nèi)互聯(lián)網(wǎng)公司的率先進行的測試轉(zhuǎn)型之路，相信可以給到各位同行一些借鑒。這里需要強調(diào)一點的是，雖然測試團隊在這個方向上做了轉(zhuǎn)型，但后端測試這個事情還是需要繼續(xù)做，只是測試任務(wù)的執(zhí)行主體變成了開發(fā)工程師，本文介紹的大量后端測試的技術(shù)和方向還會繼續(xù)存在。后端服務(wù)類測試團隊轉(zhuǎn)型，除了效能工具之外，第五部分的線上穩(wěn)定性的建設(shè)是一個非常好的方向。
2 測試的線上化，既 TIP（Test In Production）
這個概念大概十年前由微軟的工程師提出。TIP 是未來測試方法上的一個方向，主要的考慮是以下三點。
1）一方面由于線下測試環(huán)境與真實線上環(huán)境總是存在一些差異，或者消除這種差異需要較大的持續(xù)成本，導致測試結(jié)論不夠置信。使用最多的就是性能測試或容量測試，后端服務(wù)的拓撲非常復雜，且許多模塊都有可擴展性，帶有不同的數(shù)據(jù)對性能測試的結(jié)果也有很大的影響，測試環(huán)境與生產(chǎn)環(huán)境的這種不同會帶來測試結(jié)果的巨大差異。另外，目前的生產(chǎn)集群都是異地多活，在夜里或者流量低谷的時候，單個集群就可以承擔起所有流量請求，剩下的集群可以很方便地用來壓測，這也給我們在線上做性能測試帶來了可能性。最具典型的代表就是阿里的雙十一全鏈路壓測，今年基本上都是在白加黑的模式下完成的。
2）另外，許多真實的演練測試也只能在線上系統(tǒng)進行，例如安全攻防和故障注入與演練，在線下測試環(huán)境是無法做到的。
3）最后，從質(zhì)量的最終結(jié)果上看，不管是發(fā)布前的線下測試，還是發(fā)布后的線上穩(wěn)定性建設(shè)，其目的都是為了減少系統(tǒng)故障的發(fā)生，把這兩部分融合在一起，針對最終的線上故障的減少去做目標優(yōu)化工作，可以最大程度地節(jié)約和利用人力資源。我們判斷，線下測試與線上穩(wěn)定性的融合必將是一個歷史趨勢，這一領(lǐng)域統(tǒng)稱為技術(shù)風險的防控。
3 測試技術(shù)的智能化
見圖 3。類似對自動駕駛的分級，智能化測試也有不同的成熟度模型，從人工測試、自動化、輔助智能測試、高度智能測試。機器智能是一個工具，在測試的不同階段都有其應(yīng)用的場景，測試數(shù)據(jù)和用例設(shè)計階段、測試用例回歸執(zhí)行階段、測試結(jié)果的檢驗階段、線上的指標異常檢測諸多技術(shù)風險領(lǐng)域都可以用到不同的算法和模型。智能化測試是發(fā)展到一定階段的產(chǎn)物，前提條件就是數(shù)字化，自動化測試是比較簡單一種數(shù)字化。沒有做到數(shù)字化或者自動化，其實是沒有智能分析與優(yōu)化的訴求的。
另外，在算法的使用上，一些簡單算法的使用可能會有不錯的效果，比較復雜的深度學習甚至強化學習算法的效果反而一般，原因或者難點在兩個地方，一個是特征提取和建模比較困難，第二個原因是測試運行的樣本與反饋的缺失。但無論如何，運用最新的算法技術(shù)去優(yōu)化不同的測試階段的效率問題，是未來的一個方向。但我們同時判斷，完全的高度智能測試與無人駕駛一樣，目前還不成熟，主要不在算法與模型，而是測試數(shù)據(jù)的不足。
圖3 測試技術(shù)的智能化
