苏宁MOCK测试桩服务建设实践
前言? ?
\\2018 年蘇寧易購提出了智慧零售大開發戰略，今年將新開 5000 家門店，到 2020 年，線下門店總數達 2 萬家。半年來，以急速推進的大開發戰略高超迭起，店面實現從城市到縣鎮市場全面覆蓋，使得消費者在任何時間、任何地點、任何服務的需求都可以得到滿足。
\\這樣的發展速度對蘇寧的 IT 技術提出了更高的要求，其中一個重要的環節就是加快軟件版本的上線步伐，伴隨著軟件的上線必然存在巨大的測試壓力，在敏捷過程中，蘇寧測試遇到了如下困境：
\\為了提高生產效率和測試覆蓋率，蘇寧蛙測平臺上線全場景 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 標識如何傳遞:
\\測試工具如何埋樁：
\\一次 RPC 的調用，可能涉及多個后端依賴系統服務調用，所以，在工具腳本設計時，增加了步驟 Group 概念。把本次一次調用過程中，需要 Mock 的調用，放在一個 Group 下，在發起請求時，把 Group 下的 Mock 步驟，打成多個 Mock flag 標識，供 RPC 組件中 Mock 識別模塊識別，交互如下：
\\\\在 MockService 服務上，還支持匹配規則，根據匹配規則，響應不同內容。
\\\\在 Mock1.0 服務中，僅支持 RPC、HTTP、ESB 同步類型、基于單次請求級別的 Mock 調用，測試人員在本地用測試工具進行發起請求，每個測試工具都作為一個獨立的 MockService 存在，達到互不干擾、千人千面的效果，同時業務方系統無需植入 Mock 代碼，即可支持 Mock 能力，大大減少開發工作量和發布上線風險。
\\隨著 Mock 功能深入開展，基于請求級別的 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 還需具備壓測擋板的能力，問題如下：
\\為了解決以上壓測過程中問題，蛙測推出了基于熱插拔方式壓測擋板服務，主要解決了壓測過程中，模擬依賴應用性能，比如：TPS、響應延遲等，具備能力如下：
\\- 支持熱插拔，隨時可以終止 MockFilter 服務，提高了系統對災難的及時恢復能力、擴展性和靈活性；\\t
- 支持消費端擋板，樁信息一次性刷入被測應用 jvm 中，被 Mock 的后端服務，直接從消費端內存中直接獲取并返回，模擬延遲等，此 Mock 請求直接從被測應用的服務器內拿 Mock 響應；\\t
- 支持服務端擋板，樁服務由蛙測平臺額外獨立提供，根據用戶設定的性能 TPS 指標，動態計算需要多少 Mock 服務線程以及多少臺 Mock 服務節點，并把響應的 Mock 信息一次性刷入到 Mock 服務器中，供本次壓測使用，此 Mock 請求從被測應用服務器外部拿 Mock 響應；\
為什么要區分消費端擋板和服務端擋板呢？主要是在實際應用中，尤其生產環境的壓測，并沒有那么多的 Mock 服務器資源供擋板調用，而消費端擋板恰恰解決了這一問題，充分利用被壓應用服務器資源，壓測預熱前，一次性刷入需要 Mock 的后端應用服務，壓測過程中，通過各個中間件進行 MockFilter，決定后端調用是 Mock 調用還是真實調用，是消費端 Mock 還是服務端 Mock。
\\消費端擋板整體思路：
\\\\服務端擋板整體思路：
\\\\
蛙測擋板創建：
\\\\消費端 VS 服務端擋板壓測結果對比：
\\- 壓測目的：消費端擋板與服務端擋板性能對比\\t
- 機器 4C 8G\\t
- 場景：被 Mock 系統模擬樁數 1 萬條\
從壓測對比中，得出結論：消費端擋板性能表現遠遠的高于服務端擋板，但相應的對于服務端資源消耗占比較高。針對以上數據對比，并結合實際業務場景壓測需求，可擇優選擇合適的擋板方案。
\\結語? ?
\\蛙測的 Mock 服務能力從最初的請求級、千人千面的 Mock 到全局樁能力，從手工測試到自動化測試再到壓測擋板，不斷的探索、提升測試過程中的效能。未來，我們還會在字節碼層面進行線上錄制，轉化成自動化腳本，回放到測試環境，Mock 掉必要的依賴調用等，達到線上錄制回放的目的，在測試技術方向，蛙測團隊將會繼續努力探索，永不停歇！
\\作者簡介
\\程派峰，蘇寧易購測試平臺高級技術經理，2013 年加入蘇寧，一直從事測試工具與平臺的研發工作。具備廣泛的技術視野和很強的技術前瞻性，了解新技術、新趨勢，擅長自動化測試技術創新。對各種開源框架有了解，并具備良好的落地實踐，目前專注于工程效能及質量提升工作。
\\感謝張嬋對本文的審校。
新人創作打卡挑戰賽發博客就能抽獎！定制產品紅包拿不停！總結
以上是生活随笔為你收集整理的苏宁MOCK测试桩服务建设实践的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 互联网IP路由的逐跳全局最优化原则-Di
- 下一篇： ios获取设备信息总结