3-得物流量錄制回放實踐-周官寶-0605.pdf

《3-得物流量錄制回放實踐-周官寶-0605.pdf》由會員分享，可在線閱讀，更多相關《3-得物流量錄制回放實踐-周官寶-0605.pdf（41頁珍藏版）》請在三個皮匠報告上搜索。

1、得物流量錄制回放實踐周官寶演講嘉賓介紹周官寶 資深后端開發工程師l 擁有多年的后端開發經驗；曾任職美團、喜馬拉雅、現任為得物。目前負責流量錄制回放平臺，從0到搭建線上巡檢平臺、對服務端自動化測試和資損防控有一定理解和思考等。CONTENT目錄背景-為什么要落地流量錄制回放01演進-落地過程的演進及遇到問題效果-拿到怎樣效果020304規劃-未來展望Part 01背景l 測試場景l 傳統自動化劣勢l 流量錄制回放優勢我有個代碼重構代碼重構，改動涉及一批接口，需要對原有的接口及場景做回歸，你幫我測試一下。這個接口RT這么高我可不敢動，干脆新寫一個接口實現原來的功能吧！我重新寫了一個接口重新寫了一個

2、接口b，邏輯保持跟a接口一致，你幫我測試一下。哇，這個接口前置數據造數怎么這么復雜，每次都要重新構造一筆場景數據，并且針對查詢接口返回做大量的斷言，稍有斷言不充分斷言不充分就有可能遺漏問題到線上，這后面腳本維護成本可怎么辦。研發這次需求改動了十幾個核心接口，我雖然完成了用例評審內的所有場景測試，但是生產場景、數據復雜，上線有點慌上線有點慌，干脆去燒個香？01 編寫成本高本高要深入理解業務，同時需要額外的造數據和清數據02 維護成本高代碼變更導致用例失效，線下環境不穩定導致無效排查03 覆蓋率不足成本平衡到聚焦P0P1業務場景，帶來覆蓋率不足的問題04 斷言不充分斷言數量巨大，尤其一些查詢接口，

3、只能斷言一些核心字段，非核心字段問題無法發現傳統自動化真實流量無需編寫斷言回放成功率穩定用例創建成本低01OPTION03OPTION02OPTION04OPTIONPart 02演進l JAVA寫接口演進l JAVA讀接口演進l GO/Python/C+讀接口回放及場景探索l 賦能其他平臺主要里程碑模式變化、自動化、測試左移、智能化自動化、新模式探索壓測平臺、混動工程遷移回放、go回放、日志錄制回放、算法域回放JAVA讀接口演進GO/Python/C+讀接口回放及場景探索JAVA寫接口演進賦能其他平臺JAVA寫接口回放2021202220232024線下mock回放讀寫分離讀接口在預發回放寫

4、接口在測試回放寫接口回放自動化寫接口回放新模式探索JAVA線下mock回放常見四種失敗常見四種失敗子調用未匹配-多子調用子調用參數不一致響應DIFF不一致子調用未匹配-少子調用JAVA線下mock回放時間差異時間還原時間還原系統噪音)忽略字段忽略字段數組亂序數組排序數組排序降噪手段降噪手段JAVA寫接口線下回放自動化 同版本：是指將回放環境的代碼分支(CommitID)與生產代碼分支部署一致，目的補充用例，提高覆蓋率，降低噪音 新(待發)版本：是指回放環境的代碼分支是提測前的合并的分支，目的是檢查新代碼是否符合預期JAVA寫接口回放新模式探索三個三個方向方向一個原則：能mock盡量mock，不

5、能mock，發生真實調用一個關系：回放子調用與錄制子調用關系總體對比：子調用和響應全面對比20212021線下mock回放20222022讀寫分離20222022預發讀單回放20232023【基礎版】預發讀雙回放20232023【進階版】預發讀雙回放(全鏈路攔截/自動化)至今至今【探索版】預發讀雙回放(智能化)20242024測試讀雙回放(測試左移)JAVA讀接口演進1 1線上線下配置不一致2 2中間件支持不完善3 3排查成本較大4 4發現問題能力差存在問題存在問題生產線下配置不一致導致錄制、回放天然調用鏈路不一致，增加噪音1 12 23 34 4部分中間件不支持，導致無法錄制節點數據，并且異

6、步線程等問題無法較好解決回放失敗排查成本較高，需要測試具備一定代碼基礎并遠程debug調試業務代碼絕大部分失敗排錯均為正常代碼變更，較小概率發現代碼bug。部分重構和遷移不支持JAVA線下mock回放線上線下配置不一致中間件支持不完善排查成本較大發現問題能力差讀接口讀接口在預發回放寫接口寫接口在線下回放讀寫JAVA讀寫分離預發生產共庫預發生產共庫優勢優勢回放只讀接口回放只讀接口不需不需MOCK中間數據中間數據僅僅DIFF響應結果響應結果JAVA預發讀單回放1 1只讀接口定義太嚴格2 2識別只讀接口成本太高3 3可能污染生產數據4 4時效要求較高接口噪音較大存在問題存在問題部分讀接口因僅涉及日志

