4個實用的微服務測試策略
微服務架構並不是一種新的架構模式，但它的不斷髮展為那些尋求企業級私有云解決方案的公司，帶來了諸多好處，將大型一體化架構應用拆分為可組合的微服務，賦予企業獨立擴充套件和維護每個元件的能力以及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工程師驗證完全整合過程的行為，並確保系統總體上滿足其業務需求，而不管使用的服務元件體系結構如何。在功能測試的幫助下，開發人員可以確定整合系統或應用是否按要求的規定執行。
關於Rainbond
當下，已經有很大一部分公司完成了單體架構向微服務架構的遷移改造，並在疲於應對大量微服務間通訊問題時，開始考慮採用Service Mesh微服務架構作為服務與服務直接通訊的透明化管理框架，以外掛式的方式實現各種業務所需的高階管理功能。
而開源PaaS Rainbond提供了開箱即用的Service Mesh微服務架構，部署在Rainbond上的應用原生即是Service Mesh微服務架構應用。