作者 | Tomas Fernandez

譯者 | 朱鋼

策劃 | 信遠(yuǎn) 

在測試方面，微服務(wù)需要不同的方法。

微服務(wù)應(yīng)用程序是一組通過網(wǎng)絡(luò)進(jìn)行通信的分布式程序，并且與第三方服務(wù)和數(shù)據(jù)庫接口進(jìn)行交互。微服務(wù)就其網(wǎng)絡(luò)性質(zhì)而言，比傳統(tǒng)的整體架構(gòu)具有更多的故障點。因此我們需要一種不同的、更廣泛的測試方法。

那么，我們?nèi)绾螠y試微服務(wù)應(yīng)用程序呢？測試金字塔是否仍然有效呢？當(dāng)涉及第三方服務(wù)并且可能出現(xiàn)網(wǎng)絡(luò)中斷時，我們?nèi)绾芜M(jìn)行測試？我們將嘗試在這篇文章中回答所有這些問題。

測試微服務(wù)的挑戰(zhàn)

微服務(wù)架構(gòu)是一個如此深刻的范式轉(zhuǎn)變，我們必須對傳統(tǒng)的測試技術(shù)進(jìn)行重新思考。微服務(wù)在很多方面與經(jīng)典的整體式架構(gòu)不同：

• 分布式：微服務(wù)部署在多個服務(wù)器上，可能因跨地理區(qū)域位置而增加延遲并使應(yīng)用程序具有連接網(wǎng)絡(luò)中斷的風(fēng)險。依賴于網(wǎng)絡(luò)的測試可能會因代碼沒有錯誤、中斷 CI/CD 管道和阻止開發(fā)而失敗。
• 自治：只要不破壞API兼容性，開發(fā)團(tuán)隊就可以隨時自由部署其微服務(wù)。
• 增加測試區(qū)域：由于每個微服務(wù)都具有多個 API 節(jié)點，因此還有更多可測試的面需要覆蓋。
• 多語言：開發(fā)團(tuán)隊可以為其微服務(wù)選擇最佳語言。在一個大系統(tǒng)中，我們不太可能找到一個適用于所有組件的測試框架。
• 生產(chǎn)是一個移動的目標(biāo)：由于微服務(wù)是可獨立部署的，并且由自治團(tuán)隊構(gòu)建，因此需要額外的檢查和邊界來確保它們在部署時仍然能夠正確的協(xié)同工作。

所有這些特征迫使我們思考新的測試策略。

微服務(wù)的測試金字塔

測試金字塔是自動化軟件測試的規(guī)劃工具。在傳統(tǒng)形式中，金字塔使用三種類型的測試：

• 單元測試
• 集成測試
• 端到端測試

微服務(wù)金字塔添加了兩種新類型：組件測試和協(xié)定測試。

這是微服務(wù)測試金字塔的一個版本。在其他情況下，順序可能會有所不同。有些可能包括集成層中的合約測試。金字塔更像是一個指導(dǎo)方針，而不是寫在石頭上的東西。

讓我們更詳細(xì)地了解每個金字塔圖層的工作原理。

微服務(wù)的單元測試

單元測試是最細(xì)粒度且數(shù)量眾多的測試形式之一。一個單元由可以單獨測試的類、方法或函數(shù)組成。單元測試是開發(fā)實踐不可分割的一部分，如測試驅(qū)動開發(fā)或行為驅(qū)動開發(fā)。

與整體架構(gòu)相比，微服務(wù)中的單元需要網(wǎng)絡(luò)調(diào)用來實現(xiàn)其功能的概率要高得多。當(dāng)這種情況發(fā)生時，我們可以讓代碼訪問外部服務(wù)（接受一些延遲和不確定性），或者用Mock 替換調(diào)用，這為我們提供了兩種處理微服務(wù)依賴關(guān)系的方法：

• 獨立的單元測試：當(dāng)我們需要測試結(jié)果始終確定性時應(yīng)該使用這個測試。我們使用模擬或存根來隔離待測試代碼與外部依賴項。
• 社交化單元測試：允許社交化測試調(diào)用其他服務(wù)。在此模式下，我們將測試的復(fù)雜性推送到測試或過渡環(huán)境中。社交化測試是不確定性的，但是當(dāng)它們通過時，我們可以對它們的結(jié)果更有信心。

我們可以使用Mock單獨運行單元測試。或者我們可以允許測試的代碼調(diào)用其他微服務(wù)，在這種情況下，我們談?wù)摰氖巧缃换瘻y試。

