什麼是接口測試
測試人員通常所說的“接口測試”是針對系統各組件之間接口的一種測試，它屬於功能測試。接口能測出普通界面操作難以發現的問題。如，我們都知道系統是由前端後端組成，一些數據在前端做了校驗，後端同樣也需要校驗才能保證安全，界面操作顯然只能檢查到前端校驗這一層，只有直接面對前後端之間的該接口才能檢驗出後端是否也做了校驗。
接口測試的必要性
可以發現很多頁面操作發現不了的問題
檢查系統的異常處理能力
檢查系統的安全性、穩定性
前端隨便變，接口測好了，後端不用變
接口測試的流程
需求評審，熟悉業務和需求
開發提供接口文檔
編寫接口測試用例
用例評審
提測後開始測試
提交測試報告
接口文檔 是接口測試的參照，至少包括：
1、接口說明
2、調用url
3、請求方法（get\post ……）
4、請求參數、參數類型、請求參數說明
5、返回參數說明
接口測試用例設計
通過性驗證：首先保證接口好用，按文檔正常傳入，查看是否可以返回正確的結果。
參數組合： 按接口文檔中對參數的要求進行有目的的組合，比如必填未填是否通過，標誌類參數值的切換是否能對應正確的功能等。（這部分很關鍵）
接口安全：
1、繞過正常值驗證。
2、繞過身份授權驗證。
3、參數是否加密，加密規則是否容易破解。
4、密碼安全規則，密碼的複雜程度校驗。
異常驗證：不按照接口文檔上的要求輸入參數，來驗證接口對異常情況的反應。
接口測試用例模板 （可根據項目實際情況設計增減）
1、項目 測試針對哪個項目
2、模塊 哪個功能模塊
3、用例id
4、接口名稱
5、用例標題 測試用途概括
6、請求方式 GET/POST
7、請求url URL地址
8、請求參數
9、前置條件 執行當前請求依賴的條件，不滿足就不能正確執行
10、結果驗證 預期結果
11、請求報文 可以不寫
12、返回報文 一定要寫，這裏應該是你請求返回的真實結果
13、測試結果 通過/失敗
14、測試人員
測試http接口
請求常見有Get請求和Post請求。Get請求通常用來接收數據，Post請求通常用來發送數據；測Get請求可用瀏覽器完成，參數都可以寫在URL裏面，測Post請求需要藉助工具如Postman，因爲客戶端需要提供給服務器的信息較多，你要寫body傳輸大量數據。
接口調用有兩種傳參方式：key-value形式，Json串傳參形式。
key-value形式可以把參數拼接在url的後面由?相連，多個參數之間用&相連，如url?parameter1=key1¶meter2=key2…
Json串傳參不能把參數直接連在url中，需要寫在請求的body裏面，可藉助工具Postman，打開請求的body寫入Json格式參數（由花括號括起來的‘鍵：值’對）如
{
“count”: 1,
“start”: 0,
“total”: 1
}
請求發出後，http會返回一個狀態碼錶示請求是否成功，狀態碼有三位，其中開頭一位確定了狀態類型：
2xx： 表示請求發送成功，常見200。
3xx： 代表重定向，要完成請求必須進行更進一步的操作，或把請求重定向到別的地方了，最常見的是302。
4xx： 客戶端錯誤，請求有語法錯誤或請求無法實現。400代表客戶端發送的請求有語法錯誤，不能被服務器所理解；401代表訪問的頁面沒有授權；403服務器收到請求，但是拒絕提供服務，比如沒有權限訪問這個頁面；404請求的資源不存在，比如輸入錯的URL沒有這個頁面。
5xx： 代表服務器有異常，500代表服務器內部異常；503服務器當前不能處理客戶端的請求，一段時間後可能恢復正常；504代表服務器端超時，沒返回結果。
測試WebSevice接口
不需要像測http接口那樣拼報文，直接把wsdl地址或wsdl文件（這兩個都由開發人員提供）填寫或導入到工具SoapUI裏面，工具裏可顯示所有相關接口或報文，直接填入參數發送請求參照接口文檔查看結果即可。
Cookie 和 Session
Cookie是存在於本地的一個鍵值對，Session是存在於服務器端的一個鍵值對，通常保存在數據庫或緩存裏。Cookie和Session在第一次發送某個請求時成對生成，兩端都會記錄下生成的時間，超出既定的時限後便會自動刪除。當請求在時限內再次發出後，Cookie和Session兩者會相互比對，匹配上了便執行某些操作，匹配不上則不允許執行某些操作，以此實現快速處理，它們並不是孤立作用的。