建站
咨詢
售后
建站咨詢
新聞中心
正如大家所知，最初QA都是手動執(zhí)行測試用例，開發(fā)人員每修改一個版本，QA就要手動測試一遍，隨著功能的不斷增加，手動測試重復的工作量越來越大。為了解脫QA重復性勞動，提高工作效率，重復執(zhí)行的測試用例被自動化了。自動化測試讓QA的工作前進了一大步。
成都創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供高縣網(wǎng)站建設、高縣做網(wǎng)站、高縣網(wǎng)站設計、高縣網(wǎng)站制作等企業(yè)網(wǎng)站建設、網(wǎng)頁設計與制作、高縣企業(yè)網(wǎng)站模板建站服務，10年高縣做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡服務。
本文講的端到端集成測試(簡稱集成測試)是指系統(tǒng)集成后的自動化測試，是系統(tǒng)或模塊真實組裝后運行的測試。很多團隊用UI端到端來測系統(tǒng)集成后的行為，這類工具很多，比如有Selenium webdriver等。端到端的集成測試反饋與修復的周期比較長、運行速度慢，測試運行不穩(wěn)定，有時隨機失敗，維護成本也很高。它不像單元測試，單元測試測具體一個方法或API，定位準確，采用Mock機制，運行速度非常快(毫秒級)，又是開發(fā)人員在本地執(zhí)行，反饋修復及時，成本較低。
于是，我們把絕大部分能在單元測試里覆蓋的用例都放在單元測試覆蓋，只有單元測試測不了的(比如模塊或API之間連通性)，才會通過端到端的集成測試來覆蓋。此時，測試又前進了一大步。
但是，隨著業(yè)務的不斷拓展、產(chǎn)品功能不斷增加，系統(tǒng)架構(gòu)越來越復雜，端對端集成測試的成本越來越高，測試用例也越增越多，集成測試又成了快速驗證的阻塞區(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)?；贑onsumer驅(qū)動的契約測試分兩個階段：
- Consumer生成契約，開發(fā)者在Consumer端寫測試時Mock掉Provider，運行測試生成契約文件;
- Provider驗證契約，開發(fā)者拿契約文件直接在Provider端運行測試進行驗證。
第一階段：Consumer生成契約
第二階段：Provider驗證契約
如何用PACT編寫契約測試，這里就不贅述了，實例詳情請參見PACT an example。
集成測試的特點：
- 真實安裝后測試，測試更接近真實使用情況;
- 可見性強，容易理解;(比如：看一遍運行關(guān)鍵業(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)的架構(gòu)是這樣的：服務端、客戶端、郵件通知服務三部分組成。
架構(gòu)圖
通常的測試策略：底層絕大部分的單元測試+少量上層端到端集成測試。
用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)品安裝包也更快。因此，顯然契約測試才是真正對的選擇。
微服務架構(gòu)下契約測試的重要性
例如，隨著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é)議不同，驗證契約的復雜度會不同，復雜度過高時，需要權(quán)衡是否有必要加契約測試。
所以，把端到端集成測試要換成契約測試也不是絕對的，視情況而定。
總的來說，當你追加端到端集成測試的時候，如非特殊，快換契約測試吧。
【本文是專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】
文章名稱：別再加端到端集成測試了，快換契約測試吧
網(wǎng)頁地址：http://m.fisionsoft.com.cn/article/cdgpghi.html
