最近在面試，都會問接口測試相關的問題，做個整理，希望幫到求職的小伙伴。

部分內容源于：http://www.rzrgm.cn/linyu51/p/14277533.html（侵刪）

還有部分內容從抖音、嗶哩嗶哩整理所得，侵刪。

一、你們公司是如何做接口測試的？

答案1：

　　1.獲取接口文檔，熟悉單接口 以及鏈路接口（接口業務流程）的業務，包括：接口地址、鑒權方式、入參、出參、錯誤碼等。

　　2.編寫接口測試用例并評審？

　　　　正例：1-2個，單接口返回成功場景，鏈路接口業務流程實現（功能業務流程）

　　　　反例：

　　　　　　鑒權異常：空、錯誤、過期

　　　　　　參數異常：空、類型異常、長度異常

　　　　　　錯誤碼異常：接口文檔中會給出錯誤碼

　　　　　　其他異常：接口黑名單、接口調用次數現在（分頁，少于0, =0， 中間頁，最大頁，超過最大頁）

　  3.使用接口測試工具或代碼的方式執行接口測試，重要考慮的情況：接口關聯、接口加密、接口參數是否簽名、是否需要帶請求頭等

     4.實現持續集成并輸出接口測試的電子郵件，有bug 提bug。

　

如下是是一個標準的接口文檔示例，有詳細的錯誤碼說明：https://pay.weixin.qq.com/wiki/doc/apiv3/apis/chapter3_2_1.shtml

 

答案2：

　　接口測試實際跟一般測試不同就是測試用例的設計部分。
　　①獲取接口規范。
　　②設計接口測試功能用例（主要從用戶角度出發看接口能否實現業務需求，用例設計就是黑盒用例那一套）。
　　③各種入參驗證（正常情況，異常情況包括輸入參數個數不對，類型不對，可選/必選，還有考慮參數有互斥或關聯的情況）。
　　④接口返回值各種驗證（符合接口文檔需求）
　　⑤了解接口實現邏輯，實現邏輯覆蓋（語句/條件/分支/判定/…）
　　⑥接口能并發執行嗎、安全嗎，性能滿足要求嗎?
　　⑦采用工具或者自寫代碼來驗證。
　　⑧發現問題跟功能測試一樣，該報bug報bug，該跟蹤狀態的跟蹤狀態。

 

答案1 是之前在bili上 刷的面試題，給出的答案，答案2 是博客園的這個小伙伴分享的.我覺得都OK。

　　

二、設計接口測試用例的思路？

通常，設計接口測試用例需要考慮以下幾個方面：
　　①是否滿足前提條件
　　　　有些接口需要滿足前提，才可成功獲取數據。常見的，需要登錄Token
　　　　逆向用例：針對是否滿足前置條件（假設為n個條件），設計0~n條用例
　　②是否攜帶默認值參數
　　　　正向用例：帶默認值的參數都不填寫、不傳參，必填參數都填寫正確且存在的“常規”值，其他不填寫，設計1條用例
　　③業務規則、功能需求
　　　　這里根據時間情況，結合接口參數說明，可能需要設計N條正向用例和逆向用例
　　④參數是否必填
　　　　逆向用例：針對每個必填參數，都設計1條參數值為空的逆向用例
　　⑤參數之間是否存在關聯
　　　　有些參數彼此之間存在相互制約的關系
　　⑥參數數據類型限制
　　　　逆向用例：針對每個參數都設計1條參數值類型不符的逆向用例
　　⑦參數數據類型自身的數據范圍值限制
　　　　正向用例：針對所有參數，設計1條每個參數的參數值在數據范圍內為最大值的正向用例

此題來源：http://www.rzrgm.cn/linyu51/p/14277533.html

我的回答：

　　　　1.通過會議確定接口測試用例的顆粒度

　　　　2.根據顆粒度的大小設計用例，顆粒度大的話，一個接口可設計7-8個，正例 2-3條 反例 5條左右，主要是對入參的一些校驗，如默認值、必填、選填、字段類型等等，一般還根據開發文檔上的異常碼，去造相關的數據。

 

三、你平常做接口測試的過程中發現過哪些bug?

答案1：

　　面試官出這個題，主要是想知道你是不是真的做過接口測試，畢竟現在很多小伙伴簡歷經過包裝（不包裝連面試機會都沒有，沒辦法，為了生存，能理解）
答：
　　常規錯誤，接口沒實現，沒按約定返回結果，邊界值處理出錯等。
　　輸入異常值（空值、特殊字符、超過約定長度等），接口拋錯，沒做封裝處理；
　　輸入錯誤的參數、多輸入、少輸入參數，接口可能出現的錯誤；
　　安全性問題，如明文傳輸、返回結果含有敏感信息，沒對用戶身份信息做校驗，沒做惡意請求攔截等；
　　性能問題，如接口并發插入多條相同操作，響應時間過長，接口壓測出現瓶頸等；

答案2：　

　　常規bug：接口沒有安裝文檔說明返回結果，輸入異常類（空值、特殊字符），接口報錯，沒有返回合理的提示

　　　　　　如 商品價格 修改為-3

　　權限bug:

