多年來，微服務一直是行業趨勢，但組織卻未能從該方法中獲益，并因發布失敗而苦苦掙扎。這些失敗通常歸結為測試服務之間的接口以獲得預期的質量、安全性和性能的困難。

最終，未能以足夠穩健的方式測試這些 API。一線希望是遺留 SOA 測試和微服務測試之間的測試概念和解決方案是相同的。如果您可以解決 API 測試問題，您就可以改進您的微服務版本。

Parasoft 產品免費試用

微服務帶來新挑戰

如今，數百甚至數千個微服務組合在一起定義現代架構已是司空見慣。

高度分布式的企業系統具有龐大而復雜的部署，而這種部署的復雜性通常被視為不實施微服務的原因。事實上，您正在分解的整體架構中的復雜性只是分解為更復雜的部署環境。

令外行人失望的是，復雜性并沒有真正消失，而是演變成一種新的復雜性。

雖然微服務有望提高并行開發效率，但它們也帶來了一系列新的挑戰。這里有些例子。

• 在 API 層需要測試更多的交互，而之前 API 測試僅限于測試外部公開的端點。
• 并行開發障礙限制了打破整體結構帶來的上市時間優勢。對其他服務的依賴和復雜的部署環境降低了現實中的并行性。
• 對單體應用中成功的傳統測試方法（例如端到端 UI 測試）的影響現在必須轉移到 API 層。
• 由于分布式數據和計算，潛在的故障點更多，這使得故障排除和根本原因分析變得困難和復雜。

微服務測試的 3 個關鍵步驟

微服務測試的三個關鍵步驟是什么？簡單描述一下，這些步驟是：

1. 記錄
2. 監視器
3. 控制

記錄、監視和控制將幫助您實施測試方法，有效地發現要創建的測試，同時在需要隔離下游 API 時幫助您自動化組件測試。

實現這一點的支持技術是服務虛擬化。服務虛擬化通過一個基本功能將所有這 3 個概念變為現實：消息代理。

通過在部署環境中使用消息代理，您可以監控和記錄 API 之間的消息流，并控制消息發送的目的地。

消息代理如何工作？

它旨在偵聽給定端點或隊列，然后將其接收到的消息轉發到目標端點或隊列。基本上，它是 API 的中間人。您主動選擇在集成系統之間注入一個。一旦就位，您就可以開始利用它了。

API 和微服務測試

無論您的環境是高度分布式、部分分布式還是大部分單一，測試 API并克服它們所帶來的挑戰都沒有太大不同。存在的集成數量越多，一些挑戰就越嚴峻，但基本方法是相同的。

當將API 或微服務視為黑匣子時，我們可以將其分解為服務的客戶端和服務的依賴項。將 API 作為黑盒進行測試意味著您的測試工具充當服務的客戶端，其工作是驗證它收到正確的響應。依賴項是您的服務需要集成才能正常運行的內容。客戶端和依賴項之間都需要進行優化。

在探索這些優化之前，讓我們從設計階段開始，即規劃微服務以及測試策略應開始的階段。

微服務生命周期

設計階段：定義清晰度要求

一個廣為接受的 API 開發最佳實踐是在設計階段實現服務定義。對于RESTful服務，通常使用OpenAPI規范。

您的客戶使用這些服務定義來了解您的服務支持哪些資源和操作以及您的服務期望如何接收和發送數據。REST 服務的服務定義中將包含描述消息體結構的 JSON 模式，以便客戶端應用程序知道如何使用您的 API。

但服務定義不僅對于幫助其他團隊了解您的 API 工作原理很重要，而且還對您的測試策略產生積極影響。

您可以將服務定義視為合同。這是開始構建 API 治理策略的基礎。就像任何軟件測試一樣，API 測試中最大的挑戰之一是應對變化。

隨著敏捷實踐的流行，變化從未如此迅速。當您試圖與許多正在構建 API 的團隊爭論，然后期望所有這些 API 能夠以某種方式彼此良好地合作時，執行這些合同是解決混亂問題的第一步。

驗證和執行合同

如何執行合同？

作為任何自動回歸套件的一部分，您應該檢查您的團隊編寫的服務定義是否存在任何錯誤。Swagger 和 OpenAPI 有自己的模式，定義了必須如何編寫服務定義。您可以使用它們在 API 開發生命周期的早期自動執行這些檢查。

然后，除了驗證合同本身之外，您還想檢查您的服務返回的響應是否也符合合同。您的 API 測試框架應該內置支持，以捕獲 API 返回偏離其服務定義架構的響應的實例。

