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

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

Parasoft 產(chǎn)品免費試用

微服務(wù)帶來新挑戰(zhàn)

如今，數(shù)百甚至數(shù)千個微服務(wù)組合在一起定義現(xiàn)代架構(gòu)已是司空見慣。高度分布式的企業(yè)系統(tǒng)具有龐大而復(fù)雜的部署，而這種部署的復(fù)雜性通常被視為不實施微服務(wù)的原因。事實上，您正在分解的整體架構(gòu)中的復(fù)雜性只是分解為更復(fù)雜的部署環(huán)境。令外行人失望的是，復(fù)雜性并沒有真正消失，而是演變成一種新的復(fù)雜性。

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

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

微服務(wù)測試的 3 個關(guān)鍵步驟

微服務(wù)測試的三個關(guān)鍵步驟是什么？簡單描述一下，這些步驟是：

1. 記錄
2. 監(jiān)視器
3. 控制

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

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

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

消息代理如何工作？

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

API 和微服務(wù)測試

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

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

在探索這些優(yōu)化之前，讓我們從設(shè)計階段開始，即規(guī)劃微服務(wù)以及測試策略應(yīng)開始的階段。

微服務(wù)生命周期

設(shè)計階段：定義清晰度要求

一個廣為接受的 API 開發(fā)最佳實踐是在設(shè)計階段實現(xiàn)服務(wù)定義。對于RESTful服務(wù)，通常使用OpenAPI規(guī)范。

您的客戶使用這些服務(wù)定義來了解您的服務(wù)支持哪些資源和操作以及您的服務(wù)期望如何接收和發(fā)送數(shù)據(jù)。REST 服務(wù)的服務(wù)定義中將包含描述消息體結(jié)構(gòu)的 JSON 模式，以便客戶端應(yīng)用程序知道如何使用您的 API。

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

您可以將服務(wù)定義視為合同。這是開始構(gòu)建 API 治理策略的基礎(chǔ)。就像任何軟件測試一樣，API 測試中最大的挑戰(zhàn)之一是應(yīng)對變化。

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

驗證和執(zhí)行合同

如何執(zhí)行合同？

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

然后，除了驗證合同本身之外，您還想檢查您的服務(wù)返回的響應(yīng)是否也符合合同。您的 API 測試框架應(yīng)該內(nèi)置支持，以捕獲 API 返回偏離其服務(wù)定義架構(gòu)的響應(yīng)的實例。

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

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

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

服務(wù)定義合同還可以幫助您的測試過程更能適應(yīng)變化。針對 API 中的更改重構(gòu)測試用例所需的時間可能會對測試產(chǎn)生巨大影響，從而導(dǎo)致測試被推到?jīng)_刺之外。

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

實施階段：應(yīng)用最佳實踐

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

丑陋的事實是，不存在或反應(yīng)性單元測試實踐的軟件團隊往往會得到質(zhì)量較差的結(jié)果。單元測試的開銷被認為太多，因此許多經(jīng)理和領(lǐng)導(dǎo)者沒有優(yōu)先考慮它。

這是不幸的，因為工具市場已經(jīng)成熟，開發(fā)人員的生活變得更加輕松和高效，而單元測試以及成本和質(zhì)量之間的權(quán)衡比以前少得多。單元測試構(gòu)成了可靠測試實踐的基礎(chǔ)，不應(yīng)被忽視。

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

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

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

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

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

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

設(shè)計階段的 API 治理是重要的第一步，但即使有明確定義的契約和對微服務(wù)響應(yīng)的自動模式驗證，您也永遠無法完全預(yù)測端到端產(chǎn)品的需求將如何發(fā)展發(fā)展，以及這將如何影響您領(lǐng)域內(nèi)的微服務(wù)。

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

服務(wù)虛擬化通過一個基本功能將所有這三個概念變?yōu)楝F(xiàn)實：消息代理。使用消息代理可以監(jiān)控和記錄 API 之間的消息流，并控制消息發(fā)送的目的地。

精心策劃與精心設(shè)計的服務(wù)

編排和編排（或反應(yīng)式）服務(wù)是描述同步或異步消息傳遞模式的奇特術(shù)語。

如果您的服務(wù)使用消息代理與 AMQP、Kafka 或 JMS 等協(xié)議進行通信，那么您正在測試精心設(shè)計的或反應(yīng)式服務(wù)。

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

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

捕獲客戶端使用場景

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

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

使依賴關(guān)系易于管理

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

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

當消息代理部署在環(huán)境中時，團隊可以記錄 API 流量，然后構(gòu)建忠實、現(xiàn)實地響應(yīng)微服務(wù)的虛擬服務(wù)（包括有狀態(tài)事務(wù)，其中模擬依賴項必須正確處理 PUT、POST 和 DELETE 操作），而無需真實的操作可用的依賴項。

有狀態(tài)服務(wù)虛擬化是創(chuàng)建涵蓋所有測試用例的最真實虛擬服務(wù)的重要功能。

集成測試階段：控制測試環(huán)境

現(xiàn)在讓我們將測試范圍進一步縮小到集成測試。在此階段（有時稱為系統(tǒng)集成測試或 SIT 階段），測試環(huán)境是類似生產(chǎn)的環(huán)境，可確保不遺漏任何缺陷。

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

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

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

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

測試微服務(wù)的五個技巧

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

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

揭秘微服務(wù)

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

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

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

了解更多有關(guān)Parasoft產(chǎn)品咨詢，歡迎咨詢