來源：IT刊

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

前言

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

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

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

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

實踐過程及應(yīng)用效果

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

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

正常請求：

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

Mock 請求：

Mock 標(biāo)識如何傳遞:

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

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

在 MockService 服務(wù)上，還支持匹配規(guī)則，根據(jù)匹配規(guī)則，響應(yīng)不同內(nèi)容。

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

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

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

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

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

全局樁：

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

UI 樁：

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

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

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

啟動代理：

生成步驟：

埋樁：

回調(diào)樁：

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

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

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

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

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

消費端擋板整體思路：

服務(wù)端擋板整體思路：

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

消費端 VS 服務(wù)端擋板壓測結(jié)果對比：

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

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

結(jié)語

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