生產引流測試

　　在上篇文章《讓用戶幫你做測試》中我提到了“生產引流測試”的方法，這種方法的本質就是把生產系統發生的一切復制到測試系統上來。這種測試方法適合有大量用戶的系統，如電商網站、電信計費系統、大型控制系統(如機場調度系統)等。這么做有兩個好處：

　　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的模式;可以在交易中間件、企業總線上做一些改造，只要系統設計的不是太難搞，辦法總是有的。

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

　　實時對比：

　　在上圖中：

　　紅色箭頭為生產請求數據。

　　藍色箭頭為生產響應數據。

　　綠色箭頭為測試響應數據。

　　代理有2個作用：復制用戶到生產系統的請求，引流到測試系統;復制生產系統的響應發送給對比器。

　　對比器的作用：比對同一請求生產系統和測試系統的結果是否一致，將結果生成報表。

　　比對是實時的。

　　請求和響應必須附加流水號：這樣做比對的時候才會不那么費勁(應對異步的情況)，否則

　　生產系統同測試系統的初始狀態必須一致，不然做比對也會很困難：舉例來說，電商網站中某種書的庫存數。

　　實時比對的好處是：能夠在出現bug的第一秒就發現它。但它也存在問題和局限性：生產系統與測試系統直接相連可能給生產系統帶來風險，實際上在很多生產安全要求較高的公司，這么做是不被允許的。

　　延時對比：

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

原文轉自：http://www.cnblogs.com/skytraveler/p/3542046.html