聊聊DevOps下的測試技術（2）聊聊契約與契約測試

聊聊DevOps下的測試技術（2）聊聊契約與契約測試

1、服務交互帶來的問題

在上一篇文章中，我們系統的列舉了DevOps各個流程中常用的測試技術。

接著上一篇的圖，我們簡單畫下一個系統應用的內部服務的調用關系：交付一個大的系統可能涉及到多家ISV進行集成，每家ISV自己又存在前端、網關、后端等多個微服務，且各自ISV或者服務均存在自己的SE、開發和測試人員，都有自己相對獨立的版本演進，服務之間存在調用關系。

思考一下，這會帶來哪些問題呢？

通過接口文檔或者表格管理接口內容，服務交互雙方、多方頻繁對接交互調用的接口信息，頻繁刷新，剪不斷、理還亂，讓人崩潰。

服務依賴導致必須等待底層服務先開發完成才能聯調對接和集成測試，效率低下；

此時如果發現被調用服務接口不滿足要求、接口缺失、接口無法聯調等問題時，需要重新等待版本聯調，造成資源和時間上的浪費；

服務都在不停的向前演進，調用服務與被調用服務的版本會隨著外部需求增加、Bug修改、代碼重構等等因素而導致接口發生變更，接口調用服務往往無法及時獲取接口變化而導致整體業務受損。

2、服務契約--服務交互問題的一種解決方案

如何解決服務間紛紛復雜的聯調問題呢？本章節我們來聊一聊契約與契約測試。

顧明思義，契約就是一份由雙方或多方共同訂立的、具有強制遵從性的信用文書。契約測試全稱消費者驅動契約測試(Consumer Driven Contracts Testing)，最早見于2011年。“消費者驅動契約測試”名稱中清楚描述了“契約”、“誰提供契約”的問題。

一般來說，是消費者(Consumer)把自己對輸入和輸出的數據結構、性能已經并發性等期望以約定的格式告訴服務提供者(Provider)，服務提供者簽署同意，這就形成了一份服務契約，服務提供者對所有消費者的契約取并集進行服務能力開發，形成自己服務的對外承諾或者schema。

模型如下：消費端服務 A、B、C 調用訪問服務提供端服務A，消費端服務 A、C服務提供端服務B。服務提供端會根據消費端期望分別生成1份契約文件，以滿足消費端的訴求。

服務之間通過契約交互會帶來哪些好處呢？

1）、使用契約，接口調用雙方的對接、問題定界等都有“法律依據”，問題不會扯不清、道不明、來回甩鍋。

2）、使用契約，就確定了交付雙方的接口形式和入口與出口期望，消費端和服務提供端可以并行開發服務，并且在開發過程中就利用契約進行預集成測試，不需要等待聯調再來集成測試，大幅降低聯調溝通成本。

3）、因為契約的存在，可以整體看到服務消費端的原有接口使用情況，讓接口的變動有跡可循，即使變動也可以確保變動的安全性和準確性。

4）、消費端也能通過契約的變化獲知服務端的API變化情況

3、契約交互的問題

在第二章節我們看到契約的基本流程。在正常的契約測試流程中，契約由消費者提供，服務者遵從，根據消費者的提供的契約完成服務測試。但是，大家思考下這種模式存在什么樣的問題？我們思考下一下的問題：

雙方的契約有了，但是口頭協議空口無憑，契約如何存儲，以及如何才能防篡改？

郵件交互、會議紀要難以維護？

在敏感市場，消費者提供的契約是否符合正常訴求與合規？

在多ISV服務商、多部門協作的應用系統，消費者頻繁刷新契約要求怎么辦？

正常需要刷新契約怎么處理、契約怎么會退或者回溯？

消費端驅動，會不會造成消費端權力過大，話語權過重，倒逼服務提供端，最終也會導致整個系統不倫不類？

從上面的幾個問題可以看出，由于契約很重要，那么設計和管控契約也就顯得更加重要。

4、契約設計與契約管理的必要性

交互的問題并不像想象的那邊簡單，為了解決契約設計和管控的問題，我們新增一個設計管控和契約管理的環節。

設計管控環節類似于議會這種機溝通和決策機構，用于調停和審視契約的合理性、合規性和更改的必要性，且對于多消費者的契約做合并處理。

契約管理環節，解決契約存儲、訪問認證和不可篡改性、可追溯性和可回退等問題。這樣就避免了前面所說的問題，當然犧牲了一定了靈活性，但是在大型系統中，這樣行為是值得的。

我們看下，消費者的契約的生成和下載過程就變成如下流程：

同時，如果服務端要主動變更契約，也要得到消費端和審視委員會的通過，審核通過合入后，消費者和服務提供者從契約管理平臺下載契約使用。流程變得如下：

5、契約測試

前面的章節，我們花了較多篇幅介紹了契約的生成和契約在服務交互過程中的作用以及重要性，那么對契約的測試也很重要。下面我們簡單聊聊如何對契約進行測試。

契約測試不是組件測試，契約測試和核心也是通過API來進行。每個消費者只會關注自己的期望是否得到滿足，所以只需要根據自己提供的、已審核通過的契約文件進行測試。而服務提供端則需要滿足所有消費者的訴求，需要拿所有消費者的契約做測試，所有契約需要測試通過。如下所示：

由于實際開發中，契約簽訂之后，Consumer和Provider是同步開發，所以Consumer和Provider也是分別測試。一般的契約測試過程如下：

Consumer服務的測試環境，需要使用契約進行Mock Provider服務進行構建：

Provider服務的測試環境，則需要根據和Consumer簽署的契約文件生成的契約測試用例進行測試，通過測試契約用例驗證自己提供的接口是否滿足消費者需要，接口是否有變更。一旦接口發生變更，契約測試用例會執行失敗。

前面所述，契約是消費者(Consumer)把自己對輸入和輸出的數據結構、性能已經并發性等期望以約定的格式告訴服務提供者(Provider)，服務提供者簽署同意后形成的，那邊契約測試的主要內容也便是這幾個方面：

支持契約測試的工具有Pact、Pacto、Janus、CloudTest，Swagger也能滿足部分要求。一般來說，業界使用Pact工具的較多，簡單說下Pact工具的過程，具體Pact用法請參照官網：

Consumer測試：

Provider測試：

我們也補充下Pact工具的優缺點

Pact

主要優點

1.????? 允許使用同一個HTTP請求來獲得不同的HTTP應答；

2.????? 使用單元測試的方式對consumer和provider進行測試；

3.????? 配對測試不同版本的consumer和provider

4.????? 自動生成API文檔和全局的服務網絡圖

5.????? 支持多種編程語言

關鍵短板

1.????? 不適合性能與負載測試

2.????? 不適合測試數據需要嵌套依賴的Provider

3.????? 不適合僅傳遞數據而不處理數據的Provider

4.????? 界面不太友好，需要具備一定的開發能力

6、微服務下的服務契約樣例

契約一般是一個yaml文件或者json文件的格式，我們以CSE微服務的契約為展示樣例：

結語：本期和大家簡單聊聊在服務交互場景下使用服務契約的重要性，已經契約管理的必要性，最后簡單介紹了下契約測試。契約測試工具用法的指導文檔較多，本篇沒有做展開。DevOps下，契約測試也是需要集成到流水線中，歡迎下來繼續交流。

上一篇：聊聊DevOps下的測試技術（1） 聊聊DevOps測試

DevOps

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。