正如大家所知循诉，最初QA都是手動執(zhí)行測試用例，開發(fā)人員每修改一個版本懂酱，QA就要手動測試一遍竹习，隨著功能的不斷增加，手動測試重復的工作量越來越大列牺。為了解脫QA重復性勞動整陌，提高工作效率，重復執(zhí)行的測試用例被自動化了瞎领。自動化測試讓QA的工作前進了一大步蔓榄。
本文講的端到端集成測試（簡稱集成測試）是指系統(tǒng)集成后的自動化測試，是系統(tǒng)或模塊真實組裝后運行的測試默刚。很多團隊用UI端到端來測系統(tǒng)集成后的行為，這類工具很多逃魄，比如有Selenium webdriver等荤西。端到端的集成測試反饋與修復的周期比較長、運行速度慢，測試運行不穩(wěn)定邪锌，有時隨機失敗勉躺，維護成本也很高。它不像單元測試觅丰，單元測試測具體一個方法或API饵溅，定位準確，采用Mock機制妇萄，運行速度非惩善螅快（毫秒級），又是開發(fā)人員在本地執(zhí)行冠句，反饋修復及時轻掩，成本較低。
于是懦底，我們把絕大部分能在單元測試里覆蓋的用例都放在單元測試覆蓋唇牧，只有單元測試測不了的（比如模塊或API之間連通性），才會通過端到端的集成測試來覆蓋聚唐。此時丐重，測試又前進了一大步。
但是杆查，隨著業(yè)務的不斷拓展扮惦、產(chǎn)品功能不斷增加，系統(tǒng)架構越來越復雜根灯，端對端集成測試的成本越來越高径缅，測試用例也越增越多，集成測試又成了快速驗證的阻塞區(qū)烙肺。在當今持續(xù)集成的開發(fā)模式中纳猪，開發(fā)團隊會頻繁集成，每次集成都會通過流水線（Pipeline）快速驗證桃笙、準備部署包氏堤、進而發(fā)布。然而搏明，集成測試的這些問題會嚴重影響或阻礙產(chǎn)品快速發(fā)布鼠锈。
那么問題來了，怎么解決集成測試的現(xiàn)有問題星著，讓測試再前進一大步购笆？
其實，早在幾年前虚循，著名的敏捷和TDD專家JB Rainsberger就提到了同欠。
“集成測試是個騙局”样傍，正確的是應該用一種契約或協(xié)議測試來測試集成后的系統(tǒng)行為！
JB Rainsberger認為你寫的2-5%的集成測試和單元測試有重復铺遂，或者和其它地方的集成測試存在重復衫哥，而且當集成測試失敗時，你也不知道發(fā)生了什么襟锐，不能及時準確定位問題撤逢。
JB Rainsberger認為應該讓契約測試來替代集成測試，那么粮坞，什么是契約測試蚊荣？它是否能解決集成測試的這些問題？
契約測試
契約測試是驗證服務的Provider是否按照期望的方式與服務的Consumer進行交互捞蚂，簡單的說是Consumer與Provider兩者之間的集成妇押。
而Contract即合同、契約姓迅，就是Provider與Consumer的交互方式敲霍。
契約測試通常是基于Consumer驅(qū)動的（Consumer Driven Contracts，基于Consumer驅(qū)動的契約測試工具有PACT）丁存〖玷荆基于Consumer驅(qū)動的契約測試分兩個階段：
- Consumer生成契約，開發(fā)者在Consumer端寫測試時Mock掉Provider解寝，運行測試生成契約文件扩然；
- Provider驗證契約，開發(fā)者拿契約文件直接在Provider端運行測試進行驗證聋伦。
第一階段：Consumer生成契約
第二階段：Provider驗證契約
如何用PACT編寫契約測試夫偶，這里就不贅述了，實例詳情請參見PACT an example觉增。
集成測試的特點
- 真實安裝后測試兵拢，測試更接近真實使用情況；
- 可見性強逾礁，容易理解说铃；（比如：看一遍運行關鍵業(yè)務的集成測試，業(yè)務人員或客戶會覺得很放心嘹履。也可以替代驗收測試）
- 模塊真實調(diào)用腻扇，測試運行慢，秒級別或分鐘級別砾嫉，反饋與修復的周期慢幼苛，成本高；
- 問題定位難焕刮，多個子模塊組合安裝后的測試蚓峦，很難定位是哪個模塊出的問題舌剂；
- 真實的安裝或環(huán)境搭建，不穩(wěn)定暑椰，容易導致測試隨機失敗荐绝；
- 溝通成本高一汽，需要不同模塊團隊間的協(xié)調(diào)工作；
- 與底層測試或集成測試會有重復低滩，集成測試中有的路徑已經(jīng)被單元測試覆蓋召夹。
契約測試的特點
- 開發(fā)人編寫，采用Mock機制恕沫，開發(fā)本地就可以運行监憎，沒有真實調(diào)用，運行快婶溯，毫秒級修復反饋周期短鲸阔；
- Provider與Consumer兩兩之間的驗證，容易定位問題迄委，而且與底層測試或其它契約之間沒有重復褐筛；
- 不需要部署真實的集成環(huán)境，穩(wěn)定且成功率高叙身；
- 溝通成本低渔扎。(比如一個Consumer端的加入導致服務端API修改，服務端開發(fā)人員不必跑去找所有其它Consumer端開發(fā)人員溝通確認是否會被影響信轿，直接運行契約測試就能知道結(jié)果晃痴。）
由此可見，開篇談到的端到端集成測試運行慢财忽、不穩(wěn)定倘核、修復反饋周期長等等問題，都能通過契約測試得到解決或改進定罢。
舉例說明
假如某社交聊天產(chǎn)品（簡稱TWChat）的架構是這樣的：服務端笤虫、客戶端、郵件通知服務三部分組成祖凫。
架構圖
通常的測試策略：底層絕大部分的單元測試+少量上層端到端集成測試琼蚯。
用TWChat注冊場景來舉例說明吧。注冊一個帳號的工作流是：客戶端把注冊帳號信息提交給服務端惠况，服務端處理帳號時遭庶，會去調(diào)用郵件通知服務發(fā)通知，并完成注冊稠屠。
底層單元測試用例
單元測試
- 客戶端的單元測試：驗證注冊表各個Field的各種輸入組合峦睡、以及檢驗正確性等翎苫；（比如：邊界值、空榨了、中英數(shù)各類組合煎谍、合法與非法輸入等）
- 服務端的單元測試：驗證注冊數(shù)據(jù)表的各種輸入組合可以成功存放于服務端帳號DB表中，且不合法的龙屉、重復等會有相應的錯誤碼呐粘；
- 郵箱通知服務端的單元測試：輸入合法的各類不同的郵箱確，保證能正常發(fā)出通知郵件并返回正確碼转捕，輸入不合法的郵箱或空郵箱確保有相應的錯誤碼作岖。
上層端到端集成測試用例
集成測試
一條注冊連通性的Happy path測試用例, 輸入所有必填項提交，驗證注冊成功五芝，收到成功通知郵件痘儡。
以上的集成測試，必填項輸入其實是與單元測試重復枢步，郵件通知發(fā)送功能與單元測試也有重復沉删；再者，這條集成測試跑失敗价捧，我們并不能定位是客戶端的問題丑念、服務端問題、還是通知服務的問題结蟋。加上集成測試是把所有子模塊（服務端脯倚、客戶端、通知微服務）真實產(chǎn)品安裝包部署以后才能運行的測試嵌屎，反饋推正、修改周期長，不穩(wěn)定容易隨機失敗等等宝惰。
集成測試換成契約測試用例
契約測試
- TWChat客戶端Consumer與TWChat服務端Provider加一條契約測試植榕，確保TWChat服務端按期望提供給客戶端接口(參見PACT an example)。
- TWChat服務端Consumer與郵件通知服務Provider之間加一條契約測試尼夺，確保郵件通知服務按照預期與TWChat服務端交互(參見PACT an example)尊残。
契約測試與單元測試以及其它測試之間沒有重復，它是單純驗證Provider與Consumer之間按預期的方式交互淤堵，定位準確寝衫；不需要部署真實的系統(tǒng)環(huán)境、Mock機制拐邪、沒有真實API調(diào)用慰毅，運行非常快扎阶、反饋及時汹胃、修復周期短婶芭、成本低，在這種情況下着饥，自動化測試流水線運行更快了犀农，產(chǎn)品流水線出產(chǎn)品安裝包也更快。因此宰掉，顯然契約測試才是真正對的選擇井赌。
微服務架構下契約測試的重要性
例如，隨著TWChat業(yè)務的擴大贵扰，TWChat錢包，TWChat安卓端流部，TWChat iOS端戚绕，以及其它的服務方與Consumer方接入TWChat服務器。
當其中TWChat安卓端修改后枝冀，如果還按照之前的集成測試方式舞丛，就得把服務端與所有的客戶端真實的集成到一起測試，確保都沒有被影響才能生成產(chǎn)品安裝包并發(fā)布果漾，這里的集成測試成了流水線（pipeline)的一個聚集地球切，也成為了產(chǎn)品發(fā)布的阻塞區(qū)。
集成測試流水線
假如绒障，換成契約測試吨凑，我們把契約測試放在各自的流水線（pipeline）上，每次代碼提交觸發(fā)相應產(chǎn)品流水線上的契約測試户辱，當TWChat安卓客戶端Consumer API修改鸵钝，在安卓客戶端的流水線（pipeline）上運行安卓客戶端為Consumer與服務端為Provider的契約測試，測試通過庐镐，生成產(chǎn)品安裝包恩商；如果契約測試失敗，服務端需要相應修改必逆，則本次TWChat安卓端的安裝包需要在TWChat服務端修改后怠堪，方可生成安卓客戶端的產(chǎn)品安裝包。
契約測試解耦后
由此可見名眉，并不是每一次TWChat安卓端的修改都要全部Consumer端與服務端集成后驗證才出包粟矿，而是各自可以獨立出包，產(chǎn)品解耦璧针，大大節(jié)省時間嚷炉，提高出包頻率。
并非所有端到端集成測試都適合換成契約測試
契約測試相比端到端集成測試有很多優(yōu)勢探橱，但并不是所有場景都適合契約而非集成測試申屹。
比如：
- 契約測試無法做安全或性能測試等绘证。
- 契約測試采用Mock機制，所以沒有集成測試更接近真實環(huán)境哗讥，也不能給業(yè)務人員做驗收嚷那，可視性差。
- 契約測試基于不同的服務使用的協(xié)議不同杆煞，驗證契約的復雜度會不同魏宽，復雜度過高時，需要權衡是否有必要加契約測試决乎。
所以队询，把端到端集成測試要換成契約測試也不是絕對的，視情況而定构诚。
總的來說蚌斩，當你追加端到端集成測試的時候，如非特殊范嘱，快換契約測試吧送膳。
更多精彩洞見，請關注微信公眾號：思特沃克
