本文要點
- 微服務架構對在線（遠程）依賴項的依賴較多，而對進程內組件的依賴較少，您的測試策略和測試環境需要適應這種變化。
- 當使用現有技術（如服務虛擬化）測試單體應用時，您不必同時測試所有內容；相反，您可以分而治之，測試單個模塊或一組關係密切的組件。
- 當使用微服務時，還有幾個選項可供選擇，因爲微服務通常部署在容器（如Docker）環境中。
- 您需要管理相互依賴的組件，以便在測試微服務時可以有效地利用時間及控制成本。您可以在微服務測試中使用測試替身（Test Double）達到測試目的。
- 根據您的需要，您可以選用本文列出的其中一個選項或者多個選項的組合。
微服務架構和基於容器的基礎設施的組合需要一個適合這個美麗新世界的測試策略。微服務架構對在線（遠程）依賴項的依賴較多，而對進程內組件的依賴較少，您的測試策略和測試環境需要適應這種變化。
在線通信越多，測試微服務之間的連接和契約所需的精力就越多。此外，在遷移到基於容器的基礎設施時，可以使用若干新的測試技術來處理採用微服務時經常出現的組件依賴。
從上市時間、成本和風險的角度選擇測試技術。
當使用服務虛擬化等技術測試單體應用時，您不必同時測試所有內容。相反，您可以分而治之，測試單個模塊或或一組關係密切的組件。您可以創建安全的隔離環境讓開發人員測試他們的工作。在測試單體應用時，使用服務虛擬化讓您可以將測試環境與相關組件解耦，並減少以下問題的影響：
- 難以準備或配置相關組件
- 測試數據準備成本高，耗時多
- 團隊因爲其他團隊沒有及時交付API而受阻
- 測試環境時間調度
當使用微服務時，您的選擇更多，因爲微服務通常部署在容器（如Docker）環境中。在微服務架構中，您的團隊可能會使用更廣泛的測試技術。此外，由於微服務更多地通過網絡進行通信，所以需要更徹底地測試網絡連接的影響。使用更適合新架構的工具和技術可以縮短上市時間，降低成本和風險。
許多IT部門使用或維護着採用單體架構開發和部署的系統。典型的單體架構具有以下特點：
- 從事應用程序相關工作的人員被組織成獨立的專家團隊：UI開發人員、中間件開發人員、後端開發人員、數據庫管理員和系統管理員。
- 治理由架構師集中進行——例如，有一組用於代碼質量、安全準則和測試方法的全局規則。
- 數據集中管理，因此，單體應用程序通常依賴於單個大型數據庫。
- 自動化程度可能很低，有一些自動化測試，但是很少有基礎設施自動化。
應用程序開發人員的組織結構經常會影響代碼和測試環境的組織方式；這種效應被稱爲康威定律。通常，代碼會被分成幾個組件層，如UI、服務和存儲庫。每個層都是一個單體，它們將被部署到共享環境中，通常包括開發、QA和用戶驗收測試（UAT），參見圖1。
許多單體系統都是由職能豎井團隊構建的，例如，運營團隊是一個單獨的實體，有單獨的時間表。向這樣的組織引入容器化方法需要做出變革，這可能會非常耗時，因爲它涉及提供新的基礎設施、培訓員工以及爲遷移到新方法創建遷移計劃。
這意味着，從單體架構中解耦依賴項的技術常常侷限於那些不需要容器的技術，它們運行在進程中，或者是在運營團隊提供的已有的VM或硬件上。不需要容器化的技術包括：
根據康威定律，溝通模式複雜的職能豎井團隊會創建出通信模式同樣複雜的單體。這意味着用於服務虛擬化的工具必須非常強大，能夠支持複雜的工作流和許多技術（例如，許多通信協議），這取決於被測系統（單體應用程序）的複雜性和測試用例的複雜性。
通常，會有一個單獨的團隊負責創建後端或第三方服務的stub、mock或虛擬服務。這經常會在負責服務虛擬化的團隊中引起工作衝突，導致測試基礎設施準備時間很長，維護成本很高。
在微服務架構中，你會發現：
- 團隊是圍繞業務功能組織的，例如由多名UI、中間件和後端開發人員、數據庫管理員和DevOps專家組成的跨職能團隊；
- 去中心化治理，允許每個團隊選擇適合其工作的恰當工具；
- 去中心化數據管理，允許每個微服務或每一組相關的微服務管理自己的數據；
- 測試、部署和基礎設施通常自動的，很少或沒有人爲干預。
這將影響到使用什麼技術解耦微服務及其依賴項來達到測試目的。由於不需要滿足所有團隊需求的同構技術棧，所以每個團隊通常都有更多滿足其特定需求的選項可以選擇。
對於微服務測試，解決方案主要是那些可以用於單體架構的解決方案（它們也適用於微服務）以及那些專門爲微服務架構而設計的解決方案。
可用於單體架構的方法包括：使用測試替身，如stub、stub或虛擬服務；連接到後端或第三方系統的實際測試實例；契約測試。
可用於微服務架構的方法有測試容器（如數據庫測試容器、服務虛擬化測試容器）、第三方服務測試容器（如Redis測試容器、ESB測試容器或虛擬設備測試容器）和把遺留單體應用裝盒。
關於如何編寫微服務測試策略的文章和演講已經有很多。下面是一些資源，供參考：
- “微服務架構的測試策略”，Toby Clemson，ThoughtWorks（2014年11月18日）
- “微服務測試”，André Schaffer，Spotify（2018年1月11日）
- “微服務測試：從開發到生產”，Daniel Bryant，JAX London（2018年10月9日）
您將使用許多用於單體架構的測試技術，並涉及容器的新技術。然而，不同測試技術的適用性可能會發生變化，因爲微服務架構中的反饋循環更緊密，因爲團隊通常在一起並且是跨職能的。
上面列出的參考資料有一個共同的主題，即您需要管理相關組件，以便在測試微服務時可以有效地利用時間及控制成本。根據需要，您可以選擇本中列出的其中一個選項，或者多個選項的組合。
在測試中使用依賴項
用於微服務測試的測試環境可能使用真正的依賴項，而不是測試替身。
在測試場景中，微服務可以與以下幾種組件類型通信：
- 您可以使用另一個微服務的測試實例來測試您的微服務。例如，在測試微服務A時，將其連接到微服務B的測試實例並將它們一起測試。
- 您可以使用另一個微服務的生產實例來測試您的微服務。例如，在測試微服務A時，將其連接到微服務B的生產實例，並在將微服務A發佈到生產環境之前將它們一起測試。
- 您可以使用第三方依賴項測試微服務。例如，在測試微服務A時，將其連接到第三方系統的生產實例。
- 您可以使用遺留的非微服務內部依賴項來測試微服務。例如，在測試微服務A時，您將它連接到已有的本地運行的大型機系統的測試實例。
- 您可以使用非軟件（硬件）依賴項測試微服務。例如，在測試微服務A時，將其連接到負責實現服務的硬件設備。
除了上面列出的組件外，接下來，我們將列出可以在微服務測試中使用的特定於測試的依賴組件。
當然，您可以在微服務測試中使用所謂的測試替身，它們會冒充真正的依賴項。你有幾種技術可以選擇，這取決於依賴項的類型和手頭的問題：
- Mock（進程內或通過網絡/遠程）用一個特定於測試的對象替換微服務所依賴的對象，以驗證微服務是否正確地使用了它。
- Stub（進程內或通過網絡/遠程）用一個特定於測試的對象替換微服務所依賴的對象向微服務提供測試數據。測試數據可以是靜態的，也可以是動態的。
- 模擬器（進程內或通過網絡/遠程）是stub的智能版本，它模仿微服務所依賴的系統的一些行爲。例如，您不需要在測試中連接到真實的支付系統，而是可以連接到一個部分實現了可觀測支付功能的模擬器。
- 服務虛擬化（通過網絡/遠程）也稱爲API simulation或API mock。它的做法是，使用強大的服務虛擬化工具創建測試版本，替換真正的依賴組件。服務虛擬化工具提供一種類似模擬器的體驗，但是減少了開發人員和測試人員的工作量。與爲每個依賴項構建自定義的測試替身不同，有現成的工具可以處理常見的需要手寫實現的樣板功能。服務虛擬化工具提供的特性通常比stub或mock多，比如記錄請求和響應，或者內置對HTTP、JMS、FTP或gRPC等多種技術的支持。
- 您可以使用一個內存數據庫來代替真正的數據庫實例用於測試。
- 您可以運行一個測試容器，即一個位於容器中的針對每個構建或管道的依賴項的測試實例，而不是使用跨多個團隊、構建或管道共享的實例。例如，您可以使用數據庫測試容器或服務虛擬化測試容器。
- 您可以把遺留單體應用裝盒。您可以在容器中運行遺留系統，而不是依賴於共享的測試環境。您可以根據自己的測試需求來配置它。
契約測試
在使用類似微服務這樣的鬆耦合組件時，契約測試是一個關鍵部分。
契約描述組件之間如何通信和交互，包括組件之間的消息格式（語法）和組件的行爲預期（語義）。您可以使用契約測試來驗證組件之間的契約是否得到執行，從而使您相信這些組件能夠協同工作。當您使用特定於測試的依賴組件（例如測試替身）時，您還可以使用契約測試來確保它們符合最新的或任何特定版本的契約。以下是測試或管理組件之間的契約的幾種方法：
- 在契約快照測試中，您的測試替身代表了組件之間在某個時間點上的契約快照。該快照可能會過時。您可以以自動化的方式測試契約快照。
- 契約快照刷新讓您可以重新記錄（刷新）組件之間的契約。通常，刷新要考慮語法，並在一定程度上考慮契約的語義。要進一步瞭解語法和語義測試，請參閱消費者驅動的契約測試。
- 消費者驅動的契約測試是完整微服務測試策略的一個組成部分。消費者驅動的契約分爲生產者和消費者。消費者驅動的契約測試驗證生產者是否提供了滿足所有消費者期望的契約。消費者驗證生產者是否提供了它們需要的消息結構和行爲。
- 針對每個契約的小範圍集成測試可以測試微服務中的連接器模塊和依賴組件之間的契約。通常，在這種情況下，契約更多地是生產者驅動的，而不是消費者驅動的。
- 如果您想要兩個依賴組件獨立發佈，請使用面向獨立組件發佈的契約測試。您必須記住測試最新工件和生產工件的組合。
- 端到端（E2E）測試意味着驗證所有組件在完成用戶旅程時都能很好地協同工作。這意味着組件之間的契約在跨系統執行用戶旅程測試時得到了隱式驗證。
總結
在測試微服務時，有許多管理依賴組件的技術。本文給出的信息應該可以填補一些空白，並幫助您定義開發和測試策略（包括測試金字塔）。
在第二部分中，我們將基於團隊的成熟度、變化速度、上市時間、成本和風險來比較這些技術。
如果您發現本文有任何不清楚的地方，或者您有任何特定於項目的擔憂或問題，請通過郵箱聯繫作者Wojciech Bulaty （[email protected]）和Liam Williams（Liam Williams at [email protected]）。
關於作者
Wojciech Bulaty專注于敏捷軟件開發和測試架構。他在敏捷、自動化、XP、TDD、BDD、結對編程和整潔編碼方面有十多年的實際編程和領導經驗。他最新提供的服務是Traffic Parrot，通過提供API mocking和服務虛擬化工具幫助使用微服務的團隊加速交付、提高質量和縮短上市時間。
Liam Williams是一位自動化專家，專注於使用高質量的軟件解決方案改善容易出錯的手工流程。他是一個開源貢獻者和一些小型庫的作者。最近，他加入了Traffic Parrot的團隊，將注意力轉向了遷移到現代微服務架構時測試體驗的改善問題上。
原文鏈接：
Testing Microservices: Overview of 12 Useful Techniques - Part 1