摘要： 阿里內部誕生一了個依賴真實流量用於自動回歸的自動化測試平台，通過創新的自動mock機制不僅支持讀接口的回歸驗證，同時支持了寫接口驗證，在內部產生了極大價值，有價值的東西就應該分享，目前該工具已經作為雲服務對外開放。
背景
信息系統上線后通常會需要迭代升級甚至重構，如何保證被修改后系統原有業務的正確性非常重要。不復雜的業務系統通過一些常規的自動化測試工具加上人工測試可以解決，但對於業務十分復雜的系統，回歸測試將變成一項浩大的工程。
一個實際的例子：阿里巴巴作為一家以電商為核心的集團公司，交易系統和穩定性的重要性不言而喻。整個交易系統在多年的發展過程中，經歷了很多業務的上下線，維護的人員也換了一波又一波，幾乎沒有人能梳理清楚其中的業務和代碼。當它不得不面臨一次全面升級的時候，其回歸測試的困難度難以想象。因為常規的自動化測試工具需要准備測試數據、編寫腳本，因此覆蓋率不高，因此無法滿足需求重構后的回歸驗證要求。
doom平台的出現解決了這一難題，它通過復制線上真實流量去做自動化回歸，通過它發現了很多重構帶來的bug，同時加快交易重構項目的上線進程。同時通過錄制流量作為用例來實現日常自動化回歸取代傳統編寫腳本的自動化回歸大大提升了回歸效率和覆蓋率。
因為其解決方案的通用性，我們把這它拿出來給大家分享，同時也開放了雲服務希望能支持到有需要的用戶。
平台介紹
什么是doom平台
doom自動回歸平台是一個將一部分線上真實流量復制並用於自動回歸測試的平台。 通過創新的自動mock機制不僅支持讀接口的回歸驗證，同時支持了寫接口（例如用戶下單接口、付款接口）的驗證。它最底層借助了java的instrument實現aop因此，目前僅支持java應用的接入使用。其原理圖如下：
它與tcpcopy或者diffy的區別：tcpcopy、diffy是在應用外的網絡層實現流量錄制和回放的，它們只能實現一些只讀頁面的驗證。doom是在應用內部通過aop切面編程方式實現的流量錄制和回放功能，因此可以做到應用內部接口級別的回歸驗證，當然也支持服務級別或者http級別的回歸驗證。通過獨創的中間件級mock以及內部自定義的mock，可實現寫流量的回歸驗證以及跨環境的回歸驗證（線上引流到測試環境）。
應用場景
系統重構時，復制真實線上環境流量到被測試環境進行回歸，相當於在不影響業務的情況下提前上線檢測系統潛在的問題。
可以將錄制的流量作為用例管理起來進行日常自動化歸回。
優勢
低成本：無需編寫測試用例，通過流量錄制形成豐富的測試用例。
高覆蓋：一方面線上大量真實流量確保覆蓋率，另一方面支持中間過程的驗證，例如發送消息的內容、中間計算過程等等的全對象的對比驗證，傳統手工編寫驗證點很難實現。
支持寫流量驗證：（注：寫流量是指可能導致有數據變更的流量）不用擔心寫流量回放污染應用數據，支持線上引流到測試環境以及寫流量的自動化mock。
低應用侵入：通過隔離容器技術、字節碼級別的AOP技術、中間件級MOCK避免接入類沖突以及降低接入成本。
如何使用
doom平台在阿里巴巴內部，特別是一些核心系統得到廣泛使用，因此我們決定把這個產品開放出來，以雲服務的形式免費提供給大家使用。doom支持 雲效 上的應用直接申請使用，也支持任意能訪問公網的應用直接申請使用。
平台文檔：接入使用指南
平台鏈接：doom平台
原理
如何實現回歸驗證？
對於web應用來說，請求最終都通過發起http請求方式來完成。我們假定生產環境應用會正常的響應用戶的請求，通過aop的方式將請求入參及返回結果以及執行過程中的一些快照數據例如訪問數據庫的入參和返回結果、訪問遠程服務器的入參及結果保存下來。然后將快照數據發送給測試機器（代碼發生變化的機器）完成一次回放過程。通將落庫數據、調用后台請求的數據以及返回結果和線上真實請求發生時的數據進行全量對比，發現其中的差異，從而識別被測試系統的問題。針對后台應用來說也是如此，只是后台應用一般都是通過rpc請求實現，這時只要記錄rpc入參、rpc返回值以及中間快照數據用於回放即可。
如何保證數據庫不被污染？ 
mock是單元測試常用手段，用來解決接口未完成或者調不通的情況。將這個特性進行延展，在線上執行真實請求時就把寫數據庫的請求以及對外服務的訪問保存下來，在回放時當執行數據庫或者調用后台的服務進行mock，這樣回放時不會真正的訪問數據庫，也不會真正的發起對后台服務的調用，因此會影響業務數據，甚至可以在線下環境進行回放，因為mock數據來源於真實請求，也省去了造數據的麻煩。
如何實現對外系統請求的mock？
應用會通過各種各樣的中間件對外發起rpc請求，可以通過平台配置的中間件隔離來設置，平台客戶端會對這些中間件進行aop處理實現自動的mock，不需要人工去配置具體的rpc接口。如果不支持的中間件請聯系我們，我們會對其做適配開發。
如何解決回放時程序執行流程可能和線上真實流程不一致？
在生產環境程序執行時的一些內存數據狀態和回放時測試服務器的內存數據狀態往往會出現不一致，這些不一致會導致程序的執行流程不一樣。例如本機緩存、內存開關、session查詢等等。那么要如何解決呢？平台提供了自定義mock機制，將這些會導致不一致的代碼片段進行mock。例如將緩存的get方法進行mock，那么如果線上讀緩存時有數據，那么回放時直接可以用這些緩存數據進行mock即可，確保了回放的流程和線上真實執行時一致。
如何解決對比時的噪音？
回放時和錄制時必然存在一些差異，例如服務器ip、時間、以及一些隨機數等等。通過兩種方式去解決：
排除法：平台支持指定字段排除對比，將不需要的字段排除即可。
指定對比法：將關心的業務數據進對比。
系統架構
部署圖
如圖上所示，雲服務提供配置管理功能，而在用戶機房可以通過擴展實現自定義數據存儲或者直接使用阿里雲oss存儲產品來實現用例或者流量的存儲。配置之所以集中管理是為了方便平台升級，而支持數據自定義存儲則提供給了用戶更多的存儲選擇。
圖中A企業完全使用平台功能，如果平台功能不滿足需求也可以像圖中企業B一樣，基於平台提供的錄制、回放等等能力去實現自己的穩定性/回歸測試平台。
客戶端服務端架構
上圖為客戶端服務端的架構圖。客戶端為接入應用嵌入的一個功能模塊，可以負責流量錄制、流量回放、中間件mock、中間件隔離、流量對比分析等等功能。服務端提供客戶端相關的配置信息，例如要錄制哪些流量，錄制比例是多少、哪些ip服務器需要被錄制等等。客戶端的一些狀態信息也會發送給服務端方便展示管理。另外只有當發生對比異常時，服務端才會發送異常數據給服務端用於查看分析。
要實現不同企業的不同中間件mock，客戶端需要擴展不同的中間件mock插件來實現。各個插件通過中間件插件管理器去管理，平台支持一些常用的中間件也支持擴展。除了mock外還需要提供了一個中間件隔離機制，例如通過在中間件最底層做一些隔離，避免在mock失敗的情況下不會訪問到數據庫，保證回放時業務數據的安全性，當然如果是在非生產環境進行回放測試也可以避免這個風險。
平台開放
錄制數據存儲到哪里？
平台默認將錄制數據保存到oss，也支持用戶通過擴展實現使用自己的數據存儲服務。
能基於doom平台實現自己的用例管理執行平台嗎？
doom平台開放了流量的錄制、回放以及對比的api，有需求的用戶可以基於這些能力快速搭建一套屬於自己自動化回歸測試平台。