1、背景介紹

1.1 得物pandora介紹

什么是流量錄制回放？流量錄制回放是應(yīng)用端通過掛載注入錄制器探針自動注冊到服務(wù)端形成錄制流量回流，將所有外部調(diào)用依賴的響應(yīng)內(nèi)容（如數(shù)據(jù)庫、分布式緩存、外部服務(wù)響應(yīng)等）進(jìn)行完整記錄。由平臺向回放器分發(fā)流量回放指令。其核心價值是通過直接錄制生產(chǎn)的真實數(shù)據(jù)，將生產(chǎn)真實數(shù)據(jù)轉(zhuǎn)化成可復(fù)用、可執(zhí)行的流量，快速地在測試環(huán)境中進(jìn)行回放比對接口返回值和中間鏈路的驗證。

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

1.2 市場工具對比

目前市場上已知的流量錄制回放平臺大部分都是在Jvm-Sandbox-Repeater基礎(chǔ)上進(jìn)行二次開發(fā)和改造，并且多數(shù)都是只支持Java語言。核心原理也都是通過錄制線上真實流量然后在測試環(huán)境進(jìn)行回放，驗證代碼邏輯正確性。

2、實踐落地

2.1 協(xié)作模式

在具體的實施層面，目前采用的是業(yè)務(wù)測試，平臺研發(fā)，業(yè)務(wù)研發(fā)三方協(xié)同的模式。任務(wù)分拆如下圖所示。

得物流量回放實施模式

2.2 階段應(yīng)用

流量回放在各階段的理想實施應(yīng)用：

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

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

得物迭代&項目時間軸

2.3 實踐落地

流量回放的開展自發(fā)起后，在本域由探索嘗試階段逐漸過渡到應(yīng)用場景拓展階段。

訂單流量回放模式

在經(jīng)過一段時間的探索，摸索出了一套適用于本域迭代的模式。

Part1、嘗試接入

團(tuán)隊開始開展流量回放的專項之后，通過調(diào)研，選取了40%的服務(wù)優(yōu)先接入。

1. 階段目標(biāo)

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

2. 實施方案

• 調(diào)研應(yīng)用的特性，嘗試接入流量錄制回放；
• 梳理服務(wù)的P0接口及用例，配置對應(yīng)的接口及用例標(biāo)簽；
• 用例自動沉淀到用例集后，在回歸階段嘗試進(jìn)行流量回放。

3. 收益成果

• 完成30%應(yīng)用形成落地質(zhì)量卡點，落地15%用例回歸場景，驗證方案可行性和易用性，摸索研發(fā)測試協(xié)同機(jī)制。

Part2、探索升級

上一階段花費(fèi)大量的時間梳理接口配置標(biāo)簽，用例沉淀速度緩慢，并且收益與投入不成正比，因此調(diào)整了策略，應(yīng)用智能化分析進(jìn)行提效，快速沉淀用例，擴(kuò)大用例量及覆蓋的接口量。45%業(yè)務(wù)應(yīng)用接入并均實現(xiàn)強(qiáng)卡點落地，配合平臺側(cè)優(yōu)化，解決大部分組件適配和使用問題，迭代應(yīng)用流程以及應(yīng)用指標(biāo)分析機(jī)制基本跑順。

1. 階段目標(biāo)

• 應(yīng)用：接入的應(yīng)用交由對應(yīng)的服務(wù)負(fù)責(zé)人，負(fù)責(zé)對應(yīng)服務(wù)的接口維護(hù)運(yùn)營及沉淀、排錯分析；
• 用例：嘗試探索新的用例沉淀方式，進(jìn)一步擴(kuò)大用例量，增加覆蓋的接口量；
• 排錯：根據(jù)服務(wù)的用例量以及接入的時間，提升測試排錯能力，階段2結(jié)束測開排錯達(dá)到五五開；

2.收益成果

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

Part3、專項提速

在沉淀的用例case大量的增加、用例沉淀速度提效明顯的前提下，流量回放在迭代的應(yīng)用中發(fā)現(xiàn)更多的缺陷，規(guī)劃擴(kuò)大接入的應(yīng)用以及覆蓋的接口范圍。

1. 階段目標(biāo)

