原創(chuàng)|使用教程|編輯:鄭恭琳|2020-12-16 15:06:44.910|閱讀 262 次
概述:微服務(wù)在相互交互時通常遵循兩種模式:編排和響應(yīng)式(編排)。許多微服務(wù)使用組合的“混合”方法。在本文中,我將提供一些策略來解決在使用這些不同模式的微服務(wù)創(chuàng)建自動化測試時出現(xiàn)的一些挑戰(zhàn),重點是針對單個微服務(wù)的測試(而不是整個應(yīng)用程序的端到端測試) )。
# 界面/圖表報表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
相關(guān)鏈接:
在許多方面,測試微服務(wù)應(yīng)用程序與測試使用任何其他體系結(jié)構(gòu)構(gòu)建的應(yīng)用程序沒有什么不同。微服務(wù)面臨的獨特挑戰(zhàn)是組成應(yīng)用程序的服務(wù)數(shù)量之多,以及服務(wù)之間的依賴關(guān)系數(shù)量。
作為用于構(gòu)建復(fù)雜系統(tǒng)的體系結(jié)構(gòu),微服務(wù)在開發(fā)社區(qū)中獲得了巨大的關(guān)注。盡管人們開始意識到這并不是解決所有應(yīng)用程序體系結(jié)構(gòu)問題的靈丹妙藥,但是那些與依賴項和擴展性相關(guān)的挑戰(zhàn)共享的應(yīng)用程序可以從中受益匪淺。
微服務(wù)的采用正在上升,但是與了解如何測試微服務(wù)相關(guān)的斗爭也在增加。ThoughtWorks的Toby Clemson在列舉您可能希望在微服務(wù)體系結(jié)構(gòu)中使用的測試策略方面做得非常出色(請參閱他的文章,以獲取有關(guān)您可能要創(chuàng)建的不同測試類型的詳盡概述),但是有關(guān)如何建立和維護那些不同種類的測試仍處于起步階段。
但是在許多方面,測試微服務(wù)應(yīng)用程序與測試使用任何其他體系結(jié)構(gòu)構(gòu)建的應(yīng)用程序沒有什么不同。微服務(wù)使用眾所周知的技術(shù),例如REST或隊列,為此軟件行業(yè)已經(jīng)擁有完善的測試工具和最佳實踐。微服務(wù)面臨的唯一挑戰(zhàn)是構(gòu)成應(yīng)用程序的服務(wù)數(shù)量之多,以及服務(wù)之間的依賴性。此外,即使微服務(wù)依賴的其他微服務(wù)不可用或響應(yīng)不正確,每個微服務(wù)仍需要正常運行。
微服務(wù)在相互交互時通常遵循兩種模式:編排和響應(yīng)式(編排)。許多微服務(wù)使用組合的“混合”方法。在本文中,我將提供一些策略來解決在使用這些不同模式的微服務(wù)創(chuàng)建自動化測試時出現(xiàn)的一些挑戰(zhàn),重點是針對單個微服務(wù)的測試(而不是整個應(yīng)用程序的端到端測試) 。
使用業(yè)務(wù)流程的微服務(wù)將對外部服務(wù)或依賴項進行一個或多個顯式調(diào)用。這些調(diào)用通常使用同步請求-響應(yīng)流,并且通常將訪問基于REST的服務(wù)。如果需要按特定順序調(diào)用服務(wù),則在收到對前一個服務(wù)的調(diào)用的響應(yīng)之前,不會進行對后一個服務(wù)的調(diào)用。由于一項服務(wù)顯式調(diào)用另一項服務(wù),因此它們緊密耦合。
在上面顯示的示例中,為投資組合微服務(wù)創(chuàng)建和執(zhí)行測試具有挑戰(zhàn)性,因為投資組合微服務(wù)依賴于帳戶和報價微服務(wù),而依賴項需要與投資組合微服務(wù)一起部署在測試環(huán)境中。Quotes服務(wù)依賴于第三方服務(wù)來檢索實時股票價格,并且該服務(wù)返回的數(shù)據(jù)始終在變化。
依賴第三方服務(wù)或由不同團隊開發(fā)的服務(wù)極大地增加了測試環(huán)境的復(fù)雜性。此外,還需要測試投資組合服務(wù)的任何意外行為,例如,當“帳戶”和/或“報價”服務(wù)不可用,響應(yīng)緩慢或響應(yīng)意外數(shù)據(jù)時。重要的是,必須使這些服務(wù)以不同的意外行為響應(yīng),以驗證Portfolio微服務(wù)正確處理了錯誤情況。
服務(wù)虛擬化急救!
您可以使用服務(wù)虛擬化來模擬“帳戶和報價”微服務(wù)的響應(yīng)。通過服務(wù)虛擬化,您可以定義“帳戶和報價”微服務(wù)的虛擬版本,并將它們與投資組合微服務(wù)的實際實例一起部署。虛擬化微服務(wù)類似于虛擬化任何其他類型的服務(wù)或應(yīng)用程序體系結(jié)構(gòu)。它可能看起來像這樣:
完成此操作后,就可以獨立于其兩個依賴項來測試Portfolio微服務(wù)。
下一個挑戰(zhàn)是為不同的情況配置不同的環(huán)境,例如“帳戶和報價”服務(wù)表現(xiàn)出預(yù)期的行為和意外的行為。假設(shè)團隊要測試“帳戶”服務(wù)或“報價”服務(wù)響應(yīng)緩慢或出現(xiàn)錯誤情況時投資組合服務(wù)的行為。這可能需要運行至少5組不同的測試,其中每組都具有不同的環(huán)境配置,并考慮到響應(yīng)時間慢、錯誤響應(yīng)以及相關(guān)服務(wù)的正常和異常行為。
對于每次測試運行,都需要將環(huán)境放入正確的配置中,然后才能運行針對該配置的測試。在此示例中,我們最終進行了至少五次不同的測試運行,每種測試運行都有針對環(huán)境的自己的配置。Parasoft的持續(xù)測試平臺中的Environment Manager模塊可以為您管理以下不同的環(huán)境配置:
此過程并非特定于微服務(wù)架構(gòu)-在面向服務(wù)的架構(gòu)以及可能僅依賴少量服務(wù)的整體式應(yīng)用程序中,通常會出現(xiàn)相同類型的問題。但是,在微服務(wù)架構(gòu)中,從屬服務(wù)的數(shù)量顯著增加。在具有數(shù)十個或數(shù)百個服務(wù)的微服務(wù)環(huán)境中,針對不同的測試場景創(chuàng)建,管理和以編程方式在不同環(huán)境配置之間切換的能力非常重要,并且可以顯著減少時間和精力。
管理協(xié)調(diào)微服務(wù)中的API更改
隨著團隊發(fā)展其微服務(wù),不可避免的是將對服務(wù)進行API更改。API更改引起的關(guān)鍵問題是如何了解這些更改對服務(wù)使用者的影響。
當團隊為他們正在構(gòu)建的微服務(wù)修改API時,需要根據(jù)API中的更改來更新驗證該微服務(wù)的所有測試。相反,如果使用虛擬服務(wù)來模擬從屬微服務(wù)和用于這些從屬微服務(wù)更改之一的API,則必須更新從屬微服務(wù)的虛擬服務(wù)以反映API中的更改。
許多團隊使用OpenAPI,RAML或其他服務(wù)定義來描述其微服務(wù)的API。使用服務(wù)定義時,Parasoft SOAtest和Parasoft Virtualize中的Change Advisor模塊可以自動檢測哪些API已更改,然后自動重構(gòu)現(xiàn)有的功能測試或虛擬服務(wù),以使用API中的任何新字段和/或刪除的字段來更新它們。團隊可以創(chuàng)建其服務(wù)定義的更新版本,并可以使用Change Advisor在進行更改之前了解更改對其測試和虛擬服務(wù)的影響。進行更改后,Change Advisor可使您輕松快捷地更新現(xiàn)有資產(chǎn),以反映微服務(wù)中的更改。
微服務(wù)架構(gòu)的主要目標之一是創(chuàng)建獨立的組件。結(jié)果,部署、擴展和更新服務(wù)將變得更加容易。但是,當使用業(yè)務(wù)流程模式時,此目標并未完全實現(xiàn),因為單個微服務(wù)直接依賴于其他微服務(wù)。解決此問題的一種方法是使用編排模式,也稱為“反應(yīng)式”或“事件驅(qū)動”微服務(wù)。在這種模式下,微服務(wù)不會直接相互引用。相反,它們將消息推送到其他微服務(wù)已訂閱的事件流上。
請參見以下示例:
在此示例中,假設(shè)投資組合服務(wù)已被指示添加一個庫存頭寸。與其直接調(diào)用“帳戶”服務(wù),不如將事件發(fā)布到“已添加位置”事件流。帳戶微服務(wù)已訂閱該事件流,因此它獲得了通知。它檢查以確保用戶帳戶中有足夠的資金。如果是這樣,它將減少用戶帳戶中的資金數(shù)量,并將事件發(fā)布到“更新帳戶”事件流中。如果用戶的帳戶中沒有足夠的資金,則它可能會將錯誤事件發(fā)布到其他事件流(為簡化示例,未顯示)。投資組合微服務(wù)已訂閱“帳戶更新”事件流,并且當看到“帳戶”微服務(wù)發(fā)布的事件時,它隨后基于來自帳戶服務(wù)的確認更新其投資組合。
這種類型的體系結(jié)構(gòu)中的異步通信帶來的好處是,服務(wù)彼此之間高度解耦–可以替換,重新部署或擴展每個服務(wù)的實例,而無需其他微服務(wù)關(guān)心它們。折衷方案是事件的異步性質(zhì)使得很難理解系統(tǒng)將如何執(zhí)行以及事件的流向。根據(jù)產(chǎn)生的事件的順序或種類,系統(tǒng)可能會以意外的方式運行。這被稱為緊急行為,是在編排微服務(wù)的開發(fā)和測試中固有的挑戰(zhàn)。
異步命令調(diào)用模式
在事件驅(qū)動的微服務(wù)的更廣泛類別下,存在不同的異步消息傳遞模式。當需要使用異步操作來編排微服務(wù)時,可以使用異步命令調(diào)用模式——一種微服務(wù)需要異步調(diào)用另一種微服務(wù),同時保證第二種微服務(wù)接收到消息。在這種模式下,通常使用隊列交換消息。
微服務(wù)架構(gòu)中用于實現(xiàn)此模式的常見框架是RabbitMQ。當一個微服務(wù)需要發(fā)布事件以供第二個微服務(wù)處理,然后等待從該第二個微服務(wù)讀取“答復(fù)”事件時,就會發(fā)生這種模式的具體化身。
考慮我們剛才討論的Portfolio示例,其中REST API調(diào)用告訴Portfolio微服務(wù)添加位置。投資組合服務(wù)將一個事件發(fā)布到“已添加位置”隊列中,以供帳戶微服務(wù)處理,然后等待帳戶服務(wù)將回復(fù)事件發(fā)布到“帳戶已更新”隊列中,以便REST API調(diào)用可以返回從該事件接收的數(shù)據(jù)。有兩種不同的方法可以為該示例配置測試方案:
第一種方法很簡單,它使測試資產(chǎn)自成體系,而對測試基礎(chǔ)結(jié)構(gòu)沒有任何其他外部依賴性。第二種方法是可重用的,并且是對系統(tǒng)實際行為的更緊密模擬。但是,第二種方法具有構(gòu)建,部署和管理單獨的虛擬資產(chǎn)的成本。
異步命令調(diào)用模式的一種變體是微服務(wù),它在隊列上偵聽傳入事件,處理該事件,然后在另一個隊列上發(fā)布后續(xù)事件,以供一個或多個其他微服務(wù)處理:
在此示例中,發(fā)票微服務(wù)是需要測試的服務(wù)。付款服務(wù)將事件發(fā)布到“付款處理的RabbitMQ”隊列中,以供發(fā)票服務(wù)提取。發(fā)票微服務(wù)從隊列中讀取事件,創(chuàng)建發(fā)票,然后將事件發(fā)布到“發(fā)票已創(chuàng)建”隊列,以指導(dǎo)電子郵件微服務(wù)將帶有發(fā)票的電子郵件發(fā)送給客戶。要為發(fā)票微服務(wù)創(chuàng)建測試方案,可以配置一個包含兩個RabbitMQ隊列和已部署的發(fā)票微服務(wù)的測試環(huán)境。可以構(gòu)造一個Parasoft SOAtest測試方案,該方案將付款處理的事件發(fā)布到Payment Processed隊列中,然后該方案訂閱``發(fā)票創(chuàng)建''隊列以驗證發(fā)票服務(wù)是否響應(yīng)發(fā)布了正確的發(fā)票創(chuàng)建事件。非常簡單的測試方案,可以很好地單獨測試Invoice服務(wù)。
事件Firehose模式
當不同來源產(chǎn)生大量需要通過公共集線器快速交付給不同使用者的事件時,將使用事件Firehose模式。在這種模式中,消息是通過主題交換的(與異步命令調(diào)用模式中的消息是通過隊列交換的消息相反)。Apache Kafka框架是用于實現(xiàn)事件firehose模式的常見框架,它看起來像這樣:
假設(shè)我們要測試一個單一的微服務(wù),該微服務(wù)訂閱一個Kafka主題,處理它收到的事件,然后將其結(jié)果發(fā)布到另一個Kafka主題。例如,如下所示:
在此示例中,我們有一個預(yù)報微服務(wù),該微服務(wù)訂閱了“天氣數(shù)據(jù)”主題,該主題從許多不同的來源收集許多不同的天氣數(shù)據(jù)。然后,它將處理該數(shù)據(jù)以更新其預(yù)測模型,并將預(yù)測數(shù)據(jù)發(fā)布到“預(yù)測數(shù)據(jù)”主題。在這種情況下,我們需要驗證天氣預(yù)報服務(wù)是否將一組特定的天氣數(shù)據(jù)事件的預(yù)期事件發(fā)布到了預(yù)報數(shù)據(jù)主題。
這可以通過配置具有兩個Kafka主題和已部署的Forecast服務(wù)的測試環(huán)境來完成。測試場景將首先將必要的事件發(fā)布到“天氣數(shù)據(jù)”主題,然后訂閱“預(yù)測數(shù)據(jù)”主題以驗證“預(yù)測”服務(wù)是否發(fā)布了正確的預(yù)測數(shù)據(jù)事件。需要構(gòu)建多個不同的測試方案來驗證可以預(yù)期由預(yù)測微服務(wù)處理的事件的不同類型和順序。
這是一個相對簡單的測試方案。預(yù)測微服務(wù)與其他微服務(wù)分離的事實帶來了幸運的副作用,即預(yù)測服務(wù)的測試也與微服務(wù)分離。在這種情況下,您無需使用虛擬服務(wù)來建立復(fù)雜的環(huán)境,您只需創(chuàng)建發(fā)布事件的測試方案,并驗證是否創(chuàng)建了正確的事件作為響應(yīng)即可。
許多微服務(wù)團隊已采用持續(xù)集成/連續(xù)部署(CI/CD)流程來構(gòu)建,測試和部署容器化微服務(wù),以使流程自動化并降低與部署更新相關(guān)的風險。
在此過程中,將自動創(chuàng)建一個包含微服務(wù)的容器映像并將其部署到測試環(huán)境中(通常由Kubernetes或基于Kubernetes的發(fā)行版(如OpenShift)進行管理),在該環(huán)境中可以在微服務(wù)推送到端到端之前對其進行驗證。結(jié)束測試并最終投入生產(chǎn)。我建議閱讀有關(guān)容器化微服務(wù)的CI/CD和設(shè)計微服務(wù):持續(xù)集成。這兩篇文章都很好地描述了這種過程。
我們討論的一些測試模式依賴于對依賴的微服務(wù)使用虛擬服務(wù),這些虛擬服務(wù)需要高度組件化并易于部署,其原因與它們模擬的微服務(wù)被組件化的原因相同。為了使服務(wù)虛擬化在這些環(huán)境中工作,您需要創(chuàng)建可以輕松部署的容器化虛擬服務(wù)。
要創(chuàng)建容器化的虛擬服務(wù),您可以獲取一個包含Parasoft Virtualize及其所有依賴項的基礎(chǔ)映像,并用另一個包含該虛擬服務(wù)的所有虛擬資產(chǎn)配置的映像進行分層。可以將虛擬服務(wù)的新映像連同容器一起部署到Docker/Kubernetes環(huán)境中,并將其作為被測試微服務(wù)的容器及其所有(虛擬化)依賴項。
隨著團隊采用微服務(wù),重要的是要了解如何充分測試它們。我在這里討論的消息傳遞模式和相關(guān)測試模式并不是新事物,但是隨著微服務(wù)變得越來越普遍和越來越多的應(yīng)用程序,使用這些模式的需求已顯著增長采用微服務(wù)范式。
為了以最大的靈活性為您的微服務(wù)創(chuàng)建和部署測試方案,您可以利用Parasoft SOAtest,Parasoft Virtualize和來確保微服務(wù)的最高質(zhì)量和可靠性。
本站文章除注明轉(zhuǎn)載外,均為本站原創(chuàng)或翻譯。歡迎任何形式的轉(zhuǎn)載,但請務(wù)必注明出處、不得修改原文相關(guān)鏈接,如果存在內(nèi)容上的異議請郵件反饋至chenjj@ke049m.cn