背景

根據典型的測試金字塔結構，一個產品的測試可分為三個層級。第一層是單元測試，主要對程序函數進行測試。第二層是集成測試，在百度內部是大家常理解的模塊測試。第三層是系統級測試，對產品整體進行的測試。這種測試分層原理同樣遵循二八定律，越往下的層級，往往用較小的測試成本，就能換取較多的功能覆蓋；而越往上的層級，往往會耗用很多的時間，卻發現很少量的問題，但是一旦有bug出現，問題影響面、定位成本，修復成本也是很高的。因此很多新的產品線，在系統級測試上的技術投入，是望而卻步的，往往僅在最終上線前，才在接近線上的真實環境上做人工驗收測試。

然而像搜索、廣告這種系統架構非常復雜，質量要求又特別高的產品，就比較依賴系統級測試的手段來保證線上的穩定性，往往一個系統性能缺陷或異常分支問題，就有可能影響到上百萬的流量或收入損失。因此在很多產品線系統級測試是上線不可缺失的一環。

產品創立初期系統比較簡單，系統級測試往往并不會成為測試效率的瓶頸。但隨著系統架構越來越復雜，對于系統級測試技術和自動化水平的要求也是與日俱增的。百度商業產品的系統級測試技術，有著超過6年的技術積累，期間也是經歷了幾次技術的演進。這篇文章就給大家回顧一下，這幾次技術架構演進，團隊是怎么樣根據產品需求和公司導向不斷變化而一直努力和堅持，把系統級測試技術從0分做到60分，又從60分做到90分的過程的。

演進歷史

▌手工測試時代

還記得2009年之前系統只有幾個模塊的時候，當時的環境還是比較簡單的，有兩臺機器就能把整個系統給部署起來，當然那時候的環境部署也是靠人手工從線上同步的。QA通過apache自帶的ab工具或通過loadrunner模擬http請求，對系統進行發壓，壓力結束之后通過手工執行一系列stat腳本統計出模塊的各種性能數據，最后編輯到word文檔里，作為當時的主要一份測試報告內容。

這個時代，沒有太多可講的內容，當時百度還是普遍以傳統瀑布開發流程和手工測試為主，在團隊規模相對較小以及迭代效率相對很低的情況下，這種測試手段也沒有遇到明顯的瓶頸。

▌自動化腳本時代

2009年開始百度QA內部開始大力發展自動化。當時很容易想到了，系統級測試改進的第一站就是如何將重復的，手工執行的工作用腳本給自動化起來。因此有了后面的一鍵自動部署環境，一鍵自動發壓，以及自動生成報告等功能。相比手工測試，效率上的確有了一個質的飛躍。

但同時也發現像環境搭建、壓力、性能、diff等測試各種工具推出來之后，工程師學習使用和配置這些工具的成本變得很大。工具之間也有很多重復性的邏輯，比如所有工具都需要考慮模塊啟停控制，日志分析等功能。另外，當有項目并行時，機器協調及溝通成本就變得越來越大。

▌自動化平臺時代

為解決自動化腳本泛濫之后帶來的技術冗余以及測試過程管理等問題，團隊從2011年開始考慮建設業務線自有的系統級測試平臺。

平臺設計成測試平臺、環境、任務三層管理模式。測試平臺是一批資源的集合，該資源可以用于部署不同場景的測試環境，每個環境上可以串行的運行多個測試任務。平臺通過合理的調度，使得多人使用的時候，資源可以互斥。另外，通過可視化的配置管理，使得底層工具對用戶透明，用戶僅需要關注環境需求和測試場景需求本身。

為解決工具泛濫的難題，首先從工具層面定義了統一的接口規范，以及所有工具放到統一的框架中進行開發。通過將環境工具以及各種系統測試工具底層抽取了公共的lib以及環境操作lib，使得各個工具之間重復的功能得到了有效控制。另外各個工具對平臺暴露統一的接口，使得平臺在調度不同的工具的時候，都能用統一的邏輯。

為解決系統架構日益膨脹之后帶來的資源成本的難題，平臺引入環境解耦技術，將產品拆解成多個子系統，通過驅動和樁模擬系統上下游服務，使得每個子系統都能獨立的進行測試，通過流量錄制和回放技術，使得測試效果接近真實系統。從這個方案中大家也能看到，系統拆分不是很靈活，且不同的拆分方案下，需要定制不同的下游樁來做定制回放，整套方案的管理成本也是不小的，這個也為后面可定制子系統的發展打下了很好的基礎。

產品的系統級測試由此進入到工業時代。整個團隊的測試模式和工具研發模式也因此平臺的誕生而變得更加規范、統一。

▌測試云時代

產品線從2011年開始推行持續集成研發模式轉型。在持續集成能力建設初期，也感受到了此前積累的測試自動化在此過程中發揮了更大的價值。但同時也發現，持續集成使得系統級測試的需求變得更加頻繁，為了保證主干的穩定性，甚至想嘗試把系統級測試前置到開發階段來執行，這樣對于系統級測試資源和執行效率的要求也變得越來越高。

