[[243904]]

微服務架構并不是一種新的架構模式，但它的不斷發展為那些尋求企業級私有云解決方案的公司，帶來了諸多好處，將大型一體化架構應用拆分為可組合的微服務，賦予企業獨立擴展和維護每個組件的能力以及DevOps能力。

當然，微服務架構的分布式和獨立性也帶了許多挑戰，而本文講談談如何克服測試多個可獨立部署組件時可能會遇到的挑戰。

單元測試（Unit Testing）

單元測試的范圍可以是一組服務（社會性單元測試），也可以是單獨的一個服務（獨立單元測試）。被測試的單元粒度越小，就越容易確定模塊的行為、查明相關collaborators以及對象與依賴之間的交互。由于單元的復雜度較低，QA工程師可以通過單元測試策略來評估單元是否與collaborators隔離。社會性單元測試和獨立單元測試經常會在同一個代碼庫中同時進行，以解決不同的測試問題。

測試domain layer的目的是模擬DML語句并證明所有collaborators都以正確的順序使用真實的domain objects。在單元測試期間，工程師可以驗證用于生成map responses的邏輯或來自外部遠程依賴項的其他請求。就資源和服務層而言，驗證每個組件是否與collaborators正確交互，將可以可重復且一致的方式監視請求/響應周期。

集成測試（Integration Testing）

集成測試在分段環境中進行，以在分析通信路徑的功能和它們之間的交互之后集成各個服務。與單片或SOA不同，微服務架構依賴于進程間通信（IPC）機制來正常運行，這就是為什么必須驗證服務之間的交互。

我們需要編寫自動化測試，以通過與外部服務和數據存儲的集成來映射成功或錯誤的情況。運行網關集成測試將在協議級別上破壞接口錯誤，例如不正確的SSL處理和丟失的HTTP標頭。持久性集成測試確保每個組件和協議客戶端必須在超時和部分失敗的情況下作為外部依賴進行響應。

契約測試（Contract Testing）

契約測試是一種用于驗證外部服務調用與其API Provider endpoint之間契約的黑盒子。一般有兩種契約測試：

• 集成契約測試
• 消費者驅動（consumer-driven）契約測試

在集成契約測試中，每個組件都需要獨立調用，并且必須滿足消費服務（consumer）預期的契約協議。解決這個問題的***方法是對double進行測試。另一方面，定期運行一組單獨的測試以確認測試double沒有變化至關重要。不過，一單出現測試失敗，會降低部署管道的速度并破壞IT基礎架構或分布式系統的功能。處理間歇性測試失敗的***方法之一是更新測試double，同時可能也需要更新代碼，以便可以使其恢復到與外部服務一致的狀態。

在消費者驅動的契約測試中，消費者將描述他們想要使用服務的方式。消費者契約可以在生產者和消費者之間以相互同意的語言和模式進行。服務提供商將針對各個契約的副本測試服務，然后對該特定服務進行更改，而不會影響其他服務的性質。

End-to-End測試（End-to-End Testing）

End-to-End（E2E）測試用于確定整個系統正常運行以及網絡基礎設施（負載平衡器、防火墻等）已正確配置。End-to-End測試需要以最精細的粒度運行以測試整個系統的功能。在此，QA工程師驗證完全集成過程的行為，并確保系統總體上滿足其業務需求，而不管使用的服務組件體系結構如何。在功能測試的幫助下，開發人員可以確定集成系統或應用是否按要求的規定運行。