蘇寧MOCK測試樁服務建設實踐

來源：IT刊

2018 年蘇寧易購提出了智慧零售大開發(fā)戰(zhàn)略，快速的發(fā)展速度對蘇寧的 IT 技術提出了更高的要求，其中一個重要的環(huán)節(jié)就是加快軟件版本的上線步伐，伴隨著軟件的上線必然存在巨大的測試壓力。

前言

2018 年蘇寧易購提出了智慧零售大開發(fā)戰(zhàn)略，今年將新開 5000 家門店，到 2020 年，線下門店總數達 2 萬家。半年來，以急速推進的大開發(fā)戰(zhàn)略高超迭起，店面實現從城市到縣鎮(zhèn)市場全面覆蓋，使得消費者在任何時間、任何地點、任何服務的需求都可以得到滿足。

這樣的發(fā)展速度對蘇寧的 IT 技術提出了更高的要求，其中一個重要的環(huán)節(jié)就是加快軟件版本的上線步伐，伴隨著軟件的上線必然存在巨大的測試壓力，在敏捷過程中，蘇寧測試遇到了如下困境：

依賴方不可用，測試人員無法提前介入測試；數據構造，復雜的場景或者特殊的數據，無法很快生成，導致場景無法覆蓋；異常模擬；外部系統(tǒng)不可用，或者沒有對應的測試環(huán)境，或者需要現金交易；壓測時，依賴方性能較差，無法保證本系統(tǒng)性能最優(yōu)；全鏈路壓測時，無法限定鏈路范圍；

為了提高生產效率和測試覆蓋率，蘇寧蛙測平臺上線全場景 Mock 樁服務解決方案，支持 HTTP、ESB、RPC 等協(xié)議 Mock，支持同步、異步以及回調場景等功能，成功解決測試人員、開發(fā)人員在測試和研發(fā)過程中，數據構造、環(huán)境依賴等痛點，大大提高了生產效率，提高測試場景的覆蓋率，保障了業(yè)務版本上線的質量。目前蛙測 Mock 服務應用于蘇寧 100+ 中臺、后臺系統(tǒng)，服務了 1000+ 萬次樁服務調用，在蘇寧各個測試產品線得到了廣泛的應用。具備的能力如下：

實踐過程及應用效果

第一階段：Mock1.0 從無到有過程

當初，蘇寧并沒有一套通用的 MOCK 服務能力，各個業(yè)務線基本是由開發(fā)人員，在應用代碼中，植入 Mock 邏輯，由測試人員在應用外部統(tǒng)一針對特定接口進行預埋樁響應內容，這樣的方案給開發(fā)和測試帶來了很大的工作量，開發(fā)人員需要在版本迭代過程中，不斷維護 Mock 邏輯，同時也污染了應用代碼，很容易把 Mock 邏輯發(fā)布到生產壞境，增加上線的風險。所以，迫切的需要一套通用的 Mock 服務能力。基于這樣的問題，蘇寧蛙測服務平臺，通過收集各個產品線 Mock 需求、分析，開始從 0 到 1 建設一站式 Mock 服務能力，實現代碼無侵入式的通用 Mock 服務樁，也就是 Mock1.0 版本，整體思路是與中間件打通，組件識別 Mock 的標識，將請求路由到 MockService 上，實現千人千面的 Mock 服務:

正常請求：

而由測試工具發(fā)起的請求（HTTP、ESB、RPC 等），首先測試人員會在本地預埋 Mock 響應內容，同時啟動本地 MockService，在發(fā)起 Mock 請求時會生成的 Mock 標識，Mock 請求到達被測系統(tǒng) A 時，相應組件會識別此 Mock 標識，將依賴方的請求轉發(fā)到 MockService 上，大致思路如下：

Mock 請求：

Mock 標識如何傳遞:

RPC 類型：內部 Java 遠程調用框架 RSF，在測試工具模擬服務消費方，發(fā)起 RSF 請求時，會附帶本次請求中需要 Mock 的后端依賴方，以 Attachement 方式附帶到 RSF 服務方，在服務方應用中，RSF 組件會進行識別、路由，RSF 中間件請求完成后，進行 Mock 信息清理；HTTP/ESB 類型：被測應用在打包或者 CD 發(fā)布時，手動或者自動在 web.xml 中配置中增加 Mock 的 filter 過濾器，在 doFileter 方法中，如果識別到 HTTP 請求頭中包含 Mock 標識，則將 Mock 信息設置到中間件中，在中間件發(fā)起依賴方 HTTP 請求時，進行 Mock 識別、轉發(fā)，請求結束后，清理本次請求的 Mock 信息；測試工具如何埋樁：

一次 RPC 的調用，可能涉及多個后端依賴系統(tǒng)服務調用，所以，在工具腳本設計時，增加了步驟 Group 概念。把本次一次調用過程中，需要 Mock 的調用，放在一個 Group 下，在發(fā)起請求時，把 Group 下的 Mock 步驟，打成多個 Mock flag 標識，供 RPC 組件中 Mock 識別模塊識別，交互如下：

在 MockService 服務上，還支持匹配規(guī)則，根據匹配規(guī)則，響應不同內容。

在 Mock1.0 服務中，僅支持 RPC、HTTP、ESB 同步類型、基于單次請求級別的 Mock 調用，測試人員在本地用測試工具進行發(fā)起請求，每個測試工具都作為一個獨立的 MockService 存在，達到互不干擾、千人千面的效果，同時業(yè)務方系統(tǒng)無需植入 Mock 代碼，即可支持 Mock 能力，大大減少開發(fā)工作量和發(fā)布上線風險。

隨著 Mock 功能深入開展，基于請求級別的 Mock 還遠遠不能完全滿足業(yè)務測試場景，尤其是后臺系統(tǒng)，測試人員在實際使用過程中，又遇到如下困難：

多線程、Job 等異步方式發(fā)起后端依賴方請求，尤其應用自己實現的多線程邏輯時，請求的調用鏈路會斷開，導致 Mock 標識無法傳遞；被測應用的一次調用過程，往后端系統(tǒng)同一個接口，發(fā)起多次不同參數的請求，無法得到不同的 Mock 響應；實際測試場景中，存在回調過程，無法模擬；請求從 UI 層面發(fā)起時，無法生成 Mock 標識；為了解決測試的痛點，提高測試覆蓋率，蛙測平臺將 Mock1.0 進行功能擴展，推出了全局樁、UI 樁、回調樁等功能，也就是 Mock2.0 版本。

第二階段：Mock2.0 從局部到全面過程

在 Mock1.0 版本中，僅支持請求級別的 Mock 功能，而在 Mock2.0 版本中，Mock 能力將從請求級擴展到全局樁、UI 樁、回調樁等全面樁，解決測試過程中，所涉及的 Mock 需求。

全局樁：

全局樁功能是為了解決異步、多線程等測試場景，整體思路是：測試人員事先一次性的將需要 Mock 的依賴方接口信息，刷入被測系統(tǒng) JVM 內存中，這些 MOCK 信息，全局生效，當請求中沒有附帶 Mock 標識時（請求可能由頁面觸發(fā)、也能由其他測試工具觸發(fā)），被 Mock 的后方接口，一律走全局樁服務，當請求中附帶 Mock 標識時，請求級 Mock 優(yōu)先級高于全局樁 Mock。

UI 樁：

UI 樁主要應用于是分層測試設計中，通過分層、解耦，可以簡化問題，針對有明確分層設計的系統(tǒng)，在層與層之間驗證接口的正確性。比如：Web、APP UI 層面，可以適當介入 Mock，將關鍵接口 Mock 掉，達到 UI 驗證的目的，而后端接口，通過接口方式進行場景驗證，從而達到分層測試目的。UI 樁設計思路如下：

測試工具可以自動將本地瀏覽器代理、手機代理設置為 Proxy 服務地址，同時，根據規(guī)則，監(jiān)聽前后交互請求，測試人員可以選擇錄制生成自動化腳本，還可以根據規(guī)則篡改、響應等等，達到前后分離測試目的，還能屏蔽后端服務或者接口，對邊界值、等價類劃分等數據進行模擬，提高測試場景覆蓋。

