在許多方面，測(cè)試微服務(wù)應(yīng)用程序與測(cè)試使用任何其他體系結(jié)構(gòu)構(gòu)建的應(yīng)用程序沒(méi)有什么不同。微服務(wù)面臨的獨(dú)特挑戰(zhàn)是組成應(yīng)用程序的服務(wù)數(shù)量之多，以及服務(wù)之間的依賴關(guān)系數(shù)量。

作為用于構(gòu)建復(fù)雜系統(tǒng)的體系結(jié)構(gòu)，微服務(wù)在開(kāi)發(fā)社區(qū)中獲得了巨大的關(guān)注。盡管人們開(kāi)始意識(shí)到這并不是解決所有應(yīng)用程序體系結(jié)構(gòu)問(wèn)題的靈丹妙藥，但是那些與依賴項(xiàng)和擴(kuò)展性相關(guān)的挑戰(zhàn)共享的應(yīng)用程序可以從中受益匪淺。

微服務(wù)的采用正在上升，但是與了解如何測(cè)試微服務(wù)相關(guān)的斗爭(zhēng)也在增加。ThoughtWorks的Toby Clemson在列舉您可能希望在微服務(wù)體系結(jié)構(gòu)中使用的測(cè)試策略方面做得非常出色（請(qǐng)參閱他的文章，以獲取有關(guān)您可能要?jiǎng)?chuàng)建的不同測(cè)試類型的詳盡概述），但是有關(guān)如何建立和維護(hù)那些不同種類的測(cè)試仍處于起步階段。

但是在許多方面，測(cè)試微服務(wù)應(yīng)用程序與測(cè)試使用任何其他體系結(jié)構(gòu)構(gòu)建的應(yīng)用程序沒(méi)有什么不同。微服務(wù)使用眾所周知的技術(shù)，例如REST或隊(duì)列，為此軟件行業(yè)已經(jīng)擁有完善的測(cè)試工具和最佳實(shí)踐。微服務(wù)面臨的唯一挑戰(zhàn)是構(gòu)成應(yīng)用程序的服務(wù)數(shù)量之多，以及服務(wù)之間的依賴性。此外，即使微服務(wù)依賴的其他微服務(wù)不可用或響應(yīng)不正確，每個(gè)微服務(wù)仍需要正常運(yùn)行。

微服務(wù)在相互交互時(shí)通常遵循兩種模式：編排和響應(yīng)式（編排）。許多微服務(wù)使用組合的“混合”方法。在本文中，我將提供一些策略來(lái)解決在使用這些不同模式的微服務(wù)創(chuàng)建自動(dòng)化測(cè)試時(shí)出現(xiàn)的一些挑戰(zhàn)，重點(diǎn)是針對(duì)單個(gè)微服務(wù)的測(cè)試（而不是整個(gè)應(yīng)用程序的端到端測(cè)試） 。

測(cè)試精心設(shè)計(jì)的微服務(wù)

使用業(yè)務(wù)流程的微服務(wù)將對(duì)外部服務(wù)或依賴項(xiàng)進(jìn)行一個(gè)或多個(gè)顯式調(diào)用。這些調(diào)用通常使用同步請(qǐng)求-響應(yīng)流，并且通常將訪問(wèn)基于REST的服務(wù)。如果需要按特定順序調(diào)用服務(wù)，則在收到對(duì)前一個(gè)服務(wù)的調(diào)用的響應(yīng)之前，不會(huì)進(jìn)行對(duì)后一個(gè)服務(wù)的調(diào)用。由于一項(xiàng)服務(wù)顯式調(diào)用另一項(xiàng)服務(wù)，因此它們緊密耦合。

在上面顯示的示例中，為投資組合微服務(wù)創(chuàng)建和執(zhí)行測(cè)試具有挑戰(zhàn)性，因?yàn)橥顿Y組合微服務(wù)依賴于帳戶和報(bào)價(jià)微服務(wù)，而依賴項(xiàng)需要與投資組合微服務(wù)一起部署在測(cè)試環(huán)境中。Quotes服務(wù)依賴于第三方服務(wù)來(lái)檢索實(shí)時(shí)股票價(jià)格，并且該服務(wù)返回的數(shù)據(jù)始終在變化。

