什么是接口?

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

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

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

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

它是方法與方法之間焦匈，模塊與模塊之間的交互，也是程序內(nèi)部拋出的接口昵仅。比如一個web項目缓熟，有登錄、新增摔笤，修改够滑，刪除等等，那么這幾個模塊會有交互吕世，會拋出一個接口彰触，供內(nèi)部系統(tǒng)進行調(diào)用。

接口的組成

一個完整的接口應(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一般存放的是一些校驗信息比如cookie毡们，它是為了校驗這個請求是否有權(quán)限請求服務(wù)器迅皇。如果有權(quán)限它才能請求服務(wù)器，然后把請求地址連同入?yún)⒁黄鸢l(fā)送到服務(wù)器衙熔，然后服務(wù)器會根據(jù)地址和入?yún)矸祷爻鰠⒌峭恰Ｒ簿褪钦f，服務(wù)器是先接受header信息進行判斷該請求是否有權(quán)限請求红氯，判斷有權(quán)限后框咙，才會接受請求地址和入?yún)ⅰ?/p>

常見的接口類型

1、webService接口

它使用soap協(xié)議并通過http傳輸痢甘，請求報文和返回報文都是xml格式的喇嘱，我們在測試的時候通過工具才能進行調(diào)用∪ぃ可以使用的工具有SoapUI者铜、jmeter。

2放椰、http-api接口

它使用http協(xié)議作烟，通過路徑來區(qū)分調(diào)用的方法，請求報文都是key-value形式的砾医，返回報文一般都是json串拿撩，有g(shù)et和post等方法，這也是最常用的兩種請求方式如蚜⊙购悖可以使用的工具有postman、jmeter等错邦。

前端和后端

前端

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

后端

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

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

接口測試定義

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

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

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

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

接口測試意義

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

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

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

接口測試的價值

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

測試應(yīng)該更早的介入到項目開發(fā)中箍鼓，因為越早的發(fā)現(xiàn) bug崭参，修復(fù)的成本越低。然而功能測試必須要等到系統(tǒng)提供可測試的界面才能對系統(tǒng)進行測試款咖。而接口測試可以功能界面開發(fā)出來之前對系統(tǒng)進行測試何暮。系統(tǒng)接口是上層功能的基礎(chǔ)，接口測試可以更早更低成本的發(fā)現(xiàn)和解決問題铐殃。然而海洼，在實際的開發(fā)過程中，開發(fā)人員并沒有充足的時間去編寫單元測試背稼，并且他們往往對自己編寫的代碼迷之自信贰军，不愿意花時間在編寫單元測試上。這個時候接口測試的作用就會變得更加重要蟹肘。

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

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

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

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

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

通常把前端的驗證稱為弱驗證，因為它很容易被繞過巢掺，這個時候如果只站在功能的層面進行測試句伶，就很難發(fā)現(xiàn)一些安全的問題。不以功能為入口的接口測試就會很容易的驗證這些異常情況陆淀。

常見請求

GET和POST請求

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

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

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

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

3重罪、POST比GET安全樱哼，因為數(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)限未進行校驗蝇更，可以訪問其他用戶敏感信息沪编；

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

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

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

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

2. 接口前置的檢查

3. 接口邏輯實現(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ù)依賴性檢查

接口測試流程

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

需求確定以后况脆，開發(fā)會根據(jù)需求進行接口設(shè)計饭宾，會給出接口定義。在開發(fā)設(shè)計過程中格了，測試可以給出一些針對設(shè)計的建議看铆，提高可測性，針對需求及設(shè)計笆搓，指定測試計劃性湿。

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

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

在項目結(jié)束后报咳，需要對每個項目進行總結(jié)侠讯。

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

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

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

1xx（臨時響應(yīng)）表示臨時響應(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 （重定向）表示要完成請求绰沥，需要進一步操作。通常贺待，這些狀態(tài)代碼用來重定向

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

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

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

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

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

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

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

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

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

401（未授權(quá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（請求超時）服務(wù)器等候請求時發(fā)生超時。

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

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

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

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

413（請求實體過大）服務(wù)器無法處理請求馋袜，因為請求實體過大男旗，超出服務(wù)器的處理能力。

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

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

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

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

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

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

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

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

503（服務(wù)不可用）服務(wù)器目前無法使用（由于超載或停機維護）咐吼。通常炭臭，這只是暫時狀態(tài)蓬网。

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

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

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

接口用例設(shè)計

一個接口通常是有輸入輸出的秒咨，輸入就是我們常見的入?yún)⑻懊恚敵鰟t時有時無糯耍。調(diào)用相關(guān)接口抓半，接口會執(zhí)行相關(guān)處理邏輯喂急。

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

1）針對輸入笛求，可按照參數(shù)類型進行設(shè)計廊移；

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

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

針對輸入設(shè)計

對于接口來說，輸入就是入?yún)⒎渌浴３Ｒ妳?shù)類型有:

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

（2）字符串類型

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

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

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

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

超長字符未進行處理苗膝，導(dǎo)致存儲、顯示等異常

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

數(shù)組或鏈表類型

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

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

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

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

特殊值：0個胖喳；

合法ID和不合法的泡躯；

重復(fù)的ID等。

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

0個item時程序異常退出丽焊；

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

針對邏輯設(shè)計

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

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

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

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

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

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

針對輸出設(shè)計

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

輸出結(jié)果

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

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

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

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

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

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

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

（1）未進行超時處理谈飒，導(dǎo)致整個流程阻塞

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

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

已廢棄協(xié)議态蒂，是指之前有定義杭措，但是因為需求變更或其他原因，暫時不用钾恢。這些接口雖然不再使用手素，但有可能代碼并沒有及時刪除鸳址。如果利用技術(shù)手段調(diào)用這些接口，可能產(chǎn)生風(fēng)險泉懦。因此新版本在考慮兼容舊版本的同時稿黍，還應(yīng)做好相關(guān)廢棄接口的檢查，避免風(fēng)險祠斧。

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

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

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

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

（2）接口是否冗余辕漂；

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

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

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