一 前言
最近十年來，随着移動網際網路和智能裝置的興起，越來越多的資料被沉澱到各大公司的應用平台之上，這些包含大量使用者特征和行為日志的資料被海量地存儲起來，先經過統計分析與特征樣本提取，然後再經過訓練就會産出相應的業務算法模型，這些模型就像智能的機器人，它可以精準地識别和預測使用者的行為和意圖。
如果把資料作為一種資源的話，網際網路公司與傳統公司有着本質的不同，它不是資源的消耗者，而是資源的生産者，在平台營運的過程中不停地在創造新的資料資源，并且随着平台的使用時長和頻率的增加，這些資源也在指數級地增長。平台通過使用這些資料和模型，又反過來帶來更好的使用者體驗和商業價值。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算法應用測試被收錄在第六章。如果還是需要更加詳盡的了解，也歡迎大家加入我們的團隊或者開源社群，一起在以上的幾個方向做更加深入的研究與建設。