正如你看到的，平衡信心與穩(wěn)定性將是貫穿整篇文章的主題。模擬使測試變得更快并減少了不確定性，但是你模擬得越多，你就越不能相信結(jié)果。社交化測試盡管有缺點，但更現(xiàn)實。因此，你可能需要在這兩種類型之間取得良好的平衡。

合約測試

每當(dāng)兩個服務(wù)通過接口耦合時，就會形成契約。該協(xié)定指定了所有可能的輸入和輸出及其數(shù)據(jù)結(jié)構(gòu)和副作用。服務(wù)的消費者和生產(chǎn)者必須遵守合約中規(guī)定的規(guī)則，以便進(jìn)行通信。

協(xié)定測試確保微服務(wù)遵守其協(xié)定。它們不會徹底測試服務(wù)的行為；它們僅確保輸入和輸出具有預(yù)期特征，并且服務(wù)在可接受的時間和性能限制內(nèi)執(zhí)行。

根據(jù)服務(wù)之間的關(guān)系，合約測試可以由生產(chǎn)者和/或消費者運行。

• 消費者端合約測試，由下游團(tuán)隊編寫和執(zhí)行。在測試期間，微服務(wù)連接到創(chuàng)建者服務(wù)的虛假版本或模擬版本，以檢查它是否可以使用其 API。
• 生產(chǎn)者端合約測試，在上游服務(wù)中運行。這種類型的測試模擬客戶端可以發(fā)出的各種 API 請求，驗證生產(chǎn)者是否與合約匹配。生產(chǎn)者端測試讓開發(fā)人員知道他們何時會破壞消費者的兼容性。

合約測試可以在上游或下游中運行。生產(chǎn)者測試檢查服務(wù)沒有實現(xiàn)會因服務(wù)而中斷的更改。消費者測試針對上游生產(chǎn)者的模擬版本（不是真正的生產(chǎn)者服務(wù)）運行消費者端組件，以驗證消費者可以發(fā)出請求并使用來自生產(chǎn)者的預(yù)期響應(yīng)。我們可以使用 WireMock 等工具來重現(xiàn) HTTP 請求。 

如果合約雙方測試通過了，則生產(chǎn)者和消費者是兼容的，應(yīng)該能夠通信。合約測試應(yīng)始終運行在持續(xù)集成中，以便在部署前檢測兼容性。

你可以在 《Pact 5-minute getting started guide》中進(jìn)行在線合約測試。 Pact 是一個基于 HTTP 的測試工具，用于編寫和運行基于消費者和生產(chǎn)者的合約測試。

微服務(wù)集成測試

微服務(wù)集成測試的工作方式與其他架構(gòu)略有不同。它的目標(biāo)是通過使微服務(wù)交互來識別接口缺陷。與合約測試總是模擬一側(cè)不同，集成測試使用真實的服務(wù)。

集成測試對評估服務(wù)的行為和業(yè)務(wù)邏輯不感興趣。相反，我們希望確保微服務(wù)能夠相互通信，而且可以正確和它們自己的數(shù)據(jù)庫進(jìn)行通信。我們正在尋找例如丟失 HTTP 請求頭或不匹配的請求/響應(yīng)對之類的問題。因此，集成測試通常在接口級別實現(xiàn)。

使用集成測試來檢查微服務(wù)是否可以與其他服務(wù)、數(shù)據(jù)庫和第三方端點進(jìn)行通信。

微服務(wù)的組件測試

組件是在較大系統(tǒng)內(nèi)完成一個角色的一個微服務(wù)或一組微服務(wù)。

組件測試是一種驗收測試，在這種測試中我們通過用模擬資源或模擬替換服務(wù)來檢查組件的行為。組件測試比集成測試更徹底，因為它們會經(jīng)歷“快樂”和“不快樂”的路徑 。 例如組件如何響應(yīng)模擬的網(wǎng)絡(luò)中斷或格式錯誤的請求。我們想知道組件是否滿足其消費者的需求，就像我們在驗收或端到端測試中所做的那樣。

組件測試對一組微服務(wù)執(zhí)行端到端測試。組件范圍之外的服務(wù)被模擬。

有兩種執(zhí)行組件測試的方法：進(jìn)程內(nèi)和進(jìn)程外。

進(jìn)程內(nèi)組件測試

在此組件測試子類中，測試運行程序與微服務(wù)存在于同一線程或進(jìn)程中。我們在“離線測試模式”中啟動微服務(wù)，其中模擬其所有依賴項，從而允許我們在沒有網(wǎng)絡(luò)的情況下運行測試。

