背景

閑魚作為一款垂直交易社區(qū)APP，擁有復雜多樣的業(yè)務場景：涉及c2c、回收寄賣、租房租賃、見面交易、驗貨擔保等，復雜多變的交易模式。比如驗貨流程：
涉及39個狀態(tài)機節(jié)點
橫跨10+應用系統
涉及6個業(yè)務部門的合作
涉及接口幾十個
需要保證每個接口、每個場景切實可行，稍微有一點點問題，就會涉及到人民幣的味道，實際工作中，我們遇到各種各樣的問題，比較棘手的問題如下：

問題

業(yè)務先贏的快速迭代模式下，全靠人工主力進行測試驗證，測完新功能，還得回歸老功能，一個小需求也須要好幾個人日，版本PTM也要回歸好幾遍，ROI并不樂觀，以下2個問題比較突出：

交易業(yè)務強依賴中臺，溝通成本高，跨團隊協作難，迭代效率低，測試環(huán)境下如何自洽？
復雜多樣交易模式下，如何支撐需求穩(wěn)步迭代上線以及日常回歸驗證？

測試策略-自動化

閑魚質量基建正在快馬加鞭進行中，針對閑魚多樣的交易模式，全靠人力是不可行的，累不說，改動、風險漏評估也時有發(fā)生。對此，我們根據接口->鏈路的策略，探索對比了幾個不同的方案，在保證每個接口OK的基礎上，保障全鏈路。

接口層

對于每一個大型應用程序來說，接口數量會不斷增加，代碼變更頻率越來越大、系統不定期重構，這個接口的質量怎么來保障？傳統編寫腳本來進行的方式，投入的人力、時間成本過大，在實際的測試過程中我們探索了一些接口測試的新想法。目前業(yè)界公認的有效方式是基于引流回放的自動化測試，實現方案業(yè)內眾說紛紜各有其詞，但萬變不離其中，引用下面這段總結，簡單明了

一種是黑盒測試思路，它在線上接口請求時采集線上流量（主要是請求參數和結果），然后使用和線上環(huán)境相同的環(huán)境（數據庫共用等）下用采集到的流量重新觸發(fā)請求，然后斷言被請求的返回值是不是和錄制時的一致。這種方法比較適合對Get類型的接口進行測試，而對于寫操作的請求容易造成數據污染，再加上所采集流量的數據狀態(tài)（數據時效性）、環(huán)境依賴性（各種中間件、接口內部請求的RPC調用）等因素，所以這種測試方式具有一些局限性，不能滿足實際測試場景中復雜的需求。

另一種思路相對白盒，主要是通過智能化的Mock手段，流量采集時采集代碼運行過程中所依賴的外部中間件或者RPC調用的返回結果，當流量回放時，能夠Mock本機程序對外的依賴中有可能產生變化的內容，使測試更關注本地接口的代碼邏輯。

阿里集團內部，基于流量回放的思想，主要實現了2種不同的流量錄制回放方案，一種是基于doom的天啟/暴雪，一種是基于JVM-Sandbox的鳳凰，兩種實現都借力于JVM AOP。

天啟/暴雪

天啟/暴雪，其底層采用的是doom進行流量錄制，其原理如下

doom原理圖

主要流程是：
通過Java agent掛在JVM中的client以ASM的AOP方式采集主調用（采集或回放時的入口方法）的入參、返回值、子調用（應用執(zhí)行過程中的一次方法調用，采集機器會采集該方法的入參和返回值用于回放時執(zhí)行到該方法進行mock）的入參和返回值，然后將采集到的數據上傳至server （離線模式）；
回放時，client收到接口回放請求后，會執(zhí)行該接口的本地邏輯，對于子調用則用采集的入參和結果進行mock；
將采集的流量和回放的結果數據進行對比。
doom方式，業(yè)務應用系統需要引入Jar包，修改啟動類，修改JVM掛載agent，有部分的業(yè)務侵入性。

