1 背景與挑戰

1.1 數據平臺業務背景

數據平臺利用大數據智能分析、數據可視化等技術，對公司內外部經過采集、建設、管理、分析的多源異構數據進行呈現和應用，實現了數據共享、日常報表自動生成、快速和智能分析，深度挖掘數據價值，滿足企業各級部門之間的數據分析應用需求。因而也具有數據量大，場景多，數據準確性要求高，查詢性能要有保障等特點。

1.2 傳統測試方法

基于數據平臺的特點，使得我們在線下進行數據測試或者回歸測試時成本比較高，難度也比較大。所以我們希望能有一種有效的手段來降低測試的成本和門檻，實現測試的標準化。一直以來我們都是通過編寫自動化測試來實現的。但是傳統的自動化測試其實是有很多弊端的，比如成本高，覆蓋場景有限，標準化難度高等。

1.3 傳統自動化的弊端

1.3.1 成本高：

人工編寫、維護自動化用例成本高

較低的測開比無法跟上迭代的速度

1.3.2 覆蓋場景有限：

線下構造測試場景難度大

場景覆蓋度有限

1.3.3 標準化難度高：

強依賴 QA 個人經驗和能力

開發獨立排查自動化問題難度高，推動開發自測效果差

因此我們希望利用線上的流量來搭建一個流量回放的平臺，與自動化測試結合，來實現一個符合數據平臺特點的自動化測試體系。

2 流量回放平臺介紹

流量回放的實現原理即是使用線上入口錄制用戶操作的真實流量，到預發環境進行回放，對比生產和預發環境錄入接口的子調用、響應差異去定位代碼問題，接入對象范圍是只讀、讀寫、只寫接口，優點是業務代碼零侵入，自動流量 diff，真實鏈路調用，數據可查，問題定位精準，發現問題的可能性提高，缺點是面向范圍有一定局限性，操作不慎可能導致回放的接口中存在寫操作的子調用產生臟數據，影響業務。

2.1 流量回放平臺調研

確定之后我們便立刻展開了調研，研究對比了公司的流量回放平臺，阿里的 Doom 以及 Twitty 的 Diffy，差異如下圖。

2.2 數據平臺業務特點

因為數平報表的查詢特點， 導致代碼中對外查詢鏈路少，對內的維度條件業務組合多，基于這樣的特點導致在使用 Pandora 平臺錄制線上流量時，流量錄制不全，大多數場景無法完全覆蓋。

復雜的數據平臺一般都依賴大量屬性配置管理、定時同步任務等，因此預發環境和生產環境配置庫需要隔離，保護數據不被污染。而流量回放又依賴配置庫和數據庫相同，使用場景高度依賴配置數據， 導致回放落地難度大。

數據平臺的流量回放，驗證結果時往往需要對數據進行校驗， 請求會對生產數據庫造成一定查詢壓力，可能會影響生產環境穩定性。需要控制好回放速度和控制、監控和降級保護。

部分數據是實時的，回放結果需要計算波動率。

基于以上特點導致數據平臺無法接入公司的 Pandora 平臺，我們也在第一時間聯系公司平臺負責人進行溝通和提出改進需求方案。 但問題的迫切使得我們決定先小成本的進行一些工作，一方面盡快緩解我們的痛點，一方面也要方便后期接入公司平臺，減少資源浪費。以此為目的，我們在一期使用腳本采集流量， 并借助開源工具 Diffy 快速實驗了一套簡易的流量回放系統。同時給平臺提出適應性接入需求。在二期時，將腳本采集的流量上傳至平臺，接入平臺進行流量回放。 這樣的好處是：

流量自主可控，可根據需要定點擴充流量，無需擔心流量稀疏、錄制對線上環境的影響、接口覆蓋不全等問題。

使用日志或埋點的方式采集流量，為流量采集提供了一種流量采集的新思路

開源工具只有部署和熟悉的資源投入，后期接入平臺后可回收資源，沒有浪費資源重復造輪子

基于以上背景，進行了數據平臺的流量回放實現方案。

2.3 核心原理

整體思路依然是沿著線上獲取流量，分別在不同代碼環境進行回放，最后對接口返回結果進行比對，以達到檢測被測代碼準確性的目的。這里我們將生產的流量根據時間、接口白名單和操作人等字段進行過濾，并按照窗口進行流量的去重和篩選，最后沉淀為一個穩定的流量池。任務觸發后會并發的按照指定速率向預發和生產雙發回放，獲取接口的返回結果，經過一系列降噪操作后，根據字段對比結果統計出整體的成功率，并產出報告。下面我會從流量采集、環境策略、執行調度、比對結果四個方面來介紹整個方案。 ~ 流量回放交互構架圖～

