（1）什么是接口測試
接口測試是測試系統組件間接口的一種測試。
接口測試主要用於檢測系統內部各個子系統之間、外部系統與系統之間的交互。
測試的重點是檢查數據交換，傳遞和控制管理的過程，以及系統間相互邏輯依賴關系等。
通俗來說接口測試就是接口提供方、接口調用方之間的交互，及邏輯處理的測試。
數據交換：注冊
數據傳遞：將注冊數據傳遞到服務器，調用程序，執行數據庫sql語句，往數據表中插入數據
控制管理：在程序中設置字段的長度
系統間相互邏輯依賴關系：注冊成功之后調用登錄進行登錄；共享充電寶是否收取押金依賴芝麻信用分
接口：
1. GUI：圖形用戶界面，並不是接口測試的重點。
2. API：應用程序接口，接口測試的主要對象。API專門用來提供給其他系統進行調用的程序接口。
Browser/Server、Client/Server架構必然需要前端和服務器進行交互，接口就是它們交互的樞紐。
其本質就是前台發送一個request（請求）報文給服務器，然后服務器響應返回一個response（響應）報文。我們對response報文進行分析，判斷是否和我們的預期一致，從而檢驗業務是否正確實現。
通過輸入看輸出
模擬實際場景（服務架構（Java、Python、php）、數據場景（CRUD）、業務場景），對接口進行模擬調用，驗證其響應性能、輸出結果、異常處理等測試點。
HTTP接口測試知識點：
考試系統網址：http://182.92.178.83:8088/student/index.html#/login
Request URL(請求地址)
URL形式: http[s]://host[:port][abs_path][parameter]
比如: http://182.92.178.83:8088/api/student/user/register
Request Headers(請求頭):頭信息，包含了報文的描述信息
Accept(接收形式): application/json, text/plain, */*
Content-Type(提交形式): application/json
Cookie: JSESSIONID=C68ED1A8DA1A3B2CDACC5612F158467D
# Content-Type的幾種形式:
- form-data
- application/x-www-form-urlencoded
- application/json
比如：{"username":"ctt","password":"123456",age:21,"a":[{"b":123},{"c":456}]}
Request Method(提交方法): GET/POST DELETE/PUT
GET: 獲取服務器信息的一些操作。一般用於獲取數據
比如：
Request URL: http://182.92.178.83:8081/article/all?state=-1&page=1&count=6&keywords=
Request Method: GET
PS：直接在url后面連接參數，url有長度限制。
POST: 一些提交等操作。一般用於提交數據，注冊、上傳文件。
DELETE: 一般用於刪除操作（物理刪除）
比如：
Request URL: http://182.92.178.83:8081/admin/category/56
Request Method: DELETE
PUT: 跟post功能一致，但是有一個對等加密的過程，比如兩人同時提交就會對比誰先提交，執行先提交的那個操作，后提交的不做處理。比如邏輯刪除。（邏輯刪除：比如將state=0）
比如：
Request URL: http://182.92.178.83:8081/article/dustbin
Request Method: PUT
這四種形式無論用哪一種都能實現對數據庫的增刪改查，那么為什么會分四種呢，它更像是一種約定。
（面試題）get和post的區別❓
- 傳參方式不同，get是通過url？后面去傳參的，post是在請求體里面傳參。
- 有些約定里面，get更多的是做獲取信息的操作，post更多的是做提交信息的一些操作。
Request Parameters(請求參數)
Status Code(響應狀態碼)
200(服務器響應成功)
404(找不到路徑)
500(服務器內部錯誤)
Response(響應信息)
（2）為什么要進行接口測試
接口測試相對於UI來說，更加穩定；
也可以說接口測試是一種特殊的單元測試；
當一個系統提供了大量的后台服務，有較少或者基本沒有頁面操作，比較適合開展接口測試；例如：某個系統大概有100多個對外的接口，每次上線，測試人員不得不一個一個驗證，此時如果開展自動化，將大大提高回歸的效率和測試的覆蓋率。
為什么接口比UI更加穩定：如果接口響應信息都變了，UI也需要變。
🐒前后端分離，一個接口給多個端使用（web端、app端）
🐷什么時候做接口測試？
- 有大量用戶的時候，前端頁面限制了但是沒有限制完。
（3）怎樣做接口測試
- 方式一：先拿到接口測試規范文檔，再去做接口測試。
- 方式二：抓包（瀏覽器F12、Charles、fiddler）。
1.接口測試在工作中的流程
-
准備階段（20%）
拿到開發的接口文檔，並理解每個接口的參數及含義；
了解被測系統的業務流程。
-
編寫接口測試用例、執行階段（70%）
測試用例/測試場景執行
測試數據/系統數據收集
-
分析階段（5%）
數據匯總/日志分析
測試報告
2.接口測試規范文檔
接口功能
URL
支持格式
HTTP請求方式
請求參數
🔑為提高接口測試效率，及TDD（測試驅動開發）模式，前期我們需要推動開發規范，接口說明文檔。
3.如何獲取接口（Charles、fiddler）
抓包工具Charles、fiddler，web端瀏覽器的F12。
（4）接口測試用例的設計
接口測試用例編寫要點：
- 測試每個參數類型不合法的情況。
- 測試每個參數取值范圍不合法的情況。
- 測試參數為空的情況。
- 測試參數前后台定義的一致性。
- 測試每個參數的上下限（這里容易出致命的BUG，如果程序員處理不當，可能導致崩潰）。
- 測試每個參數取值不合理的情況（包括取的值不屬於自己，取值在這階段不會出現，取值超出了自己所謂的數量或者范圍）。
- 如果兩個請求有嚴格的先后順序，需要測試調轉順序的情況。
（5）接口測試的流程規范（團隊中）
- 與產品、開發一起梳理需求，確定實現哪些接口和功能。
- 編寫測試計划（開發人員預估時間、風險預估及解決時間，測試人員用例准備、數據准備、環境准備、與開發產品協調測試時間等）
- 測試計划review。請各部門再進行溝通，確定最終計划。
- 編寫用例及自動化腳本。
- 用例review（以該用例為最終驗證的用例）。
- 執行測試，提交bug，驗證bug。
- 測試總結（包括測試過程、開發過程遇到的問題、解決問題、小組內討論以后遇到這種問題如何可以處理更快、對自己啟發）