架構升級的救星！流量回放自動化測試的必備指南
Hello，大家好呀，我是小米，一個29歲的技術宅，今天要跟大家分享的是物聯網領域裡的一個非常實用的技能——流量回放自動化測試。
在日常的開發和維運過程中，系統升級和架構改造是不可避免的，尤其是系統級重構。對開發團隊來說，每一次大的重構後，測試迴歸的工作量是相當龐大的，動輒就是以月為單位的工作量。如果你不小心走進了這個坑，想想那些龐大的測試案例、複雜的場景，光是想想就頭痛吧？ ！
系統重構後的挑戰
我們常常會遇到以下幾種場景：
- 場景1：讀取服務基本上是無狀態的查詢，狀態不會改變，簡單、輕量，資料可以輕鬆回傳。
- 場景2：不管是架構升級還是日常的功能需求，讀取服務的外部介面格式一般不會變化，即輸入輸出的格式是保持不變的。
這種看似簡單的場景卻是系統重構中的困難之一。你會發現，雖然資料本身沒有問題，但重構後的邏輯往往藏有看不見的Bug，而這些問題通常是在生產環境下才會被揭露。這就產生了一個問題——如何在不影響線上服務的情況下進行全面的自動化測試？
兩種常見但難以實現的因應方案
很多公司在面對重構時，會提出兩種常見的因應方案：
- 先不改造，等系統頂不住了再想辦法：這是一種「先拖著」的策略，問題會累積到爆發點，但很容易造成系統崩潰，得不償失。
- 暫停需求，全力進行改造：雖然這種方法聽起來比較理想，但在實際的工作場景中，業務需求永遠不會停止，暫停需求意味著損失市場機會、延遲交付等問題。
實際情況是：
無論哪種策略都很難實現，既不能讓系統崩潰，又不可能完全停止業務需求，這就迫使我們需要找到更好的方式來應對這個問題。
日誌收集與流量回放的應對策略
這裡，小米要介紹的一個非常實用的方案就是──基於流量回放的自動化測試。這個方法的核心思想就是：日誌收集和資料回放。
日誌收集
首先，我們需要對使用者的真實請求進行日誌收集。日誌的作用不僅僅是儲存訊息，更重要的是，它可以用作回歸測試的用例。
如何實現日誌收集呢？在Spring框架裡，我們可以透過Interceptor，在Servlet裡我們可以用Filter過濾器來實現。對於每個請求的入參和出參，我們都需要記錄下來，並透過訊息佇列（MQ）傳送到儲存體中。
這裡需要注意幾個問題：
- 錯峰處理：避免短時間內大規模資料湧入所帶來的效能問題。
- 資料過濾與去重：避免冗餘資料佔用儲存空間，並確保資料的有效性。
數據回放
接下來就是關鍵的步驟——資料回放。透過日誌收集的歷史請求數據，我們可以對重構後的系統進行資料回放，模擬真實使用者的請求，從而進行自動化測試。
資料回放可以分為三種模式：
- 離線回放：僅呼叫新服務，將新服務的回傳結果與日誌中的原始出參進行比較，不直接影響線上系統，但由於日誌量大，對儲存的要求較高。
- 即時回放：同時呼叫線上系統和新系統進行請求，即時對比它們的返回結果。缺點是對線上系統有一定的性能影響，適合在系統壓力較小時進行。
- 並行回放：新版本不直接上線，而是以一定機率在調用舊版本接口時並行回放新版本接口，週期較長，但影響較小，適合在系統穩定上線前進行。
差異對比與Bug 定位
資料回放的結果如何？最終我們關心的當然是能不能找到重構後的Bug！透過差異對比，我們可以自動發現那些與預期不一致的用例。
在這個過程中，我們可以透過文字對比的方式來快速發現問題。由於介面的輸入輸出格式保持不變，我們只需要對比傳回的特定資料是否有差異。例如，有些欄位的值可能在新舊系統中表現不同，這就可能是潛在的Bug。我們可以將這些差異標記出來，交給開發人員進行進一步定位與修復。
實踐中的技巧
在實際實施流量重播的過程中，小米也累積了一些小技巧，來幫助大家更好地運用這個工具。
- 日誌壓縮與儲存最佳化：流量回放所產生的日誌資料量非常龐大，因此需要考慮日誌的壓縮與儲存最佳化策略。我們可以對收集到的日誌進行壓縮處理，或定期清理不再需要的舊日誌，節省儲存空間。自動化工具鏈的整合：將流量回放與現有的自動化工具鏈進行集成，可大幅提升測試效率。例如結合Jenkins 等CI/CD 工具，自動觸發回放測試，自動記錄差異並產生報告。灰階發布與流量回放結合：在灰階發佈時，可以使用流量回放進行新舊系統的平行測試，從而提前發現潛在問題，確保新版本的穩定性。
流量重播的優勢
總的來說，流量回放為系統重構後的回歸測試提供了一個自動化、高效、低幹擾的方案。相較於傳統的手動測試，流量重播有幾個明顯的優點：
- 真實使用者請求：基於真實的使用者請求日誌，確保測試場景覆蓋全面。
- 自動化迴歸測試：減少人工測試的工作量，提高效率。
- 快速發現問題：透過差異對比，能夠及時發現並定位Bug。
- 低風險：新版本不直接上線，避免了對線上業務的干擾。
END
流量回放自動化測試為我們在應對系統重構時，提供了一個既能滿足業務需求，又能保障系統穩定的解決方案。透過日誌收集、資料回放和差異對比，開發團隊能夠快速定位問題，減少回歸測試的工作量，大幅提高系統升級的效率。