傳統(tǒng)測試與微服務(wù)測試的區(qū)別

烏拉特中網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)從2013年創(chuàng)立到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。

傳統(tǒng)測試模型抽象

上圖中的服務(wù)器端包括n個功能，傳統(tǒng)服務(wù)是所有的功能都部署在一臺機器上，通過增加服務(wù)器數(shù)量來擴容!參考下圖(每一種顏色代表一個功能，部署了四套同樣的服務(wù))

微服務(wù)測試模型抽象

微服務(wù)不同于傳統(tǒng)測試，它往往沒有UI頁面，我們需要通過構(gòu)建請求(通過編碼或者工具模擬)調(diào)用各個服務(wù)接口。微服務(wù)是以業(yè)務(wù)為單位進行部署的，上圖中的每一個服務(wù)代表一個功能，不同的業(yè)務(wù)部署在不同的服務(wù)器上，業(yè)務(wù)使用頻繁的還可以使用更多的資源進行部署(下圖中橘黃色部署了5個單元，而玫紅色只部署了1個單元)，這樣就可以更合理的利用資源了。

微服務(wù)的主要測試內(nèi)容

• 單元測試：從服務(wù)中最小可測試單元視角驗證代碼行為符合預期，以便測試出方法、類級別的缺陷。
• 集成測試：驗證當前服務(wù)與外部模塊之間的通信方式或者交互符合預期，以便測試出接口缺陷。
• 組件測試：將測試范圍限制在被測系統(tǒng)的一部分(一般是單個服務(wù))，使用測試替身(mock)將其與其他組件隔離，以便測試出被測代碼的缺陷。
• 契約測試：驗證當前服務(wù)與外部服務(wù)之間的交互，以表明它符合消費者服務(wù)所期望的契約，本質(zhì)驗證接口規(guī)范
• UI測試：傳統(tǒng)的點點點頁面測試。

其中，集成測試、組件測試和契約測試是我們的測試重點，而上述三種測試，我們可以理解為接口測試(關(guān)于什么是接口測試這里就不再詳細介紹了)。即每個服務(wù)提供對外接口，然后我們通過這個接口對服務(wù)進行調(diào)用，最后驗證其返回值是否達到預期!我們可以通過編碼或者工具來構(gòu)建接口并向接口發(fā)起請求，然后按照接口文檔來校驗響應(yīng)是否符合預期。

微服務(wù)測試注意事項

微服務(wù)可以分為無依賴的服務(wù)和有依賴的服務(wù)。

• 無依賴的服務(wù)：自己就能夠滿足調(diào)用者的需求提供完整的服務(wù)功能，無需其他服務(wù)提供功能。我們直接對該服務(wù)提供的接口進行測試即可
• 有依賴的服務(wù)：自己不能夠滿足調(diào)用者的需求，需要其他服務(wù)提供某一種或多種功能，一起向調(diào)用者提供完整的服務(wù)功能。此時我們需要隔離掉單個微服務(wù)依賴的其他微服務(wù)，避免測試過程中受到依賴服務(wù)的影響(如服務(wù)不可用、服務(wù)缺陷等)而出現(xiàn)阻塞測試過程、測試無效等情況。通常使用mock技術(shù)將被測服務(wù)與依賴的服務(wù)進行隔離，使得服務(wù)鏈路穩(wěn)定、環(huán)境可控，這有利于測試過程的開展。Mock概念起源于單元測試，單元測試中我們只關(guān)注被測的單元，而不關(guān)心其他依賴的內(nèi)容。Mock讓我們有了一套仿真的環(huán)境，不用擔心在檢查單元內(nèi)的內(nèi)部流轉(zhuǎn)的過程時還會因為環(huán)境的關(guān)系導致驗證過程失敗。由于外部環(huán)境的多樣性，單元測試應(yīng)該設(shè)計一些異常場景使得代碼能夠捕獲該異常。例如在下圖a中，如果我們要對A進行測試，那么就要先把整個依賴樹構(gòu)建出來，也就是BCDE的實例，該方案的成本極高。一種替代方案就是使用mock，如圖b所示，我們只需要規(guī)定 Mock B 和Mock C 在接收到A的請求后給出對應(yīng)的響應(yīng)即可(無需在Mock B 和Mock C中執(zhí)行復雜的邏輯運算)。在代碼實現(xiàn)層面，我們可以通過mockito(針對java)實現(xiàn)mock操作。

圖a

圖b

在微服務(wù)測試中mock的服務(wù)又是什么呢?舉個例子，我們把支付功能做成微服務(wù)，該服務(wù)負責處理支付的邏輯，而在最后付款時，我們需要調(diào)用支付寶來完成付款。那么這個場景該如何處理呢?簡單方式，我們花一分錢真實的購買服務(wù)。那么假設(shè)我們要驗證10000元購買服務(wù)呢?或者當支付寶出錯時，我們的程序又該如何處理呢?在這里我們就可以把支付寶作為一個mock服務(wù)，核心實現(xiàn)思路如下：

對應(yīng)用的請求進行解析，并返回預先定義好的響應(yīng)值，具體如下：

1.支付請求校驗正確，返回支付成功;

2.支付請求校驗失敗，返回支付失敗;

3.關(guān)掉支付寶mock服務(wù)，可以模擬支付寶異常

我們可以使用wiremock來搭建自己的mock服務(wù)器，簡單原理如下圖所示:

我們需要在配置文件中設(shè)置預定義的請求，如果應(yīng)用的請求符合預定義請求則返回預定義的響應(yīng)。然后啟動wiremock來實現(xiàn)請求的處理，wiremock就是一個web服務(wù)器!具體詳情請參考：https://github.com/tomakehurst/wiremock

微服務(wù)測試總結(jié)

1. 如果你只做UI功能測試，那么微服務(wù)測試與傳統(tǒng)測試沒有區(qū)別，因為你只你感受不到架構(gòu)的變化。

2.對各個微服務(wù)提供的接口測試本質(zhì)上等價于接口測試。需要按照微服務(wù)的接口說明文檔進行接口功能以及性能和安全的測試。

3.必要時需要通過mock方式來模擬微服務(wù)所依賴的服務(wù)來提升被測服務(wù)的可測性。

4.要關(guān)注負載均衡，測試請求是否分發(fā)到多點應(yīng)用。參考文章：微服務(wù)性能測試的關(guān)鍵——IP欺騙技術(shù)

5.通過工具 SpringCloud Sleuth、 Turbine、Prometheus對各個服務(wù)消耗的資源(包括：cpu、內(nèi)存、磁盤，網(wǎng)絡(luò))進行監(jiān)控;

6.通過ELK( ElasticStack )來集中化管理日志。參考文章：微服務(wù)測試的關(guān)鍵——通過ELK查詢?nèi)罩?/p>

7.理解微服務(wù)的核心概念。參考文章：一文搞定微服務(wù)測試本質(zhì)

分享標題：讀懂這篇文章，就掌握微服務(wù)測試核心了
文章路徑：http://uogjgqi.cn/article/coicdsc.html