正如大家所知，最初QA都是手動執行測試用例，開發人員每修改一個版本，QA就要手動測試一遍，隨著功能的不斷增加，手動測試重復的工作量越來越大。為了解脫QA重復性勞動，提高工作效率，重復執行的測試用例被自動化了。自動化測試讓QA的工作前進了一大步。

本文講的端到端集成測試(簡稱集成測試)是指系統集成后的自動化測試，是系統或模塊真實組裝后運行的測試。很多團隊用UI端到端來測系統集成后的行為，這類工具很多，比如有Selenium webdriver等。端到端的集成測試反饋與修復的周期比較長、運行速度慢，測試運行不穩定，有時隨機失敗，維護成本也很高。它不像單元測試，單元測試測具體一個方法或API，定位準確，采用Mock機制，運行速度非常快(毫秒級)，又是開發人員在本地執行，反饋修復及時，成本較低。

于是，我們把絕大部分能在單元測試里覆蓋的用例都放在單元測試覆蓋，只有單元測試測不了的(比如模塊或API之間連通性)，才會通過端到端的集成測試來覆蓋。此時，測試又前進了一大步。

但是，隨著業務的不斷拓展、產品功能不斷增加，系統架構越來越復雜，端對端集成測試的成本越來越高，測試用例也越增越多，集成測試又成了快速驗證的阻塞區。在當今持續集成的開發模式中，開發團隊會頻繁集成，每次集成都會通過流水線(Pipeline)快速驗證、準備部署包、進而發布。然而，集成測試的這些問題會嚴重影響或阻礙產品快速發布。

那么問題來了，怎么解決集成測試的現有問題，讓測試再前進一大步?

其實，早在幾年前，著名的敏捷和TDD專家JB Rainsberger就提到了。

集成測試是個騙局”，正確的是應該用一種契約或協議測試來測試集成后的系統行為!

JB Rainsberger認為你寫的2-5%的集成測試和單元測試有重復，或者和其它地方的集成測試存在重復，而且當集成測試失敗時，你也不知道發生了什么，不能及時準確定位問題。

JB Rainsberger認為應該讓契約測試來替代集成測試，那么，什么是契約測試?它是否能解決集成測試的這些問題?

契約測試

契約測試是驗證服務的Provider是否按照期望的方式與服務的Consumer進行交互，簡單的說是Consumer與Provider兩者之間的集成。

而Contract即合同、契約，就是Provider與Consumer的交互方式。

契約測試通常是基于Consumer驅動的(Consumer Driven Contracts，基于Consumer驅動的契約測試工具有PACT)。基于Consumer驅動的契約測試分兩個階段：

1. Consumer生成契約，開發者在Consumer端寫測試時Mock掉Provider，運行測試生成契約文件;
2. Provider驗證契約，開發者拿契約文件直接在Provider端運行測試進行驗證。

第一階段：Consumer生成契約

第二階段：Provider驗證契約

如何用PACT編寫契約測試，這里就不贅述了，實例詳情請參見PACT an example。

集成測試的特點：

1. 真實安裝后測試，測試更接近真實使用情況;
2. 可見性強，容易理解;(比如：看一遍運行關鍵業務的集成測試，業務人員或客戶會覺得很放心。也可以替代驗收測試)
3. 模塊真實調用，測試運行慢，秒級別或分鐘級別，反饋與修復的周期慢，成本高;
4. 問題定位難，多個子模塊組合安裝后的測試，很難定位是哪個模塊出的問題;
5. 真實的安裝或環境搭建，不穩定，容易導致測試隨機失敗;
6. 溝通成本高，需要不同模塊團隊間的協調工作;
7. 與底層測試或集成測試會有重復，集成測試中有的路徑已經被單元測試覆蓋。

契約測試的特點：

1. 開發人編寫，采用Mock機制，開發本地就可以運行，沒有真實調用，運行快，毫秒級修復反饋周期短;
2. Provider與Consumer兩兩之間的驗證，容易定位問題，而且與底層測試或其它契約之間沒有重復;
3. 不需要部署真實的集成環境，穩定且成功率高;
4. 溝通成本低。(比如一個Consumer端的加入導致服務端API修改，服務端開發人員不必跑去找所有其它Consumer端開發人員溝通確認是否會被影響，直接運行契約測試就能知道結果。)

由此可見，開篇談到的端到端集成測試運行慢、不穩定、修復反饋周期長等等問題，都能通過契約測試得到解決或改進。

