豆豆小说阅读网,遮天,小说阅读器

一、背景

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

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

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

二、流量回放

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

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

三、流量錄制

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

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

1、流量規則

流量過濾：

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

流量去重：

有時R2可能錄制到非常多的相同流量，如果某些系統不需要的話，可能造成后續回放耗時較長和問題排查效率低下。需要思考如何能在保證接口覆蓋率的情況下盡可能減少相同流量的數量。通過這種機制在一些場景大幅度減少了錄制流量數量，提高了流量的使用效率。當然大部分場景是不需要去重的，如果需要去重流量不清楚現在R2是否可以通過自定義腳本支持（比如根據10個入參其中的8個入參來判斷重復的邏輯）。

2、場景覆蓋度

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

案例：

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

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

3、大促&春節特殊場景流量

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

1.是不是可以通過R2的流量錄制，通過入參過濾獲取這部分特殊場景流量，但需要思考不影響大促當天線上系統性能。并且要求接口入參可以區分哪些是大促特殊場景的流量。

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

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

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

四、回放

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

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

1、讀接口回放

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

案例：

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

臨時解決方案：

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

2、寫接口回放

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

2.讀接口和寫接口的不同，在于讀接口沒有副作用，而寫接口有副作用。寫接口的副作用通常體現在會對被測系統產生臟數據上。

3.寫接口需要注意可能操作不慎導致回放的接口中調用產生臟數據，影響業務。

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

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