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