依賴第三方服務(wù)或由不同團(tuán)隊(duì)開(kāi)發(fā)的服務(wù)極大地增加了測(cè)試環(huán)境的復(fù)雜性。此外，還需要測(cè)試投資組合服務(wù)的任何意外行為，例如，當(dāng)“帳戶”和/或“報(bào)價(jià)”服務(wù)不可用，響應(yīng)緩慢或響應(yīng)意外數(shù)據(jù)時(shí)。重要的是，必須使這些服務(wù)以不同的意外行為響應(yīng)，以驗(yàn)證Portfolio微服務(wù)正確處理了錯(cuò)誤情況。

服務(wù)虛擬化急救！

您可以使用服務(wù)虛擬化來(lái)模擬“帳戶和報(bào)價(jià)”微服務(wù)的響應(yīng)。通過(guò)服務(wù)虛擬化，您可以定義“帳戶和報(bào)價(jià)”微服務(wù)的虛擬版本，并將它們與投資組合微服務(wù)的實(shí)際實(shí)例一起部署。虛擬化微服務(wù)類似于虛擬化任何其他類型的服務(wù)或應(yīng)用程序體系結(jié)構(gòu)。它可能看起來(lái)像這樣：

完成此操作后，就可以獨(dú)立于其兩個(gè)依賴項(xiàng)來(lái)測(cè)試Portfolio微服務(wù)。

下一個(gè)挑戰(zhàn)是為不同的情況配置不同的環(huán)境，例如“帳戶和報(bào)價(jià)”服務(wù)表現(xiàn)出預(yù)期的行為和意外的行為。假設(shè)團(tuán)隊(duì)要測(cè)試“帳戶”服務(wù)或“報(bào)價(jià)”服務(wù)響應(yīng)緩慢或出現(xiàn)錯(cuò)誤情況時(shí)投資組合服務(wù)的行為。這可能需要運(yùn)行至少5組不同的測(cè)試，其中每組都具有不同的環(huán)境配置，并考慮到響應(yīng)時(shí)間慢、錯(cuò)誤響應(yīng)以及相關(guān)服務(wù)的正常和異常行為。

對(duì)于每次測(cè)試運(yùn)行，都需要將環(huán)境放入正確的配置中，然后才能運(yùn)行針對(duì)該配置的測(cè)試。在此示例中，我們最終進(jìn)行了至少五次不同的測(cè)試運(yùn)行，每種測(cè)試運(yùn)行都有針對(duì)環(huán)境的自己的配置。Parasoft的持續(xù)測(cè)試平臺(tái)中的Environment Manager模塊可以為您管理以下不同的環(huán)境配置：

此過(guò)程并非特定于微服務(wù)架構(gòu)-在面向服務(wù)的架構(gòu)以及可能僅依賴少量服務(wù)的整體式應(yīng)用程序中，通常會(huì)出現(xiàn)相同類型的問(wèn)題。但是，在微服務(wù)架構(gòu)中，從屬服務(wù)的數(shù)量顯著增加。在具有數(shù)十個(gè)或數(shù)百個(gè)服務(wù)的微服務(wù)環(huán)境中，針對(duì)不同的測(cè)試場(chǎng)景創(chuàng)建，管理和以編程方式在不同環(huán)境配置之間切換的能力非常重要，并且可以顯著減少時(shí)間和精力。

管理協(xié)調(diào)微服務(wù)中的API更改

隨著團(tuán)隊(duì)發(fā)展其微服務(wù)，不可避免的是將對(duì)服務(wù)進(jìn)行API更改。API更改引起的關(guān)鍵問(wèn)題是如何了解這些更改對(duì)服務(wù)使用者的影響。

當(dāng)團(tuán)隊(duì)為他們正在構(gòu)建的微服務(wù)修改API時(shí)，需要根據(jù)API中的更改來(lái)更新驗(yàn)證該微服務(wù)的所有測(cè)試。相反，如果使用虛擬服務(wù)來(lái)模擬從屬微服務(wù)和用于這些從屬微服務(wù)更改之一的API，則必須更新從屬微服務(wù)的虛擬服務(wù)以反映API中的更改。

許多團(tuán)隊(duì)使用OpenAPI，RAML或其他服務(wù)定義來(lái)描述其微服務(wù)的API。使用服務(wù)定義時(shí)，Parasoft SOAtest和Parasoft Virtualize中的Change Advisor模塊可以自動(dòng)檢測(cè)哪些API已更改，然后自動(dòng)重構(gòu)現(xiàn)有的功能測(cè)試或虛擬服務(wù)，以使用API中的任何新字段和/或刪除的字段來(lái)更新它們。團(tuán)隊(duì)可以創(chuàng)建其服務(wù)定義的更新版本，并可以使用Change Advisor在進(jìn)行更改之前了解更改對(duì)其測(cè)試和虛擬服務(wù)的影響。進(jìn)行更改后，Change Advisor可使您輕松快捷地更新現(xiàn)有資產(chǎn)，以反映微服務(wù)中的更改。