2.3.1 流量采集

通過公司的流量錄制方式， 接口覆蓋提升難度較大， 不太適合數平對外鏈路少，條件組合多的特點，因此我們想通過埋點篩選的方式進行流量采集。這樣的好處是完美避免了流量錄制過程中流量分布不均，降低對線上服務的性能影響，同時接口的覆蓋又非常的完整。實現了自主可控，定點獲取流量。 在流量采集中，我們會分批次的去生產系統上根據配置的日期和數量不斷地撈取流量，對每一個批次流量根據入參和請求路徑進行接口去重，并根據梳理好的接口白名單、流量操作人、接口關鍵字、請求類型等來過濾數據，然后需要對流量中的臟數據進行篩選、對參數中的特殊字符和多余字段進行修正。最后將清洗好的干凈數據保存到本地流量池中，等待任務使用。 在后期，處理后的流量會通過接口上傳至流量回放回放 Pandora 平臺，通過我司的平臺化工具更便捷高效的管理流量和執行。 上傳后即可在流量回放平臺查看流量，這里也可以通過 excel 的方式手動上傳，但是每批次流量數量受限。

2.3.2 環境策略

環境采用了預發和生產兩套環境對比。通過配置將預發環境的數據來源指向了生產服務。并且定時同步生產的配置庫到預發環境，來解決數據和配置的 Gap。

2.3.3 執行調度

調度有兩種方式， 一種是配置定時觸發，一種是手動調用接口觸發。任務觸發后，會獲取流量池中的流量，并對流量的關鍵字和執行數據量級再次判斷是否可執行。確認執行后，將流量放入線程池中開始回放。這里采用了定長線程池和速率控制器來實現高并發和靈活的請求速率配置。 在任務執行后，也可以根據實際執行情況隨時修改配置來停止任務或者調整任務的發送速率，控制對線上環境的影響。

2.3.4 比對結果

拿到生產和預發的返回結果之后就是對比兩端結果，發現不一致的字段和返回，介于數平的特點，噪音點會非常的多，因此引入了 AAdiff 的方式，來達到自動降噪的功能。如何降噪： a. AAdiff ：在對比之前， 連續調用兩次生產環境，獲取結果后對比， 將不一致的字段剔除。即可去除不穩定或者有波動的字段 b. 指定字段忽略：跟對一些配置字段或者無意義字段進行手動配置忽略，降低噪點。 結果差異對比匯總后， 會根據字段進行分組匯總，對與 AAdiff 不通過的字段會直接置灰。點擊字段即可在右側查看字段下差異的數據。 通過點擊差異詳情，可進一步看到請求的 path、請求體、生產和預發的返回值等信息，幫助排查定位問題。 同時在結果報表中可以觀測到流量數、回放成功率等信息。

3 業務實踐

這里以智能運營系統為例，對比流量回放接入前后的效能成本差異。 通過流量回放的方式，不僅快速提升了自動化的接口覆蓋，降低了迭代人力投入，更是增強了回歸的可靠性。這一點通過迭代質量變化趨勢也能很好的反應。 平臺數據： 流量回放工具在 513 迭代初步使用， 但覆蓋率和穩定性較差， 514 迭代完善，正式投入使用。 在 514 迭代工具正式投入使用后，發現遺漏 bug 比例達 25%，515 迭代質量有明顯提升， 連續兩個迭代線上無缺陷逃逸發生。平臺質量和穩定性明顯提升。 目前智能運營流量回放投入使用至今，已持續支持多個迭代的日常回歸測試以及日常壓測工作，讀接口覆蓋率達 86%，回放通過率穩定在 98%，發現回歸漏測比率達 25%，大大提高了系統的穩定性和線上質量。

4 規劃與展望

智能運營系統流量回放已進入維護階段，在日常迭代中幫助測試實現冒煙、回歸、壓測、緩存驗證等多種任務。后續將通過精準接口流量獲取的方式，將少部分稀疏接口納入覆蓋。并將流量上傳至流量回放平臺。借助流量回放平臺的能力，更加穩定、方便的執行計劃和排查問題。 基于數據平臺各系統以讀接口為主的特點，非常適合流量回放的回歸形式，后續會將各個系統按優先級陸續接入我司流量回放平臺，并通過流量埋點的方式快速提升接口覆蓋。