微服務測試的 12 項實用技術（第二部分）

本文要點

• 一個成功的微服務測試策略必須有效地管理涉及到的相互依賴的組件。這可能包括隔離、模擬（mock）、虛擬化或其他技術
• 組織特徵影響着對測試技術的選擇，例如團隊的成熟度和所需的變更速度，例如待重新開發的領域與全新的領域
• 我們認爲，從業務的角度來看，測試方法有三個主要的結果：投入市場的時間、成本和風險。
• 每種測試技術都有其優缺點。應用程序應該使用哪種方法取決於你的上下文。

本系列的第1部分“微服務測試的 12 項實用技術（第一部分）”探討了在測試微服務時管理依賴於微服務的組件的技術。本文將根據團隊的成熟度、變更的速度、投入市場的時間、成本和風險來比較這些技術。

這個比較是基於我們超過14個項目的經驗，但是我們可能漏掉了一些東西，或者我們的經驗不能反映你的經驗。所以，請幫助我們完善這個總結，這樣我們可以幫助更多的人一起作爲一個社區。請在文章下面評論，在LinkedIn上或者在Tweet上加上#TestingMicroservices標籤發表。

下表從經理的角度比較了測試微服務的技術。加號(+)表示優勢，減號(-)表示負面影響，波浪號(~)表示影響不大或中性。

技術	組織特徵		使用給定測試方法的後果
	團隊成熟度	變更的速度	投入市場的時間	成本	風險
1. 使用另一個微服務的測試實例來測試您的微服務。	低度影響。	低度影響。	+快速啓動。 -隨着複雜性的增加，減慢項目進度。	+複雜度低時成本也低。 -隨着複雜性的增加，成本可能會增加	+減少了在測試替身中引入問題的機會。 -不遵循測試金字塔的風險。
2. 使用另一個微服務的生產實例來測試您的微服務。	中度影響。	低度影響。	+快速啓動。 -隨着複雜性的增加，減慢項目進度。	+複雜度低時成本也低。 -隨着複雜性的增加，成本可能會增加	+減少了在測試替身中引入問題的可能。 -不遵循測試金字塔的風險。 -會改變生產系統的狀態。 ~很難模擬假設的情景。
3.使用第三方依賴項測試微服務。	中度影響。	低度影響。	+快速啓動。 -隨着複雜性的增加，減慢項目進度。	+複雜度低時成本也低。 -隨着複雜性的增加，成本可能會增加 ~調用第三方API的會產生成本。	+減少了在測試替身中引入問題的可能。 -不遵循測試金字塔的風險。 -會改變生產系統的狀態。 ~很難模擬假設的情景。
4. 使用遺留的非微服務內部依賴項來測試微服務。	中度影響。	低度影響。	+快速啓動。 -隨着複雜性的增加，減慢項目進度。	+複雜度低時成本也低。 -隨着複雜性的增加，成本可能會增加	+減少了在測試替身中引入問題的可能。 -不遵循測試金字塔的風險。 -會改變生產系統的狀態。 ~很難模擬假設的情景。
5. 使用非軟件（硬件）依賴項測試微服務。	中度影響。	低的影響。	+快速啓動。 -隨着複雜性的增加，減慢項目進度。	~只測試的硬件可能很昂貴。	+快速反饋迴路。
6. 模擬(進程內或通過網絡/遠程)。	中度影響。	中度影響。	~適量的時間啓動。 +降低複雜度。	~可能需要內部開發。	+增加測試覆蓋率。 -可能會過時。
7. 樁(進程內或通過網絡/遠程)。	中度影響。	中度影響。	~適量的時間啓動。 +降低複雜度。	~內部成本可能會比較高。	+增加測試覆蓋率。 -可能會過時。
8. 模擬器(進程內或通過網絡/遠程)。	中度影響。	低度影響。	+使用現成的模擬器快速啓動。 -內部工作會花費很多時間。	+現成的模擬可以節省成本。 -內部工作可能代價高昂。	+假設的場景可以增加你的測試覆蓋率。 -內部工作可能導致差異。
9. 服務虛擬化(通過網絡/遠程)，也稱爲API模擬。	中度影響。	低度影響。	+現成的產品可以幫助你更快地進入市場。	+現成的產品可以節省成本。 -現成的商業化產品可能會很貴。	+減少了犯常見錯誤的風險。 +允許模擬網絡問題。 ~開源產品不具備支持合約。 ~虛擬服務可能會過時。
10. 內存數據庫。	中度影響。	低度影響。	+當新數據庫的供應存在問題時，可以縮短投入市場的時間	+降低了授權商業數據庫的成本。	~內存數據庫的表現可能與真實的數據庫不同。
11. 測試容器。	中度影響。	低度影響。	+允許團隊按照自己的節奏移動。 +當新數據庫的供應存在問題時，可以縮短投入市場的時間	+可以降低許可成本。 +可以降低基礎設施成本。 ~可能具有許可證成本影響。	~測試容器可以有不同於實際生產環境的配置
12. 裝入箱中的遺留系統。	中度至高度影響	低度影響。	+快速啓動。 -隨着複雜性的增加，減慢項目進度。 +供應容器比供應硬件環境快一個數量級。 ~預先花費時間配置容器。 -用於重構的潛在時間。	+快速啓動。 -隨着複雜性的增加，減慢項目進度。 +供應容器比供應硬件環境快一個數量級。 ~預先花費時間配置容器。 -用於重構的潛在時間。	+減少了在測試替身中引入問題的可能。 -不遵循測試金字塔的風險。

