乾貨時間：聊聊DevOps下的技術系列之契約測試

摘要：本期和你們簡單聊聊在服務交互場景下使用服務契約的重要性，以及契約管理的必要性，最後簡單介紹了下契約測試。

一、服務交互帶來的問題

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

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

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

• 經過接口文檔或者表格管理接口內容，服務交互雙方、多方頻繁對接交互調用的接口信息，頻繁刷新，剪不斷、理還亂，讓人崩潰。
• 服務依賴致使必須等待底層服務先開發完成才能聯調對接和集成測試，效率低下；
• 此時若是發現被調用服務接口不知足要求、接口缺失、接口沒法聯調等問題時，須要從新等待版本聯調，形成資源和時間上的浪費；
• 服務都在不停的向前演進，調用服務與被調用服務的版本會隨着外部需求增長、Bug修改、代碼重構等等因素而致使接口發生變動，接口調用服務每每沒法及時獲取接口變化而致使總體業務受損。

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

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

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

通常來講，是消費者(Consumer)把本身對輸入和輸出的數據結構、性能已經併發性等指望以約定的格式告訴服務提供者(Provider)，服務提供者簽署贊成，這就造成了一份服務契約，服務提供者對全部消費者的契約取並集進行服務能力開發，造成本身服務的對外承諾或者schema。

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

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

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

2）、使用契約，就肯定了交付雙方的接口形式和入口與出口指望，消費端和服務提供端能夠並行開發服務，而且在開發過程當中就利用契約進行預集成測試，不須要等待聯調再來集成測試，大幅下降聯調溝通成本。

3）、由於契約的存在，能夠總體看到服務消費端的原有接口使用狀況，讓接口的變更有跡可循，即便變更也能夠確保變更的安全性和準確性。

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

三、契約交互的問題

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

• 雙方的契約有了，可是口頭協議空口無憑，契約如何存儲，以及如何才能防篡改？
• 郵件交互、會議紀要難以維護？
• 在敏感市場，消費者提供的契約是否符合正常訴求與合規？
• 在多ISV服務商、多部門協做的應用系統，消費者頻繁刷新契約要求怎麼辦？
• 正常須要刷新契約怎麼處理、契約怎麼會退或者回溯？
• 消費端驅動，會不會形成消費端權力過大，話語權太重，倒逼服務提供端，最終也會致使整個系統不三不四？

從上面的幾個問題能夠看出，因爲契約很重要，那麼設計和管控契約也就顯得更加劇要。

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

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

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

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

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

同時，若是服務端要主動變動契約，也要獲得消費端和審視委員會的經過，審覈經過合入後，消費者和服務提供者從契約管理平臺下載契約使用。流程變得以下：

五、契約測試

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

契約測試不是組件測試，契約測試和核心也是經過API來進行。每一個消費者只會關注本身的指望是否獲得知足，因此只須要根據本身提供的、已審覈經過的契約文件進行測試。而服務提供端則須要知足全部消費者的訴求，須要拿全部消費者的契約作測試，全部契約須要測試經過。以下所示：

因爲實際開發中，契約簽定以後，Consumer和Provider是同步開發，因此Consumer和Provider也是分別測試。通常的契約測試過程以下：

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

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

前面所述，契約是消費者(Consumer)把本身對輸入和輸出的數據結構、性能已經併發性等指望以約定的格式告訴服務提供者(Provider)，服務提供者簽署贊成後造成的，那邊契約測試的主要內容也即是這幾個方面：

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

Consumer測試：

Provider測試：

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

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

契約通常是一個yaml文件或者json文件的格式，咱們以CSE微服務的契約爲展現樣例：

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

本文分享自華爲雲社區《聊聊DevOps下的測試技術（2）聊聊契約與契約測試 》，原文做者：柳哥說 。

 

點擊關注，第一時間瞭解華爲雲新鮮技術~