生產引流測試

“生產引流測試”的方法，這種方法的本質就是 把生產系統發生的一切復制到測試系統上來。這種測試方法適合有大量用戶的系統，如電商網站、電信計費系統、大型控制系統（如機場調度系統）等。這么做有兩個好處：

1.能夠讓系統在真正上線以前就能夠真正經受實踐檢驗。多年來的測試實踐告訴我們，測試永遠是抽樣活動，即使經過很大強度的 充分測試，很多大型系統上線后仍然馬上會產生這樣那樣的問題，有時候這些問題往往是致命的。

2.不會象灰度發布那樣拿部分用戶當小白鼠，引發部分客戶不滿；其實要實現灰度發布在一定程度上會增加系統架構復雜性，不是哪個公司都能玩得轉。

當然生產引流測試必須滿足一個前提： 那就是已經有了生產系統，在特性升級或者技術重構的時候使用這招。 ^_^|||

生產引流測試的用法一般有如下幾種：

1.非功能測試（主要是性能測試），看看將生產系統的壓力引到測試系統后，測試系統會不會產生性能問題。這種測試往往非常有效，因為，我們做性能測試也是非常有局限性的：場景選取不可能跟真實用戶帶來的壓力完全一致；網絡、硬件環境也可能不一樣；某些超大型網站根本沒辦法模擬那么大的壓力，只能依靠縮量模型做測試并估算真實的性能。

非功能測試不太關注業務邏輯的正確性，因此我們可以從網絡層進行生產引流，這樣效率更高，模型更加簡單。目前有一個非常不錯的工具tcpcopy，非常適合web類產品。它的工作原理可見下圖：

部署一個agent在onlineserver上。從tcp層截取數據包，然后生成向Testserver的請求數據包（通過換網絡傳輸的數據包的包頭）， 這樣壓力就傳導到了Testserver上。Testserver的響應數據包被 Assistant server截獲，截獲后拆包，刪除包中內容（減小部署在Online Server端agent的壓力），封包，回復給Online Server上的agent（TCP協議要求必須有來有回）。Tcpcopy在網易，淘寶，去哪兒等很多公司都得到了非常好的應用，目前國外也有很多用戶開始使用這個工具了，如果大家有興趣可以查看作者在Github上的頁面 https://github.com/wangbin579/tcpcopy 或者作者的博客： http://my.csdn.net/wangbin579 很贊作者王斌！

2.功能測試

對于功能測試，單純的使用tcpcopy就有些不足了。 因為功能測試關注業務邏輯，我們一般要對結果內容進行比對，而不是簡單的拋棄。而在網絡層進行內容比對代價是非常大的，有時候是不可完成的任務，如非web類產品；另外，不同的技術架構造成了某些內容是無法簡單在網絡層復制的，如某些加密信道傳輸的內容、包含了認證信息的內容、對目標機器信息有依賴的內容。這樣， 我們就需要在應用層想辦法，而不是在網絡層。一般我們會在應用層加一個代理將請求和響應進行復制，這個代理根據被測系統的技術架構不同而不同，比如web服務器，可以搞一個反向代理來做這件事兒；銀行、電信用的多的Message Queue 可以采取pubsub的模式；可以在交易中間件、企業總線上做一些改造，只要系統設計的不是太難搞，辦法總是有的。

下面給出一個最簡單的模型：它描述了 技術重構的系統（功能上無變化）進行生產引流測試的思路。

實時對比：

與實時比對相比，延時比對模型的變化如下：

代理的作用變成了紀錄生產日志，有時候能夠直接利用系統的日志模塊數據，不用分流，性能壓力減少了很多。

多了一個存儲模塊存儲日志（有可能復用系統現有日志模塊）

多了一個對比引擎，它的作用是：從存儲取出成對的請求-響應的數據，將請求數據發送到測試系統，接收測試系統的響應，與存儲中的響應結果比對，然后生成報表。

引擎可能要做比較復雜的日志分析工作：請求-響應配對，清洗無效數據，做數據篩選等。

由于做了隔離，基本上杜絕了測試系統污染生產系統的風險。

延時比對也有很多缺點：有很多技術架構，實時復制比記log再還原要付出的成本小很多；發現缺陷的時間點出現延遲。

 

對于 業務升級類型的 系統，業務流程或者計算邏輯發生了變化， 使用生產系統數據進行比對的難度就大大增強了，但還是可以做，模型如下：

這張圖跟上張基本一樣，唯一的不同就是比對引擎變成了“加強型”比對引擎。

加強的地方表現在：對業務不同點進行處理，使得比對工作能夠順利進行。

有一些技術架構下，對不同點進行處理非常困難。例如，web應用，一個表單多了一項。你有可能要重寫http請求的內容。

 

小結：是否要利用生產引流測試說到底還是一個工程型問題。 一定要看它的投入產出比。