什么是接口?

一般來說接口有兩種，一種是程序內(nèi)部的接口，一種是系統(tǒng)對外的接口。廣義來說，客戶端與后臺(tái)服務(wù)間的協(xié)議；插件間通信的接口；模塊間的接口；再小到一個(gè)類提供的方法；都可以理解為接口。

系統(tǒng)對外的接口：

如果我們要從網(wǎng)站或服務(wù)器上獲取資源或信息，網(wǎng)站肯定不會(huì)把數(shù)據(jù)庫共享給你，它只會(huì)給你提供一個(gè)寫好的方法來獲取數(shù)據(jù)，我們通過引用它提供的接口就能獲取數(shù)據(jù)。

程序內(nèi)部的接口：

它是方法與方法之間，模塊與模塊之間的交互，也是程序內(nèi)部拋出的接口。比如一個(gè)web項(xiàng)目，有登錄、新增，修改，刪除等等，那么這幾個(gè)模塊會(huì)有交互，會(huì)拋出一個(gè)接口，供內(nèi)部系統(tǒng)進(jìn)行調(diào)用。

接口的組成

一個(gè)完整的接口應(yīng)該包含以下內(nèi)容：

1. 接口說明

2. 調(diào)用的url

3. 請求方法（get\post）

4. 請求參數(shù)、參數(shù)類型、請求參數(shù)說明

5. 返回參數(shù)說明

接口至少應(yīng)有請求地址、請求方法、請求參數(shù)（入?yún)⒑统鰠ⅲ?，部分接口有請求頭header。header是服務(wù)器以HTTP協(xié)議傳HTML資料到瀏覽器前所送出的字串，一般存放cookie、token等信息。

header和入?yún)⑹怯袇^(qū)別的。header一般存放的是一些校驗(yàn)信息比如cookie，它是為了校驗(yàn)這個(gè)請求是否有權(quán)限請求服務(wù)器。如果有權(quán)限它才能請求服務(wù)器，然后把請求地址連同入?yún)⒁黄鸢l(fā)送到服務(wù)器，然后服務(wù)器會(huì)根據(jù)地址和入?yún)矸祷爻鰠?。也就是說，服務(wù)器是先接受header信息進(jìn)行判斷該請求是否有權(quán)限請求，判斷有權(quán)限后，才會(huì)接受請求地址和入?yún)ⅰ?/p>

常見的接口類型

1、webService接口

它使用soap協(xié)議并通過http傳輸，請求報(bào)文和返回報(bào)文都是xml格式的，我們在測試的時(shí)候通過工具才能進(jìn)行調(diào)用?？梢允褂玫墓ぞ哂蠸oapUI、jmeter。

2、http-api接口

它使用http協(xié)議，通過路徑來區(qū)分調(diào)用的方法，請求報(bào)文都是key-value形式的，返回報(bào)文一般都是json串，有g(shù)et和post等方法，這也是最常用的兩種請求方式?？梢允褂玫墓ぞ哂衟ostman、jmeter等。

前端和后端

前端

咱們使用的網(wǎng)頁，打開的網(wǎng)站，都是前端。包括Web頁面的結(jié)構(gòu)、Web的外觀視覺表現(xiàn)以及Web層面的交互實(shí)現(xiàn)；

后端

我們在頁面上進(jìn)行操作的時(shí)候，這些業(yè)務(wù)邏輯、功能，比如說新增，修改，刪除這些功能是由后端來實(shí)現(xiàn)的。后端更多的是與數(shù)據(jù)庫進(jìn)行交互去處理相應(yīng)的業(yè)務(wù)邏輯。需要考慮的是如何實(shí)現(xiàn)功能、數(shù)據(jù)的存取、平臺(tái)的穩(wěn)定性與性能等。

前端和后端通過接口進(jìn)行交互。前端頁面通過調(diào)用后端接口來實(shí)現(xiàn)功能、數(shù)據(jù)的存取，將數(shù)據(jù)展現(xiàn)在用戶面前。

接口測試定義

1、接口測試是測試系統(tǒng)組件之間接口的一種測試方法

2、它用于檢測外部系統(tǒng)與系統(tǒng)之間以及系統(tǒng)內(nèi)部各個(gè)子系統(tǒng)之間的交互

3、重點(diǎn)是要檢查數(shù)據(jù)的交換，以及系統(tǒng)間的相互邏輯依賴關(guān)系等

4、接口測試就是通過測試不同情況下的入?yún)⑴c之相應(yīng)的出參信息來判斷接口是否符合或滿足相應(yīng)的功能性、安全性要求。

接口測試意義