舉例說明

假如某社交聊天產品(簡稱TWChat)的架構是這樣的：服務端、客戶端、郵件通知服務三部分組成。

架構圖

通常的測試策略：底層絕大部分的單元測試+少量上層端到端集成測試。

用TWChat注冊場景來舉例說明吧。注冊一個帳號的工作流是：客戶端把注冊帳號信息提交給服務端，服務端處理帳號時，會去調用郵件通知服務發通知，并完成注冊。

底層單元測試用例

單元測試

1. 客戶端的單元測試：驗證注冊表各個Field的各種輸入組合、以及檢驗正確性等;(比如：邊界值、空、中英數各類組合、合法與非法輸入等)
2. 服務端的單元測試：驗證注冊數據表的各種輸入組合可以成功存放于服務端帳號DB表中，且不合法的、重復等會有相應的錯誤碼;
3. 郵箱通知服務端的單元測試：輸入合法的各類不同的郵箱確，保證能正常發出通知郵件并返回正確碼，輸入不合法的郵箱或空郵箱確保有相應的錯誤碼。

上層端到端集成測試用例

集成測試

一條注冊連通性的Happy path測試用例, 輸入所有必填項提交，驗證注冊成功，收到成功通知郵件。

以上的集成測試，必填項輸入其實是與單元測試重復，郵件通知發送功能與單元測試也有重復;再者，這條集成測試跑失敗，我們并不能定位是客戶端的問題、服務端問題、還是通知服務的問題。加上集成測試是把所有子模塊(服務端、客戶端、通知微服務)真實產品安裝包部署以后才能運行的測試，反饋、修改周期長，不穩定容易隨機失敗等等。

集成測試換成契約測試用例

契約測試

1. TWChat客戶端Consumer與TWChat服務端Provider加一條契約測試，確保TWChat服務端按期望提供給客戶端接口(參見PACT an example)。
2. TWChat服務端Consumer與郵件通知服務Provider之間加一條契約測試，確保郵件通知服務按照預期與TWChat服務端交互(參見PACT an example)。

契約測試與單元測試以及其它測試之間沒有重復，它是單純驗證Provider與Consumer之間按預期的方式交互，定位準確;不需要部署真實的系統環境、Mock機制、沒有真實API調用，運行非常快、反饋及時、修復周期短、成本低，在這種情況下，自動化測試流水線運行更快了，產品流水線出產品安裝包也更快。因此，顯然契約測試才是真正對的選擇。

微服務架構下契約測試的重要性

例如，隨著TWChat業務的擴大，TWChat錢包，TWChat安卓端，TWChat iOS端，以及其它的服務方與Consumer方接入TWChat服務器。

當其中TWChat安卓端修改后，如果還按照之前的集成測試方式，就得把服務端與所有的客戶端真實的集成到一起測試，確保都沒有被影響才能生成產品安裝包并發布，這里的集成測試成了流水線(pipeline)的一個聚集地，也成為了產品發布的阻塞區。

集成測試流水線

假如，換成契約測試，我們把契約測試放在各自的流水線(pipeline)上，每次代碼提交觸發相應產品流水線上的契約測試，當TWChat安卓客戶端Consumer API修改，在安卓客戶端的流水線(pipeline)上運行安卓客戶端為Consumer與服務端為Provider的契約測試，測試通過，生成產品安裝包;如果契約測試失敗，服務端需要相應修改，則本次TWChat安卓端的安裝包需要在TWChat服務端修改后，方可生成安卓客戶端的產品安裝包。

契約測試解耦后

由此可見，并不是每一次TWChat安卓端的修改都要全部Consumer端與服務端集成后驗證才出包，而是各自可以獨立出包，產品解耦，大大節省時間，提高出包頻率。

并非所有端到端集成測試都適合換成契約測試

契約測試相比端到端集成測試有很多優勢，但并不是所有場景都適合契約而非集成測試。

比如：

1. 契約測試無法做安全或性能測試等。
2. 契約測試采用Mock機制，所以沒有集成測試更接近真實環境，也不能給業務人員做驗收，可視性差。
3. 契約測試基于不同的服務使用的協議不同，驗證契約的復雜度會不同，復雜度過高時，需要權衡是否有必要加契約測試。

所以，把端到端集成測試要換成契約測試也不是絕對的，視情況而定。

總的來說，當你追加端到端集成測試的時候，如非特殊，快換契約測試吧。

【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】

戳這里，看該作者更多好文