一、背景

測試小伙伴們在2023年保障了團隊線上系統(tǒng)0問題，這簡直就是一項了不起的壯舉！這得益于咱們測試組同事對工作的細致投入、風險把控、以及嚴格遵循流程規(guī)范進行測試用例評審、自動化建設、聯(lián)調(diào)推動、回歸驗證、常態(tài)化壓測、大促高保真壓測、引流回放等多重保險策略工作。尤其是測試團隊在流量錄制回放方面的實踐經(jīng)驗非常豐富，還貢獻了不少文檔，簡直是測試界的大佬啊！

本文從研發(fā)的的視角去看待流量回放這個問題，或許也能提供一些有趣的觀點呢。

文檔內(nèi)容說的不一定對，歡迎專業(yè)的測試大佬鞭打我的思維火花！這樣對我來說也是成長。

二、流量回放

從系統(tǒng)穩(wěn)定性角度出發(fā)，任何需求我都會跟小組團隊強烈要求一點，不要影響線上既有功能，做好DUCC開關快速止血。（太多的COE報告歷史經(jīng)驗教訓都是因為上線某功能B最終導致之前功能A出問題，比如修改了公共的某些方法等）那如何保障不影響線上既有功能呢，自動化測試是一方面，但流量回放比對才是最佳的方式。

流量回放原理其實就是錄制線上真實的流量，到預發(fā)引流環(huán)境進行回放，對比生產(chǎn)和預發(fā)環(huán)境錄入接口的子調(diào)用、響應差異去定位代碼問題。流量回放用例的創(chuàng)建成本很低，使得每次迭代全量回歸有了理論基礎。優(yōu)點是業(yè)務代碼零侵入、真實鏈路調(diào)用、多場景、數(shù)據(jù)可查、結果diff比對、問題定位精準，提前發(fā)現(xiàn)問題。風險是操作不慎可能導致線上問題，比如依賴的下游接口流量暴漲，或者寫操作導致線上臟數(shù)據(jù)，最終影響業(yè)務

??

三、流量錄制

流量來源哪里？肯定是線上真實流量靠譜，可以包含實時的流量也可包含歷史流量（離線錄制的流量），或者人為造的測試流量（造的流量也是參考線上歷史流量有價值的）

其實流量錄制核心關心的是錄制的流量夠不夠，是否能覆蓋這次代碼改動牽扯的業(yè)務場景。

1、流量規(guī)則

流量過濾：

R2支持過濾規(guī)則設置，通過可視化配置：支持字段級過濾規(guī)則配置，僅錄制符合規(guī)則的流量?；蛘咦远x腳本：當過濾規(guī)則較為復雜時，可使用自定腳本，編寫過濾代碼。

流量去重：

有時R2可能錄制到非常多的相同流量，如果某些系統(tǒng)不需要的話，可能造成后續(xù)回放耗時較長和問題排查效率低下。需要思考如何能在保證接口覆蓋率的情況下盡可能減少相同流量的數(shù)量。通過這種機制在一些場景大幅度減少了錄制流量數(shù)量，提高了流量的使用效率。當然大部分場景是不需要去重的，如果需要去重流量不清楚現(xiàn)在R2是否可以通過自定義腳本支持（比如根據(jù)10個入?yún)⑵渲械?個入?yún)砼袛嘀貜偷倪壿嫞?/p>

?

2、場景覆蓋度

為了使用戶了解錄制到流量的覆蓋程度，如：是否存在場景缺失？是否存在我們不知道的場景等，R2特此開發(fā)錄制場景覆蓋度功能，幫你更了解你的生產(chǎn)流量。

案例：

比如Promise社區(qū)團購業(yè)務只有晚上20點后才會有這種特殊的業(yè)務，故需要思考你本次回放的代碼是否需要覆蓋該場景，則需要錄制回放晚上20點后流量。

所以流量錄制回放多久合適？是2小時、4小時還是多久，評判標準就是場景覆蓋度。

??

3、大促&春節(jié)特殊場景流量

為什么要單獨談一下大促&春節(jié)特殊場景的流量，比如Promise很多場景是只有大促才會有的，比如預售場景。這部分流量日常根本獲取不到，就算你錄制回放線上1個月流量也是無用的。這樣的特殊場景流量用于日?；胤欧浅Ｓ袃r值。尤其是改了大促場景需求或者大促前上線了N個需求，可能影響到大促特殊場景功能正確性。那具體如何做呢？我想到的如下思路：

1.是不是可以通過R2的流量錄制，通過入?yún)⑦^濾獲取這部分特殊場景流量，但需要思考不影響大促當天線上系統(tǒng)性能。并且要求接口入?yún)⒖梢詤^(qū)分哪些是大促特殊場景的流量。

2.如果接口依賴很多下游，這需要思考，他們的結果mock保留起來 或者其他方式

3.或者根據(jù)logbook日志找出大促特殊場景的業(yè)務 入?yún)?、出參等等。然后人為整理流量，但這耗時耗力。

當然因為時間久遠，大促特殊場景的流量我們核心是需要入?yún)?，當時的出參結果可能價值不大，因為現(xiàn)在跑結果可能就是不一樣，當然具體因系統(tǒng)而定。

四、回放