1、系統(tǒng)復(fù)雜度不斷上升，傳統(tǒng)的測試方法成本急劇增加且測試效率大幅下降，所以要做接口測試。

2、接口測試相對容易實(shí)現(xiàn)。且接口自動(dòng)化相對UI自動(dòng)化也較穩(wěn)定。減少人工回歸測試人力成本與時(shí)間，縮短測試周期，支持快速迭代。

3、由于很多系統(tǒng)前后端是分離的，所以從安全層面來說，只依賴前端進(jìn)行限制已經(jīng)完全不能滿足系統(tǒng)的安全要求（繞過前端很容易）， 需要后端也進(jìn)行校驗(yàn)，在這種情況下就需要從接口層面進(jìn)行驗(yàn)證。前后端傳輸、日志打印等信息是否加密傳輸也是需要驗(yàn)證的，特別是涉及到用戶的隱私信息，如錢，身份信息等。

接口測試的價(jià)值

1、更早發(fā)現(xiàn)問題

測試應(yīng)該更早的介入到項(xiàng)目開發(fā)中，因?yàn)樵皆绲陌l(fā)現(xiàn) bug，修復(fù)的成本越低。然而功能測試必須要等到系統(tǒng)提供可測試的界面才能對系統(tǒng)進(jìn)行測試。而接口測試可以功能界面開發(fā)出來之前對系統(tǒng)進(jìn)行測試。系統(tǒng)接口是上層功能的基礎(chǔ)，接口測試可以更早更低成本的發(fā)現(xiàn)和解決問題。然而，在實(shí)際的開發(fā)過程中，開發(fā)人員并沒有充足的時(shí)間去編寫單元測試，并且他們往往對自己編寫的代碼迷之自信，不愿意花時(shí)間在編寫單元測試上。這個(gè)時(shí)候接口測試的作用就會(huì)變得更加重要。

2、縮短產(chǎn)品研發(fā)周期

對于產(chǎn)品研發(fā)周期來說，如果將所有測試工作都集中在功能測試階段。那么測試的問題和修復(fù)周期就會(huì)變長。因?yàn)闇y試可以更早的介入產(chǎn)品開發(fā)中，所以，可以有效的控制功能階段 bug的數(shù)量；從而有效的縮短產(chǎn)品開發(fā)周期。

3、發(fā)現(xiàn)更底層的問題

系統(tǒng)的有些底層邏輯是在UI功能測試中不太容易觸發(fā)的，那么這些邏輯可能會(huì)存在問題。接口測試可以更容易更全面的測試到這些底層的邏輯。

4、檢查服務(wù)器的異常處理能力

通常把前端的驗(yàn)證稱為弱驗(yàn)證，因?yàn)樗苋菀妆焕@過，這個(gè)時(shí)候如果只站在功能的層面進(jìn)行測試，就很難發(fā)現(xiàn)一些安全的問題。不以功能為入口的接口測試就會(huì)很容易的驗(yàn)證這些異常情況。

常見請求

GET和POST請求

如果是get請求的話，直接在瀏覽器里輸入就可以，只要在瀏覽器里面直接能請求到的，都是get請求，如果是post的請求的話就得借助工具來發(fā)送。

GET請求和POST的區(qū)別

1、GET使用URL或Cookie傳參。而POST將數(shù)據(jù)放在BODY中。

2、GET的URL會(huì)有長度上的限制，則POST的數(shù)據(jù)則可以非常大。

3、POST比GET安全，因?yàn)閿?shù)據(jù)在地址欄上不可見。

4、一般get請求用來獲取數(shù)據(jù)，post請求用來發(fā)送數(shù)據(jù)

常見問題：

（1）傳入?yún)?shù)處理不當(dāng)，導(dǎo)致程序異常；?

（2）類型溢出，導(dǎo)致數(shù)據(jù)讀出和寫入不一致；

（3）因?qū)ο髾?quán)限未進(jìn)行校驗(yàn)，可以訪問其他用戶敏感信息；

（4）狀態(tài)處理不當(dāng)，導(dǎo)致邏輯出現(xiàn)錯(cuò)亂；

（5）邏輯校驗(yàn)不完善，可利用漏洞獲取非正當(dāng)利益等

接口測試場景設(shè)計(jì)

1. 接口文檔的規(guī)范性檢查

2. 接口前置的檢查

3. 接口邏輯實(shí)現(xiàn)功能的檢查

4. 請求參數(shù)合法性的檢查

5. 請求參數(shù)屬性的檢查

6. 請求參數(shù)異常處理的檢查

7. 響應(yīng)體的結(jié)構(gòu)性檢查

8. 響應(yīng)數(shù)據(jù)的正確性檢查

