簡介： 閑魚交易質量自動化
背景
閑魚作為一款垂直交易社區APP，擁有復雜多樣的業務場景：涉及c2c、回收寄賣、租房租賃、見面交易、驗貨擔保等，復雜多變的交易模式。比如驗貨流程： - 涉及39個狀態機節點
- 橫跨10+應用系統
- 涉及6個業務部門的合作
- 涉及接口幾十個
需要保證每個接口、每個場景切實可行，稍微有一點點問題，就會涉及到人民幣的味道，實際工作中，我們遇到各種各樣的問題，比較棘手的問題如下：
問題
業務先贏的快速迭代模式下，全靠人工主力進行測試驗證，測完新功能，還得回歸老功能，一個小需求也須要好幾個人日，版本PTM也要回歸好幾遍，ROI並不樂觀，以下2個問題比較突出：
- 交易業務強依賴中台，溝通成本高，跨團隊協作難，迭代效率低，測試環境下如何自洽？
- 復雜多樣交易模式下，如何支撐需求穩步迭代上線以及日常回歸驗證？
測試策略-自動化
閑魚質量基建正在快馬加鞭進行中，針對閑魚多樣的交易模式，全靠人力是不可行的，累不說，改動、風險漏評估也時有發生。對此，我們根據接口->鏈路的策略，探索對比了幾個不同的方案，在保證每個接口OK的基礎上，保障全鏈路。
接口層
對於每一個大型應用程序來說，接口數量會不斷增加，代碼變更頻率越來越大、系統不定期重構，這個接口的質量怎么來保障？傳統編寫腳本來進行的方式，投入的人力、時間成本過大，在實際的測試過程中我們探索了一些接口測試的新想法。目前業界公認的有效方式是基於引流回放的自動化測試，實現方案業內眾說紛紜各有其詞，但萬變不離其中，引用下面這段總結，簡單明了
一種是黑盒測試思路，它在線上接口請求時采集線上流量（主要是請求參數和結果），然后使用和線上環境相同的環境（數據庫共用等）下用采集到的流量重新觸發請求，然后斷言被請求的返回值是不是和錄制時的一致。這種方法比較適合對Get類型的接口進行測試，而對於寫操作的請求容易造成數據污染，再加上所采集流量的數據狀態（數據時效性）、環境依賴性（各種中間件、接口內部請求的RPC調用）等因素，所以這種測試方式具有一些局限性，不能滿足實際測試場景中復雜的需求。
另一種思路相對白盒，主要是通過智能化的Mock手段，流量采集時采集代碼運行過程中所依賴的外部中間件或者RPC調用的返回結果，當流量回放時，能夠Mock本機程序對外的依賴中有可能產生變化的內容，使測試更關注本地接口的代碼邏輯。
阿里集團內部，基於流量回放的思想，主要實現了2種不同的流量錄制回放方案，一種是基於doom的天啟/暴雪，一種是基於JVM-Sandbox的鳳凰，兩種實現都借力於JVM AOP。
- 天啟/暴雪
天啟/暴雪，其底層采用的是doom進行流量錄制，其原理如下
doom原理圖
主要流程是：
- 通過Java agent掛在JVM中的client以ASM的AOP方式采集主調用（采集或回放時的入口方法）的入參、返回值、子調用（應用執行過程中的一次方法調用，采集機器會采集該方法的入參和返回值用於回放時執行到該方法進行mock）的入參和返回值，然后將采集到的數據上傳至server （離線模式）；
- 回放時，client收到接口回放請求后，會執行該接口的本地邏輯，對於子調用則用采集的入參和結果進行mock；
- 將采集的流量和回放的結果數據進行對比。
doom方式，業務應用系統需要引入Jar包，修改啟動類，修改JVM掛載agent，有部分的業務侵入性。
- 鳳凰
鳳凰，也是采用JVM AOP實現的流量錄制方案，理念和doom差不多，鳳凰整體架構底層基於JVM-Sandbox（阿里開源的一款 JVM 平台非侵入式運行期 AOP 解決方案，通過字節碼增強實現方法級別的AOP功能）輸出模塊原子能力。錄制時，記錄了發生調用的方法，入參、返回值和調用發生的順序，以鏈式數據結構存儲，回放時進行接口邏輯執行和子調用mock。<br /><br />鳳凰錄制回放<br />鳳凰無需代碼侵入修改，不需要修改應用啟動參數，相對來說，對業務代碼影響小，但是有應用結構要求。考慮成本和風險，以及我們的應用結構，閑魚采用基於Sandbox的鳳凰流量錄制回放進行保障，變更上線流程卡點。<br />研發過程中，也會遇到各種各樣的流量回放問題，比如用例過期，需要人工清楚重新錄制。我們現在是采用定時任務自動清除重新錄制的方式解決。<br />下面是我們的一個場景例子：<br /><br /><br />鏈路層
在基於流量錄制、回放比對的接口測試過程中，我們發現這種機制對於單應用的質量保障比較實用，但是對於跨應用的鏈路驗證、核心寫操作、外調用，以及系統重構類、方案改造等大需求就有些不足，鏈路級的解決解決方案接踵而至。
- Thub + 微服務
測試環境下，對於全鏈路上下游的強依賴，措施之一是開發測試服務化能力，建立自洽能力，測試環境下解藕對於外界諸如交易中台、菜鳥裹裹的依賴，測試環境能進行全鏈路閉環。
落地首要任務是梳理業務全鏈路節點：
- 主干鏈路上的每一個MTOP接口，以及接口的上下游依賴 - 內部應用、中台應用、外部商家的依賴 - 數據流以及TDDL梳理 
業務梳理完整，進行測試服務化接口開發。下面是我們截取的一部分鏈路case：
同時，諸如測試環境由於依賴方測試環境不穩定block測試的情況，我們提供測試服務化接口進行封裝，暴露成下單、驗貨等服務化能力內置於閑魚質量平台，用於開發、測試在研發過程中使用。
- 天算平台
天算平台，利用影子庫，全鏈路壓測的模式，線上業務數據和測試數據隔離，測試庫copy線上庫一部分數據。主要實現的方式是將線上的場景進行固化仿真，全鏈路執行，並且在執行的過程中進行所有數據變更的比對，用戶可以選擇任何代碼版本的基線和變更版本進行對比。
大致流程
天算能力基本能滿足閑魚的交易鏈路，閑魚建立了主鏈路相關影子庫，影子鏈路正在調試中，用於交易服務端的全鏈路巡檢。 同時，影子鏈路有諸如業務變更導致影子數據過期的問題，這個方案則主要是用於業務比較穩定的業務，新業務或者不斷迭代更新的業務並未all in這個方案。
總結
綜上，目前閑魚交易，接口層用基於jvm-sandbox的流量錄制方案, 日常巡檢利用影子鏈路，研發過程自測、鏈路自動化用業務編排服務化能力。
| doom | jvm-sandbox | Thub+微服務 | 影子鏈路 | |
|---|---|---|---|---|
| Release | 否 | 是（github已開源） | 否 | 否 |
| 代碼侵入 | 是 | 否 | 否 | 否 |
| 應用要求 | 否 | 是 | 否 | 否 |
| 穩定性 | 一般 | 一般 | 一般 | 一般 |
| 全鏈路測試 | 否 | 否 | 是 | 是 |
展望
在基建完善的基礎上，我們將繼續探索flutter以及服務端的全端智能化方向的測試解決方案，希望讓更多技術小二從重復勞動中釋放出來，從治、防、控，三層質量網，保障閑魚交易，讓用戶在閑魚放心的賣賣賣、買買買。期待和大家一起交流業內的不同測試方案！同時感謝doom、sandbox、鳳凰、天啟、暴雪、全鏈路壓測、Thub等團隊提供的能力支持！
原文鏈接
本文為阿里雲原創內容，未經允許不得轉載。