CODING DevOps 系列第五課：微服務測試——微服務下展開體系化的微服務測試

微服務測試的痛點與挑戰

這張圖能夠形象地展現單體服務和微服務的對比，單體應用就像左邊巨大的集裝箱，軟件模塊和應用都包括其中；而微服務就像是由一個小集裝箱組成，微小的服務組成一個龐大、完整的系統。單體服務是一個大而全的應用體，而微服務由拆分紅出來的不少小服務來組成一個龐大而完整的系統。

微服務是一種架構模式，是面向服務型架構 SOA 的一種變體，提倡將單一應用程序逐漸還原劃分紅小的服務，服務間互相協調、互相配合，爲用戶提供最終價值。微服務架構風格就是一些小而自治的服務協同工做造成鬆耦合的系統。另外，咱們須要儘可能避免一個統一的、集中式的服務管理機制，對具體的一個服務而言，應該根據上下文選擇合適的語言工具對其進行構建。

結合下方的這張圖，咱們能夠理解微服務構建的核心實際上是中間領域的業務邏輯，圍繞着這個領域業務邏輯，會有一些微服務去進行拆分構建。

微服務具備專一、自治、獨立進程、獨立部署和技術異構的特色，即每一個服務只限定於特定的業務而專一作一件事情，每一個服務承擔的是單一職責，可是它也須要達到必定規模可以完整的處理特定的領域業務。不少人都會被微服務的「微」這個詞所誤導，認爲微服務就是要拆分的越小越好。可是其實爲了「微」而將同一領域的業務拆分到不一樣的服務，只會徒勞增長軟件的複雜度和維護困難。

咱們能夠圍繞應用的業務能力進行分組，每一個小組的開發組人員開發微服務的技術能夠不受限制。每一個服務小組可使用不一樣的技術架構和存儲技術，有針對性地解決一些性能瓶頸問題。每一個服務是互相獨立部署互不影響的，這樣的話咱們能夠實現獨立打包、獨立測試和獨立附屬，減小部署時間，提高研發效率。

微服務架構測試具備三個痛點：1、如何測試微服務的外部依賴是否正常；2、如何在微服務架構下驗證系統的整個功能是否符合預期；3、這麼多微服務的部署和測試，應如何開展。按照以上痛點咱們能夠看到，微服務測試是一種驗證成本高、結果不穩定、反饋週期長的測試。

測試金字塔

測試金字塔實際上是一種方法論，解決微服務測試的關鍵在於將微服務的測試按照不一樣的力度來分組。測試金字塔的概念由麥克科恩首先提出。測試是分層次的，咱們看到圖片左邊，這個金字塔被分爲三個層次，從下往上分別是單元測試、服務測試、界面測試，從下往上測試的運行速度是逐漸減慢的，外物依賴或者服務間的依賴從下到上會依賴更多。這個測試金字塔的另一個重要特徵是，從下往上對每一層的測試代碼是逐層減小的。下方應該寫一些小而快的測試，往上應該編寫一些粗粒度的測試，編寫更少的高層次測試。

然而實際中若是以這個金字塔圖來做爲指導，會過於籠統簡單，因此咱們會採用右邊的分爲四層的測試金字塔來作內部測試的指導思想。底層是單元測試，在這之上是集成測試，再往上是端到端的測試，頂層是探索測試。

做爲開發人員或測試人員，應該關注金字塔的哪些部分呢？微服務開發人員應更多關注位於塔基底部的單元測試與集成測試。在這兩層須要開發人員編寫必定量的測試代碼來保證覆蓋，應該寫許多小而快的單元測試覆蓋絕大部分的業務場景，再寫必定的粗粒度的集成測試，來測試重要系統之間外部依賴的交互是否正常。測試人員和質量保證人員應更多關注金字塔上面兩層，測試人員能夠依據 BDD 的規範來編寫測試用例，用於校驗系統功能的交互是否正常，還能夠用很是規的手段進行破壞性的探索測試。

單元測試是測試金字塔的底基，它的定義沒有標準答案。從編程角度來看，在函數式語言中咱們能夠認爲一個函數是一個單元，在面向對象的語言中一個方法或者一個類能夠表示一個單元。單元測試具備可以及時發現 bug、利於重構、保證代碼質量的優點，咱們系統中須要編寫得最多的其實就是單元測試。

微服務的測試通常是對入棧適配器、業務邏輯和出棧適配器這三部分進行測試。入棧適配器測試的是 Controller API 是否正確；業務邏輯部分測試 Service 業務邏輯是否正確，而出棧適配器部分測試的是 SQL 邏輯是否正確。單元測試通常會遵循一個通用的 3A 結構：Arrange，Act，Assert，這樣寫出來的代碼更有閱讀性和表達力。

在微服務架構下咱們所理解的集成測試是測試應用與外部依賴的集成。第三方外部服務依賴主要有兩種類：第一種是微服務會依賴第三方系統的服務；第二種是系統內部的微服務與微服務之間，一種服務可能會依賴另外一種微服務來實現自身邏輯。對應這兩種狀況會有不一樣的策略，第一種策略是準備真實的外部服務的依賴，第二種是使用測試替身隔絕外部依賴。進行集成測試的時候咱們一般會使用一些，依賴第三方服務的話會採用 WireMock 或者 mountebank，而微服務之間的依賴調用會使用 Spring-Cloud-Contract 或者 Pact。

微服務之間的測試會使用契約測試，服務之間的接口文檔就是一個契約。契約測試能夠解決聯調成本太高，接口變更把控困難，契約變化時提供一種可當即被服務端和消費端發現的方式，這三種痛點。契約測試的提供者指微服務接口的提供者，消費者指微服務接口的消費者。契約文件是微服務提供者和消費者共同定義的接口規範，包括接口的訪問路徑和輸出數據。

CDC 的核心思想在於從消費者業務實現的角度出發，由消費者本身定義須要的測試數據格式以及交互細節，並驅動生成一份消費者契約。而後生產者根據契約來實現本身的邏輯，並在服務提供者端進行測試驗證。契約文檔應該被轉換成一個存根。生產者會根據契約編寫契約驗證測試，契約驗證測試經過會將契約文件轉換爲存根，存根會被消費者引用，契約的修改會致使任意一方測試的失敗。這樣的話能夠保證契約被消費者和生產者共同遵照。

契約測試適用於微服務接口的消費者和提供者由不一樣的團隊維護，或提供者接口被多個消費者消費這樣的場景中。

端到端測試主要用於驗證工做流程中的全部流程，以檢查一切是否按照預期工做，確保系統以統一的方式工做，從而知足業務需求。端到端測試的難點在於安裝和配置相關依賴，測試數據的自動準備二號服務的自動部署。

微服務測試藍圖

作微服務測試須要作 TDD，也就是測試在先，編碼在後的開發實踐。有別於以往的先編碼、後測試的開發過程，而是在編程以前，先寫測試腳本或設計測試用例。TDD 能夠增長開發人員代碼質量的信心，有利於代碼設計和重構，以及快速迭代和持續交付。

微服務測試推動主要分爲四步：第一步是工具，依照微服務測試層次，階段選擇合適的測試框架與工具；第二步是依據測試金字塔制定規範，貫穿生命週期始終，明確開發、測試人員的職責；第三步是自動化，貫穿 CI、CD 流程，與 DevOps 的融合；第四步是測試平臺搭建，以容器化技術搭建測試平臺，以 namespace 隔離不一樣測試環境。

點擊觀看完整課程視頻