• 應(yīng)用接入：新增40%應(yīng)用接入，接入應(yīng)用占比合計90%；
• 排錯：提升測試的排錯能力，新版本排錯由平臺研發(fā)轉(zhuǎn)交業(yè)務(wù)研發(fā)，測試開發(fā)排錯占比五五開；
• 用例量：加速沉淀用例量，擴(kuò)大覆蓋的范圍，至少65%的應(yīng)用完成全量用例沉淀；
• 卡點：接入應(yīng)用達(dá)到100%卡點，提升排錯速度，部分應(yīng)用由生產(chǎn)卡點轉(zhuǎn)為預(yù)發(fā)卡點；
• 全域接入應(yīng)用接口維度覆蓋率98%以上，接口配置完善度98%以上，全量用例路徑覆蓋率60%以上。

2. 收益成果

隨著應(yīng)用的接入，沉淀的用例量也在擴(kuò)大，發(fā)現(xiàn)的問題數(shù)也在增多。同時也增加覆蓋率的指標(biāo)來衡量流量回放用例覆蓋的代碼占總代碼行的比值。隨著對覆蓋率的關(guān)注，平臺采樣策略也進(jìn)行了一個調(diào)整，刪除所有歷史沉淀用例，僅沉淀新策略實施之后錄制的流量。

• 流量回放接入90%應(yīng)用，擴(kuò)大應(yīng)用接入和case沉淀，超預(yù)期達(dá)成目標(biāo)，沉淀應(yīng)用Case量是原計劃的3倍，此階段累計發(fā)現(xiàn)缺陷數(shù)占全域流量回放發(fā)現(xiàn)的bug數(shù)的45%，充分驗證了落地策略的有效性；
• 從階段3本域發(fā)現(xiàn)的缺陷統(tǒng)計來看，其中回歸類BUG占比38%，發(fā)現(xiàn)線上自有/隱藏問題占比8%，迭代過程中代碼問題（日志報錯）和代碼規(guī)范類問題占比46%，性能問題占比8%；
• 接口配置完善度100%；接口維度覆蓋率96.49%；全量用例路徑覆蓋率79.32%，全量代碼覆蓋率平均39.8%；

3、總結(jié)分析

3.1 問題歸類分析

3.1.1 累計發(fā)現(xiàn)的缺陷分類：

3.1.2 累計發(fā)現(xiàn)的缺陷來源分類：

3.1.3 典型案例：

• 回放時系統(tǒng)異常，排查之后定位為NPE類問題，如：

• response返回的業(yè)務(wù)字段diff對比不一致，如：

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

• 流量回放發(fā)現(xiàn)攔截的問題近一半都是會引起生產(chǎn)業(yè)務(wù)報錯的，其中包括像金額不對涉及資損的問題以及字段傳值不對、枚舉類型取錯等缺陷；作為生產(chǎn)發(fā)布前的最后階段的防線之一，充分展現(xiàn)了流量錄制回放作為對測試回歸的兜底能力的補(bǔ)充手段的重要性。
• 45%左右的問題是手工測試過程中難以發(fā)現(xiàn)隱藏比較深的代碼層面問題，例如NPE報錯、入?yún)⒊鰠⒆侄挝葱蛄谢龋@些問題如果僅僅通過前端測試或接口測試不看日志不一一對比所有字段勢必會將問題帶到生產(chǎn)環(huán)境，最終影響生產(chǎn)環(huán)境的穩(wěn)定性。
• 6%左右的性能問題，例如存在重復(fù)子調(diào)用，影響接口RT，如果不在生產(chǎn)發(fā)布前發(fā)現(xiàn)解決，勢必給用戶體驗帶來一定的挑戰(zhàn)。
• 從缺陷的來源上看，發(fā)現(xiàn)的缺陷來源還是集中在項目迭代需求和技術(shù)優(yōu)化上，充分驗證了流量回放整體提速后的有效性以及對測試覆蓋兜底能力的補(bǔ)充。
• 通過對失敗用例的排錯分析經(jīng)驗的累積和分享培訓(xùn)，參與專項的測試團(tuán)隊的整體技術(shù)水平通過流量回放專項提速在技術(shù)氛圍上有明顯提升，培養(yǎng)了多位同學(xué)對自身負(fù)責(zé)模塊的實現(xiàn)的代碼走讀能力，以及深挖缺陷的code diff能力。

