訂單流量錄製與回放探索實踐｜得物技術

　　 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能力提升和加強對業務的熟悉的寬度和深度上，從而最大程度的保障業務系統的質量和穩定性。

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