測(cè)試反應(yīng)微服務(wù)

微服務(wù)架構(gòu)的主要目標(biāo)之一是創(chuàng)建獨(dú)立的組件。結(jié)果，部署、擴(kuò)展和更新服務(wù)將變得更加容易。但是，當(dāng)使用業(yè)務(wù)流程模式時(shí)，此目標(biāo)并未完全實(shí)現(xiàn)，因?yàn)閱蝹€(gè)微服務(wù)直接依賴于其他微服務(wù)。解決此問(wèn)題的一種方法是使用編排模式，也稱為“反應(yīng)式”或“事件驅(qū)動(dòng)”微服務(wù)。在這種模式下，微服務(wù)不會(huì)直接相互引用。相反，它們將消息推送到其他微服務(wù)已訂閱的事件流上。

請(qǐng)參見(jiàn)以下示例：

在此示例中，假設(shè)投資組合服務(wù)已被指示添加一個(gè)庫(kù)存頭寸。與其直接調(diào)用“帳戶”服務(wù)，不如將事件發(fā)布到“已添加位置”事件流。帳戶微服務(wù)已訂閱該事件流，因此它獲得了通知。它檢查以確保用戶帳戶中有足夠的資金。如果是這樣，它將減少用戶帳戶中的資金數(shù)量，并將事件發(fā)布到“更新帳戶”事件流中。如果用戶的帳戶中沒(méi)有足夠的資金，則它可能會(huì)將錯(cuò)誤事件發(fā)布到其他事件流（為簡(jiǎn)化示例，未顯示）。投資組合微服務(wù)已訂閱“帳戶更新”事件流，并且當(dāng)看到“帳戶”微服務(wù)發(fā)布的事件時(shí)，它隨后基于來(lái)自帳戶服務(wù)的確認(rèn)更新其投資組合。

這種類型的體系結(jié)構(gòu)中的異步通信帶來(lái)的好處是，服務(wù)彼此之間高度解耦–可以替換，重新部署或擴(kuò)展每個(gè)服務(wù)的實(shí)例，而無(wú)需其他微服務(wù)關(guān)心它們。折衷方案是事件的異步性質(zhì)使得很難理解系統(tǒng)將如何執(zhí)行以及事件的流向。根據(jù)產(chǎn)生的事件的順序或種類，系統(tǒng)可能會(huì)以意外的方式運(yùn)行。這被稱為緊急行為，是在編排微服務(wù)的開(kāi)發(fā)和測(cè)試中固有的挑戰(zhàn)。

異步命令調(diào)用模式

在事件驅(qū)動(dòng)的微服務(wù)的更廣泛類別下，存在不同的異步消息傳遞模式。當(dāng)需要使用異步操作來(lái)編排微服務(wù)時(shí)，可以使用異步命令調(diào)用模式——一種微服務(wù)需要異步調(diào)用另一種微服務(wù)，同時(shí)保證第二種微服務(wù)接收到消息。在這種模式下，通常使用隊(duì)列交換消息。

微服務(wù)架構(gòu)中用于實(shí)現(xiàn)此模式的常見(jiàn)框架是RabbitMQ。當(dāng)一個(gè)微服務(wù)需要發(fā)布事件以供第二個(gè)微服務(wù)處理，然后等待從該第二個(gè)微服務(wù)讀取“答復(fù)”事件時(shí)，就會(huì)發(fā)生這種模式的具體化身。

考慮我們剛才討論的Portfolio示例，其中REST API調(diào)用告訴Portfolio微服務(wù)添加位置。投資組合服務(wù)將一個(gè)事件發(fā)布到“已添加位置”隊(duì)列中，以供帳戶微服務(wù)處理，然后等待帳戶服務(wù)將回復(fù)事件發(fā)布到“帳戶已更新”隊(duì)列中，以便REST API調(diào)用可以返回從該事件接收的數(shù)據(jù)。有兩種不同的方法可以為該示例配置測(cè)試方案：

