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

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

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

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

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

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

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

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

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

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

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

圖a

圖b

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

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

1.支付請求校驗(yàn)正確，返回支付成功;

2.支付請求校驗(yàn)失敗，返回支付失敗;

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

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

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

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

1. 如果你只做UI功能測試，那么微服務(wù)測試與傳統(tǒng)測試沒有區(qū)別，因?yàn)槟阒荒愀惺懿坏郊軜?gòu)的變化。

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

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

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

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

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

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