在許多方面，測試微服務應用程序與測試使用任何其他體系結構構建的應用程序沒有什么不同。微服務面臨的獨特挑戰是組成應用程序的服務數量之多，以及服務之間的依賴關系數量。

作為用于構建復雜系統的體系結構，微服務在開發社區中獲得了巨大的關注。盡管人們開始意識到這并不是解決所有應用程序體系結構問題的靈丹妙藥，但是那些與依賴項和擴展性相關的挑戰共享的應用程序可以從中受益匪淺。

微服務的采用正在上升，但是與了解如何測試微服務相關的斗爭也在增加。ThoughtWorks的Toby Clemson在列舉您可能希望在微服務體系結構中使用的測試策略方面做得非常出色（請參閱他的文章，以獲取有關您可能要創建的不同測試類型的詳盡概述），但是有關如何建立和維護那些不同種類的測試仍處于起步階段。

但是在許多方面，測試微服務應用程序與測試使用任何其他體系結構構建的應用程序沒有什么不同。微服務使用眾所周知的技術，例如REST或隊列，為此軟件行業已經擁有完善的測試工具和最佳實踐。微服務面臨的唯一挑戰是構成應用程序的服務數量之多，以及服務之間的依賴性。此外，即使微服務依賴的其他微服務不可用或響應不正確，每個微服務仍需要正常運行。

微服務在相互交互時通常遵循兩種模式：編排和響應式（編排）。許多微服務使用組合的“混合”方法。在本文中，我將提供一些策略來解決在使用這些不同模式的微服務創建自動化測試時出現的一些挑戰，重點是針對單個微服務的測試（而不是整個應用程序的端到端測試） 。

測試精心設計的微服務

使用業務流程的微服務將對外部服務或依賴項進行一個或多個顯式調用。這些調用通常使用同步請求-響應流，并且通常將訪問基于REST的服務。如果需要按特定順序調用服務，則在收到對前一個服務的調用的響應之前，不會進行對后一個服務的調用。由于一項服務顯式調用另一項服務，因此它們緊密耦合。

在上面顯示的示例中，為投資組合微服務創建和執行測試具有挑戰性，因為投資組合微服務依賴于帳戶和報價微服務，而依賴項需要與投資組合微服務一起部署在測試環境中。Quotes服務依賴于第三方服務來檢索實時股票價格，并且該服務返回的數據始終在變化。

依賴第三方服務或由不同團隊開發的服務極大地增加了測試環境的復雜性。此外，還需要測試投資組合服務的任何意外行為，例如，當“帳戶”和/或“報價”服務不可用，響應緩慢或響應意外數據時。重要的是，必須使這些服務以不同的意外行為響應，以驗證Portfolio微服務正確處理了錯誤情況。

服務虛擬化急救！

您可以使用服務虛擬化來模擬“帳戶和報價”微服務的響應。通過服務虛擬化，您可以定義“帳戶和報價”微服務的虛擬版本，并將它們與投資組合微服務的實際實例一起部署。虛擬化微服務類似于虛擬化任何其他類型的服務或應用程序體系結構。它可能看起來像這樣：

完成此操作后，就可以獨立于其兩個依賴項來測試Portfolio微服務。

下一個挑戰是為不同的情況配置不同的環境，例如“帳戶和報價”服務表現出預期的行為和意外的行為。假設團隊要測試“帳戶”服務或“報價”服務響應緩慢或出現錯誤情況時投資組合服務的行為。這可能需要運行至少5組不同的測試，其中每組都具有不同的環境配置，并考慮到響應時間慢、錯誤響應以及相關服務的正常和異常行為。

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

此過程并非特定于微服務架構-在面向服務的架構以及可能僅依賴少量服務的整體式應用程序中，通常會出現相同類型的問題。但是，在微服務架構中，從屬服務的數量顯著增加。在具有數十個或數百個服務的微服務環境中，針對不同的測試場景創建，管理和以編程方式在不同環境配置之間切換的能力非常重要，并且可以顯著減少時間和精力。

管理協調微服務中的API更改

隨著團隊發展其微服務，不可避免的是將對服務進行API更改。API更改引起的關鍵問題是如何了解這些更改對服務使用者的影響。