3.2 適用性分析

• 適用場景

適用于返回數(shù)據(jù)量大、業(yè)務(wù)流量也很大，以及讀取業(yè)務(wù)占比大的場景，如ToC產(chǎn)品。

• 不適用場景
• 掛載沙箱后開啟錄制會導(dǎo)致RT瞬間飆高，影響生產(chǎn)服務(wù)的穩(wěn)定性。
• 異步場景目前流量回放平臺不支持。
• 需要驗證數(shù)據(jù)庫的落地，節(jié)點的流轉(zhuǎn)的鏈路測試，需要自動化。

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

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

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

1、接口覆蓋不全。迭代需求新接口，未配置關(guān)聯(lián)錄制，不在流量回放的錄制范圍。

2、全量代碼覆蓋率不高。接口已經(jīng)配置覆蓋了，但是由于采樣比例小場景極端等原因，接口的分支場景并沒有錄制到未被覆蓋。

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

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

3.3 面臨的挑戰(zhàn)

3.3.1 排錯的效率

錄制流量后對流量進(jìn)行回放，發(fā)現(xiàn)回放結(jié)果比對失敗的很多。經(jīng)過對失敗原因的排查與分析，有些是代碼bug導(dǎo)致的失敗，但更多的失敗不一定是代碼bug，常見噪音主要包含：

• 代碼修改，新增或刪除了子調(diào)用，導(dǎo)致mock失敗
• 平臺不支持的子調(diào)用，導(dǎo)致失敗
• 時間戳相關(guān)的子調(diào)用，diff不一致
• 子調(diào)用中使用隨機(jī)參數(shù)相關(guān)，導(dǎo)致mock匹配不上
• repeater代碼自身缺陷
• 業(yè)務(wù)自增數(shù)據(jù)差異
• 配置中心數(shù)據(jù)不一致
• 返回?zé)o序元素集合，造成結(jié)果對比誤差

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

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

3.3.2 異步線程錄制回放問題

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

上面的案例就是由于應(yīng)用開啟了排查提效優(yōu)先的開關(guān)，忽略了異步子線程的調(diào)用，導(dǎo)致diff比對異常，顯示回放成功。該接口在生產(chǎn)發(fā)布時報了異常，String類型長度超長被try catch，埋點丟失。

4、展望&未來規(guī)劃

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

預(yù)發(fā)只讀接口非mock回放

在得物預(yù)發(fā)環(huán)境是聯(lián)通生產(chǎn)環(huán)境的數(shù)據(jù)庫和下游應(yīng)用，因此對于預(yù)發(fā)進(jìn)行不mock的回放，特別是對只讀接口進(jìn)行不mock的回放能夠在上線前的最后階段進(jìn)行一次兜底的回歸校驗。最難解決的問題是，當(dāng)前是只讀的接口難以保證后續(xù)的變更不會引入寫操作。在當(dāng)前階段開放這一功能會引入額外的資損類風(fēng)險敞口。

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

方案1-單回放（準(zhǔn)實時回放）

方案1落地遇到的問題：

1.配置中心的數(shù)據(jù)不一致，噪音比較大

2.時效問題，有10S的時差，一些業(yè)務(wù)對時效要求比較高

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

方案2不僅避免了上面方案1的問題，另外后續(xù)規(guī)劃還可以根據(jù)覆蓋率沉淀有效用例集，手工添加異常用例。

通過一段時間的運(yùn)行，目前已經(jīng)看到了一些流量錄制回放在業(yè)務(wù)迭代中產(chǎn)生了價值，發(fā)現(xiàn)了一些隱藏bug。接入流量回放明顯的變化是能夠?qū)y試從繁重的回歸測試、用例梳理維護(hù)等重復(fù)性高的勞動中解放出來，將重心放在測試計劃的設(shè)定、思考測試策略以及自我提升的實踐上，比如做些輔助排錯提效的coding能力提升和加強(qiáng)對業(yè)務(wù)的熟悉的寬度和深度上，從而最大程度的保障業(yè)務(wù)系統(tǒng)的質(zhì)量和穩(wěn)定性。

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