今天我要分享的是關(guān)于接口測(cè)試的內(nèi)容，相信測(cè)試人員對(duì)接口測(cè)試都是不陌生的。在軟件的開發(fā)過(guò)程中，大部分開發(fā)由于種種原因，放棄了單元測(cè)試，那么單接口測(cè)試就可以在一定程度上接近于單元測(cè)試，來(lái)彌補(bǔ)單元測(cè)試的不足，并且接口測(cè)試在一定程度上保障了產(chǎn)品的后端服務(wù)質(zhì)量。

目前有很多的測(cè)試人員在做接口測(cè)試的時(shí)候，只是使用Postman等接口測(cè)試工具來(lái)驗(yàn)證單接口的返回是否符合預(yù)期，但事實(shí)上，完成單接口測(cè)試是遠(yuǎn)遠(yuǎn)不夠的。除了驗(yàn)證單接口的正確性之外，我們還需要通過(guò)多接口測(cè)試去驗(yàn)證SUT（被測(cè)系統(tǒng)）的業(yè)務(wù)邏輯正確性。

接口測(cè)試為什么重要

當(dāng)測(cè)試人員在測(cè)試一個(gè)產(chǎn)品時(shí)，沒(méi)有做接口測(cè)試或者只做了單接口測(cè)試的情況下，產(chǎn)品的后端服務(wù)質(zhì)量是無(wú)法把控的。因?yàn)榻缑鏈y(cè)試是前端的，只有接口測(cè)試和單元測(cè)試才是保障后端服務(wù)質(zhì)量的測(cè)試，但是如果開發(fā)沒(méi)有去做單元測(cè)試的情況下，測(cè)試人員一定要加大接口測(cè)試的比重，來(lái)盡量彌補(bǔ)缺少單元測(cè)試的情況。

如果不去做接口測(cè)試，我們不能保證用戶在使用產(chǎn)品時(shí)發(fā)起的每一次請(qǐng)求都會(huì)返回用戶想要的信息。理論上來(lái)講，界面測(cè)試中的bug也許只是出現(xiàn)在某一客戶端或某一瀏覽器的bug，但是后端的bug是會(huì)體現(xiàn)在所有用戶的客戶端上的，其影響范圍比前端bug要嚴(yán)重地多。

接口測(cè)試是在測(cè)什么

接口測(cè)試通常包含兩部分，單接口測(cè)試和多接口測(cè)試。那么什么是單接口測(cè)試和多接口測(cè)試？

以買咖啡為例，客戶在前臺(tái)點(diǎn)單，并傳輸需要的咖啡參數(shù)，例如：

- 咖啡：冰美式

- 杯型：超大杯

- 備注：無(wú)

當(dāng)輸入這些信息給店員后，店員會(huì)反饋點(diǎn)單成功的信息，這就是單接口的返回符合預(yù)期的情況。

多接口串聯(lián)測(cè)試是什么呢？以同樣的買咖啡為例：

接口1：客戶將這些信息傳遞給店員點(diǎn)單后，店員反饋點(diǎn)單成功。

接口2：點(diǎn)單店員將訂單信息傳輸給咖啡師，咖啡師確認(rèn)收到訂單信息。

接口3：咖啡師開始按照收到的訂單信息制作該咖啡，完成后將咖啡交給取餐區(qū)的店員。

接口4：取餐區(qū)的店員收到咖啡后，發(fā)出取餐提醒。

接口5：客戶收到取餐提醒，拿到相應(yīng)的咖啡。

在接口測(cè)試中，單接口測(cè)試和多接口測(cè)試缺一不可，它們所關(guān)注的點(diǎn)也是不一樣的。單接口測(cè)試關(guān)注單個(gè)接口的正確性，而多接口關(guān)注的是業(yè)務(wù)流程是否是通順的。

為什么接口測(cè)試可以保障后端服務(wù)質(zhì)量