- 鳳凰 鳳凰，也是采用JVM AOP實現的流量錄制方案，理念和doom差不多，鳳凰整體架構底層基于JVM-Sandbox（阿里開源的一款 JVM 平臺非侵入式運行期 AOP 解決方案，通過字節(jié)碼增強實現方法級別的AOP功能）輸出模塊原子能力。錄制時，記錄了發(fā)生調用的方法，入參、返回值和調用發(fā)生的順序，以鏈式數據結構存儲，回放時進行接口邏輯執(zhí)行和子調用mock。<br /><br />鳳凰錄制回放<br />鳳凰無需代碼侵入修改，不需要修改應用啟動參數，相對來說，對業(yè)務代碼影響小，但是有應用結構要求。考慮成本和風險，以及我們的應用結構，閑魚采用基于Sandbox的鳳凰流量錄制回放進行保障，變更上線流程卡點。<br />研發(fā)過程中，也會遇到各種各樣的流量回放問題，比如用例過期，需要人工清楚重新錄制。我們現在是采用定時任務自動清除重新錄制的方式解決。<br />下面是我們的一個場景例子：<br /><br /><br />

鏈路層

在基于流量錄制、回放比對的接口測試過程中，我們發(fā)現這種機制對于單應用的質量保障比較實用，但是對于跨應用的鏈路驗證、核心寫操作、外調用，以及系統重構類、方案改造等大需求就有些不足，鏈路級的解決解決方案接踵而至。

Thub + 微服務

測試環(huán)境下，對于全鏈路上下游的強依賴，措施之一是開發(fā)測試服務化能力，建立自洽能力，測試環(huán)境下解藕對于外界諸如交易中臺、菜鳥裹裹的依賴，測試環(huán)境能進行全鏈路閉環(huán)。
落地首要任務是梳理業(yè)務全鏈路節(jié)點：

- 主干鏈路上的每一個MTOP接口，以及接口的上下游依賴 - 內部應用、中臺應用、外部商家的依賴 - 數據流以及TDDL梳理

業(yè)務梳理完整，進行測試服務化接口開發(fā)。下面是我們截取的一部分鏈路case：

同時，諸如測試環(huán)境由于依賴方測試環(huán)境不穩(wěn)定block測試的情況，我們提供測試服務化接口進行封裝，暴露成下單、驗貨等服務化能力內置于閑魚質量平臺，用于開發(fā)、測試在研發(fā)過程中使用。

天算平臺

天算平臺，利用影子庫，全鏈路壓測的模式，線上業(yè)務數據和測試數據隔離，測試庫copy線上庫一部分數據。主要實現的方式是將線上的場景進行固化仿真，全鏈路執(zhí)行，并且在執(zhí)行的過程中進行所有數據變更的比對，用戶可以選擇任何代碼版本的基線和變更版本進行對比。大致流程

天算能力基本能滿足閑魚的交易鏈路，閑魚建立了主鏈路相關影子庫，影子鏈路正在調試中，用于交易服務端的全鏈路巡檢。 同時，影子鏈路有諸如業(yè)務變更導致影子數據過期的問題，這個方案則主要是用于業(yè)務比較穩(wěn)定的業(yè)務，新業(yè)務或者不斷迭代更新的業(yè)務并未all in這個方案。

總結

綜上，目前閑魚交易，接口層用基于jvm-sandbox的流量錄制方案, 日常巡檢利用影子鏈路，研發(fā)過程自測、鏈路自動化用業(yè)務編排服務化能力。

展望

在基建完善的基礎上，我們將繼續(xù)探索flutter以及服務端的全端智能化方向的測試解決方案，希望讓更多技術小二從重復勞動中釋放出來，從治、防、控，三層質量網，保障閑魚交易，讓用戶在閑魚放心的賣賣賣、買買買。期待和大家一起交流業(yè)內的不同測試方案！同時感謝doom、sandbox、鳳凰、天啟、暴雪、全鏈路壓測、Thub等團隊提供的能力支持！

原文鏈接：http://click.aliyun.com/m/1000282373/