9. 異常響應(yīng)的檢查

10. 響應(yīng)圖片的檢查

11. 對舊版本的兼容性檢查

12. 業(yè)務(wù)邏輯中的角色權(quán)限檢查

13. 業(yè)務(wù)邏輯中的參數(shù)依賴性檢查

接口測試流程

接口測試的流程其實(shí)和功能測試的流程類似，它依賴的主要對象是需求說明書，所以，最初流程是參與需求評審。

需求確定以后，開發(fā)會(huì)根據(jù)需求進(jìn)行接口設(shè)計(jì)，會(huì)給出接口定義。在開發(fā)設(shè)計(jì)過程中，測試可以給出一些針對設(shè)計(jì)的建議，提高可測性，針對需求及設(shè)計(jì)，指定測試計(jì)劃。

在開發(fā)完成接口定義之后，需要根據(jù)需求文檔及接口定義設(shè)計(jì)測試用例與導(dǎo)圖。測試用例設(shè)計(jì)主要從業(yè)務(wù)場景，功能，以及異常測試幾個(gè)方面考慮。

測試用例設(shè)計(jì)完成后，針對測試用例進(jìn)行評審。測試人員可以提前介入開發(fā)的接口聯(lián)調(diào)階段。

在項(xiàng)目結(jié)束后，需要對每個(gè)項(xiàng)目進(jìn)行總結(jié)。

接口響應(yīng)狀態(tài)碼

http請求狀態(tài)碼詳細(xì)

使用ASP.NET/PHP/JSP 或者javascript都會(huì)用到http的不同狀態(tài)，一些常見的狀態(tài)碼為：200 – 服務(wù)器成功返回網(wǎng)頁 404 – 請求的網(wǎng)頁不存在 503 – 服務(wù)不可用。

1xx（臨時(shí)響應(yīng)）表示臨時(shí)響應(yīng)并需要請求者繼續(xù)執(zhí)行操作的狀態(tài)代碼

100（繼續(xù)）請求者應(yīng)當(dāng)繼續(xù)提出請求。服務(wù)器返回此代碼表示已收到請求的第一部分，正在等待其余部分。

101（切換協(xié)議）請求者已要求服務(wù)器切換協(xié)議，服務(wù)器已確認(rèn)并準(zhǔn)備切換。

2xx （成功）表示成功處理了請求的狀態(tài)代碼

200（成功）服務(wù)器已成功處理了請求。通常，這表示服務(wù)器提供了請求的網(wǎng)頁。

201（已創(chuàng)建）請求成功并且服務(wù)器創(chuàng)建了新的資源。

202（已接受）服務(wù)器已接受請求，但尚未處理。

203（非授權(quán)信息）服務(wù)器已成功處理了請求，但返回的信息可能來自另一來源。

204（無內(nèi)容）服務(wù)器成功處理了請求，但沒有返回任何內(nèi)容。

205（重置內(nèi)容）服務(wù)器成功處理了請求，但沒有返回任何內(nèi)容。

206（部分內(nèi)容）服務(wù)器成功處理了部分 GET 請求。

3xx （重定向）表示要完成請求，需要進(jìn)一步操作。通常，這些狀態(tài)代碼用來重定向

300（多種選擇）針對請求，服務(wù)器可執(zhí)行多種操作。服務(wù)器可根據(jù)請求者 (user agent) 選擇一項(xiàng)操作，或提供操作列表供請求者選擇。

301（永久移動(dòng)）請求的網(wǎng)頁已永久移動(dòng)到新位置。服務(wù)器返回此響應(yīng)（對 GET 或 HEAD 請求的響應(yīng)）時(shí)，會(huì)自動(dòng)將請求者轉(zhuǎn)到新位置。

302（臨時(shí)移動(dòng)）服務(wù)器目前從不同位置的網(wǎng)頁響應(yīng)請求，但請求者應(yīng)繼續(xù)使用原有位置來進(jìn)行以后的請求。

303（查看其他位置）請求者應(yīng)當(dāng)對不同的位置使用單獨(dú)的 GET 請求來檢索響應(yīng)時(shí)，服務(wù)器返回此代碼。

304（未修改）自從上次請求后，請求的網(wǎng)頁未修改過。服務(wù)器返回此響應(yīng)時(shí)，不會(huì)返回網(wǎng)頁內(nèi)容。

305（使用代理）請求者只能使用代理訪問請求的網(wǎng)頁。如果服務(wù)器返回此響應(yīng)，還表示請求者應(yīng)使用代理。

307（臨時(shí)重定向）服務(wù)器目前從不同位置的網(wǎng)頁響應(yīng)請求，但請求者應(yīng)繼續(xù)使用原有位置來進(jìn)行以后的請求。

