一.如果一個接口請求不通,那么你會考慮那些方面的問題?
如果一個接口請求不通,我會像“排查水管漏水”一樣一步步定位問題發生在哪一段,主要從這幾個方向去思考:
當一個接口請求不通時,我會從以下幾個方面進行排查:
接口地址與請求方式是否正確:確認 URL 是否拼寫正確,是否使用了正確的 HTTP 方法(GET、POST 等)。
網絡連通性檢查:使用 ping、curl 或 Postman 檢查接口是否能訪問,是否存在 DNS 或代理等網絡層問題。
請求參數合法性:檢查必傳參數是否缺失,格式是否符合接口規范。
服務端狀態排查:查看服務是否部署正常,接口是否已上線或存在異常(如500錯誤)。
權限與鑒權問題:確認是否傳遞了正確的 token 或 API key,是否有權限訪問該接口。
跨域限制(前端場景):檢查是否存在 CORS 跨域問題導致請求被瀏覽器攔截。
通過從客戶端、網絡、服務端三個層級依次排查,可以快速定位接口請求失敗的根本原因。
在實際項目中,我遇到過因為 token 過期導致接口返回 401 的問題,通過日志定位并添加自動刷新機制解決了問題。
二.如何設計接口測試用例,請列舉關鍵步驟
1.通俗易懂解釋
設計接口測試用例,就像你要驗證一個自動販賣機是否工作正常。你需要:
確認輸入是否正確處理(比如投幣+按鍵,能買到飲料);
測試異常輸入會不會報錯(比如投假幣);
看看它穩定性如何(快速多次操作會不會崩);
驗證權限(是不是管理員才能開機);
驗證邊界情況(最多能買多少瓶);
這些就是接口測試要覆蓋的邏輯。
2.面試術語
設計接口測試用例通常包括以下關鍵步驟:
1. 明確接口需求和文檔
理解接口的功能、輸入參數、請求方式(GET/POST等)、返回格式、狀態碼等。
2. 劃分測試維度
主要包括:
? 功能測試:驗證接口是否按預期返回正確結果(如正常輸入返回 200 和期望數據);
🚫 異常/負面測試:如缺失參數、參數類型錯誤、非法輸入等,檢查返回是否符合預期錯誤(如400/401等);
🔐 權限測試:是否需要鑒權?Token 缺失/無效是否能攔截?
🔁 邊界測試:如字符串最大長度、數組最大值、分頁邊界等;
📶 兼容性和穩定性測試:高并發、大數據量、重復請求、請求順序等;
🕒 超時與性能測試:模擬慢響應或超大請求,看系統是否穩定處理;
3. 設計具體測試用例
每個維度下撰寫用例,通常包括以下字段:
用例編號
測試目標
請求方法/URL
輸入參數
預期返回結果(狀態碼+響應內容)
4. 構造測試數據
區分正常值、邊界值、非法值、空值等組合情況,覆蓋不同場景。
5. 使用工具執行測試
如 Postman、JMeter、Python 腳本或自動化框架(如 pytest + requests)來執行與驗證。
三.如何驗證接口的安全性?
1.通俗易懂解釋:怎么理解接口安全性驗證
可以把接口安全性理解成給“出入口加防盜門+監控”,防止別人:
偷看(信息泄露)
偷用(越權訪問)
搗亂(注入攻擊、篡改數據)
所以你要做的,就是模擬“壞人”常用的幾種攻擊手段,驗證系統有沒有防住。
2.面試術語
當驗證接口的安全性時,我主要從以下六個維度進行系統性測試:
身份認證與權限控制
確認接口是否正確校驗用戶身份(如 token、API key),并防止未授權或越權訪問。
重點測試未登錄、低權限用戶訪問敏感接口的行為。
參數校驗與防注入
驗證接口是否對輸入參數做了格式校驗,能否抵御 SQL 注入、XSS、命令注入等攻擊。
會構造惡意 payload,如
' OR 1=1 --
、HTML 標簽等,進行黑盒驗證。
敏感數據保護
檢查接口是否啟用了 HTTPS,傳輸過程是否加密;
響應中是否有明文密碼、身份證號、token 等敏感信息泄露。
防刷與限流機制
測試接口是否具有限速、IP 限制、驗證碼等防刷設計,防止接口被惡意調用或攻擊。
通常使用并發腳本測試限流閾值和響應策略。
防重放與簽名機制
檢查是否使用時間戳、nonce、簽名等方式防止請求被截獲重放;
對關鍵接口進行重復請求驗證。
接口暴露與錯誤信息控制
驗證是否存在未授權的調試接口、Swagger 文檔泄露;
檢查異常返回是否暴露堆棧信息或系統路徑。
四.什么是接口斷言,如何設計接口斷言?
1.通俗解釋
可以把斷言理解成驗收標準:
我們不是只發出請求,而是要檢查接口返回的結果是不是“對的”。
比如你點外賣后,收到的不是奶茶而是漢堡,你當然要投訴 —— 接口斷言就是“檢查你點的是不是你要的”。
2.面試術語
接口斷言是指在接口測試中,對接口返回的狀態碼、響應體、字段內容、結構等進行自動化校驗,以判斷接口是否返回了預期結果。
例如,購物系統的訂單狀態查詢接口測試中,設計斷言,狀態碼是200,表示響應體中的訂單狀態字段值與數據庫一致。
確定斷言維度(設計斷言類型)
? 1. 狀態碼斷言
確保接口響應狀態正確
例:assert response.status_code == 200
? 2. 字段值斷言
驗證返回中關鍵字段值是否為預期
例:assert response.json()["code"] == 0
? 3. 字段類型與格式斷言
確保字段類型正確,或符合正則、格式標準
例:assert isinstance(response.json()["data"]["id"], int)
? 4. 字段存在性斷言
驗證返回體中是否包含預期字段
例:assert "userId" in response.json()["data"]
? 5. 列表/分頁數據斷言
校驗數組長度、分頁邊界、順序
例:assert len(response.json()["data"]["items"]) <= page_size
? 6. 業務邏輯斷言(核心加分項)
如余額變更是否正確、訂單狀態是否符合流程等
例:assert response.json()["data"]["orderStatus"] == "PAID"
五.如何處理接口依賴?
1.通俗解釋
接口依賴就像做飯時要先洗菜、切菜,才能炒菜。
比如你要測試“下單接口”,但它依賴“登錄接口”和“添加購物車接口”先執行,才能成功下單。
所以你要想辦法:
把前置接口先跑一遍;
把里面的關鍵數據(比如 token、order_id)提取出來;
用在后面的接口請求中。
2.面試術語
在接口測試中,若某個接口依賴前置接口提供的數據(如 token、user_id、訂單號等),可以通過以下方式進行處理:
1. 通過接口調用獲取依賴數據
先執行前置接口(如登錄),提取響應中的關鍵字段(如 token、id);
使用該數據動態傳入后續接口的請求參數中,實現數據鏈路閉環。
🧩 示例:從登錄接口響應中提取 token,添加到下單接口的 header。
2. 利用測試框架的數據傳遞機制
使用全局變量、fixture(pytest)、環境變量或數據上下文對象,在多個接口間傳遞數據;
自動化框架如 Postman、pytest、HttpRunner 支持變量引用與參數提取機制。
3. 設計前置步驟或數據準備函數
將依賴數據的創建邏輯封裝成 setup 方法或前置腳本,在測試執行前自動調用;
確保測試環境干凈、數據可控、可復現。
4. 使用 Mock 或數據庫初始化(降低強依賴)
若接口過于復雜或依賴不穩定,也可使用 Mock 接口模擬返回數據;
或通過 SQL 語句直接初始化測試數據,提高執行效率與穩定性。
總結:我處理接口依賴時,通常會通過執行前置接口并提取關鍵字段(如 token、id),結合自動化測試框架的變量機制傳遞到后續接口中。如果依賴關系復雜,也會將前置數據準備邏輯封裝成 setup 方法,或者通過數據庫初始化和 Mock 減少對上游接口的依賴,保證測試流程的穩定性和可復現性。
六.在多接口業務流程測試中,如何確保接口之間的調用順序正確
1.通俗解釋
可以把多接口測試流程想象成“網購流程”:
先登錄 → 再加購物車 → 再下單 → 再支付 → 再查訂單
如果順序錯了,比如還沒登錄就去下單,就會失敗。
所以你要做的就是:
每個接口按業務順序執行
上一個接口的返回值要正確傳給下一個接口
并且中間出錯時,整個流程要能及時終止或報警
2.思考流程?
? 1. 明確業務流程與依賴關系
先分析接口間的上下游依賴,比如必須先登錄再下單、必須先創建資源再更新等。
🧩 建議繪制接口流程圖或寫成步驟列表,幫助理清順序。
? 2. 按順序設計測試步驟
測試用例中接口調用應嚴格按照業務流程順序執行,每一步成功后才執行下一步。
例如:Step 1:調用登錄接口 → 獲取 token Step 2:使用 token 調用創建訂單接口 → 獲取 order_id Step 3:使用 order_id 調用支付接口
? 3. 數據動態提取與傳遞
利用自動化測試框架(如 Postman、pytest、HttpRunner)提取前置接口的返回值,通過變量機制傳入后續請求中。
🧩 示例:
提取 token:
{{login_response.token}}
提取 order_id:
extract_var("order_id") → inject_to("next_api_body")
? 4. 前置依賴封裝(setup/fixture)
將前置步驟封裝為 setup 方法或 fixture,讓測試框架自動先執行前置接口,保障數據準備完整。
? 5. 流程中加入斷言與失敗中斷機制
每個接口執行后加入斷言,若任一步失敗,及時中斷后續接口調用,避免無效操作或誤判結果。
? 6. 使用測試集或場景管理工具(高級做法)
在大型項目中,使用如 Postman Collection Runner、pytest 測試集、Jenkins 流程任務等,管理完整業務流程測試。
3.面試術語?
在多接口流程測試中,我會先梳理接口依賴關系,明確業務順序,然后按邏輯設計測試用例鏈條,并在每一步提取關鍵數據傳給下一個接口。通過斷言與前置方法機制,確保每一步成功執行,整體流程穩定可控。在自動化測試中,我也會使用 fixtures 或流程控制機制保障順序性。
七.接口測試是什么,為什么要做接口測試
接口測試就像是“檢查系統內部各個模塊之間的溝通是否順暢”,防止“你說的我聽不懂”這種情況。
接口測試是指針對系統中模塊或服務之間的數據交換接口(如 HTTP API、RPC 接口等)進行的測試,主要驗證接口的功能正確性、穩定性、安全性、兼容性和性能,確保系統各個部分之間數據傳輸準確、調用邏輯合理。
通常包括:
請求是否能正確處理參數;
返回的數據是否符合預期;
接口是否具備容錯機制、安全控制等。
接口測試是保障系統模塊間通信正確性與穩定性的關鍵手段。相比 UI 測試,它更早介入、更高效穩定,能快速定位服務端問題,是構建高質量系統不可或缺的環節,尤其在微服務和前后端分離架構中更為重要。
?八.Cookie、session、token的區別
Cookie 就像“你隨身帶的身份證”——瀏覽器存的,每次訪問都會自動發給服務器。
Session 是“服務器開的檔案柜”,你來一次,它給你一個編號(session id),存在服務端。
Token 是“數字簽名的通行證”,你帶著它,別人不能偽造,常用于移動端、分布式登錄。
對比項 | Cookie | Session | Token(如 JWT) |
---|---|---|---|
存儲位置 | 瀏覽器端(客戶端) | 服務端 | 客戶端(一般存 localStorage 或 Cookie) |
數據存儲 | 小量鍵值對(如 session ID) | 用戶信息保存在服務器內存或數據庫中 | 用戶信息編碼后存儲在 token 中 |
生命周期 | 可設置過期時間 | 一般隨服務器關閉或用戶退出而失效 | 可設置過期時間 |
安全性 | 容易被盜用,需配合 HTTPOnly + HTTPS | 安全性較好,但服務端要保存大量會話信息 | 簽名機制防偽造,不易被篡改 |
跨域支持 | 默認不支持跨域 | 不支持 | 支持跨域,適合前后端分離系統 |
是否依賴服務端 | 否(只是存數據) | 是(需服務器維護 session 狀態) | 不依賴服務端存狀態(無狀態) |
常見應用場景 | 網站登錄記住我、簡單信息記錄等 | PC端登錄、傳統網站 | 移動端、前后端分離、單點登錄(SSO) |
Cookie、Session 和 Token 都用于管理用戶身份和狀態:
Cookie 存在客戶端,用于在每次請求時攜帶信息;
Session 存在服務端,基于 Session ID 實現身份管理;
Token(如 JWT)是一種無狀態的身份驗證機制,適合前后端分離和分布式系統。
實際中,我通常在傳統網站使用 Cookie + Session,在前后端分離或移動端場景采用 Token 認證機制。
?九.接口測試中如何處理第三方依賴
接口測試中,第三方依賴就像“外包服務商” —— 比如發短信、支付接口、地圖服務等:
你要測試自己的系統,但這些外部接口你控制不了;
如果對方掛了、慢了、數據變了,你的測試就會出問題。
所以你要做的,就是:不完全依賴它,甚至“假裝它在”,也能測自己。
? 1. 使用 Mock 技術模擬第三方接口返回
用 Mock Server 或工具(如 WireMock、Mock Service Worker、Postman Mock)模擬第三方接口的響應數據,避免測試依賴真實外部服務。
🧩 示例:
模擬支付接口返回
{"code": 0, "msg": "success"}
;模擬地圖接口返回定位坐標。
? 2. 配置測試環境使用“沙箱環境”
如果第三方提供測試/沙箱環境,應切換接口配置,避免真實扣費、發短信等操作。
🧩 示例:
支付寶、微信支付、短信服務等都有沙箱環境。
? 3. 前置準備依賴數據 / 響應緩存
對于無法 Mock 的接口,可提前調用一次并緩存響應結果,用于后續測試中“模擬使用”。
? 4. 接口調用進行降級處理 / 添加重試機制
在自動化測試腳本中,若第三方接口不穩定,可設定超時重試或失敗兜底邏輯,避免影響整條測試鏈路。
? 5. 僅測試集成邏輯,不重復驗證第三方服務功能
第三方接口自身已被測試過,我們關注的僅是與我方系統的集成是否正確,如參數是否正確傳入、回調是否處理成功。
總結:在接口測試中遇到第三方依賴時,我通常通過使用 Mock 服務模擬響應、切換至沙箱環境,或配置響應緩存,避免對外部接口的強依賴。同時,我會聚焦驗證系統自身的集成邏輯,確保參數傳遞、響應處理、容錯機制等正確,從而提高測試的穩定性和可控性。
十.你做接口測試的過程中發現了那些bug?
1.接口測試 Bug 匯總表
序號 | Bug 類型 | 接口名稱 | 問題描述 | 預期行為 | 實際返回示例 / 狀態碼 | 優先級 |
---|---|---|---|---|---|---|
1 | 參數校驗缺失 | /api/user/login | 密碼字段為空仍返回 200 且提示登錄成功 | 應返回 400 并提示“密碼不能為空” | { "code": 0, "msg": "登錄成功" } | 高 |
2 | 業務邏輯錯誤 | /api/order/create | 多次點擊“提交訂單”生成多筆相同訂單,缺少冪等性 | 應限制重復提交或返回相同訂單號 | 創建多個訂單編號 | 高 |
3 | 越權訪問 | /api/admin/user | 普通用戶身份調用管理員接口可成功拉取所有用戶數據 | 應返回 403 無權限 | 狀態碼:200,返回全量用戶信息 | 高 |
4 | 數據未更新 | /api/pay/notify | 支付完成后,訂單狀態未更新,但接口提示支付成功 | 應將訂單狀態更新為“已支付” | 返回成功但查訂單仍為“待支付” | 高 |
5 | 字段缺失 | /api/user/info | 接口文檔中說明返回 nickname 字段,但實際返回中缺失 | 應返回完整字段 | { "code": 0, "data": { "id": 1 }} | 中 |
6 | 錯誤碼混亂 | /api/common/get | 所有錯誤均返回 200 狀態碼,錯誤信息寫在 body 中 | 應使用語義正確的 HTTP 狀態碼(如 400、401、500 等) | 狀態碼:200,body: "msg": "參數錯誤" | 中 |
7 | 接口響應不一致 | /api/product/list | 部分情況下 data 字段返回數組,部分情況下返回 null | 接口返回結構應一致,空列表也應返回空數組 | { "data": null } 或 { "data": [] } | 中 |
8 | 性能異常/超時 | /api/report/export | 數據量大時接口超時,無分頁導出或異步處理機制 | 應使用異步任務或導出狀態輪詢機制 | 請求卡住30秒后失敗 | 中 |
9 | 安全漏洞 | /api/reset-pwd | 無需登錄即可傳手機號與驗證碼重置任意賬戶密碼 | 應限制登錄態或增加權限校驗 | 正常返回 密碼修改成功 | 高 |
10 | 跨域限制缺失 | /api/open/query | 跨域請求時未配置 CORS 頭,瀏覽器攔截請求 | 應返回帶有 Access-Control-Allow-Origin 等 CORS 頭部 | 瀏覽器控制臺報錯 CORS policy blocked | 中 |
? 通俗解釋:
當你訪問一個接口(比如打開一個網頁、請求一個后端服務),服務端都會返回一個“狀態碼”告訴你處理得怎么樣。
返回 200,就像對方說:“? 請求我收到了,也處理成功了。”
如果是 404,意思是“? 你找的接口地址我沒有”;
如果是 500,是“? 我服務端出錯了”;
如果是 401,是“? 你沒有權限(可能沒登錄)”。
🎯 專業術語表達:
HTTP 狀態碼是服務器對客戶端請求的響應結果的標準表示,其中
200 OK
表示接口請求成功且服務器已正確處理了該請求。
在接口測試中,檢查是否返回 200 是最基礎的斷言,用于判斷接口是否通、是否處理成功。
🧠 注意:
雖然 返回 200 表示接口成功響應,但:
不代表業務一定正確!例如:登錄接口返回 200,但登錄失敗;
所以還要結合業務字段斷言(如 code、msg、data)判斷接口是否真的“業務成功”。
總結:在接口測試過程中,我不僅關注接口是否返回 200,還會從參數合法性、權限控制、業務邏輯完整性、數據一致性等多個維度設計用例,實際也發現了不少隱藏較深的 Bug,比如重復下單、越權訪問、冪等缺失、接口結構不規范等,這些問題在早期發現能極大提升系統的穩定性與安全性。?