7、插入或redis緩存更新操作，無法被預發回放1 12 23 34 4微服務架構下，成百上千的服務，每個服務成百上千的接口，存量一個個判斷識別成本太大預發生產共庫，預發回放是不mock回放，一旦將寫接口誤判成只讀接口，可能造成生產數據污染生產錄制到預發回放有幾秒延遲，延遲期間發生數據狀態變更，導致只讀接口響應diff失敗，噪音較大JAVA預發讀單回放只讀接口定義太嚴格識別只讀接口成本太高可能污染生產數據時效要求較高接口噪音較大預發生產共庫預發生產共庫優勢優勢回放只讀接口回放只讀接口不需不需MOCK中間數據中間數據僅僅DIFF響應結果響應結果同時回放同時回放同一環境同一環境JAVA【基礎版】預發讀

8、雙回放只讀接口定義升級Login Check MockLogin Check MockRedis WriteRedis Write MockMockSend MQ MockSend MQ MockDB Insert MockDB Insert Mock”JAVA【基礎版】預發讀雙回放識別只讀接口三種手段010302人工識別接口屬性應用級別接口屬性識別鏈路級別接口屬性識別JAVA【基礎版】預發讀雙回放JAVA【基礎版】預發讀雙回放降噪手段通過一系列的手段將噪音降到最低 鏈路不穩定(下游服務部署)字段狀態變更過快 接口維度，對接口差異字段進行聚合分組 平臺有大量處于回放中，對用戶十分不友好，細化原

9、因降低排除難度 整個回放任務中所有差異字段進行聚合分組 數值、日期等類型存在差異，字符串和 json的字符串導致差異。01自動重放04 按接口+差異字段02 失敗細分原因05 按差異字段分組03 精細化配置1 1污染生產數據2 2使用成本過高3 34 4存在問題存在問題預發回放是不mock回放，如何觸發寫操作，可能導致污染生產環境的數據(目前我司生產和預發共用一套數據庫)1 12 2代碼部署、發起回放等動作都是分散，使用成本過高，JAVA【基礎版】預發讀雙回放污染生產數據使用成本過高寫操作攔截機制寫操作攔截機制在一定程度上確?；胤诺陌踩匀斯ご_認回放前-平臺攔截回放中-當前應用攔截回放中-全鏈

10、路攔截風險問題p 沒有被沙箱切到的子調用無法攔截，如使用httpcomponents客戶端的httpp 對于未知組件不支持攔截p 鏈路涉及到公司外調用JAVA【進階版】預發讀雙回放-全鏈路攔截用戶只需關注回放失敗JAVA【進階版】預發讀雙回放-自動化JAVA【進階版】預發讀雙回放1 1排查手段有限2 23 34 4存在問題存在問題回放失敗目前只有通過traceId、日志和代碼進行分析，排查比較費力1 1排查手段有限自動聚合報告自動聚合報告結合代碼分析和大模型識結合代碼分析和大模型識別導致差異字段的代碼別導致差異字段的代碼JAVA【探索版】預發讀雙回放-智能化2023.Q12023.Q22023

11、.Q32023.Q4預發讀遷移雙回放主要解決應不同服務之間讀接口遷移GO預發讀雙回放開發相應sdk，復用已有的能力來解決go讀接口相關的回歸測試問題算法域灰度讀雙回放利用流量錄制回放解決算法域回歸測試問題和測試提效基于日志錄制回放1.補充錄制數據源；2.復用現有能力解決python和c+回放測試回歸問題GO/Python/C+讀接口回放及場景探索JAVA預發讀遷移雙回放測試零投入研發使用成本低GO預發讀雙回放提供http或grpc mock能力提供redis和mysql寫攔截能力算法域灰度環境讀雙回放流量回放雙回放一般流程流量回放雙回放擴展流程-算法域日志錄制回放(Python/C+)壓測平臺

12、為 它 們 流 量 數 據，降低造數成本混沌工程提 供 流 量 數 據，為其注入提供方便強弱依賴提 供 給 強 弱 依 賴 的mock能力Mock平臺為 測 試 和 研 發 測 試提 效，依 賴 底 層 的mock能力賦能其他平臺Part 03效果l 運營策略l 運用數據運營策略運營數據接入應用數攔截缺陷數發布卡點數300+270+5+接入應用數300+累計接入超300個應用到流量回放，預發比線下推廣使用超50%01每迭代覆蓋接口數11000+流量回放已形成質量保障必要手段之一，目前每迭代回歸覆蓋11000+接口，持續增長中02累計攔截缺陷數400+預發回放+線下回放模式結合后，發現缺陷能力直線提升，讀寫分離覆蓋，ROI提升10倍以上0311000+100+400+覆蓋接口數發布卡點應用數100+通過卡點機制，部分技改重構已實現測試零投入，并且在測試側將流量回放納入質量保障策略，結合自動化兜底測試質量04Part 04展望展望