來源：IT刊

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

前言

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

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

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

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

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

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

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

正常請(qǐng)求：

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

Mock 請(qǐng)求：

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

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

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

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

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

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

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

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

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

全局樁：

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

UI 樁：

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

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

測(cè)試工具提供簡(jiǎn)單的 GUI 操作，具體如下：

啟動(dòng)代理：

生成步驟：

埋樁：

回調(diào)樁：

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

第三階段：從自動(dòng)化到壓測(cè)擋板過程

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

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

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

消費(fèi)端擋板整體思路：

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

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

消費(fèi)端 VS 服務(wù)端擋板壓測(cè)結(jié)果對(duì)比：

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

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

結(jié)語

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