得物技術

1 背景介紹

1.1 得物pandora介紹

什麼是流量錄製回放？流量錄製回放是應用端通過掛載注入錄製器探針自動註冊到服務端形成錄製流量回流，將所有外部調用依賴的響應內容（如資料庫、分布式緩存、外部服務響應等）進行完整記錄。由平台向回放器分發流量回放指令。其核心價值是通過直接錄製生產的真實數據，將生產真實數據轉化成可復用、可執行的流量，快速地在測試環境中進行回放比對接口返回值和中間鏈路的驗證。

得物版本的流量錄製回放平台pandora在官方開源版本上進行了很大的拓展，支持了很多官方版本不支持的子調用和入口調用。此外，平台還對得物的中間件進行了諸多適配工作，避免了大量的回放失敗噪音。

1.2 市場工具對比

目前市場上已知的流量錄製回放平台大部分都是在Jvm-Sandbox-repeater基礎上進行二次開發和改造，並且多數都是只支持Java語言。核心原理也都是通過錄製線上真實流量然後在測試環境進行回放，驗證代碼邏輯正確性。

2 實踐落地

2.1 協作模式

在具體的實施層面，目前採用的是業務測試，平台研發，業務研發三方協同的模式。任務分拆如下圖所示。

得物流量回放實施模式

2.2 階段應用

流量回放在各階段的理想實施應用：

• 提測階段卡點：聚焦核心場景，低成本驗證每次提測對於核心場景的影響；
• 測試回歸階段卡點：全量場景，重點追求覆蓋場景全面性，驗證新功能對歷史功能的影響；
• 預發環境回歸：目前預發跟生產同庫，未來會推動落地基於預發&生產環境的流量回放，儘可能拉近錄製時環境和回放時環境的仿真差異，從而降低回放階段的噪音影響；

在得物的整體QA體系中，流量回放短期聚焦在回歸兜底保障上。

得物疊代&項目時間軸

2.3 實踐落地

流量回放的開展自發起後，在本域由探索嘗試階段逐漸過渡到應用場景拓展階段。

訂單流量回放模式

在經過一段時間的探索，摸索出了一套適用於本域疊代的模式。

Part1、嘗試接入

團隊開始開展流量回放的專項之後，通過調研，選取了40%的服務優先接入。

1. 階段目標

• 完成30%P0應用top10 接口100%場景覆蓋，形成疊代落地質量卡點，完成適用性和提效分析；
• 增加訂單域流量回放人員投入，落地質量卡點，覆蓋5%回歸場景；

2. 實施方案

• 調研應用的特性，嘗試接入流量錄製回放；
• 梳理服務的P0接口及用例，配置對應的接口及用例標籤；
• 用例自動沉澱到用例集後，在回歸階段嘗試進行流量回放。

3. 收益成果

• 完成30%應用形成落地質量卡點，落地15%用例回歸場景，驗證方案可行性和易用性，摸索研發測試協同機制。

Part2、探索升級

上一階段花費大量的時間梳理接口配置標籤，用例沉澱速度緩慢，並且收益與投入不成正比，因此調整了策略，應用智能化分析進行提效，快速沉澱用例，擴大用例量及覆蓋的接口量。45%業務應用接入並均實現強卡點落地，配合平台側優化，解決大部分組件適配和使用問題，疊代應用流程以及應用指標分析機制基本跑順。

1. 階段目標

• 應用：接入的應用交由對應的服務負責人，負責對應服務的接口維護運營及沉澱、排錯分析；
• 用例：嘗試探索新的用例沉澱方式，進一步擴大用例量，增加覆蓋的接口量；
• 排錯：根據服務的用例量以及接入的時間，提升測試排錯能力，階段2結束測開排錯達到五五開；

2.收益成果

• 從開始試點到應用卡點，沉澱的用例量也在應用熱點流量方案之後開始了升級之路。接入的應用數也超過原定目標達到50%且均實現強卡點落地。
• 應用智能化分析策略提效效果明顯，沉澱的用例數成指數型增長，接入應用的P0接口覆蓋率達到100%。
• 測試排錯能力提升，每疊代流量回放發現的bug數也在增加，新方案的可實施性和可推廣性基本符合預期。

Part3、專項提速