回放分離線DIFF和實時DIFF。實時DIFF適合業(yè)務場景時效性比較強，例如：計費、活動等類型的場景。這些場景因為時效性，不能使用流量錄制來進行 Diff 測試。實時 Diff 恰好可以幫助我們進行此類場景 diff 測試。但如果對時間特別敏感的，實時 Diff也是會存在回放失敗率。 為了能實現(xiàn)將 回放時間 倒回到 錄制時間，不知道現(xiàn)在R2是否支持，可將錄制時間戳傳遞給服務（比如System.currentTimeMillis() 這種native方法，動態(tài)修改方法體的字節(jié)碼，代理掉業(yè)務對該方法的調(diào)用，動態(tài)替換為R2事先定義的獲取時間方法從而保證時間替換。）

流量回放一般牽扯讀接口、讀寫接口、寫接口。

1、讀接口回放

對只讀接口進行不mock的回放能夠在上線前的最后階段進行一次兜底的回歸校驗。但需要注意的是，當前是只讀的接口難以保證后續(xù)的變更不會引入寫操作。

案例：

Promise時效域-下傳控制 之前一直是只讀接口，在2023年期間上線了門店產(chǎn)能占用寫邏輯，但團隊有次線上流量回放忘了這個寫的新功能，導致占用線上產(chǎn)能了（唯一幸運點的是占用產(chǎn)能波次跟線上是一致，不會導致產(chǎn)能波次占用錯誤）

臨時解決方案：

團隊制定規(guī)則，如果讀接口變成讀寫，則需要去Ducc引流環(huán)境把對應寫功能的開關關閉，同理發(fā)送MQ同理也是通過開關關閉。并且每次回放前都進行人工校驗寫鏈路，但這能不能做到 或者效率也是個問題，暫時未想到更好的方法。

2、寫接口回放

1.在流量回放中，讀接口和寫接口回放的方式有很大不同。事實上，這不只是流量回放的特點。即使是傳統(tǒng)接口自動化測試，讀接口和寫接口的測試策略也是有很大不同的。

2.讀接口和寫接口的不同，在于讀接口沒有副作用，而寫接口有副作用。寫接口的副作用通常體現(xiàn)在會對被測系統(tǒng)產(chǎn)生臟數(shù)據(jù)上。

3.寫接口需要注意可能操作不慎導致回放的接口中調(diào)用產(chǎn)生臟數(shù)據(jù)，影響業(yè)務。

4.如果寫接口，mock的意義不大，如果不操作線上寫，可以搭建一套UAT引流回放寫的環(huán)境，可鏈路的某些服務或者組件依賴可以mock，當然里面可能比較復雜，比如數(shù)據(jù)的操作，mysql，redis等UAT環(huán)節(jié)。結果比對不是簡單的diff比對。則應該是去看具體關鍵數(shù)據(jù)、log日志等去驗證結果。如果接口返回的數(shù)據(jù)依賴于數(shù)據(jù)庫或其他外部系統(tǒng)，那么在真實調(diào)用時可能會出現(xiàn)數(shù)據(jù)不一致的問題，導致測試結果不準確。

5.跟上面搭建的UAT引流環(huán)境類似。參考軍演全鏈路壓測，通過修改錄制的流量數(shù)據(jù)，通過修改入?yún)?，傳遞forcebot標識，代碼識別到forcebot標識，走對應軍演影子環(huán)境。數(shù)據(jù)線上有mysql影子庫，Redis等影子環(huán)境，寫操作是直接寫到影子里。

??

JSF接口MOCK失敗

??

3、讀寫接口回放

讀寫接口分為讀和寫。核心是偏讀，內(nèi)部部分邏輯是寫，針對這，讀遵循上面的原則即可，寫可以采用如下方式

1.通過Mock方式返回，不會真實操作寫動作，不會污染應用數(shù)據(jù)。R2支持各種中間件Mock，不詳細講解。

2.通過DUCC開關關閉寫的邏輯。

案例：比如Promise上面說的產(chǎn)能占用邏輯&發(fā)送MQ就是通過DUCC開關關閉該邏輯。

??

4、是否應該Mock回放

1.Mock回放與接口是否讀寫操作并沒有直接的聯(lián)系。只是日常習慣寫接口mock，讀用線上真實。但對于讀接口，既可以使用Mock回放，也可以不使用Mock回放；而對于寫接口，同樣可以選擇使用Mock回放或不使用Mock回放

2.Mock回放與非Mock回放之間的本質(zhì)區(qū)別在于：Mock回放是一種白盒測試方法，而非Mock回放則是一種黑盒測試方法。

5、回放覆蓋率統(tǒng)計

我們是否已經(jīng)全面錄制了流量？回放測試是否存在代碼盲區(qū)？如何證明我們的測試足夠全面？或許你也曾有過這樣的疑慮。為了解決這個問題，R2支持離線回放代碼覆蓋率。覆蓋率統(tǒng)計回放，即流量回放的同時，支持被測代碼覆蓋率統(tǒng)計，并生成覆蓋率報告。

??

?

五、Diff結果比對

1.制定靈活的回放結果比對策略，減輕排錯成本：比如忽略哪些字段，核心關注哪些出參，需要對API接口的出入?yún)⒓皹I(yè)務非常熟悉，需要制定合理的對比策略，根據(jù)場景的不同，靈活采用關鍵字段對比、結構對比等策略。

2.有些Diff比對不一致，只能分別去查看logbook日志尋找原因，有些是因為回放的時候業(yè)務修改了配置導致，有些是真正的bug問題，則需要及時修復然后再次引流回放。

3.有些需求改了邏輯，需要的就是Diff不一樣，這時候流量回放的目的不是為了比對，而是用線上流量豐富測試用例，讓測試更加精準。

?

我是研發(fā)，是一個測試小白，文章內(nèi)容可能有些不完全準確，希望通過您的指正和建議來不斷完善和改進。

審核編輯 黃宇