當團隊為他們正在構建的微服務修改API時，需要根據API中的更改來更新驗證該微服務的所有測試。相反，如果使用虛擬服務來模擬從屬微服務和用于這些從屬微服務更改之一的API，則必須更新從屬微服務的虛擬服務以反映API中的更改。

許多團隊使用OpenAPI，RAML或其他服務定義來描述其微服務的API。使用服務定義時，Parasoft SOAtest和Parasoft Virtualize中的Change Advisor模塊可以自動檢測哪些API已更改，然后自動重構現有的功能測試或虛擬服務，以使用API中的任何新字段和/或刪除的字段來更新它們。團隊可以創建其服務定義的更新版本，并可以使用Change Advisor在進行更改之前了解更改對其測試和虛擬服務的影響。進行更改后，Change Advisor可使您輕松快捷地更新現有資產，以反映微服務中的更改。

測試反應微服務

微服務架構的主要目標之一是創建獨立的組件。結果，部署、擴展和更新服務將變得更加容易。但是，當使用業務流程模式時，此目標并未完全實現，因為單個微服務直接依賴于其他微服務。解決此問題的一種方法是使用編排模式，也稱為“反應式”或“事件驅動”微服務。在這種模式下，微服務不會直接相互引用。相反，它們將消息推送到其他微服務已訂閱的事件流上。

請參見以下示例：

在此示例中，假設投資組合服務已被指示添加一個庫存頭寸。與其直接調用“帳戶”服務，不如將事件發布到“已添加位置”事件流。帳戶微服務已訂閱該事件流，因此它獲得了通知。它檢查以確保用戶帳戶中有足夠的資金。如果是這樣，它將減少用戶帳戶中的資金數量，并將事件發布到“更新帳戶”事件流中。如果用戶的帳戶中沒有足夠的資金，則它可能會將錯誤事件發布到其他事件流（為簡化示例，未顯示）。投資組合微服務已訂閱“帳戶更新”事件流，并且當看到“帳戶”微服務發布的事件時，它隨后基于來自帳戶服務的確認更新其投資組合。

這種類型的體系結構中的異步通信帶來的好處是，服務彼此之間高度解耦–可以替換，重新部署或擴展每個服務的實例，而無需其他微服務關心它們。折衷方案是事件的異步性質使得很難理解系統將如何執行以及事件的流向。根據產生的事件的順序或種類，系統可能會以意外的方式運行。這被稱為緊急行為，是在編排微服務的開發和測試中固有的挑戰。

異步命令調用模式

在事件驅動的微服務的更廣泛類別下，存在不同的異步消息傳遞模式。當需要使用異步操作來編排微服務時，可以使用異步命令調用模式——一種微服務需要異步調用另一種微服務，同時保證第二種微服務接收到消息。在這種模式下，通常使用隊列交換消息。

微服務架構中用于實現此模式的常見框架是RabbitMQ。當一個微服務需要發布事件以供第二個微服務處理，然后等待從該第二個微服務讀取“答復”事件時，就會發生這種模式的具體化身。

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

1. 第一種方法是創建具有必要隊列的環境，在該環境中部署了Portfolio服務，而沒有部署Accounts服務。因為沒有部署Accounts服務，所以測試場景將需要通過在適當的時間發布來自Accounts服務的預期事件來模擬Accounts服務的行為。Parasoft SOAtest測試場景將由兩個測試構成：一個測試執行Portfolio服務的REST API，第二個測試從Accounts服務發布事件。測試需要配置為可同時運行，以便在組合服務正在監聽事件的同時，帳戶服務中的事件得以發布。
2. 與其通過使用測試來模擬Accounts服務來發布事件，不如構建一個可重用的虛擬服務來偵聽發布到Position Position隊列中的事件并將結果事件發布到Account Updated隊列中，這可能會有所幫助。然后，該虛擬微服務將可以在可能需要它的多個不同測試場景中重用。

第一種方法很簡單，它使測試資產自成體系，而對測試基礎結構沒有任何其他外部依賴性。第二種方法是可重用的，并且是對系統實際行為的更緊密模擬。但是，第二種方法具有構建，部署和管理單獨的虛擬資產的成本。