1. 第一種方法是創(chuàng)建具有必要隊(duì)列的環(huán)境，在該環(huán)境中部署了Portfolio服務(wù)，而沒(méi)有部署Accounts服務(wù)。因?yàn)闆](méi)有部署Accounts服務(wù)，所以測(cè)試場(chǎng)景將需要通過(guò)在適當(dāng)?shù)臅r(shí)間發(fā)布來(lái)自Accounts服務(wù)的預(yù)期事件來(lái)模擬Accounts服務(wù)的行為。Parasoft SOAtest測(cè)試場(chǎng)景將由兩個(gè)測(cè)試構(gòu)成：一個(gè)測(cè)試執(zhí)行Portfolio服務(wù)的REST API，第二個(gè)測(cè)試從Accounts服務(wù)發(fā)布事件。測(cè)試需要配置為可同時(shí)運(yùn)行，以便在組合服務(wù)正在監(jiān)聽(tīng)事件的同時(shí)，帳戶服務(wù)中的事件得以發(fā)布。
2. 與其通過(guò)使用測(cè)試來(lái)模擬Accounts服務(wù)來(lái)發(fā)布事件，不如構(gòu)建一個(gè)可重用的虛擬服務(wù)來(lái)偵聽(tīng)發(fā)布到Position Position隊(duì)列中的事件并將結(jié)果事件發(fā)布到Account Updated隊(duì)列中，這可能會(huì)有所幫助。然后，該虛擬微服務(wù)將可以在可能需要它的多個(gè)不同測(cè)試場(chǎng)景中重用。

第一種方法很簡(jiǎn)單，它使測(cè)試資產(chǎn)自成體系，而對(duì)測(cè)試基礎(chǔ)結(jié)構(gòu)沒(méi)有任何其他外部依賴性。第二種方法是可重用的，并且是對(duì)系統(tǒng)實(shí)際行為的更緊密模擬。但是，第二種方法具有構(gòu)建，部署和管理單獨(dú)的虛擬資產(chǎn)的成本。

異步命令調(diào)用模式的一種變體是微服務(wù)，它在隊(duì)列上偵聽(tīng)傳入事件，處理該事件，然后在另一個(gè)隊(duì)列上發(fā)布后續(xù)事件，以供一個(gè)或多個(gè)其他微服務(wù)處理：

在此示例中，發(fā)票微服務(wù)是需要測(cè)試的服務(wù)。付款服務(wù)將事件發(fā)布到“付款處理的RabbitMQ”隊(duì)列中，以供發(fā)票服務(wù)提取。發(fā)票微服務(wù)從隊(duì)列中讀取事件，創(chuàng)建發(fā)票，然后將事件發(fā)布到“發(fā)票已創(chuàng)建”隊(duì)列，以指導(dǎo)電子郵件微服務(wù)將帶有發(fā)票的電子郵件發(fā)送給客戶。要為發(fā)票微服務(wù)創(chuàng)建測(cè)試方案，可以配置一個(gè)包含兩個(gè)RabbitMQ隊(duì)列和已部署的發(fā)票微服務(wù)的測(cè)試環(huán)境。可以構(gòu)造一個(gè)Parasoft SOAtest測(cè)試方案，該方案將付款處理的事件發(fā)布到Payment Processed隊(duì)列中，然后該方案訂閱``發(fā)票創(chuàng)建''隊(duì)列以驗(yàn)證發(fā)票服務(wù)是否響應(yīng)發(fā)布了正確的發(fā)票創(chuàng)建事件。非常簡(jiǎn)單的測(cè)試方案，可以很好地單獨(dú)測(cè)試Invoice服務(wù)。

事件Firehose模式

當(dāng)不同來(lái)源產(chǎn)生大量需要通過(guò)公共集線器快速交付給不同使用者的事件時(shí)，將使用事件Firehose模式。在這種模式中，消息是通過(guò)主題交換的（與異步命令調(diào)用模式中的消息是通過(guò)隊(duì)列交換的消息相反）。Apache Kafka框架是用于實(shí)現(xiàn)事件firehose模式的常見(jiàn)框架，它看起來(lái)像這樣：

假設(shè)我們要測(cè)試一個(gè)單一的微服務(wù)，該微服務(wù)訂閱一個(gè)Kafka主題，處理它收到的事件，然后將其結(jié)果發(fā)布到另一個(gè)Kafka主題。例如，如下所示：

