【轉】契約測試的必要性

因爲工做的緣由，最近一直在研究API接口測試問題，由於先後端開發常常遇到進度不一致、信息不對稱的狀況，最近正在找尋能完美解決這個問題的方案。嘗試尋找了一下，發現這實際上是一個契約測試問題，在博客園上找到以前的一些文章，看完以爲對我理解契約測試有很大幫助，轉過來記錄一下。如今我已經有一些思路了，後續會專門寫一篇文章來記錄這部分的內容。

測試金字塔模型

 

測試是軟件流程中很是重要，不可或缺的一個環節。通常的測試分爲單元測試，集成測試，端到端的手工測試，這也是構成測試金字塔的三個層級。咱們今天將要討論的話題是契約測試，它是處於單元測試和集成測試中間的一個環節。這三個層級分別測試的場景以下：

• 單元測試：測試單個service
• 集成測試：測試由多個services組成的系統
• 端到端測試：測試從用戶到各個外部系統的整個場景

 

什麼是契約測試？

契約測試最開始的概念由Martin Fowler 提出，請參見這篇文章， 它又被稱之爲：消費者驅動的契約測試（Consumer Driven Contracts）。這裏的契約是指軟件系統中各個服務間交互的數據標準格式，更多的指消費端（client）和提供端（server）之間交互的數據接口的格式。

爲何要存在契約測試？

 系統工程中存在這樣的理論：線性系統（即複雜性隨規模線性增加的系統）的可靠性等於組成它的各個組件的可靠性之乘積。這容易理解，由於整個系統正常工做的條件是必須每一個組件都同時正常工做。

 

如上圖所述，三個組件共同支撐的系統，若是每一個組件的可靠性是90%，那麼整個系統的可靠性就是 90%×90%×90%=72.9%，咱們能夠看到系統總體的可靠度是低於任一組件的可靠性的。若是一個系統由100個組件組成，每一個組件即便能達到99%的可靠性，那麼整個系統的可靠性也會降到36.6%左右。

　　咱們常說複雜性是軟件工程的最重要的特性，一個完善的軟件系統必然是靠不少的子系統，組件共同撐起來的。根據上面的理論，若是是一個複雜的軟件系統那麼每個組件的可靠性都對系統總體的可靠性有着很是重要的影響，排除組件自己的可靠性的因素，各個組件之間的相互依賴和調用關係也將會對系統的穩定性有着決定性的影響。隨着業務的複雜度愈來愈高，整個系統也變得愈來愈龐大和錯綜複雜，在今天的軟件工程開發中微服務已經不是一個新名詞，在微服務的架構下一般一個client會與多個service相互交互，能夠想象一下若是某一個服務的接口發生變化將會影響整個系統的運行。以下圖展現的傳統的大服務與微服務的區別。

那麼在微服務模式下若是保證各個服務端與消費端之間以及服務與服務之間可以可靠的交互呢？這就回到了到咱們要聊的契約測試的話題。

以下圖，在服務端接口發生變化的狀況下經過契約測試能夠很容易的測試出契約不匹配，能夠在集成測試以前就能發現問題，儘早解決。

 

 

契約測試和單元測試，集成測試，端到端測試區別是什麼？

單元測試：

• 一般是測試單個類，方法的可靠性
• 它的價值在於快速的反饋某一個很小的功能點是否能準確的工做
• 經過單元測試可以更明確的剖析你的實現邏輯
• 若是用TDD的開發模式，可以作代碼重構以及改善代碼整潔度

集成測試：

• 關注的是各個服務之間交互
• 測試接口連通性和流程的可用性

端到端測試：

• 從用戶的角度驗證整個功能的準確性和可用性
• 測試的是端到端的流程，會加入用戶數據驗證功能是否可用
• 不會關注在某一細小的功能點的實現
• 關注的是整個業務流程，產生的業務價值大

契約測試：

• 測試接口和接口之間的正確性
• 驗證服務層提供的數據是不是消費端所須要的
• 將原本須要在集成測試中體現的問題前移，更早的發現問題
• 更快速的驗證消費端和提供端之間交互的基本正確性

 

契約測試解決能解決什麼問題？

 

1. 可使得消費端和提供端之間測試解耦，再也不須要客戶端和服務端聯調才能發現問題
2. 徹底由消費者驅動的方式，消費者須要什麼數據，服務端就給什麼樣的數據，數據契約也是由消費者來定的
3. 測試前移，越早的發現問題，保證後續測試的完整性
4. 經過契約測試，團隊能以一種離線的方式(不須要消費者、提供者同時在線)，經過契約做爲中間的標準，驗證提供者提供的內容是否知足消費者的指望。

 

通常契約測試是在單元測試以後，集成測試以前要進行的，首先在保證各自功能正確的前提下測試消費者和提供者的契約是否相匹配，而後再進一步的測試功能的完備性和整個業務流的正確性。

 

寫在最後

 

本文主要淺顯的介紹了契約測試是什麼以及它的重要性，後續將會繼續介紹契約測試的框架以及相關實踐。

 

做者： Ken Wang

出處： http://www.cnblogs.com/Wolfmanlq/