在沉澱的用例case大量的增加、用例沉澱速度提效明顯的前提下，流量回放在疊代的應用中發現更多的缺陷，規劃擴大接入的應用以及覆蓋的接口範圍。

1. 階段目標

• 應用接入：新增40%應用接入，接入應用占比合計90%；
• 排錯：提升測試的排錯能力，新版本排錯由平台研發轉交業務研發，測試開發排錯占比五五開；
• 用例量：加速沉澱用例量，擴大覆蓋的範圍，至少65%的應用完成全量用例沉澱；
• 卡點：接入應用達到100%卡點，提升排錯速度，部分應用由生產卡點轉為預發卡點；
• 全域接入應用接口維度覆蓋率98%以上，接口配置完善度98%以上，全量用例路徑覆蓋率60%以上。

2. 收益成果

隨著應用的接入，沉澱的用例量也在擴大，發現的問題數也在增多。同時也增加覆蓋率的指標來衡量流量回放用例覆蓋的代碼占總代碼行的比值。隨著對覆蓋率的關注，平台採樣策略也進行了一個調整，刪除所有歷史沉澱用例，僅沉澱新策略實施之後錄製的流量。

• 流量回放接入90%應用，擴大應用接入和case沉澱，超預期達成目標，沉澱應用Case量是原計劃的3倍，此階段累計發現缺陷數占全域流量回放發現的bug數的45%，充分驗證了落地策略的有效性；
• 從階段3本域發現的缺陷統計來看，其中回歸類BUG占比38%，發現線上自有/隱藏問題占比8%，疊代過程中代碼問題（日誌報錯）和代碼規範類問題占比46%，性能問題占比8%；
• 接口配置完善度100%；接口維度覆蓋率96.49%；全量用例路徑覆蓋率79.32%，全量代碼覆蓋率平均39.8%；

3 總結分析

3.1 問題歸類分析

3.1.1 累計發現的缺陷分類：

3.1.2 累計發現的缺陷來源分類：

3.1.3 典型案例：

• 回放時系統異常，排查之後定位為NPE類問題，如：

• response返回的業務欄位diff對比不一致，如：

通過對缺陷以及缺陷來源的歸類不難看出：

• 流量回放發現攔截的問題近一半都是會引起生產業務報錯的，其中包括像金額不對涉及資損的問題以及欄位傳值不對、枚舉類型取錯等缺陷；作為生產發布前的最後階段的防線之一，充分展現了流量錄製回放作為對測試回歸的兜底能力的補充手段的重要性。
• 45%左右的問題是手工測試過程中難以發現隱藏比較深的代碼層面問題，例如NPE報錯、入參出參欄位未序列化等，這些問題如果僅僅通過前端測試或接口測試不看日誌不一一對比所有欄位勢必會將問題帶到生產環境，最終影響生產環境的穩定性。
• 6%左右的性能問題，例如存在重複子調用，影響接口RT，如果不在生產發布前發現解決，勢必給用戶體驗帶來一定的挑戰。
• 從缺陷的來源上看，發現的缺陷來源還是集中在項目疊代需求和技術優化上，充分驗證了流量回放整體提速後的有效性以及對測試覆蓋兜底能力的補充。
• 通過對失敗用例的排錯分析經驗的累積和分享培訓，參與專項的測試團隊的整體技術水平通過流量回放專項提速在技術氛圍上有明顯提升，培養了多位同學對自身負責模塊的實現的代碼走讀能力，以及深挖缺陷的code diff能力。

3.2 適用性分析

• 適用場景
• 適用於返回數據量大、業務流量也很大，以及讀取業務占比大的場景，如ToC產品。
• 不適用場景
• 掛載沙箱後開啟錄製會導致RT瞬間飆高，影響生產服務的穩定性。
• 異步場景目前流量回放平台不支持。
• 需要驗證資料庫的落地，節點的流轉的鏈路測試，需要自動化。

先投入能迅速形成能卡點有收益的應用（疊代代碼變更相對少，分層結構比較好，異步少，寫操作少），把看得到的使用效果做出來。

流量回放能否完全替代手工回歸以及自動化？

目前來看，答案是否定的。首先，從沙箱掛載到接口配置再到流量錄製這一套流程下來，也需要較長的時間才能達到較高的用例覆蓋，對於一些邊界極端場景還是需要手工設計；其次，流量錄製回放是後置的回歸兜底，更側重於對歷史邏輯的回歸驗證。

