作者 | Tomas Fernandez

譯者 | 朱鋼

策劃 | 信遠 

在測試方面，微服務需要不同的方法。

微服務應用程序是一組通過網絡進行通信的分布式程序，并且與第三方服務和數據庫接口進行交互。微服務就其網絡性質而言，比傳統的整體架構具有更多的故障點。因此我們需要一種不同的、更廣泛的測試方法。

那么，我們如何測試微服務應用程序呢？測試金字塔是否仍然有效呢？當涉及第三方服務并且可能出現網絡中斷時，我們如何進行測試？我們將嘗試在這篇文章中回答所有這些問題。

測試微服務的挑戰

微服務架構是一個如此深刻的范式轉變，我們必須對傳統的測試技術進行重新思考。微服務在很多方面與經典的整體式架構不同：

• 分布式：微服務部署在多個服務器上，可能因跨地理區域位置而增加延遲并使應用程序具有連接網絡中斷的風險。依賴于網絡的測試可能會因代碼沒有錯誤、中斷 CI/CD 管道和阻止開發而失敗。
• 自治：只要不破壞API兼容性，開發團隊就可以隨時自由部署其微服務。
• 增加測試區域：由于每個微服務都具有多個 API 節點，因此還有更多可測試的面需要覆蓋。
• 多語言：開發團隊可以為其微服務選擇最佳語言。在一個大系統中，我們不太可能找到一個適用于所有組件的測試框架。
• 生產是一個移動的目標：由于微服務是可獨立部署的，并且由自治團隊構建，因此需要額外的檢查和邊界來確保它們在部署時仍然能夠正確的協同工作。

所有這些特征迫使我們思考新的測試策略。

微服務的測試金字塔

測試金字塔是自動化軟件測試的規劃工具。在傳統形式中，金字塔使用三種類型的測試：

• 單元測試
• 集成測試
• 端到端測試

微服務金字塔添加了兩種新類型：組件測試和協定測試。

這是微服務測試金字塔的一個版本。在其他情況下，順序可能會有所不同。有些可能包括集成層中的合約測試。金字塔更像是一個指導方針，而不是寫在石頭上的東西。

讓我們更詳細地了解每個金字塔圖層的工作原理。

微服務的單元測試

單元測試是最細粒度且數量眾多的測試形式之一。一個單元由可以單獨測試的類、方法或函數組成。單元測試是開發實踐不可分割的一部分，如測試驅動開發或行為驅動開發。

與整體架構相比，微服務中的單元需要網絡調用來實現其功能的概率要高得多。當這種情況發生時，我們可以讓代碼訪問外部服務（接受一些延遲和不確定性），或者用Mock 替換調用，這為我們提供了兩種處理微服務依賴關系的方法：

• 獨立的單元測試：當我們需要測試結果始終確定性時應該使用這個測試。我們使用模擬或存根來隔離待測試代碼與外部依賴項。
• 社交化單元測試：允許社交化測試調用其他服務。在此模式下，我們將測試的復雜性推送到測試或過渡環境中。社交化測試是不確定性的，但是當它們通過時，我們可以對它們的結果更有信心。

我們可以使用Mock單獨運行單元測試。或者我們可以允許測試的代碼調用其他微服務，在這種情況下，我們談論的是社交化測試。

正如你看到的，平衡信心與穩定性將是貫穿整篇文章的主題。模擬使測試變得更快并減少了不確定性，但是你模擬得越多，你就越不能相信結果。社交化測試盡管有缺點，但更現實。因此，你可能需要在這兩種類型之間取得良好的平衡。

合約測試

每當兩個服務通過接口耦合時，就會形成契約。該協定指定了所有可能的輸入和輸出及其數據結構和副作用。服務的消費者和生產者必須遵守合約中規定的規則，以便進行通信。

協定測試確保微服務遵守其協定。它們不會徹底測試服務的行為；它們僅確保輸入和輸出具有預期特征，并且服務在可接受的時間和性能限制內執行。

根據服務之間的關系，合約測試可以由生產者和/或消費者運行。

• 消費者端合約測試，由下游團隊編寫和執行。在測試期間，微服務連接到創建者服務的虛假版本或模擬版本，以檢查它是否可以使用其 API。
• 生產者端合約測試，在上游服務中運行。這種類型的測試模擬客戶端可以發出的各種 API 請求，驗證生產者是否與合約匹配。生產者端測試讓開發人員知道他們何時會破壞消費者的兼容性。

合約測試可以在上游或下游中運行。生產者測試檢查服務沒有實現會因服務而中斷的更改。消費者測試針對上游生產者的模擬版本（不是真正的生產者服務）運行消費者端組件，以驗證消費者可以發出請求并使用來自生產者的預期響應。我們可以使用 WireMock 等工具來重現 HTTP 請求。 

如果合約雙方測試通過了，則生產者和消費者是兼容的，應該能夠通信。合約測試應始終運行在持續集成中，以便在部署前檢測兼容性。

你可以在 《Pact 5-minute getting started guide》中進行在線合約測試。 Pact 是一個基于 HTTP 的測試工具，用于編寫和運行基于消費者和生產者的合約測試。