考慮到平臺對于資源管理的方案，還是一個個獨立的私有集群，由于集群之間用戶、環境和任務分布不均與，帶來很大的資源浪費以及任務排隊等問題。隨著業界Cloud技術的發展，也給系統級測試技術優化帶來了新的思路。通過將資源整合和模塊混布，使得相同資源的情況下，任務的吞吐量得到了一個很好的提升。另外多個用戶共同競爭剩余資源，整體的任務排隊時間也有了一個很好的控制。為減小資源靈活分配帶來的環境數據遷移的成本，引入hdfs/nfs做中間數據緩存，通過增量存儲技術，使得環境數據可以進行快速的快照和鏡像恢復。

同時，為了進一步縮減測試成本，希望系統可以解耦到任意組合。在此前子系統解耦的方案的基礎上，也進行了重構。

錄制環境從線下搭建的環境遷移到了線上旁路，模塊的更新更加及時，截取的數據更加真實實時，線下仿真效果更好。

通過nb（百度內部使用的通用截包工具）+redis做數據回放服務，免去了此前stub的數據管理和部署成本。

系統可以任意定制，缺失的下游通過回放服務來補充數據，數據覆蓋和測試效果可以和全系統下的表現相當。

這套方案在很長一段時間內支撐著鳳巢檢索系統從數10個模塊發展到上百個模塊，幾百人研發團隊的持續集成工作開展，是幫助鳳巢團隊成為公司第一批CI標桿團隊的重要武器。同時基于業務線多年精細化的打磨，也為后面平臺化的重構提供了很好的技術保障。

▌平臺化時代

2014年，在公司提出的接口化、平臺化的戰略口號下。平臺也在考慮如何將系統級測試這種技術門檻很高的技術抽象成服務，從而在其他產品線得到更廣泛的使用和推廣。因此平臺進行了一次整體的重構，旨在通過提供一套通用的建模工具和測試組件，使得產品線構建系統級測試能力可以像搭積木一樣簡單、靈活。

平臺提供兩個通用測試組件。一個是環境搭建組件，可以支持單機、多機部署方式，物理機/虛擬機/容器等多種資源形式，和公司內的主流PAAS平臺打通。另一個是系統測試組件，通過一些合理的抽象分層設計和靈活的測試場景描述能力，產品線只需要通過簡單的配置，就能夠支持性能、diff和壓測等不同的系統級測試場景。同時框架支持開發diy插件，滿足產品線定制化的場景需求。當然產品線也可以自己開發工具，只需要實現平臺所定義的接口，就可以接入到平臺變成服務。

平臺提供了一套拓撲建模工具，產品線可以根據被測系統的部署和測試需求，構建測試拓撲。平臺通過三層結構來刻畫測試需求，第一層是模塊，產品線可以配置模塊的CPU/MEM/DISK/PORT等需求，以便平臺可以調度到合適的資源，同時需要模塊設置一些靜態參數（如log位置、啟動命令、啟動線程數等）和自定義參數，使得工具和平臺可以更好的理解模塊的屬性。這里除了被測模塊，測試程序也需要進行定義，如driver/stub。第二層是子系統，也可理解是被測模塊的集合，方便用戶理解測試范圍。第三層是拓撲模板，產品線根據測試場景驅動，繪制出測試系統的拓撲，可支持模塊分組、多實例，以及支持實例間直連/混連，同時選擇和配置配套的環境工具和測試工具，就能構建出一個用戶可見的測試服務。

用戶使用的時候就比較簡單了，只需要選擇拓撲模板，搭建環境，啟動測試任務，即可由平臺調度，最終生成測試報告了。通過平臺化重構，使得開發者更加專注工具的實現邏輯，而不用資源和任務調度。用戶更加關注測試需求本身，而不用考慮工具和資源細節，最終形成一個良性發展的平臺生態。目前平臺已經支持公司內幾十個產品，每周接近1W次規模的系統級測試任務執行。

總結和未來展望

通過歷史上三次大的系統級測試技術的重構，從業務線專用做到公司通用，不斷將技術和用戶體驗做到極致，這里有很關鍵的三點信念。

與時俱進：技術的發展需要適應產品業務的發展需要，追求過度設計或者設計不足都會導致項目失敗。

匠人精神：任何技術的成功都不可能一蹴而就，需要一點點做起，并不斷在產品線進行打磨，當技術遇到瓶頸的時候，要敢于尋求突破而不是逃避。

開放心態：通過內部開源，擴大技術生態。沒有任何通用的技術可以解決所有產品線的問題，只有通過開源讓可以讓大家共同參與改進，才能讓產品線不會因為10%的需求不滿足而放棄使用技術。

平臺離一百分的目標還很遙遠，微服務、容器化技術的迅速發展，使得系統的環境部署和測試變得更加復雜，同時也對測試工具和平臺有著更高的標準規范。線上測試也是系統級測試場景創新的下一站，到時候也會對工具和平臺提出新的要求。只要抱著十年磨一劍的信念，緊跟著公司和業務發展的步伐不斷前行，相信系統級測試的技術還會迎來更多的創新和挑戰。

作者介紹

董海煒

百度資深測試工程師，多年從事復雜檢索系統的系統級測試和持續集成工作，在測試自動化和平臺化方面有著豐富的實踐經驗。