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

前言

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

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

1. 依賴方不可用，測試人員無法提前介入測試；
2. 資料構造，複雜的場景或者特殊的資料，無法很快生成，導致場景無法覆蓋；
3. 異常模擬；
4. 外部系統不可用，或者沒有對應的測試環境，或者需要現金交易；
5. 壓測時，依賴方效能較差，無法保證本系統效能最優；全鏈路壓測時，無法限定鏈路範圍；

爲了提高生產效率和測試覆蓋率，蘇寧蛙測平臺上線全場景 Mock 樁服務解決方案，支援 HTTP、ESB、RPC 等協議 Mock，支援同步、非同步以及回撥場景等功能，成功解決測試人員、開發人員在測試和研發過程中，資料構造、環境依賴等痛點，大大提高了生產效率，提高測試場景的覆蓋率，保障了業務版本上線的質量。目前蛙測 Mock 服務應用於蘇寧 100+ 中臺、後臺系統，服務了 1000+ 萬次樁服務呼叫，在蘇寧各個測試產品線得到了廣泛的應用。具備的能力如下：

實踐過程及應用效果

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

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

正常請求：

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

Mock 請求：

Mock 標識如何傳遞:

1. RPC 型別：內部 Java 遠端呼叫框架 RSF，在測試工具模擬服務消費方，發起 RSF 請求時，會附帶本次請求中需要 Mock 的後端依賴方，以 Attachement 方式附帶到 RSF 服務方，在服務方應用中，RSF 元件會進行識別、路由，RSF 中介軟體請求完成後，進行 Mock 資訊清理；
2. HTTP/ESB 型別：被測應用在打包或者 CD 釋出時，手動或者自動在 web.xml 中配置中增加 Mock 的 filter 過濾器，在 doFileter 方法中，如果識別到 HTTP 請求頭中包含 Mock 標識，則將 Mock 資訊設定到中介軟體中，在中介軟體發起依賴方 HTTP 請求時，進行 Mock 識別、轉發，請求結束後，清理本次請求的 Mock 資訊；

測試工具如何埋樁：

一次 RPC 的呼叫，可能涉及多個後端依賴系統服務呼叫，所以，在工具指令碼設計時，增加了步驟 Group 概念。把本次一次呼叫過程中，需要 Mock 的呼叫，放在一個 Group 下，在發起請求時，把 Group 下的 Mock 步驟，打成多個 Mock flag 標識，供 RPC 元件中 Mock 識別模組識別，互動如下：

在 MockService 服務上，還支援匹配規則，根據匹配規則，響應不同內容。

在 Mock1.0 服務中，僅支援 RPC、HTTP、ESB 同步型別、基於單次請求級別的 Mock 呼叫，測試人員在本地用測試工具進行發起請求，每個測試工具都作為一個獨立的 MockService 存在，達到互不干擾、千人千面的效果，同時業務方系統無需植入 Mock 程式碼，即可支援 Mock 能力，大大減少開發工作量和釋出上線風險。

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

1. 多執行緒、Job 等非同步方式發起後端依賴方請求，尤其應用自己實現的多執行緒邏輯時，請求的呼叫鏈路會斷開，導致 Mock 標識無法傳遞；
2. 被測應用的一次呼叫過程，往後端系統同一個介面，發起多次不同引數的請求，無法得到不同的 Mock 響應；
3. 實際測試場景中，存在回撥過程，無法模擬；
4. 請求從 UI 層面發起時，無法生成 Mock 標識；

爲了解決測試的痛點，提高測試覆蓋率，蛙測平臺將 Mock1.0 進行功能擴充套件，推出了全域性樁、UI 樁、回撥樁等功能，也就是 Mock2.0 版本。

第二階段：Mock2.0 從區域性到全面過程

在 Mock1.0 版本中，僅支援請求級別的 Mock 功能，而在 Mock2.0 版本中，Mock 能力將從請求級擴充套件到全域性樁、UI 樁、回撥樁等全面樁，解決測試過程中，所涉及的 Mock 需求。

全域性樁：

全域性樁功能是爲了解決非同步、多執行緒等測試場景，整體思路是：測試人員事先一次性的將需要 Mock 的依賴方介面資訊，刷入被測系統 JVM 記憶體中，這些 MOCK 資訊，全域性生效，當請求中沒有附帶 Mock 標識時（請求可能由頁面觸發、也能由其他測試工具觸發），被 Mock 的後方介面，一律走全域性樁服務，當請求中附帶 Mock 標識時，請求級 Mock 優先順序高於全域性樁 Mock。