微服務集成測試

微服務集成測試的工作方式與其他架構略有不同。它的目標是通過使微服務交互來識別接口缺陷。與合約測試總是模擬一側不同，集成測試使用真實的服務。

集成測試對評估服務的行為和業務邏輯不感興趣。相反，我們希望確保微服務能夠相互通信，而且可以正確和它們自己的數據庫進行通信。我們正在尋找例如丟失 HTTP 請求頭或不匹配的請求/響應對之類的問題。因此，集成測試通常在接口級別實現。

使用集成測試來檢查微服務是否可以與其他服務、數據庫和第三方端點進行通信。

微服務的組件測試

組件是在較大系統內完成一個角色的一個微服務或一組微服務。

組件測試是一種驗收測試，在這種測試中我們通過用模擬資源或模擬替換服務來檢查組件的行為。組件測試比集成測試更徹底，因為它們會經歷“快樂”和“不快樂”的路徑 。 例如組件如何響應模擬的網絡中斷或格式錯誤的請求。我們想知道組件是否滿足其消費者的需求，就像我們在驗收或端到端測試中所做的那樣。

組件測試對一組微服務執行端到端測試。組件范圍之外的服務被模擬。

有兩種執行組件測試的方法：進程內和進程外。

進程內組件測試

在此組件測試子類中，測試運行程序與微服務存在于同一線程或進程中。我們在“離線測試模式”中啟動微服務，其中模擬其所有依賴項，從而允許我們在沒有網絡的情況下運行測試。

在與微服務相同的進程中運行的組件測試。該測試在適配器中注入模擬服務，以模擬與其他組件的交互。 

僅當組件是單個微服務時，進程內測試才有效。乍一看，組件測試看起來與端到端或驗收測試非常相似。唯一的區別是組件測試選擇系統的一個部分（組件），并將其與其他部分隔離。該組件經過全面測試，以驗證它是否執行其用戶或消費者所需的功能。

組件測試和端到端測試可能看起來很相似。但不同之處在于，端到端在類似生產的環境中測試整個系統（所有微服務），而組件在整個系統的隔離部分上進行測試。這兩種類型的測試都從用戶（或消費者）的角度檢查系統的行為，遵循用戶將要執行的操作。我們可以用任何語言或框架編寫組件測試，但最受歡迎的可能是Cucumber和Capybara。

進程外組件測試

進程外測試適用于任何大小的組件，包括由許多微服務組成的組件。在這種類型的測試中，組件部署在測試環境中，其中所有外部依賴項都被模擬或存根。

在這種類型的組件測試中，復雜性被推到測試環境中，測試環境應該復制系統的其余部分。

為了完善合約測試的概念，您可以??探索《Java Spring上合約測試的示例代碼?》。此外，如果您是Java開發人員，??那么這篇文章提供了用于在各個級別測試Java微服務的代碼示例?。

微服務中的端到端測試

到目前為止，我們已經對系統進行了零碎的測試。單元測試用于測試微服務的各個部分，合約測試涵蓋API兼容性，集成測試檢查網絡調用，組件測試用于驗證子系統的行為。只有在自動化測試金字塔的最頂端，我們才能測試整個系統。

端到端（E2E）測試確保系統滿足用戶的需求并實現業務目標。E2E 套件應使用與用戶相同的接口覆蓋應用程序中的所有微服務，通常結合使用 UI 和 API 測試。

應用程序應在盡可能靠近生產環境中運行。最理想情況是測試環境將包括應用程序通常需要的所有第三方服務，但有時這些服務可以被模擬，以降低成本或防止濫用。

端到端是模擬用戶交互的自動化測試。只有外部第三方服務可能會被嘲笑。

正如測試金字塔所描述的那樣，E2E測試是數量最少的，因為它們通常是最難運行和維護的。只要我們專注于用戶的操作和他們的需求，我們只需要幾個端到端的測試就可以提取很多資源價值。

結論

不同的模式要求改變測試策略。在微服務架構中進行測試比以往任何時候都更加重要，但我們需要調整技術以適應新的開發模型。系統不再由單個團隊管理。相反每個微服務所有者都必須盡自己的一份力量，以確保應用程序作為一個整體工作。

一些組織可能會認為單元、合約和組件測試就足夠了。其他不滿足于沒有端到端和集成測試的人可能會選擇建立一個 QA 團隊來促進跨團隊的測試覆蓋。

譯者介紹

朱鋼，51CTO社區編輯，2021年IT影響力專家博主，阿里云專家博主，2019年CSDN博客之星20強，2020年騰訊云+社區優秀作者，11年一線開發經驗，曾參與獵頭服務網站架構設計，企業智能客服以及大型電子政務系統開發，主導某大型央企內部防泄密和電子文檔安全監控系統的建設，目前在北京圖伽健康從事醫療軟件研發工作。

原文標題：Testing Strategies for Microservices，作者：Tomas Fernandez

鏈接：????https://dzone.com/articles/testing-strategies-for-microservices????