我在多本軟件測(cè)試的書中都曾看到一個(gè)觀點(diǎn)：“一個(gè)產(chǎn)品越早介入測(cè)試越好”。因?yàn)橥ǔＧ闆r下，越早發(fā)現(xiàn)Bug，修復(fù)的成本就越低。而接口測(cè)試就可以使測(cè)試人員更早地對(duì)產(chǎn)品介入測(cè)試。

比起前端頁(yè)面，后端總是更早開發(fā)完成。那么比起前端的界面測(cè)試，我們總是可以更先一步的去做接口測(cè)試。接口測(cè)試是直接測(cè)試后端服務(wù)，那測(cè)試人員就更容易發(fā)現(xiàn)底層Bug。越底層的Bug，影響范圍是越廣的。

接口測(cè)試是一個(gè)技術(shù)知識(shí)和業(yè)務(wù)知識(shí)相結(jié)合的工作，除了測(cè)試技術(shù)之外，我們需要了解業(yè)務(wù)，因?yàn)橹挥辛私鈽I(yè)務(wù)，我們才能驗(yàn)證針對(duì)業(yè)務(wù)流程的多接口串聯(lián)測(cè)試。

在開始接口測(cè)試前，測(cè)試人員會(huì)拿到產(chǎn)品提供的需求文檔和開發(fā)提供的接口文檔。接口文檔詳細(xì)描述了接口的訪問(wèn)方式和參數(shù)。有了這些信息，我們可以開展單接口測(cè)試，來(lái)驗(yàn)證單個(gè)接口的正確性。還是以買咖啡為例：

- 當(dāng)客戶向店員傳輸“超大杯冰美式咖啡”，店員會(huì)反饋點(diǎn)單成功

- 當(dāng)客戶向店員傳輸“大杯珍珠奶茶”，店員會(huì)反饋點(diǎn)單失敗，并會(huì)告知本店沒(méi)有此飲品

也就是說(shuō)，單接口測(cè)試我們不僅要驗(yàn)證輸入正確參數(shù)時(shí)，點(diǎn)單成功，也要驗(yàn)證輸入錯(cuò)誤參數(shù)時(shí)，點(diǎn)單失敗。

當(dāng)測(cè)試人員驗(yàn)證完單個(gè)接口的正確性后，就需要驗(yàn)證SUT業(yè)務(wù)邏輯是否符合預(yù)期。首先測(cè)試人員需要將接口文檔和需求文檔結(jié)合起來(lái)，設(shè)計(jì)符合業(yè)務(wù)邏輯的接口測(cè)試用例，這次例子我們換成線上點(diǎn)單咖啡，已知業(yè)務(wù)邏輯是“客戶App下單咖啡，咖啡師收到訂單并制作咖啡放至取餐區(qū)，客戶取餐”，根據(jù)這個(gè)業(yè)務(wù)邏輯，可能會(huì)有以下流程：

- 客戶下單咖啡成功，咖啡師收到訂單并制作咖啡放至取餐區(qū)，客戶取餐成功

- 客戶下單咖啡成功，咖啡師收到訂單并制作咖啡放至取餐區(qū)，客戶誤取餐

- 客戶下單咖啡成功，咖啡師收到訂單并制作咖啡放至取餐區(qū)，客戶未取餐

- 。。。。。

一定會(huì)有小伙伴好奇，為什么不同情況只在客戶取餐環(huán)節(jié)，中間的異常情況呢？比如說(shuō)客戶下單咖啡失敗？客戶下單咖啡成功但是咖啡師未收到訂單？等等，這些情況在單接口測(cè)試的時(shí)候應(yīng)該已經(jīng)驗(yàn)證過(guò)了。

SUT的業(yè)務(wù)邏輯性驗(yàn)證的前提，是單接口測(cè)試的返回值全部都是符合預(yù)期的。只有這樣，我們才能串聯(lián)多個(gè)接口去驗(yàn)證SUT的業(yè)務(wù)邏輯。

以上就是今天我要分享的內(nèi)容。