微服務架構中的軟體測試

　近幾年來，微服務悄然而又堅定地在擁擠的軟體架構市場中占有一席之地。微服務體系結構不同于傳統的單一整體體系結構，微服務體系結構并不以單體形式建構。盡管單一整體體系結構是可靠的，但其相關的問題也日益增多，尤其是當越來越多的應用采用雲部署的方式時。微型服務體系結構是一種子產品化結構，它不是由元件拼裝而成的，而是将軟體分解分散到不同的服務中，形成元件化結構。是以在微服務體系結構中，整個應用就像是一組互相獨立、可部署、可擴充的服務，甚至可以靈活地編寫不同的服務。另外，這種方法還可以幫助團隊間并行開發。

　　顯然，随着行業向微服務體系結構過渡，适用于單一整體架構的測試方案也需要改變。基于微服務建構的應用在功能和性能上都更加出色，微服務測試也必須覆寫所有級别以及跨級别的服務，同時還必須保持輕量級。但是，由于微服務開發在本質上是分布式的，是以相關的測試常常具有巨大的挑戰，其中包括如下：

　　假如一個測試團隊傾向于使用 Web API測試工具——這種工具經常用于 SOA測試，那麼在微服務測試中就會産生問題。因為在微服務體系結構中，服務是由不同的團隊開發的，是以要在測試時及時提供所有服務是相當困難的;

　　對于測試生命周期的不同階段，如何确定合适的測試數量也是一個挑戰;

　　在測試和資料驗證中提取日志非常複雜;

　　為了實作靈活和非內建的開發，提供專門的測試環境也是一個挑戰。

　　Mike Cohn的測試金字塔(Testing Pyramid)對于測試方案開發非常有用，并且能夠幫助确定需要的測試數量。基于此金字塔，在測試時采用自底向上的方法，并且考慮了各個階段所需要的自動化工作，這将幫助解決上述問題。

　　機關測試

　　一個單元測試的範圍僅限于服務内部，它圍繞一系列相關的案例進行編寫。因為單元測試的數量很大，是以理論上應該以自動化的方式進行。當單元測試在一個微服務中執行時，您必須結合合作型單元測試(Sociable

unit testing)和孤立型單元測試(Solitary unit

testing)，它通過觀察它的狀态變化來檢查子產品的行為，并看到對象和它們的依賴之間的互相作用。但是，測試人員需要確定在單元測試中，當單元“行為”受到限制時，“實作”不受測試的限制——通過持續地将單元測試的價值與維護成本/實作受限成本進行比較，就可以做到這一點。

　　綜合測試：

　　雖然獨立測試子產品非常重要，但是同樣重要的是測試子產品是否能夠正确互動，并測試它們作為子系統的互動作用，看界面的缺陷，這一工作可以通過內建測試來完成。綜合測試的目的是：通過綜合測試子產品，檢驗各子產品是否通暢，确認子產品與外部元件的互動。實施“網關內建測試”和“持續內建測試”可以確定，當發現外部元件之間的邏輯回歸和缺陷時，能夠迅速得到回報，進而幫助評估個别子產品所包含的邏輯是否正确。

　　元件測試：

　　微型服務中的元件測試需求：使用測試覆寫和内部

API端點，通過替換外部協作元件，獨立地對單個元件執行測試。組合式測試為測試人員提供了一個可控的測試環境，幫助他們從消費者的角度來引導測試，允許綜合測試，增加測試的執行次數，最大限度地減少可移動部分，進而降低整體構件的複雜性。構件測試還可以确認微服務的網絡配置是否正确，并且能夠處理網絡請求。

　　合同測試：

　　以上三個測試提供了一個高測試覆寫率，但是沒有測試一個外部依賴性是否支援端對端業務流。合同測試測試了外部服務的邊界，以檢視服務調用的輸入/輸出，并測試服務是否符合合同預期。收集所有消費者契約測試結果，幫助維護者在需要時對服務做出改變(不影響消費者)，并且非常有助于為新服務的定義提供支援。

　　兩端式測試：

　　除測試服務外，測試人員還需要確定應用必須滿足業務目标，而不論構模組化式是什麼，同時還要測試內建系統運作的完整性。是以，端到端測試在微服務測試方案中起着重要作用。此外，考慮到在微服務體系結構中有可移動的部分具有相同的行為，端對端測試需要确定覆寫範圍，并確定在進行架構重構時業務功能不受影響。

　　總結：

　　微細粒測試必須更仔細地考慮微粒，同時避免因為過于敏感而浪費時間。為了開發一個強有力的測試方案，測試人員需要正确地定義服務，明确規定範圍。鑒于軟體業正傾向于微服務，測試人員可能必須在服務級别直接修改過程和測試的執行方式。通過這種方式，他們不僅能夠正确地測試各個元件，還可以有更多的時間來內建應用，并提供更多的時間來進行端對端測試。