導(dǎo)讀：微服務(wù)架構(gòu)下，API 測(cè)試的最大挑戰(zhàn)來自于龐大的測(cè)試用例數(shù)量，以及微服務(wù)之間的相互耦合。基于這種挑戰(zhàn)，如何進(jìn)行高效的API測(cè)試，選擇什么樣的方式就比較重要，此文主要是采用契約測(cè)試的方法來對(duì)微服務(wù)模式下的API測(cè)試做簡(jiǎn)要的闡述。

一、背景

集成開放平臺(tái)由1個(gè)云端管理中心+N個(gè)后臺(tái)服務(wù)組成（連接中心、接口中心等），云端管理中心與后臺(tái)服務(wù)存在1對(duì)多的API調(diào)用關(guān)系，而服務(wù)與服務(wù)間也存在多對(duì)多的API調(diào)用關(guān)系。如何高效精準(zhǔn)的保障這些接口調(diào)用穩(wěn)定，結(jié)合行業(yè)內(nèi)接口測(cè)試方法和微服務(wù)模式下的接口測(cè)試，我們總結(jié)了一套集成開放平臺(tái)的API測(cè)試方法：契約測(cè)試。

二、契約測(cè)試與傳統(tǒng)API測(cè)試的不同

2.1 傳統(tǒng)的 API 測(cè)試策略

在傳統(tǒng)的 API 測(cè)試中，我們的測(cè)試策略通常是：

1. 根據(jù)被測(cè) API 輸入?yún)?shù)的各種組合調(diào)用 API，并驗(yàn)證相關(guān)結(jié)果的正確性；
2. 衡量上述測(cè)試過程的代碼覆蓋率；
3. 根據(jù)代碼覆蓋率進(jìn)一步找出遺漏的測(cè)試用例；
4. 以代碼覆蓋率達(dá)標(biāo)作為 API 測(cè)試成功完成的標(biāo)志。

2.2?基于消費(fèi)者契約的 API 測(cè)試（后面簡(jiǎn)稱契約測(cè)試）

而服務(wù)拆分之后，API 接口數(shù)量將成倍增加，此時(shí)需要找到一種既能保證 API 質(zhì)量，又能減少測(cè)試用例數(shù)量的測(cè)試策略。即基于消費(fèi)者契約的 API 測(cè)試。
如下圖，基于消費(fèi)者契約的 API 測(cè)試的核心思想是：只測(cè)試那些真正被實(shí)際使用到的 API 調(diào)用，如果沒有被使用到的，就不去測(cè)試。

看上圖大家可能對(duì)契約測(cè)試還是比較模糊，下面我舉個(gè)實(shí)例進(jìn)行詳細(xì)講解。

案例：連接中心提供了創(chuàng)建連接的API給云端管理中心，我們需要對(duì)創(chuàng)建連接的API進(jìn)行接口測(cè)試。

傳統(tǒng)的接口用例設(shè)計(jì)如下：

2.3 契約測(cè)試的用例設(shè)計(jì)如下：

從上面兩幅圖可以清晰的看出，契約測(cè)試拋棄了異常場(chǎng)景的驗(yàn)證，契約模式下，傳參可定是合法的。

從上面兩幅圖可以清晰的看出。契約測(cè)試做了如下改變：

1.拋棄了異常場(chǎng)景的驗(yàn)證，契約下，傳參肯定是合法的。不需要額外進(jìn)行驗(yàn)證。

2.對(duì)接口提供方的業(yè)務(wù)邏輯做了場(chǎng)景合并處理，不關(guān)注里面的業(yè)務(wù)邏輯，重在驗(yàn)證契約的功能是否正常。

2.4 契約測(cè)試、單元測(cè)試、接口測(cè)試區(qū)別

API測(cè)試和單元測(cè)試，更強(qiáng)調(diào)的是覆蓋API內(nèi)部邏輯。

契約測(cè)試，更強(qiáng)調(diào)是組件之間連接的正確性，除了保證組件內(nèi)部，還要保證組件間的調(diào)用是正確的，也就是服務(wù)API之間的調(diào)用。