除了上表中的權衡之外，你的組織特徵也會影響測試方法的選擇。團隊與任務相關的成熟度也將影響你的選擇。微服務或其依賴項的項目需求的變化速度也會影響你的選擇。例如，競爭市場中的全新項目與處於維護模式的項目將有着不同的價值權衡。

使用給定的測試方法會影響你投入市場的時間、成本、風險和其他一些方面。

下面是這12種技術的高層次概述。

1. 使用另一個微服務的測試實例來測試您的微服務。

團隊成熟度的影響很小，因爲團隊不需要了解測試替身的類型以及如何使用它們。如果你是軟件開發和測試的新手，那麼用這種方式進行測試比較容易。

這種技術適合任何變更速度。如果速度很快，團隊就會得到關於API之間兼容性問題的快速反饋。當節奏變慢時，也沒什麼關係。

隨着複雜性的增加，大多數項目投入市場的時間會變慢。這是軟件團隊的典型陷阱，也是許多大型企業的技術債務來源。這項技術很容易就能開始用起來，因爲它幾乎不需要額外的基礎設施或測試替身的知識。

許多公司在最初的測試之後仍然使用這種方法，這導致了技術債務的快速積累，最終會減慢開發團隊的速度，因爲被測試系統的複雜性會隨着其組件的數量呈指數級增長。

大多數項目需要結合包括測試替身在內的測試技術，以達到足夠的測試覆蓋率和穩定的測試套件——你可以閱讀關於這個稱爲測試金字塔的更多信息。適當地使用測試替身，你可以更快地投入市場，因爲你測試得比其他情況下要少。

成本會隨着複雜度的增加而增加。因爲你不需要太多額外的基礎設施或測試替身的知識，所以這項技術的初始成本並不高。但是，成本可能會增加——例如，你需要更多的測試基礎設施來承載必須一起測試的相關微服務組。

測試依賴項的測試實例可以減少在測試替身中引入問題的機會。遵循測試金字塔制定一個合理的開發和測試策略，否則你可能會得到巨大的E2E測試套件，這些套件維護成本高，運行速度慢。

只有在仔細考慮過測試金字塔之後，才能謹慎地使用這種技術，不要落入倒置測試金字塔的陷阱。

2. 使用另一個微服務的生產實例來測試您的微服務。

在使用產品實例進行測試時，團隊需要格外小心，相比於使用測試替身的團隊，必須要更加信任這個團隊。

投入市場的成本和時間與第一種技術沒有區別。你的團隊與產品發佈週期維繫在一起，這可能會延遲他們的測試。

團隊需要格外小心，因爲這種技術的風險比測試替身要高得多。連接到生產系統的測試可以更改生產系統的狀態。僅針對無狀態API或團隊精心選擇的在生產中可以使用的測試數據使用此方法。

使用生產實例進行測試通常意味着很難模擬假設的失敗場景和錯誤響應。在設計開發和測試策略時，請記住這一點。

對依賴的生產實例進行性能測試可能會給生產系統帶來不必要的壓力。

這種技術通常適用於簡單、穩定、非關鍵的API，這是一種罕見的用例。除非你有明確的理由，否則不要這樣做。

3.使用第三方依賴項測試微服務。

團隊需要知道如何在第三方依賴項中設置測試數據，但其他方面不需要特別的經驗。

你的團隊受到第三方發佈週期的約束，這可能會減慢他們的速度。