這樣想吧。汽車由數千個單獨的零件組成，所有零件都需要完美配合。

如果負責動力裝置的團隊提供的發動機偏離了設計規范，那么當您嘗試連接其他團隊制造的變速箱時，您可能會遇到大問題，因為他們正在參考發動機的設計來了解螺栓需要對齊的地方。

這就是您在這里檢查的內容。良好的 API 治理可以幫助您避免這些類型的集成問題。根據這些契約進行設計并遵守這些契約應該是 API 測試實踐的首要關注點之一。

服務定義合同還可以幫助您的測試過程更能適應變化。針對 API 中的更改重構測試用例所需的時間可能會對測試產生巨大影響，從而導致測試被推到沖刺之外。

這既是質量風險，也是安全風險。這也意味著需要額外的測試時間。使用 API 測試框架時，它需要幫助團隊在 API 設計更改時批量重構現有測試用例，以便他們能夠跟上敏捷和沖刺測試的快節奏。服務合同和正確的工具可以減輕這一切的痛苦。

實施階段：應用最佳實踐

微服務開發并不意味著可以免費跳過單元測試。代碼就是代碼，單元測試是基本的質量實踐。它可以幫助團隊快速、盡早地發現回歸問題，并以開發人員易于修復的方式進行修復——無論是哪種軟件。

丑陋的事實是，不存在或反應性單元測試實踐的軟件團隊往往會得到質量較差的結果。單元測試的開銷被認為太多，因此許多經理和領導者沒有優先考慮它。

這是不幸的，因為工具市場已經成熟，開發人員的生活變得更加輕松和高效，而單元測試以及成本和質量之間的權衡比以前少得多。單元測試構成了可靠測試實踐的基礎，不應被忽視。

此外，開發人員的軟件質量實踐已經成熟，具有 API 開發的專用編碼標準。2019年，國際非營利組織OWASP發布了OWASP Top 10 API安全標準。

像這樣的編碼標準可以幫助微服務團隊避免常見的安全性和可靠性反模式，這些反模式可能會給他們的項目帶來業務風險。嘗試在沒有工具的情況下采用編碼標準幾乎是不可能的。

幸運的是，現代靜態分析工具，也稱為靜態應用程序安全測試 (SAST) 工具，與行業標準保持同步，并將支持該標準。開發人員可以在編寫代碼時掃描代碼，并將其作為持續集成過程的一部分，以確保不會遺漏任何內容。

組件測試階段：使用 API 依賴代理

組件測試意味著單獨測試您的微服務。實現真正的隔離面臨一些挑戰，例如了解如何處理微服務的依賴項。此外，作為微服務開發人員，最難預測的事情之一就是準確理解其他系統將如何使用您的 API。

API 的客戶端應用程序可能會發現從未考慮過的微服務的創造性用途。這既是商業上的祝福，也是工程上的詛咒，這也正是為什么花費精力來理解 API 用例如此重要的原因。

設計階段的 API 治理是重要的第一步，但即使有明確定義的契約和對微服務響應的自動模式驗證，您也永遠無法完全預測端到端產品的需求將如何發展發展，以及這將如何影響您領域內的微服務。

記錄、監視和控制將幫助您實施測試方法，有效地發現需要哪些測試，同時在需要隔離下游 API 時幫助您自動化組件測試。實現這一點的支持技術是服務虛擬化。

服務虛擬化通過一個基本功能將所有這三個概念變為現實：消息代理。使用消息代理可以監控和記錄 API 之間的消息流，并控制消息發送的目的地。

精心策劃與精心設計的服務

編排和編排（或反應式）服務是描述同步或異步消息傳遞模式的奇特術語。

如果您的服務使用消息代理與 AMQP、Kafka 或 JMS 等協議進行通信，那么您正在測試精心設計的或反應式服務。

如果您正在測試 REST 或 GraphQL 接口，那么這是一個精心策劃的或同步的服務。

就本文而言，您所面對的協議和消息交換模式并不重要。但是，如果您的 API 測試框架不支持您的組織選擇采用的協議，您可能會發現將這些原則應用于異步消息傳遞會更加困難。

捕獲客戶端使用場景

微服務團隊很難預測其他團隊將如何使用他們的 API。我們知道端到端、完全集成的測試既昂貴又緩慢。使用服務虛擬化工具中的消息代理功能，您可以記錄來自上游客戶端應用程序的流量，以便您可以捕獲真實的使用場景，從而顯著提高您對 CI/CD 管道中應運行哪些測試的了解，而無需這些客戶端應用程序始終存在以觸發該流量。