　　　　　　測試修改服務包商品信息接口，接口文檔要求只有超級管理員才有權限修改，我傳入一個普通人員的人員ID 和角色編碼，都能修改成功。

　　接口測試就是為了避免繞過前端測試，直接訪問后端接口的BUG。

 

答案1(博客園)和答案2(bilibili)結合起來更好。

 

四、你做接口測試，測什么？

• 可用性測試　　根據約定的協議、方法、格式內容，傳輸數據到接口經處理后返回期望的結果：

　　　　接口功能是否正確實現；
　　　　返回值測試 - 返回值除了內容要正確，類型也要正確，保證調用方能夠正確地解析；
　　　　參數值邊界值、等價類測試；

• 錯誤和異常處理測試

　　　　輸入異常值（空值、特殊字符、超過約定長度等），接口能正確處理，且按預期響應；
　　　　輸入錯誤的參數，接口能正確處理，并按預期響應；
　　　　多輸入、少輸入參數，接口能正確處理，且按預期響應；
　　　　錯誤傳輸數據格式（如json格式寫成form格式）測試；

• 安全性測試，主要指傳輸數據的安全性：

　　　　敏感數據（如密碼、秘鑰）等是否加密傳輸；
　　　　返回數據是否含有敏感數據，如用戶密碼、完整的用戶銀行賬號信息等；
　　　　接口是否對傳入的數據做安全校驗，如身份ID加token類似校驗；
　　　　接口是否防止惡意請求（如大量偽造請求接口致使服務器崩潰）；

• 性能測試，如接口的響應時間、并發處理能力、壓測處理情況：

　　　　并發請求相同的接口（特別為POST請求），接口的處理情況（如插入了相同的記錄導致數據出錯，引發系統故障）；
　　　　接口響應時長在用戶可忍受的范圍內；
　　　　對于請求量大的接口做壓測，確定最大的瓶頸點是否滿足當前業務需要；

此題來源：http://www.rzrgm.cn/linyu51/p/14277533.html

 

五、瀏覽器地址欄輸入了一個URL，直到請求結束數據加載出來，這中間經歷了什么？

　　第一進行DNS域名解析

　　第二它會建立TCP鏈接（3次握手4次揮手）

　　第三發送一個http的請求

　　第四服務器處理相關的請求

　　第五是返回響應的結果

　　第六關閉TCP連接

　　第七瀏覽器解析HTML

　　第八瀏覽器進行布局渲染

來源：抖音

　　

六、cookie、session、token的區別

相同點：都是用于鑒權并且都是服務器生成的。

不同點：

　　cookie 保存在客戶端的瀏覽器上，cookie不安全，可以去分析存在在本地的cookie進行cookie欺騙

　　session保存在服務器的內存，默認保存30分鐘，比cookie安全，缺點是當登錄的用戶過多，比較占用服務器的資源。session一邊會生成一個sessionid（名稱自定義），sessionid可以通過cookis傳輸。

　　token存儲在服務器的數據庫里面，通過一個接口或者通過登錄獲取，然后后續所有的接口都必須傳token才可以請求成功。

 

來源:bilibili

七、接口關聯是如何處理的？

　　接口關聯：一個接口依賴于多個接口，或多個接口依賴于一個接口（登錄）。很多的接口測試都是登錄之后獲取鑒權碼，然后其他所以的接口都需要這個鑒權碼。

　　以實際做過的案例為主：登錄接口-登錄成功后，會返回token信息，其他需要登錄才能查看的接口都需要這個token，并且是在請求頭header里邊，處理辦法：將登錄成功后的token取出來保存為全局變量，哪里需要直接引用就可以。

　　jmeter 里邊使用json提取器（正則也能實現），將token提取出來，別處直接引用：${token},可借助chrome的插件：JSON-handle_0.6.1.crx  之前寫過文章，

　　　　　　　傳送門： http://www.rzrgm.cn/eosclover/p/15325499.html

　　postman :用腳本的方式去實現，提取之后都要保存在全局變量。 

 

八、常用的接口測試工具？

　　postman  jmeter

　　我的回答：單接口的話  使用postman比較多，多接口 關聯的話，使用jmeter比較多，jmeter處理接口關聯比較方便。

 

九、對于依賴第三方數據的接口如何進行測試？

　　我的回答：通過postman 搭建Mock服務器。

　　之前寫過搭建步驟，傳送門：http://www.rzrgm.cn/eosclover/p/15695581.html

 

十、接口測試如何校驗結果是否正確？

　　　　1.HTTP狀態碼校驗

　　　　　　　　　驗證返回的狀態碼為200（常見的HTTP 狀態碼有：200，404，501）

　　　　2.業務狀態碼

　　　　　　　　（1）根據接口文檔，看看業務狀態碼成功是什么，之前遇到的是用10個0  代表成功。

　　　　　　　　  (2）當接口響應的內容比較少，比較固定的情況下，校驗完全一致。

　　　　　　　　（3）當接口響應的內容比較多，校驗最核心的業務信息。

　　　　　　　　（4）當接口響應的內容為層級較多的xml格式或JSON格式時，可通過xpath、JSONPath、正則的方式匹配獲取到最關鍵字的業務字段，然后再校驗。

　　　　　　　　（5）查詢數據庫校驗或是通過其他接口校驗。