組織可能必須付費使用第三方API進行測試，因爲第三方通常對每個事務收費。這在測試性能時尤其重要。

4. 使用遺留的非微服務內部依賴項來測試微服務。

這種技術就微服務的新領域和舊遺留系統之間的契約問題提供快速反饋週期，從而降低風險。

除了技術1的所有缺點之外，你還需要記住，遺留系統常常存在測試環境可用性和測試數據設置方面的問題。

5. 使用非軟件（硬件）依賴項測試微服務。

團隊需要知道如何在硬件依賴項中設置測試數據。

一般來說，硬件的變化速度比較慢，但是價格可能會比較貴。即使僅要得到一個用於測試目的的硬件實例，成本也會很高。當你需要更多的硬件來由不同的團隊或構建\流水線並行運行測試時，成本可能會顯著增加。

與前一項技術類似，微服務和硬件之間有一個快速的反饋週期，這可以降低風險——但是硬件可能存在測試環境可用性和測試數據設置方面的問題。

6. 模擬(進程內或通過網絡/遠程)。

團隊必須知道如何使用進程內的模擬。

模擬有助於降低測試用例的複雜性，減少調查和重現問題的時間，但是會帶來API之間存在差異的高風險。它們通過對其他系統的行爲進行假設來降低複雜性，但是可能會對API的工作方式做出不正確或過時的假設。項目需求的變更速度越快，保持模型最新就越重要。請參閱契約測試以瞭解減少這種風險的策略。

需要一定的時間以開始使用模擬和定義緩解策略(如消費者驅動的契約、集成的測試或集成測試)來確保模擬是最新的。模擬可能會過時，而成功地運行一個過時的測試套件將使你對質量抱有錯誤的信心。

你的技術棧中可能沒有免費的模擬解決方案，因此你可能必須自己開發一個或者購買一款商業產品。

模擬允許你設置低粒度的故障和假設的場景，從而提升測試覆蓋率。

在大多數用例中，使用模擬是一個好主意，它可以是最健康的測試金字塔或測試蜂巢的一部分。模擬通常是測試複雜系統的基本技術。

7. 樁(進程內或通過網絡/遠程)。

模擬使用特定於測試的對象替代微服務依賴的對象，該對象驗證微服務是否正確地使用了它，而樁使用特定於測試的對象替代它，該對象爲微服務提供測試數據。兩者的取捨很是相似。

內部開發複雜依賴項的樁可能非常耗時和昂貴。建議選擇現成的模擬、模擬器（simulators）或服務虛擬化工具，而不是樁。

8. 模擬器(進程內或通過網絡/遠程)。

團隊必須知道如何使用你選擇的模擬器。模擬器通常爲開發人員或測試人員提供個別的方式與它們進行交互。

組織通常爲廣泛使用的或穩定的API創建模擬器，你可以快速開始使用這些現成的模擬器。快速、早期的測試縮短了你投入市場的時間，並且使用現成的、穩定的模擬器可以節省成本。它們可以提供大量預定義的錯誤響應和假設場景，以提升測試覆蓋率。

爲複雜的依賴關係開發自己的內部模擬器可能非常耗時和昂貴。開發你自己的模擬器可能會引入模擬器與實際依賴之間的差異，並在測試套件中創建錯誤的信心。

然而，很容易用複雜的模擬器替換複雜的依賴項，並且忘記必須隨着依賴項的演變使其保持最新。應考慮持續維護的成本。

該技術使你可以模擬網絡問題，這對於測試依賴於網絡的微服務架構非常重要。

儘可能選擇現成的模擬器。只有當你的團隊對真正的依賴項和模擬有大量經驗時，才能夠構建內部模擬器。

9. 服務虛擬化(通過網絡/遠程)，也稱爲API模擬。

你的團隊必須知道如何進行服務虛擬化，並且必須選擇附帶教程和其他材料的工具。

服務虛擬化工具有助於保持虛擬服務的最新狀態。項目需求的變化速度越快，就越需要防止虛擬服務過時。服務虛擬化工具提供了一些技術和組件，其中之一是“記錄和回放”，這是一種使你可以快速爲經常變化的API重新創建虛擬服務的技術。請參閱“契約測試”以瞭解其他降低這種風險的策略。

如果採用其內置的經過充分測試的模式，那麼使用現成的服務虛擬化產品可以幫助你更快地進入市場。熟悉現成工具的顧問可以與開發人員和測試人員密切合作，基於許多項目的經驗幫助你選擇一個微服務的測試方法。