換句話說，記錄使您能夠重播這些集成場景以進行自動回歸測試，這比要求客戶運行測試（間接測試您的 API）更簡單、更容易管理。這就是為什么將服務虛擬化與 API 測試相結合的工具如此受歡迎。它們可以輕松記錄此 API 流量，然后將其用于您控制下的 API 場景測試。

使依賴關系易于管理

測試您的服務很快就會變得困難，因為它依賴于測試環境中的其他 API，這會帶來可用性、實際測試數據和容量方面的問題。

這可能會將測試工作推到沖刺之外，并使團隊難以及早發現集成問題以便有時間處理這些問題。這是服務虛擬化的傳統用例，該技術允許模擬或模擬下游 API 的響應（這樣做時，創建服務的虛擬版本）提供隔離，以便您可以更早、更輕松地全面測試您的 API您的 CI/CD 管道。

當消息代理部署在環境中時，團隊可以記錄 API 流量，然后構建忠實、真實地響應微服務的虛擬服務（包括有狀態事務，其中模擬依賴項必須正確處理 PUT、POST 和 DELETE 操作），而無需真實的操作可用的依賴項。

有狀態服務虛擬化是創建涵蓋所有測試用例的最真實虛擬服務的重要功能。

集成測試階段：控制測試環境

現在讓我們將測試范圍進一步縮小到集成測試。在此階段，有時稱為系統集成測試或 SIT 階段，測試環境是類似生產的環境，可確保不遺漏任何缺陷。

您應該期望消息代理能夠控制您是否想要與依賴項建立隔離的連接或現實世界的連接。控制的另一個方面是確保消息代理可以通過 API 輕松管理。CI/CD 流程高度成熟的組織正在自動化部署和銷毀工作流程，其中消息代理的編程控制是必須滿足的要求。

當您處于集成測試階段時，您可以從消息代理公開的可見性（或可觀察性）中提取哪些優化？

這就是監控功能對于支持自動化測試的服務虛擬化解決方案至關重要的地方。來自消息代理的監控將暴露這些復雜工作流程的內部工作原理，以便您可以實施更好的測試，告訴您問題出在哪里，而不僅僅是問題存在。

例如，考慮一個訂單處理系統，它需要檢查多個下游服務（例如庫存、計費和運輸系統）來履行訂單。對于給定的測試輸入，您可以針對某些幕后行為進行斷言，以幫助開發人員查明測試失敗的原因。當您的團隊花費更少的時間來找出問題發生的原因時，他們就有更多的時間來實際解決問題。

測試微服務的五個技巧

這里有五個技巧可以幫助您制定微服務測試策略。請記住，這些只是建議。與所有類型的測試計劃一樣，您需要考慮您的設置的具體情況。

1. 將每項服務視為一個軟件模塊。像對任何新代碼一樣對服務執行單元測試。在微服務架構中，每個服務都被視為一個黑匣子。因此，對每個進行類似的測試。
2. 確定架構中的基本鏈接并測試它們。例如，如果登錄服務、顯示用戶詳細信息的前端和詳細信息數據庫之間存在牢固的鏈接，請測試這些鏈接。
3. 不要只測試快樂路徑場景。微服務可能會失敗，模擬失敗場景以在系統中建立彈性非常重要。
4. 盡力跨階段進行測試。經驗證明，使用多種測試實踐組合的測試人員，從開發開始，逐步擴大測試范圍，不僅增加了錯誤暴露的機會，而且效率很高。在復雜的虛擬環境中尤其如此，其中各種庫之間存在微小差異，并且盡管存在可視化層，底層硬件架構仍可能產生不可預見的、不期望的結果。
5. 對新代碼使用“金絲雀測試”并對真實用戶進行測試。確保所有代碼都經過充分檢測。并且還使用您的平臺提供商提供的所有監控。這滿足了“左移”測試和“右移”測試，因為您也在“野外”進行測試。

揭秘微服務

微服務將繼續存在。不幸的是，組織未能獲得該方法的好處。歸根結底是測試分布式系統之間的接口（即 API）以獲得預期的質量、安全性和性能的難度。

我們需要一種微服務測試方法，能夠發現、創建和自動化組件測試。支持技術是消息代理和服務虛擬化，它們與功能豐富的 API 測試框架緊密集成。

消息代理可以記錄 API 流量、進行監控以發現場景和用例，以及進行控制以管理和自動化 API 測試套件。與服務虛擬化相結合，自動化微服務測試成為可實現的現實。