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

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

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

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

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

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

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

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

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

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

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

圖a

圖b

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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