1、接口覆蓋不全。疊代需求新接口，未配置關聯錄製，不在流量回放的錄製範圍。

2、全量代碼覆蓋率不高。接口已經配置覆蓋了，但是由於採樣比例小場景極端等原因，接口的分支場景並沒有錄製到未被覆蓋。

3、排錯能力的高低影響。接口覆蓋了，排錯的時候由於新加了子調用，導致失敗的用例在排錯的時候容易被簡單定義為代碼變更。

4、平台問題。diff比對異常，顯示回放成功，異步線程的回放是一個待攻克的難點。

3.3 面臨的挑戰

3.3.1 排錯的效率

錄製流量後對流量進行回放，發現回放結果比對失敗的很多。經過對失敗原因的排查與分析，有些是代碼bug導致的失敗，但更多的失敗不一定是代碼bug，常見噪音主要包含：

• 代碼修改，新增或刪除了子調用，導致mock失敗
• 平台不支持的子調用，導致失敗
• 時間戳相關的子調用，diff不一致
• 子調用中使用隨機參數相關，導致mock匹配不上
• repeater代碼自身缺陷
• 業務自增數據差異
• 配置中心數據不一致
• 返回無序元素集合，造成結果對比誤差

失敗原因很多，真正有效的失敗數很少。如此一來，每次回放失敗的排查成本就非常高。給業務的推進造成了巨大的阻礙。

原版repeater上報的信息不夠豐富，很多情況需要看日誌才能排查。目前也沒有公開成熟的參考的方案。平台也進行了一些初步的探索，對回放失敗的場景自動進行歸類，上報更豐富的數據信息提供排查指引，幫助排查人員聚焦定位問題。同時平台也針對一些噪音進行自動識別並在回放時自動過濾降噪。

3.3.2 異步線程錄製回放問題

入口主線程不等子線程執行完就返回的異步場景，當前的策略是用戶可配置對異步子線程的多調用忽略，只關注主線程的執行情況。這一方式雖然可以提升這種異步線程場景的回放成功率，但是損失了異步子線程業務邏輯的回歸能力。

上面的案例就是由於應用開啟了排查提效優先的開關，忽略了異步子線程的調用，導致diff比對異常，顯示回放成功。該接口在生產發布時報了異常，String類型長度超長被try catch，埋點丟失。

4 展望&未來規劃

流量錄製回放作為測試領域的一個新興事物，在誕生初期就吸引了廣大測試同仁的關注，市場上也有些公司也對此進行了一些實踐。我們對流量錄製回放的實踐還處於起步的階段，一些問題的解法也在探索中 。

預發只讀接口非mock回放

在得物預發環境是聯通生產環境的資料庫和下游應用，因此對於預發進行不mock的回放，特別是對只讀接口進行不mock的回放能夠在上線前的最後階段進行一次兜底的回歸校驗。最難解決的問題是，當前是只讀的接口難以保證後續的變更不會引入寫操作。在當前階段開放這一功能會引入額外的資損類風險敞口。

對此問題，每次回放前都進行人工校驗可能可以解決，但是又引入了極大的效率問題。如何高效地保證在預發/灰度環境進行不mock流量回放不會產生資損風險，是一個值得探索的問題，需要研發跟測試的共同努力。

方案1-單回放（准實時回放）

方案1落地遇到的問題：

1.配置中心的數據不一致，噪音比較大

2.時效問題，有10S的時差，一些業務對時效要求比較高

方案2-雙回放（實時回放）

方案2不僅避免了上面方案1的問題，另外後續規劃還可以根據覆蓋率沉澱有效用例集，手工添加異常用例。

通過一段時間的運行，目前已經看到了一些流量錄製回放在業務疊代中產生了價值，發現了一些隱藏bug。接入流量回放明顯的變化是能夠將測試從繁重的回歸測試、用例梳理維護等重複性高的勞動中解放出來，將重心放在測試計劃的設定、思考測試策略以及自我提升的實踐上，比如做些輔助排錯提效的coding能力提升和加強對業務的熟悉的寬度和深度上，從而最大程度的保障業務系統的質量和穩定性。

未來期望能在不斷的實踐中把得物的流量錄製回放體系建設得越來越完善，解放更多的生產力，產出更多的價值。