測試工具提供簡單的 GUI 操作，具體如下：

啟動代理：

生成步驟：

埋樁：

回調樁：

在實際系統(tǒng)交互中，還存在這樣的場景：后方依賴服務響應比較慢，在高并發(fā)場景下，調用方會積壓大量的線程阻塞等待依賴方的返回結果，導致調用方資源被耗盡，產生嚴重后果，為了解決這種場景，業(yè)務方一般采用異步回調方式來解決。為了模擬異步回調測試場景，Mock 能力也擴展了回調功能，模擬后方系統(tǒng)結果返回、延遲回調等場景，從而達到測試目的。

第三階段：從自動化到壓測擋板過程

從第一階段的請求級樁到全局樁，樁的服務能力不斷增強，不斷滿足測試產品線各類業(yè)務場景，主要針對功能的驗證，模擬依賴方的返回，并結合自動化工具，固化成腳本，達到復用的目的。但在性能測試過程中，期望對 Mock 還需具備壓測擋板的能力，問題如下：

在跨系統(tǒng)的性能測試中，由于客觀因素的限制，如：測試資源有限、后端系統(tǒng)不具備壓測條件、后端系統(tǒng)性能不達標等，導致無法線下壓測被測系統(tǒng)性能；全鏈路壓測過程中，無法屏蔽外部依賴系統(tǒng)和限定鏈路范圍；線下壓測過程中，很難模擬在后端應用不同性能下，比如：延遲設置 0.5s、1s 甚至 2s 的不同延遲，考察被測應用在不同的延遲情況下的性能表現。為了解決以上壓測過程中問題，蛙測推出了基于熱插拔方式壓測擋板服務，主要解決了壓測過程中，模擬依賴應用性能，比如：TPS、響應延遲等，具備能力如下：

支持熱插拔，隨時可以終止 MockFilter 服務，提高了系統(tǒng)對災難的及時恢復能力、擴展性和靈活性；支持消費端擋板，樁信息一次性刷入被測應用 jvm 中，被 Mock 的后端服務，直接從消費端內存中直接獲取并返回，模擬延遲等，此 Mock 請求直接從被測應用的服務器內拿 Mock 響應；支持服務端擋板，樁服務由蛙測平臺額外獨立提供，根據用戶設定的性能 TPS 指標，動態(tài)計算需要多少 Mock 服務線程以及多少臺 Mock 服務節(jié)點，并把響應的 Mock 信息一次性刷入到 Mock 服務器中，供本次壓測使用，此 Mock 請求從被測應用服務器外部拿 Mock 響應；為什么要區(qū)分消費端擋板和服務端擋板呢？主要是在實際應用中，尤其生產環(huán)境的壓測，并沒有那么多的 Mock 服務器資源供擋板調用，而消費端擋板恰恰解決了這一問題，充分利用被壓應用服務器資源，壓測預熱前，一次性刷入需要 Mock 的后端應用服務，壓測過程中，通過各個中間件進行 MockFilter，決定后端調用是 Mock 調用還是真實調用，是消費端 Mock 還是服務端 Mock。

消費端擋板整體思路：

服務端擋板整體思路：

蛙測擋板創(chuàng)建：

消費端 VS 服務端擋板壓測結果對比：

壓測目的：消費端擋板與服務端擋板性能對比機器 4C 8G場景：被 Mock 系統(tǒng)模擬樁數 1 萬條

從壓測對比中，得出結論：消費端擋板性能表現遠遠的高于服務端擋板，但相應的對于服務端資源消耗占比較高。針對以上數據對比，并結合實際業(yè)務場景壓測需求，可擇優(yōu)選擇合適的擋板方案。

結語

蛙測的 Mock 服務能力從最初的請求級、千人千面的 Mock 到全局樁能力，從手工測試到自動化測試再到壓測擋板，不斷的探索、提升測試過程中的效能。未來，我們還會在字節(jié)碼層面進行線上錄制，轉化成自動化腳本，回放到測試環(huán)境，Mock 掉必要的依賴調用等，達到線上錄制回放的目的，在測試技術方向，蛙測團隊將會繼續(xù)努力探索，永不停歇！