前言
在前幾天的博客中，我轉載了一篇文章，其中介紹了契約測試和pact是怎么實施的，的確很有幫助。但我經過研究，其實是pact本身也是有缺陷的，結合我近期在使用的服務型工具和我的實際情況，覺得實現契約測試其實有更有效率的解決方案，本文就通過我的視角看看我是如何快速實現契約測試的。
契約測試
因為前后端對接的過程中會出現信息不對稱，以及工作進度不一致的情況，因此希望通過事先約定好API返回數據的文檔，根據文檔來開發后端代碼，以及生產可以被前端調用的虛擬的API，幫助前后端能夠同時開展工作並且保持前后端代碼的正確性，加快后期的系統集成測試甚至是取消系統集成測試。
我們將以上的做法稱之為契約測試。契約測試最開始的概念由 Martin Fowler 提出，它又被稱之為：消費者驅動的契約測試（Consumer Driven Contracts），簡稱CDC。這里的契約是指軟件系統中各個服務間交互的數據標准格式，更多的指消費端（client）和提供端（server）之間交互的API的格式。
契約測試帶來的變化主要是：
1.將前后端測試解耦，前后端可以分別在對方還沒有完成工作的時候就開展測試；
2.將測試過程前移，加速或者取代集成測試；
3.保證數據的一致性，讓后端服務返回的數據就是前端想要得到的。
我做了一張圖方便大家理解CDC的概念：
上圖經歷了三個步驟：
1.消費者（廣義的前端）根據業務需要編寫好契約文件，契約文件里面編寫了需要返回的數據；
2.消費者（廣義的前端）向契約文件（實際上是一個API服務）發起請求，得到預期的結果，驗證前端業務邏輯是否正確；
3.契約文件（實際上是一個API服務）向提供者（廣義的后端）發起請求，得到后端真實的返回結果並且與契約文件中的數據規則進行校驗，判斷后端返回的數據是否滿足契約的要求。如果無法通過校驗，說明提供者的服務發生了改變，或者是沒有按照契約所規定的來進行開發。
如果通過了上面的三步，我們可以認為前后端對於契約的理解和實現是一致的，等到真正集成之后也不會出現問題。
Pact 契約測試框架
之前業內較為常見的做法是通過Pact（一個契約測試框架）進行契約測試：通過前端開發人員編寫代碼進行測試並生成Pact契約文件，后端通過Pact Brocker等服務管理契約以及調用等。
但是Pact也存在一些缺點：
1.需要引入Pact的相關文件以及正確搭建服務，用起來需要一定的時間成本
2.生成的返回數據不夠靈活，無法編寫代碼生成復雜的隨機數據；
3.無法判斷請求參數來返回不同的結果；
4.需要開發人員額外編寫代碼，增加了工作量；
5.存在代碼入侵的情況，並且目前支持的語言較少；
6.模糊了開發與測試人員之間的界限，管理不當容易導致重復勞動；
由於有以上的不足之處，Pact 在實際應用的效果往往並不理解。因此我們提出了通過 Mock API 以及測試用例實現更快速、更有效地契約測試。
通過 EOLINKER API Studio 實現契約測試
EOLINKER API Studio（https://www.eolinker.com） 提供了UI實現的 Mock API，配合API Studio 的測試用例與自動化測試，可以幫助研發團隊更快速、更有效地實現契約測試。
什么是Mock API？
通過 Mock API，您可以事先編寫好 API 的數據生成規則，由 API Studio 動態生成 API 的返回數據。開發人員通過訪問 Mock API 的 URL 來獲得所需要的數據，完成對接工作。
在 API Studio中，同一個項目中的 Mock API 的地址前綴是相同的（如mock.eolinker.com/uasyd1/…），因此可以在代碼中將 Mock API 的地址前綴作為全局變量，項目上線時僅需替換變量的值即可改變整個項目的 API 請求地址前綴。
創建Mock API，實現前端的契約測試
在EOLINKER API Studio中，創建 Mock API 之前需要先創建API文檔（或者導入Postman、Swagger等數據），API文檔可以作為前后端對接的依據。這里我創建了一個簡單的用戶登錄API文檔：
創建好API文檔之后，點擊 Mock API 標簽進入Mock API的管理頁面，在這里可以快速創建多個Mock API，並且根據不同的請求參數返回相應的數據：
創建一個 Mock API 期望，我們希望當傳遞user_name=******和user_psw=112233時，Mock Server返回登錄成功的數據，這里返回的數據類型選擇Json，填寫好Json的格式以及內容即可：
點擊預覽按鈕可以看到是我們希望得到的返回數據，然后確定保存即可：
通過這種方式可以創建多個Mock API，並且通過請求紅框處的 Mock API URL 得到返回結果：
API Studio 中也提供了強大的 API 測試的功能，我們直接在平台上對剛才的登錄成功的 Mock API 發起請求，可以看到當我們傳遞正確的參數時，可以得到預期的返回結果，至此契約測試的前端契約就已經完成了：
創建測試用例，實現后端的契約測試：
傳統的契約測試其實並不能夠保證測試的覆蓋率，因為前端開發人員提供的契約文件很可能無法覆蓋所有的請求情況，導致出現漏測的情況。
因此 API Studio 建議將后端的契約測試交給測試人員負責，這樣可以提供更完善的測試用例，並且可以結合各類CI工具實現自動化測試。
由於 API Studio 基於 API 文檔來實現契約測試、API用例測試、API自動化測試等功能，因此可以將前端、后端、測試人員解耦，工作的流程可以進一步改進為下圖所示，前后端、測試人員可以同時開展工作，並且測試用例可以導入到自動化測試中成為長期的定時測試任務。
由於測試用例與自動化測試所包含的內容較多，如有需要可以前往 EOLINKER API Studio 官方網站（https://www.eolinker.com）或者是查閱 API Studio 幫助文檔，在此不再贅述。