阿里創新自動化測試工具平臺--Doom

摘要： 阿里內部誕生一了個依賴真實流量用於自動迴歸的自動化測試平臺，經過創新的自動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，有需求的用戶能夠基於這些能力快速搭建一套屬於本身自動化迴歸測試平臺。