當團隊剛開始接觸微服務時，使用現成的工具可以節省成本，因爲那些供應商可以幫助你避免常見的錯誤。然而，隨着時間的推移，你對商業產品的使用可能會變得昂貴。建議根據ROI預測選擇供應商。

使用沒有支持合同的開源工具可能會導致你的開發人員和測試人員花費時間來修復bug並維護文檔和培訓材料。

服務虛擬化有助於降低被測系統的複雜性。這些工具可以幫助你管理你的假設。大多數服務虛擬化工具已經在市場上存在很多年了，它們的設計都考慮到了大型和獨體集成系統。選擇最適合你的微服務架構的開源或商業工具——但是任何虛擬服務都可能過時，因此請參考你的供應商對於緩解策略的建議。

10. 內存數據庫。

團隊必須瞭解切換爲使用內存數據庫進行測試的技術風險。

因爲這種技術使用一個內存數據庫，所以在此變更的速度影響很小。當爲了開發或測試的目的做新數據庫的供應存在問題時，它可以顯著減少項目投入市場的時間。

許多內存數據庫都是開源和免費的，這顯然有助於降低許可成本。但是內存數據庫在極端情況下的表現可能與實際數據庫不同。應將對實際數據庫執行測試作爲測試策略的一部分，以便觀察實際數據庫和內存數據庫之間的差異。

11. 測試容器。

你的團隊必須知道如何運行測試容器。

由於測試是在實際依賴上（在一個容器中）進行的，所以變更的速度對這個解決方案影響很小。

運行第三方服務或服務虛擬化測試容器可以減少團隊之間的依賴，並允許每個團隊以自己的速度移動。這些容器還可以顯著降低測試基礎設施的成本。

運行一個測試容器，而不是依賴共享實例，可以減少環境問題影響測試結果的可能性。

將商業數據庫的開發版作爲開發和測試的測試容器來運行，可以降低你的許可成本。將生產型商業數據庫作爲容器來運行是非常昂貴的。

測試容器可以配置得與真正的依賴項不同，從而導致對測試套件的錯誤信任。應確保將容器數據庫配置爲與生產數據庫相同(例如，使用相同級別的事務隔離)。

12. 裝入箱中的遺留系統。

當遺留系統可以輕鬆地移植到容器中時，你的團隊的成熟度只有中等程度的影響，但是如果你的團隊需要重構舊遺留系統中的部分配置和代碼以使其在容器中工作，則會產生更多的影響。工作量取決於項目，所以首先要研究和評估工作的規模。

遺留基礎設施需要時間來準備。在容器中就遺留系統方面的設置進行了最初、潛在的大量投資之後，啓動和運行新環境(容器)所花費的時間和金錢要比典型的硬件設置少幾個數量級。

這種技術減少了引入測試替身和實際系統之間的差異的可能。應確保將容器遺留系統配置爲與生產系統相同，以便生產環境和測試環境之間不存在顯著差異。

總結

我們從一名管理者的視角探討了在測試微服務時管理微服務依賴關係的技術，並根據團隊成熟度、變化速度、投入市場的時間、成本和風險對它們進行了比較。

這些信息應該填補一些空白，並幫助你定義開發和測試策略(包括測試金字塔)，以縮短投入市場的時間，降低成本，並提高組織內的質量。

每種方法都有其優點和缺點，哪種選擇對你的應用程序更有價值取決於你的環境。本文的第3部分將包括案例研究，重點介紹我們的客戶如何應用這些知識來做出決策。

如果您發現本文有任何不清楚的地方，或者您有任何特定於項目的擔憂或問題，請通過郵箱聯繫作者 Wojciech Bulaty （[email protected]）和 Liam Williams（Liam Williams at [e-mail] ）。

作者簡介

Wojciech Bulaty 專注于敏捷軟件開發和測試架構。他在敏捷、自動化、XP、TDD、BDD、結對編程和整潔編碼方面有十多年的實際編程和領導經驗。他最新提供的服務是 Traffic Parrot ，通過提供 API mocking 和服務虛擬化工具幫助使用微服務的團隊加速交付、提高質量和縮短投入市場的時間。

Liam Williams 是一位自動化專家，專注於使用高質量的軟件解決方案改善容易出錯的手工流程。他是一個開源貢獻者和一些小型庫的作者。最近，他加入了 Traffic Parrot 的團隊，將注意力轉向了遷移到現代微服務架構時測試體驗的改善問題上。

原文鏈接：

Testing Microservice: Examining the Tradeoffs of Twelve Techniques - Part 2