哈啰業(yè)務(wù)數(shù)據(jù)場景痛點(diǎn)
軟硬件一體化應(yīng)用場景 ?
用戶從APP端、支付寶小程序、微信小程序、H5和WEB,經(jīng)過一些核心服務(wù)。核心服務(wù)通過HTTP或內(nèi)部的RPC接口,包含用戶增長、配置平臺(tái)、綜合平臺(tái)、用戶增長等,對(duì)應(yīng)的基礎(chǔ)平臺(tái)包括存儲(chǔ)平臺(tái)、用戶平臺(tái)、算法平臺(tái)、開放平臺(tái)、大數(shù)據(jù)、地圖平臺(tái)等。物聯(lián)網(wǎng)目前主要對(duì)接單車、電動(dòng)車、電池、電柜等。
研發(fā)測試階段遇到的痛點(diǎn) ?
單車這里,紅包車數(shù)據(jù)測試鏈路過長,手工構(gòu)造一次數(shù)據(jù)需要0.5天以上;不同入?yún)⒎祷夭煌Y(jié)果,難以構(gòu)造模擬返回?cái)?shù)據(jù)。助力車這里,超區(qū)斷電依賴地圖算法模型,測試線下路上跑來跑去模擬臨區(qū)超區(qū)耗時(shí)過長。
順風(fēng)車這里,對(duì)接眾多第三方平臺(tái),迭代回歸第三方接口,各種場景返回難以構(gòu)造。支付這里,異常場景眾多,實(shí)名認(rèn)證信息難以構(gòu)造。
換電這里,不同項(xiàng)目并行開發(fā),對(duì)方接口未開發(fā)的情況下,開發(fā)調(diào)試成本過高;無法模擬只支持某個(gè)時(shí)間段的返回結(jié)果。電動(dòng)車這里,通過單測的方式Mock各種場景代碼量巨大;部分場景Mock需要研發(fā)配合改造代碼,侵入性過高,成本較大。
哈啰HiMock和傳統(tǒng)Mock的對(duì)比
傳統(tǒng)Mock在哈啰全場景先天性不足 ?
傳統(tǒng)Mock,一是代碼改動(dòng)頻繁,只要代碼變動(dòng),case相關(guān)代碼都需要改動(dòng),整體耗時(shí)較長;二是鏈路簡單,只支持簡單鏈路的Mock;三是Mock難度上,數(shù)據(jù)構(gòu)造難,非本業(yè)務(wù)線同學(xué)如果沒有接口文檔,不知道如何快速M(fèi)ock;四是擴(kuò)展難度較大,僅支持部分軟件協(xié)議,不能擴(kuò)展。
而哈啰全場景業(yè)務(wù)特性一是代碼改動(dòng)難,涉及到多個(gè)業(yè)務(wù)方,研發(fā)無法及時(shí)配合驗(yàn)證迭代需求改動(dòng)相關(guān)代碼;二是鏈路復(fù)雜,需要支持前后多端、涉及硬件協(xié)議鏈路的Mock;三是Mock難度上,并行開發(fā)時(shí),多個(gè)業(yè)務(wù)同個(gè)接口模擬不同的返回,構(gòu)造成本較大;四是拓展程度上,需要支持軟硬件協(xié)議數(shù)據(jù)模擬。
打破傳統(tǒng)Mock的設(shè)計(jì)思路 ?
我們?yōu)榱舜蚱苽鹘y(tǒng)Mock的設(shè)計(jì)思路,從以下六點(diǎn)設(shè)計(jì)HiMock。一是低代碼,代碼開發(fā)量少,可以快速搭建框架;二是代碼解耦,不需要用戶改動(dòng)任何代碼;三是高性能,不影響原有系統(tǒng)的性能指標(biāo);四是應(yīng)用性,用戶可以低成本Mock;五是支持前后置場景,如簽名、回調(diào)、數(shù)據(jù)庫操作等;六是全場景,支持前后端各種協(xié)議。
Mock技術(shù)支撐全場景業(yè)務(wù)域的實(shí)踐
打破傳統(tǒng)互聯(lián)網(wǎng)的軟硬件結(jié)合的Mock業(yè)務(wù)架構(gòu) ?
首先介紹服務(wù)鏈路,C端用戶主要來源于哈啰APP、支付寶小程序、微信小程序,通過HTTP網(wǎng)關(guān),再進(jìn)入各個(gè)業(yè)務(wù)的入口,包括單車、助力車、電動(dòng)車、換電、順風(fēng)車等,接下來我們協(xié)議攔截之后,再去匹配對(duì)應(yīng)規(guī)則引擎里配置的規(guī)則來看是不是命中了對(duì)應(yīng)的Mock,并去檢查對(duì)應(yīng)的靜默開關(guān)、生效時(shí)間、生效范圍、延時(shí)、參數(shù)替換、后置條件,這些都是通過規(guī)則引擎拿到對(duì)應(yīng)的數(shù)據(jù)。我們通過Mock返回的規(guī)則,一站式并支持多端。
接下來介紹產(chǎn)品能力,一是Mock管理,包括case創(chuàng)建、case列表、我的Mock;二是工具管理,主要是YAPI|Swagger接口導(dǎo)入;三是大盤統(tǒng)計(jì),主要是調(diào)用統(tǒng)計(jì)的分析,包含每個(gè)業(yè)務(wù)域、調(diào)用量以及對(duì)應(yīng)的Mock量、各業(yè)務(wù)線使用的分析等;四是權(quán)限管理,包括用戶權(quán)限和用戶組權(quán)限;五是攔截規(guī)則引擎,包括高并發(fā)支持、靜默支持、生效范圍和參數(shù)替換;六是一體化Mock工作臺(tái),可以集成APP、H5、微信小程序和支付寶小程序,自動(dòng)接口抓包、一鍵功能,并支持YAPI|Swagger接口導(dǎo)入、接口參數(shù)自動(dòng)獲取、匹配規(guī)則參數(shù)自動(dòng)生成;七是自動(dòng)更新,底層代碼改動(dòng),自動(dòng)更新最新代碼;八是環(huán)境穩(wěn)定性,保證整體研發(fā)測試流程不被打斷,Mock可被追溯。
HiMock整體流程 ?
我們case的來源分為三部分,包括HiMock、Fox和第三方。左邊這部分就是用戶請(qǐng)求,分為后端請(qǐng)求和前端請(qǐng)求。后端請(qǐng)求我們通過Agent攔截到對(duì)應(yīng)的協(xié)議之后,根據(jù)Mock、規(guī)則引擎去匹配對(duì)應(yīng)的規(guī)則,如果能匹配到,就把對(duì)應(yīng)的Mock結(jié)果返回出去。
Agent的下載流程也有兩部分,一是Atlas部署的時(shí)候,會(huì)去檢查Agent是否存在,如果不存在,會(huì)自動(dòng)下載到對(duì)應(yīng)服務(wù)的原容器上或者ECS上面。二是添加或更新case的時(shí)候,也會(huì)去判斷Agent是否存在。前端請(qǐng)求iOS是針對(duì)NSURLProtocol協(xié)議進(jìn)行攔截和轉(zhuǎn)發(fā)到對(duì)應(yīng)的Mock規(guī)則引擎,去判斷是否命中;安卓是針對(duì)OkHttp協(xié)議攔截和轉(zhuǎn)發(fā),其他協(xié)議也可以在這里進(jìn)行兼容適配處理。
HiMock底層Agent設(shè)計(jì) ?
HiMock底層Agent設(shè)計(jì)主要分四方面,一是字節(jié)碼攔截,我們經(jīng)過大量的對(duì)比分析,最終選型ByteBuddy作為字節(jié)碼攔截的底層框架,可實(shí)現(xiàn)低代碼,迭代敏捷迅速開發(fā)。二是攔截協(xié)議,我們實(shí)現(xiàn)插件化模式開發(fā),可快速實(shí)現(xiàn)攔截協(xié)議的開發(fā)與配置,支持多維度協(xié)議攔截。三是殼化Agent,對(duì)外暴露一個(gè)premain的殼函數(shù),可實(shí)現(xiàn)動(dòng)態(tài)代碼更新相關(guān)功能。四是后置處理,復(fù)雜鏈路信息,需要在Mock 返回之后,執(zhí)行一些數(shù)據(jù)庫操作、消息發(fā)送、地址回調(diào)等。
?
在HiMock底層Agent實(shí)現(xiàn)上,我們首先把Agent進(jìn)行一個(gè)premain函數(shù)的殼化處理,再對(duì)各個(gè)協(xié)議攔截的Interceptor封裝。HTTP協(xié)議請(qǐng)求,我們針對(duì)CloseableHttpClient、HttpClient、OkHttpClient和RestTemplate等等Class進(jìn)行攔截。RPC協(xié)議,我們有進(jìn)行RpcHandler Class攔截。針對(duì)Mq,我們有Hms進(jìn)行攔截。同理,其他也是攔截對(duì)應(yīng)的核心請(qǐng)求類,再進(jìn)行協(xié)議的攔截。
HiMock規(guī)則引擎設(shè)計(jì) ?
HiMock規(guī)則引擎設(shè)計(jì)思路主要分三方面,包括高并發(fā)、兼容性和多端。在方案調(diào)研上,基于不同協(xié)議,攔截規(guī)則不盡相同,但是作為攔截收口,統(tǒng)一轉(zhuǎn)為JSON進(jìn)行參數(shù)匹配入?yún)l件。最常用的JsonPath框架有fastJson、jackson、json-path和snack3,經(jīng)過多輪壓測,我們最終選型snack3,支持的選擇器表達(dá)式更豐富,性能較優(yōu)。
在方案執(zhí)行上,攔截規(guī)則判斷時(shí)多條件支持,且支持多條件“與、或”組合等。目前支持的條件有equals、not equals、contains、not contains、in等。在方案落地上,攔截規(guī)則參數(shù)根據(jù)入?yún)⒆詣?dòng)生成,參數(shù)預(yù)期值智能匹配。
HiMock平臺(tái)系統(tǒng)架構(gòu) ?
HiMock平臺(tái)包含WEB、核心功能、數(shù)據(jù)層、Agent和Mock服務(wù)。WEB主要有DashBoard、Mock管理、權(quán)限管理、工具管理和平臺(tái)指南。核心功能主要有云容器自動(dòng)部署、自動(dòng)化部署、添加Mock、Mock列表、Mock日志、Mock規(guī)則、工具管理、權(quán)限管理、數(shù)據(jù)統(tǒng)計(jì)和用戶手冊(cè)。同時(shí)我們要適配一些攔截協(xié)議,如RPC、HTTP、TCP、MQ、MQTT、DB、ES。
數(shù)據(jù)層主要分為Mysql、Redis和ES,我們會(huì)把數(shù)據(jù)緩存到Redis里,再定期匯總到Mysql里,并把Redis里的數(shù)據(jù)進(jìn)行清空,減輕緩存壓力。Mock的服務(wù)請(qǐng)求被對(duì)應(yīng)的Agent攔截到協(xié)議請(qǐng)求之后,Agent訪問Mock服務(wù)設(shè)置的規(guī)則數(shù)據(jù),拿到規(guī)則數(shù)據(jù)判斷請(qǐng)求是否被匹配到Mock規(guī)則。
HiMock落地使用場景 ?
HiMock落地使用場景有依賴測試、自動(dòng)化測試、性能壓測和并行開發(fā)等。依賴測試支持 case Mock生效日期和端到端的Mock生效范圍,主要是為了避免某一個(gè)case過大影響實(shí)際的測試范圍。自動(dòng)化測試支持自動(dòng)開啟、關(guān)閉對(duì)應(yīng)的Mock開關(guān)。
性能壓測支持一鍵靜默,只要把靜默開關(guān)打開,所有的調(diào)用Mock case都不會(huì)生效,這時(shí)所有的性能壓測都會(huì)走原始的調(diào)用請(qǐng)求。并行開發(fā)支持生效范圍界定和Mock參數(shù)動(dòng)態(tài)調(diào)整等。當(dāng)然我們?cè)跍y試過程中不要過度依賴基于Mock的測試結(jié)果,Mock只是一種提效手段,基于Mock的測試無論如何多么的充分,都不能保證不會(huì)遺漏。一個(gè)完整的測試策略,一定是由基于Mock的測試和基于非Mock的測試共同組成,二者相輔相成,缺一不可。
HiMock平臺(tái)能力介紹 ?
這里介紹RPC接口的新增,在Mock標(biāo)題里可以根據(jù)自己的場景設(shè)置標(biāo)題,如助力車賠付,應(yīng)用名稱、iface、method是要攔截的對(duì)應(yīng)服務(wù)以及它對(duì)應(yīng)的method。在右邊,我們也可以看到對(duì)應(yīng)這兩個(gè)應(yīng)用名稱,后面可以查看Atlas的配置,如果選擇在ClientAppId進(jìn)行Mock攔截,需要把對(duì)應(yīng)服務(wù)的自定義啟動(dòng)參數(shù)中Agent啟動(dòng)命令配置上去。
Mock環(huán)境里FAT和UAT都可以選擇,同一個(gè)case多個(gè)環(huán)境同時(shí)生效。生效時(shí)間默認(rèn)是永久生效的,如果填寫生效范圍,只會(huì)針對(duì)生效時(shí)間范圍內(nèi)走M(jìn)ock邏輯;下面也有對(duì)應(yīng)的是否開啟的開關(guān)。添加規(guī)則這里,我們支持從用戶請(qǐng)求日志里自動(dòng)獲取對(duì)應(yīng)的請(qǐng)求有哪些參數(shù),減少用戶手動(dòng)填入的復(fù)雜度。最下面的請(qǐng)求響應(yīng)、執(zhí)行日志和變更記錄,主要用來查看預(yù)執(zhí)行的時(shí)候?qū)?yīng)這個(gè)規(guī)則能否匹配到,哪一步攔截失敗,進(jìn)而去調(diào)整Mock匹配規(guī)則。
針對(duì)復(fù)雜場景,我們支持后置模擬回調(diào),包括HMS、HTTP等。 ?
這里是測試請(qǐng)求,測試請(qǐng)求自動(dòng)填入,也可以根據(jù)實(shí)際情況進(jìn)行動(dòng)態(tài)調(diào)整,Mock結(jié)果即時(shí)校驗(yàn)。執(zhí)行日志做到了執(zhí)行過程的匹配,結(jié)果校驗(yàn)可以實(shí)時(shí)看到匹配規(guī)則是否正常匹配,以及匹配的返回結(jié)果是否是想要的。
?
接下來介紹前端一鍵Mock的功能,左邊是我們的APP端,右邊通過掃碼APP-QrCode就可以看到左邊菜單欄有自動(dòng)抓包的鏈路信息,點(diǎn)擊后會(huì)有接口對(duì)應(yīng)的Request和Response。這里我們可以快速M(fèi)ock對(duì)應(yīng)接口的返回,或者是Mock異常的返回。
HiMock平臺(tái)效果價(jià)值回收能力分析 ?
我們主要從六部分進(jìn)行HiMock效果價(jià)值回收能力分析,包括接口調(diào)用統(tǒng)計(jì)分析、Mock業(yè)務(wù)線覆蓋統(tǒng)計(jì)分析、Mock占比分析、業(yè)務(wù)線Mock運(yùn)營分析、Mock case統(tǒng)計(jì)分析和Mock次數(shù)、平均耗時(shí)統(tǒng)計(jì)分析。 ?
這里是HiMock平臺(tái)整體的調(diào)用統(tǒng)計(jì)分析,可以看到具體某個(gè)業(yè)務(wù)線、當(dāng)天調(diào)用量和對(duì)應(yīng)的Mock次數(shù)。左邊是調(diào)用統(tǒng)計(jì)的趨勢圖,右邊是業(yè)務(wù)線Mock次數(shù)的占比。
后續(xù)規(guī)劃&探討
?
Mock平臺(tái)我們分三步走,第一步是測試小哥哥小姐姐通過手工Mock的方式人肉抓包Mock返回,后端Mock代碼改動(dòng)較大,費(fèi)時(shí)費(fèi)事費(fèi)人,重復(fù)勞動(dòng)嚴(yán)重。第二步是HiMock一體化Mock平臺(tái),可以支持全場景、多端Mock。前端自動(dòng)抓包一鍵Mock,規(guī)則匹配參數(shù)自動(dòng)生成,日志請(qǐng)求自動(dòng)填充,極大提升了我們Mock case的整體效率。第三步是HiMock智能化,我們后續(xù)也會(huì)支持適配中間件DB、MQ類型協(xié)議的Mock,與仿真實(shí)驗(yàn)室、精準(zhǔn)自動(dòng)化的進(jìn)一步結(jié)合,打造研發(fā)、精準(zhǔn)測試、高效運(yùn)營的一體化Mock,并打造智能出行Mock平臺(tái),能夠self-learning自適應(yīng),以及更多場景的Mock支持。
審核編輯:劉清
-
RPC
+關(guān)注
關(guān)注
0文章
111瀏覽量
11585 -
HTTP協(xié)議
+關(guān)注
關(guān)注
0文章
66瀏覽量
9812
原文標(biāo)題:基于出行領(lǐng)域全場景的mock提效探索與實(shí)踐
文章出處:【微信號(hào):軟件質(zhì)量報(bào)道,微信公眾號(hào):軟件質(zhì)量報(bào)道】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
FDD與傳統(tǒng)通信技術(shù)的對(duì)比
智能密集架控制系統(tǒng)與傳統(tǒng)系統(tǒng)對(duì)比
POE供電與傳統(tǒng)供電對(duì)比 POE供電技術(shù)原理解析
激光焊縫跟蹤器與傳統(tǒng)焊縫檢測方法的對(duì)比
![激光焊縫跟蹤器與<b class='flag-5'>傳統(tǒng)</b>焊縫檢測方法的<b class='flag-5'>對(duì)比</b>](https://file1.elecfans.com//web3/M00/00/53/wKgZO2dILgSASh4_AABgk32ZH8U65.jpeg)
迅為RK3568開發(fā)板傳統(tǒng)分區(qū)和定制擴(kuò)展分區(qū)鏡像對(duì)比
光伏電站運(yùn)維管理系統(tǒng)與傳統(tǒng)運(yùn)維模式對(duì)比分析
![光伏電站運(yùn)維管理系統(tǒng)與<b class='flag-5'>傳統(tǒng)</b>運(yùn)維模式<b class='flag-5'>對(duì)比</b>分析](https://file1.elecfans.com/web2/M00/F3/13/wKgZomZ7zZmAaOF_AAIWESybF_g809.png)
無人機(jī)智能巡檢系統(tǒng)與傳統(tǒng)巡檢方式的對(duì)比
![無人機(jī)智能巡檢系統(tǒng)與<b class='flag-5'>傳統(tǒng)</b>巡檢方式的<b class='flag-5'>對(duì)比</b>](https://file1.elecfans.com/web2/M00/FE/58/wKgaomaaKmyAdQRIAAH2eJn_H8M850.png)
對(duì)比分析點(diǎn)焊機(jī)與傳統(tǒng)焊接方法
傳統(tǒng)園區(qū)與智慧園區(qū)的對(duì)比及優(yōu)勢
深度學(xué)習(xí)與傳統(tǒng)機(jī)器學(xué)習(xí)的對(duì)比
固態(tài)繼電器與傳統(tǒng)繼電器的對(duì)比
全光網(wǎng)絡(luò)與傳統(tǒng)網(wǎng)絡(luò)架構(gòu)的對(duì)比分析
![全光網(wǎng)絡(luò)與<b class='flag-5'>傳統(tǒng)</b>網(wǎng)絡(luò)架構(gòu)的<b class='flag-5'>對(duì)比</b>分析](https://file1.elecfans.com/web2/M00/EC/62/wKgZomZidC2AC8BCAAVtVZ7ogqQ348.png)
UVLED面光源與傳統(tǒng)光源對(duì)比:誰更勝一籌?
![UVLED面光源與<b class='flag-5'>傳統(tǒng)</b>光源<b class='flag-5'>對(duì)比</b>:誰更勝一籌?](https://file1.elecfans.com/web2/M00/E4/CA/wKgaomY9zKOANjNqAABYeYyiIwY764.png)
UVLED固化箱與傳統(tǒng)固化設(shè)備對(duì)比:優(yōu)勢一目了然
![UVLED固化箱與<b class='flag-5'>傳統(tǒng)</b>固化設(shè)備<b class='flag-5'>對(duì)比</b>:優(yōu)勢一目了然](https://file1.elecfans.com/web2/M00/E4/08/wKgaomY8ONGAN33qAABNpntoYlA735.png)
三種Mock測試方案的應(yīng)用與實(shí)踐總結(jié)
![三種<b class='flag-5'>Mock</b>測試方案的應(yīng)用與實(shí)踐總結(jié)](https://file1.elecfans.com/web2/M00/DE/3D/wKgZomYuHESAU6rhAAAJuluyFY8933.jpg)
評(píng)論