在與微服務(wù)相同的進(jìn)程中運行的組件測試。該測試在適配器中注入模擬服務(wù)，以模擬與其他組件的交互。 

僅當(dāng)組件是單個微服務(wù)時，進(jìn)程內(nèi)測試才有效。乍一看，組件測試看起來與端到端或驗收測試非常相似。唯一的區(qū)別是組件測試選擇系統(tǒng)的一個部分（組件），并將其與其他部分隔離。該組件經(jīng)過全面測試，以驗證它是否執(zhí)行其用戶或消費者所需的功能。

組件測試和端到端測試可能看起來很相似。但不同之處在于，端到端在類似生產(chǎn)的環(huán)境中測試整個系統(tǒng)（所有微服務(wù)），而組件在整個系統(tǒng)的隔離部分上進(jìn)行測試。這兩種類型的測試都從用戶（或消費者）的角度檢查系統(tǒng)的行為，遵循用戶將要執(zhí)行的操作。我們可以用任何語言或框架編寫組件測試，但最受歡迎的可能是Cucumber和Capybara。

進(jìn)程外組件測試

進(jìn)程外測試適用于任何大小的組件，包括由許多微服務(wù)組成的組件。在這種類型的測試中，組件部署在測試環(huán)境中，其中所有外部依賴項都被模擬或存根。

在這種類型的組件測試中，復(fù)雜性被推到測試環(huán)境中，測試環(huán)境應(yīng)該復(fù)制系統(tǒng)的其余部分。

為了完善合約測試的概念，您可以??探索《Java Spring上合約測試的示例代碼?》。此外，如果您是Java開發(fā)人員，??那么這篇文章提供了用于在各個級別測試Java微服務(wù)的代碼示例?。

微服務(wù)中的端到端測試

到目前為止，我們已經(jīng)對系統(tǒng)進(jìn)行了零碎的測試。單元測試用于測試微服務(wù)的各個部分，合約測試涵蓋API兼容性，集成測試檢查網(wǎng)絡(luò)調(diào)用，組件測試用于驗證子系統(tǒng)的行為。只有在自動化測試金字塔的最頂端，我們才能測試整個系統(tǒng)。

端到端（E2E）測試確保系統(tǒng)滿足用戶的需求并實現(xiàn)業(yè)務(wù)目標(biāo)。E2E 套件應(yīng)使用與用戶相同的接口覆蓋應(yīng)用程序中的所有微服務(wù)，通常結(jié)合使用 UI 和 API 測試。

應(yīng)用程序應(yīng)在盡可能靠近生產(chǎn)環(huán)境中運行。最理想情況是測試環(huán)境將包括應(yīng)用程序通常需要的所有第三方服務(wù)，但有時這些服務(wù)可以被模擬，以降低成本或防止濫用。

端到端是模擬用戶交互的自動化測試。只有外部第三方服務(wù)可能會被嘲笑。

正如測試金字塔所描述的那樣，E2E測試是數(shù)量最少的，因為它們通常是最難運行和維護(hù)的。只要我們專注于用戶的操作和他們的需求，我們只需要幾個端到端的測試就可以提取很多資源價值。

結(jié)論

不同的模式要求改變測試策略。在微服務(wù)架構(gòu)中進(jìn)行測試比以往任何時候都更加重要，但我們需要調(diào)整技術(shù)以適應(yīng)新的開發(fā)模型。系統(tǒng)不再由單個團(tuán)隊管理。相反每個微服務(wù)所有者都必須盡自己的一份力量，以確保應(yīng)用程序作為一個整體工作。

一些組織可能會認(rèn)為單元、合約和組件測試就足夠了。其他不滿足于沒有端到端和集成測試的人可能會選擇建立一個 QA 團(tuán)隊來促進(jìn)跨團(tuán)隊的測試覆蓋。

譯者介紹

朱鋼，51CTO社區(qū)編輯，2021年IT影響力專家博主，阿里云專家博主，2019年CSDN博客之星20強，2020年騰訊云+社區(qū)優(yōu)秀作者，11年一線開發(fā)經(jīng)驗，曾參與獵頭服務(wù)網(wǎng)站架構(gòu)設(shè)計，企業(yè)智能客服以及大型電子政務(wù)系統(tǒng)開發(fā)，主導(dǎo)某大型央企內(nèi)部防泄密和電子文檔安全監(jiān)控系統(tǒng)的建設(shè)，目前在北京圖伽健康從事醫(yī)療軟件研發(fā)工作。

原文標(biāo)題：Testing Strategies for Microservices，作者：Tomas Fernandez

鏈接：????https://dzone.com/articles/testing-strategies-for-microservices????