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