4xx（請求錯(cuò)誤）這些狀態(tài)代碼表示請求可能出錯(cuò)，妨礙了服務(wù)器的處理

400（錯(cuò)誤請求）服務(wù)器不理解請求的語法。

401（未授權(quán)）請求要求身份驗(yàn)證。對于需要登錄的網(wǎng)頁，服務(wù)器可能返回此響應(yīng)。

403（禁止）服務(wù)器拒絕請求。

404（未找到）服務(wù)器找不到請求的網(wǎng)頁。

405（方法禁用）禁用請求中指定的方法。

406（不接受）無法使用請求的內(nèi)容特性響應(yīng)請求的網(wǎng)頁。

407（需要代理授權(quán)）此狀態(tài)代碼與 401（未授權(quán)）類似，但指定請求者應(yīng)當(dāng)授權(quán)使用代理。

408（請求超時(shí)）服務(wù)器等候請求時(shí)發(fā)生超時(shí)。

409（沖突）服務(wù)器在完成請求時(shí)發(fā)生沖突。服務(wù)器必須在響應(yīng)中包含有關(guān)沖突的信息。

410（已刪除）如果請求的資源已永久刪除，服務(wù)器就會(huì)返回此響應(yīng)。

411（需要有效長度）服務(wù)器不接受不含有效內(nèi)容長度標(biāo)頭字段的請求。

412（未滿足前提條件）服務(wù)器未滿足請求者在請求中設(shè)置的其中一個(gè)前提條件。

413（請求實(shí)體過大）服務(wù)器無法處理請求，因?yàn)檎埱髮?shí)體過大，超出服務(wù)器的處理能力。

414（請求的 URI 過長）請求的 URI（通常為網(wǎng)址）過長，服務(wù)器無法處理。

415（不支持的媒體類型）請求的格式不受請求頁面的支持。

416（請求范圍不符合要求）如果頁面無法提供請求的范圍，則服務(wù)器會(huì)返回此狀態(tài)代碼。

417（未滿足期望值）服務(wù)器未滿足”期望”請求標(biāo)頭字段的要求。

5xx（服務(wù)器錯(cuò)誤）這些狀態(tài)代碼表示服務(wù)器在嘗試處理請求時(shí)發(fā)生內(nèi)部錯(cuò)誤。這些錯(cuò)誤可能是服務(wù)器本身的錯(cuò)誤

500（服務(wù)器內(nèi)部錯(cuò)誤）服務(wù)器遇到錯(cuò)誤，無法完成請求。

501（尚未實(shí)施）服務(wù)器不具備完成請求的功能。例如，服務(wù)器無法識別請求方法時(shí)可能會(huì)返回此代碼。

502（錯(cuò)誤網(wǎng)關(guān)）服務(wù)器作為網(wǎng)關(guān)或代理，從上游服務(wù)器收到無效響應(yīng)。

503（服務(wù)不可用）服務(wù)器目前無法使用（由于超載或停機(jī)維護(hù)）。通常，這只是暫時(shí)狀態(tài)。

504 （網(wǎng)關(guān)超時(shí)）服務(wù)器作為網(wǎng)關(guān)或代理，但是沒有及時(shí)從上游服務(wù)器收到請求。

505（HTTP 版本不受支持）服務(wù)器不支持請求中所用的 HTTP 協(xié)議版本。

511 Network Authentication Required (要求網(wǎng)絡(luò)認(rèn)證)

接口用例設(shè)計(jì)

一個(gè)接口通常是有輸入輸出的，輸入就是我們常見的入?yún)?，輸出則時(shí)有時(shí)無。調(diào)用相關(guān)接口，接口會(huì)執(zhí)行相關(guān)處理邏輯。

接口測試的用例設(shè)計(jì)，主要從輸入和接口處理兩方面考慮：

1）針對輸入，可按照參數(shù)類型進(jìn)行設(shè)計(jì)；

2）針對接口處理，可按照邏輯進(jìn)行用例設(shè)計(jì)；

3）針對輸出，可根據(jù)結(jié)果進(jìn)行分析設(shè)計(jì)

針對輸入設(shè)計(jì)

對于接口來說，輸入就是入?yún)?。常見參?shù)類型有:

（1）數(shù)值型(int,long,float,double等）

（2）字符串類型

（3）數(shù)組或鏈表

（4）結(jié)構(gòu)體

可能出現(xiàn)的問題和風(fēng)險(xiǎn)

傳入非特定類型程序異常退出

超長字符未進(jìn)行處理，導(dǎo)致存儲(chǔ)、顯示等異常

其他用戶可見設(shè)置的敏感字

數(shù)組或鏈表類型

參數(shù)類型為數(shù)組或鏈表時(shí)，用例可以考慮

例如批量提交任務(wù)的接口，參數(shù)用例設(shè)計(jì)考慮：

正常取值：1-5個(gè)權(quán)限，范圍外：6個(gè)權(quán)限；

邊界值：1-35的邊界值，請求允許最大最小值；

特殊值：0個(gè)；

合法ID和不合法的；

重復(fù)的ID等。

可能存在的問題和風(fēng)險(xiǎn)：

0個(gè)item時(shí)程序異常退出；

重復(fù)的item處理時(shí)未去重導(dǎo)致結(jié)果異常等。

針對邏輯設(shè)計(jì)

接口需要進(jìn)行一些邏輯處理的，那么按邏輯設(shè)計(jì)用例可以從以下幾個(gè)角度分析：

（1）數(shù)值限制、分?jǐn)?shù)限制、等級限制等等。例如：兌換Q幣活動(dòng)要求積分>50才可參與

（2）狀態(tài)限制：登錄狀態(tài)等例如：同步用戶信息需要先登錄賬號。

（3）權(quán)限限制：管理員等。

約束條件的測試在功能測試中經(jīng)常遇到，在接口測試中更為重要。它的意義在于：用戶進(jìn)行操作時(shí)，在該操作的前端可以已經(jīng)進(jìn)行了約束條件的限制，故用戶無法直接觸發(fā)請求該接口。但是實(shí)際上，如果有其他手段：例如通過技術(shù)手段直接調(diào)用接口，那么接口是否針對這些條件進(jìn)行了限制就尤為重要。

例如常見的例子：要兌換5Q幣需要200積分，但是我積分不足，所以兌換按鈕是灰色無法點(diǎn)擊的狀態(tài)。但是我是否可以繞過前端直接調(diào)用接口去兌換？預(yù)期當(dāng)然是不能兌換的。因此積分這個(gè)數(shù)值限制就需要針對接口進(jìn)行測試，并且非常重要。

針對輸出設(shè)計(jì)

針對輸出設(shè)計(jì)其實(shí)是針對接口返回的結(jié)果進(jìn)行分析：

輸出結(jié)果

接口處理正確的結(jié)果可能只有一個(gè)，但是錯(cuò)誤異常返回結(jié)果有很多情況很多值。如果知道返回結(jié)果有很多種，就可以針對不同結(jié)果設(shè)計(jì)用例。我們不一定能完全覆蓋所有錯(cuò)誤碼，但是根據(jù)接口返回定義的返回碼可以設(shè)計(jì)更多用例。

常見問題和風(fēng)險(xiǎn)

（1）錯(cuò)誤前端處理不足，導(dǎo)致前端異常；

（2）錯(cuò)誤提示處理不當(dāng)，導(dǎo)致用戶看到晦澀的錯(cuò)誤碼；

（3）錯(cuò)誤提示不當(dāng)，導(dǎo)致用戶不知道哪里出了問題，如何解決。

針對接口超時(shí)設(shè)計(jì)

接口正常情況下是有返回的，那么如果接口不返回呢？也就是說接口超時(shí)后的處理也是測試需要考慮的部分。如果超時(shí)處理不當(dāng)，可能會(huì)引起以下問題：

（1）未進(jìn)行超時(shí)處理，導(dǎo)致整個(gè)流程阻塞

（2）超時(shí)后又收到接口返回，導(dǎo)致邏輯出現(xiàn)錯(cuò)亂

針對廢棄接口設(shè)計(jì)

已廢棄協(xié)議，是指之前有定義，但是因?yàn)樾枨笞兏蚱渌颍瑫簳r(shí)不用。這些接口雖然不再使用，但有可能代碼并沒有及時(shí)刪除。如果利用技術(shù)手段調(diào)用這些接口，可能產(chǎn)生風(fēng)險(xiǎn)。因此新版本在考慮兼容舊版本的同時(shí)，還應(yīng)做好相關(guān)廢棄接口的檢查，避免風(fēng)險(xiǎn)。

常見的問題和風(fēng)險(xiǎn)：約束條件判斷不足，導(dǎo)致用戶可通過特殊手段獲取利益。

針對接口合理性設(shè)計(jì)

接口定義是否合理可以從以下幾個(gè)方面分析：

（1）接口字段是否冗余；

（2）接口是否冗余；

（3）接口是否返回了調(diào)用方期望得到的信息；

（4）接口定義是否可滿足所有調(diào)用需求；

（5）接口定義調(diào)用是否方便。