單元測(cè)試單元測(cè)試針對(duì)代碼單元（通常是類）的測(cè)試，單元測(cè)試的價(jià)值在于能提供最快的反饋。另外好的單元測(cè)試還可以幫助你改善設(shè)計(jì)，在你的團(tuán)隊(duì)掌握TDD的前提下，單元測(cè)試能輔助重構(gòu)，幫助改善代碼整潔度。

API測(cè)試	API測(cè)試是針對(duì)業(yè)務(wù)接口進(jìn)行的測(cè)試，主要測(cè)內(nèi)部接口功能實(shí)現(xiàn)是否完整，比如說內(nèi)部邏輯是不是正常，異常處理是不是正確。
契約測(cè)試	契約測(cè)試其實(shí)是為了測(cè)試服務(wù)之間連接或者說接口調(diào)用的正確性，為了驗(yàn)證服務(wù)提供者的功能是不是真正能夠滿足消費(fèi)者的需求。它其實(shí)體現(xiàn)了測(cè)試前移的思想，把本來要通過集成測(cè)試才能驗(yàn)證的工作化作單元測(cè)試和接口測(cè)試，用更輕量的方式快速進(jìn)行驗(yàn)證。關(guān)注點(diǎn)是consumer是否可以正確的消費(fèi)provider的API，這里的"消費(fèi)"包括調(diào)用接口和解析數(shù)據(jù)。它的被測(cè)對(duì)象，注意，一定是consumer。
集成測(cè)試	它從用戶的角度驗(yàn)證整個(gè)功能的正確性，測(cè)的是端到端的流程，并且加入用戶場(chǎng)景和數(shù)據(jù)，驗(yàn)證整個(gè)過程是不是OK，它的價(jià)值業(yè)務(wù)價(jià)值最高，是驗(yàn)證一個(gè)完整的流程。

2.5 契約測(cè)試帶來的好處

降低服務(wù)集成的難度，把服務(wù)集成這個(gè)過程分解成了單元測(cè)試和接口測(cè)試來做，它從消費(fèi)者的需求為出發(fā)點(diǎn)，把消費(fèi)者的需求作為你的測(cè)試用例驅(qū)動(dòng)出一份契約，然后驗(yàn)證提供者端的功能。

通過使用契約測(cè)試，接口調(diào)用雙方協(xié)商接口后就可以并行開發(fā)，并且在開發(fā)過程中就利用契約進(jìn)行預(yù)集成測(cè)試，不用等到聯(lián)調(diào)再來集成調(diào)通接口，一旦成熟，在保證質(zhì)量的前提下，聯(lián)調(diào)的成本可以減低到幾乎為0。

三、總結(jié)及適用場(chǎng)景

契約測(cè)試相對(duì)傳統(tǒng)接口測(cè)試來說，很大程度上縮減了測(cè)試場(chǎng)景，使測(cè)試更聚焦于客戶實(shí)際應(yīng)用場(chǎng)景。但是缺點(diǎn)也很明顯，一旦消費(fèi)者毀壞契約進(jìn)行非法的參數(shù)調(diào)用時(shí)，就會(huì)導(dǎo)致生產(chǎn)者出現(xiàn)不可預(yù)知的異常，甚至?xí)?dǎo)致宕機(jī)的發(fā)生。為此我梳理一下適用的場(chǎng)景，請(qǐng)慎重選擇。

場(chǎng)景描述	是否適用
1.微服務(wù)內(nèi)部接口，不對(duì)外開放	√
2.微服務(wù)前后端調(diào)用接口，有指定身份認(rèn)證	√
3.微服務(wù)間相互調(diào)用接口，不對(duì)外開放	√
4.微服務(wù)對(duì)外指定接口，有指定身份認(rèn)證	√
5.微服務(wù)對(duì)外公開接口	×
6.微服務(wù)對(duì)外指定接口，涉及核心業(yè)務(wù)場(chǎng)景	×

------ END ------

作者簡(jiǎn)介

吳同學(xué)：?測(cè)試工程師，目前負(fù)責(zé)集成開放平臺(tái)的測(cè)試工作。

總結(jié)

以上是生活随笔為你收集整理的技术分享 | 微服务模式下如何高效进行API测试的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。