UI 樁：

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

測試工具可以自動將本地瀏覽器代理、手機代理設定為 Proxy 服務地址，同時，根據規則，監聽前後互動請求，測試人員可以選擇錄製生成自動化指令碼，還可以根據規則篡改、響應等等，達到前後分離測試目的，還能遮蔽後端服務或者介面，對邊界值、等價類劃分等資料進行模擬，提高測試場景覆蓋。

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

啟動代理：

生成步驟：

埋樁：

回撥樁：

在實際系統互動中，還存在這樣的場景：後方依賴服務響應比較慢，在高併發場景下，呼叫方會積壓大量的執行緒阻塞等待依賴方的返回結果，導致呼叫方資源被耗盡，產生嚴重後果，爲了解決這種場景，業務方一般採用非同步回撥方式來解決。爲了模擬非同步回撥測試場景，Mock 能力也擴充套件了回撥功能，模擬後方系統結果返回、延遲迴調等場景，從而達到測試目的。

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

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

1. 在跨系統的效能測試中，由於客觀因素的限制，如：測試資源有限、後端系統不具備壓測條件、後端系統性能不達標等，導致無法線下壓測被測系統性能；
2. 全鏈路壓測過程中，無法遮蔽外部依賴系統和限定鏈路範圍；
3. 線下壓測過程中，很難模擬在後端應用不同效能下，比如：延遲設定 0.5s、1s 甚至 2s 的不同延遲，考察被測應用在不同的延遲情況下的效能表現。

爲了解決以上壓測過程中問題，蛙測推出了基於熱插拔方式壓測擋板服務，主要解決了壓測過程中，模擬依賴應用效能，比如：TPS、響應延遲等，具備能力如下：

• 支援熱插拔，隨時可以終止 MockFilter 服務，提高了系統對災難的及時恢復能力、擴充套件性和靈活性；
• 支援消費端擋板，樁資訊一次性刷入被測應用 jvm 中，被 Mock 的後端服務，直接從消費端記憶體中直接獲取並返回，模擬延遲等，此 Mock 請求直接從被測應用的伺服器內拿 Mock 響應；
• 支援服務端擋板，樁服務由蛙測平臺額外獨立提供，根據使用者設定的效能 TPS 指標，動態計算需要多少 Mock 服務執行緒以及多少臺 Mock 服務節點，並把響應的 Mock 資訊一次性刷入到 Mock 伺服器中，供本次壓測使用，此 Mock 請求從被測應用伺服器外部拿 Mock 響應；

為什麼要區分消費端擋板和服務端擋板呢？主要是在實際應用中，尤其生產環境的壓測，並沒有那麼多的 Mock 伺服器資源供擋板呼叫，而消費端擋板恰恰解決了這一問題，充分利用被壓應用伺服器資源，壓測預熱前，一次性刷入需要 Mock 的後端應用服務，壓測過程中，通過各個中介軟體進行 MockFilter，決定後端呼叫是 Mock 呼叫還是真實呼叫，是消費端 Mock 還是服務端 Mock。

消費端擋板整體思路：

服務端擋板整體思路：

蛙測擋板建立：

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

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

從壓測對比中，得出結論：消費端擋板效能表現遠遠的高於服務端擋板，但相應的對於服務端資源消耗佔比較高。針對以上資料對比，並結合實際業務場景壓測需求，可擇優選擇合適的擋板方案。

結語

蛙測的 Mock 服務能力從最初的請求級、千人千面的 Mock 到全域性樁能力，從手工測試到自動化測試再到壓測擋板，不斷的探索、提升測試過程中的效能。未來，我們還會在位元組碼層面進行線上錄製，轉化成自動化指令碼，回放到測試環境，Mock 掉必要的依賴呼叫等，達到線上錄製回放的目的，在測試技術方向，蛙測團隊將會繼續努力探索，永不停歇！

作者簡介

程派峰，蘇寧易購測試平臺高階技術經理，2013 年加入蘇寧，一直從事測試工具與平臺的研發工作。具備廣泛的技術視野和很強的技術前瞻性，瞭解新技術、新趨勢，擅長自動化測試技術創新。對各種開源框架有了解，並具備良好的落地實踐，目前專注於工程效能及質量提升工作。

感謝張嬋對本文的審校。