異步命令調用模式的一種變體是微服務，它在隊列上偵聽傳入事件，處理該事件，然后在另一個隊列上發布后續事件，以供一個或多個其他微服務處理：

在此示例中，發票微服務是需要測試的服務。付款服務將事件發布到“付款處理的RabbitMQ”隊列中，以供發票服務提取。發票微服務從隊列中讀取事件，創建發票，然后將事件發布到“發票已創建”隊列，以指導電子郵件微服務將帶有發票的電子郵件發送給客戶。要為發票微服務創建測試方案，可以配置一個包含兩個RabbitMQ隊列和已部署的發票微服務的測試環境。可以構造一個Parasoft SOAtest測試方案，該方案將付款處理的事件發布到Payment Processed隊列中，然后該方案訂閱``發票創建''隊列以驗證發票服務是否響應發布了正確的發票創建事件。非常簡單的測試方案，可以很好地單獨測試Invoice服務。

事件Firehose模式

當不同來源產生大量需要通過公共集線器快速交付給不同使用者的事件時，將使用事件Firehose模式。在這種模式中，消息是通過主題交換的（與異步命令調用模式中的消息是通過隊列交換的消息相反）。Apache Kafka框架是用于實現事件firehose模式的常見框架，它看起來像這樣：

假設我們要測試一個單一的微服務，該微服務訂閱一個Kafka主題，處理它收到的事件，然后將其結果發布到另一個Kafka主題。例如，如下所示：

在此示例中，我們有一個預報微服務，該微服務訂閱了“天氣數據”主題，該主題從許多不同的來源收集許多不同的天氣數據。然后，它將處理該數據以更新其預測模型，并將預測數據發布到“預測數據”主題。在這種情況下，我們需要驗證天氣預報服務是否將一組特定的天氣數據事件的預期事件發布到了預報數據主題。

這可以通過配置具有兩個Kafka主題和已部署的Forecast服務的測試環境來完成。測試場景將首先將必要的事件發布到“天氣數據”主題，然后訂閱“預測數據”主題以驗證“預測”服務是否發布了正確的預測數據事件。需要構建多個不同的測試方案來驗證可以預期由預測微服務處理的事件的不同類型和順序。

這是一個相對簡單的測試方案。預測微服務與其他微服務分離的事實帶來了幸運的副作用，即預測服務的測試也與微服務分離。在這種情況下，您無需使用虛擬服務來建立復雜的環境，您只需創建發布事件的測試方案，并驗證是否創建了正確的事件作為響應即可。

配置測試環境

許多微服務團隊已采用持續集成/連續部署（CI/CD）流程來構建，測試和部署容器化微服務，以使流程自動化并降低與部署更新相關的風險。

在此過程中，將自動創建一個包含微服務的容器映像并將其部署到測試環境中（通常由Kubernetes或基于Kubernetes的發行版（如OpenShift）進行管理），在該環境中可以在微服務推送到端到端之前對其進行驗證。結束測試并最終投入生產。我建議閱讀有關容器化微服務的CI/CD和設計微服務：持續集成。這兩篇文章都很好地描述了這種過程。

用于測試微服務的服務虛擬化

我們討論的一些測試模式依賴于對依賴的微服務使用虛擬服務，這些虛擬服務需要高度組件化并易于部署，其原因與它們模擬的微服務被組件化的原因相同。為了使服務虛擬化在這些環境中工作，您需要創建可以輕松部署的容器化虛擬服務。

要創建容器化的虛擬服務，您可以獲取一個包含Parasoft Virtualize及其所有依賴項的基礎映像，并用另一個包含該虛擬服務的所有虛擬資產配置的映像進行分層。可以將虛擬服務的新映像連同容器一起部署到Docker/Kubernetes環境中，并將其作為被測試微服務的容器及其所有（虛擬化）依賴項。

結論

隨著團隊采用微服務，重要的是要了解如何充分測試它們。我在這里討論的消息傳遞模式和相關測試模式并不是新事物，但是隨著微服務變得越來越普遍和越來越多的應用程序，使用這些模式的需求已顯著增長采用微服務范式。

為了以最大的靈活性為您的微服務創建和部署測試方案，您可以利用Parasoft SOAtest，Parasoft Virtualize和來確保微服務的最高質量和可靠性。