在此示例中，我們有一個(gè)預(yù)報(bào)微服務(wù)，該微服務(wù)訂閱了“天氣數(shù)據(jù)”主題，該主題從許多不同的來(lái)源收集許多不同的天氣數(shù)據(jù)。然后，它將處理該數(shù)據(jù)以更新其預(yù)測(cè)模型，并將預(yù)測(cè)數(shù)據(jù)發(fā)布到“預(yù)測(cè)數(shù)據(jù)”主題。在這種情況下，我們需要驗(yàn)證天氣預(yù)報(bào)服務(wù)是否將一組特定的天氣數(shù)據(jù)事件的預(yù)期事件發(fā)布到了預(yù)報(bào)數(shù)據(jù)主題。

這可以通過(guò)配置具有兩個(gè)Kafka主題和已部署的Forecast服務(wù)的測(cè)試環(huán)境來(lái)完成。測(cè)試場(chǎng)景將首先將必要的事件發(fā)布到“天氣數(shù)據(jù)”主題，然后訂閱“預(yù)測(cè)數(shù)據(jù)”主題以驗(yàn)證“預(yù)測(cè)”服務(wù)是否發(fā)布了正確的預(yù)測(cè)數(shù)據(jù)事件。需要構(gòu)建多個(gè)不同的測(cè)試方案來(lái)驗(yàn)證可以預(yù)期由預(yù)測(cè)微服務(wù)處理的事件的不同類型和順序。

這是一個(gè)相對(duì)簡(jiǎn)單的測(cè)試方案。預(yù)測(cè)微服務(wù)與其他微服務(wù)分離的事實(shí)帶來(lái)了幸運(yùn)的副作用，即預(yù)測(cè)服務(wù)的測(cè)試也與微服務(wù)分離。在這種情況下，您無(wú)需使用虛擬服務(wù)來(lái)建立復(fù)雜的環(huán)境，您只需創(chuàng)建發(fā)布事件的測(cè)試方案，并驗(yàn)證是否創(chuàng)建了正確的事件作為響應(yīng)即可。

配置測(cè)試環(huán)境

許多微服務(wù)團(tuán)隊(duì)已采用持續(xù)集成/連續(xù)部署（CI/CD）流程來(lái)構(gòu)建，測(cè)試和部署容器化微服務(wù)，以使流程自動(dòng)化并降低與部署更新相關(guān)的風(fēng)險(xiǎn)。

在此過(guò)程中，將自動(dòng)創(chuàng)建一個(gè)包含微服務(wù)的容器映像并將其部署到測(cè)試環(huán)境中（通常由Kubernetes或基于Kubernetes的發(fā)行版（如OpenShift）進(jìn)行管理），在該環(huán)境中可以在微服務(wù)推送到端到端之前對(duì)其進(jìn)行驗(yàn)證。結(jié)束測(cè)試并最終投入生產(chǎn)。我建議閱讀有關(guān)容器化微服務(wù)的CI/CD和設(shè)計(jì)微服務(wù)：持續(xù)集成。這兩篇文章都很好地描述了這種過(guò)程。

用于測(cè)試微服務(wù)的服務(wù)虛擬化

我們討論的一些測(cè)試模式依賴于對(duì)依賴的微服務(wù)使用虛擬服務(wù)，這些虛擬服務(wù)需要高度組件化并易于部署，其原因與它們模擬的微服務(wù)被組件化的原因相同。為了使服務(wù)虛擬化在這些環(huán)境中工作，您需要?jiǎng)?chuàng)建可以輕松部署的容器化虛擬服務(wù)。

要?jiǎng)?chuàng)建容器化的虛擬服務(wù)，您可以獲取一個(gè)包含Parasoft Virtualize及其所有依賴項(xiàng)的基礎(chǔ)映像，并用另一個(gè)包含該虛擬服務(wù)的所有虛擬資產(chǎn)配置的映像進(jìn)行分層。可以將虛擬服務(wù)的新映像連同容器一起部署到Docker/Kubernetes環(huán)境中，并將其作為被測(cè)試微服務(wù)的容器及其所有（虛擬化）依賴項(xiàng)。

結(jié)論

隨著團(tuán)隊(duì)采用微服務(wù)，重要的是要了解如何充分測(cè)試它們。我在這里討論的消息傳遞模式和相關(guān)測(cè)試模式并不是新事物，但是隨著微服務(wù)變得越來(lái)越普遍和越來(lái)越多的應(yīng)用程序，使用這些模式的需求已顯著增長(zhǎng)采用微服務(wù)范式。

為了以最大的靈活性為您的微服務(wù)創(chuàng)建和部署測(cè)試方案，您可以利用Parasoft SOAtest，Parasoft Virtualize和來(lái)確保微服務(wù)的最高質(zhì)量和可靠性。