一、什么是接口測試？
接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。
二、為什么要做接口測試?
1、接口測試相對容易實現自動化持續集成，且相對UI自動化也比較穩定，可以減少人工回歸測試人力成本與時間，縮短測試周期，支持后端快速發版需求。
2、從安全成面來說：只依賴前端進行限制已經完全不能滿足系統的安全要求（繞過前面實在太容易）， 需要后端同樣進行控制，在這種情況下就需要從接口層面進行驗證。其次，前后端傳輸、日志打印等信息是否加密傳輸也是需要驗證的，特別是涉及到用戶的隱私信息，如身份證，銀行卡等。
說了這么多如何設計接口測試用例呢？設計測試用例的時候可以重這9個方面進行考慮：
1、基本功能測試（業務測試）：
必須要清楚業務流程規則和每個接口的使用場景方式，設計符合業務邏輯和接口使用場景的用例。保證每個接口的基本功能正常
2、邊界分析測試：
在基本功能的基礎上，就開始考慮輸入輸出參數的影響，主要采用的方法有等價類划分和邊界值等方法。
覆蓋所有的參數
組合可選的參數
參數有無或者為空
參數的順序、個數和類型
參數數值類型數值大小和輸入參數的范圍
參數字符串長短
參數包含特殊字符
3、參數的組合測試:
上述根據邊界值的基礎上，考慮輸入條件的各種組合和輸入條件之間的相互制約，盡可能多的去覆蓋參數的組合。
4、異常情況測試
接口實現是否對異常情況都進行了處理，有些內部的異常不一定是輸入的數據造成的，而有可能是其他邏輯造成的，程序需要對任何異常都進行處理，比如：某個接口需要先登錄獲取 sesssion，如果直接調用該接口應該給出相應提示，是否提示登錄失敗。
5、重復提交接口的冪等級測試
簡單說就時針對連續重復提交的情況的進行測試，特別是涉及到交易金額的場景，需要驗證軟件是如何處理的。
6、多用戶並發測試
就是兩個以上用戶同時操作使用同一場景時，可能引導爭奪資源，死鎖等現象。
7、事務性測試
這里是針對一個業務流程含有多個操作步驟，其中一個操作失敗，整個操作就需要回滾，或者是調用前一個接口的逆向接口進行操作取消。
8、大數據量時測試
就是在數據庫數據比較多，比如百萬級別的時候，向數據庫增刪改查操作的效率
9、環境的異常測試
有關系的系統出現宕機、請求超時或者是無響應的時候，接口要返回正確的提示信息，業務邏輯要正確，不可出現業務邏輯不一致的情況。
好了設計完測試用例，后面就要執行測試並驗證測試結果的正確性，下面說一下測試驗證點需要關注的幾個方面：
A、接口返回數據
a) 返回json數據的層次關系是否與文檔一致，不能出現json格式返回的數據的結構與文檔不符，否則前端數據或者是其他系統調用接口時數據顯示就會有問題。注：接口返回的數據是json格式，數據是通用的，適用於任何的系統。
b)數值類型數據: 特別是金額，負數、小數轉為json輸出是否正確
c) 接口返回數據與接口文檔一致
d)接口返回數據和數據庫一致
e) 接口返回數據符合業務邏輯（比如轉賬功能，從一個賬戶扣款，另一個要增加相應金額）
f) 對於列表，應該根據請求參數，也應該驗證列表的長度是否與期望值一致
g) 負面測試用例，應驗證ERROR INFO是否與實際相匹配
B、數據庫
a) 接口傳入數據與插入DB的數據一致性：
b) 前端某個操作涉及后台DB多張表時，每張表都要檢驗數據正確性。
C、安全層面：
a) 后端接口返回給前端的數據包含敏感信息（如：姓名、身份證號、卡號、手機號、加密后的密碼等）時，不能明文傳輸，需要加密。
b) 后台打日志要求對於敏感信息不能打出，或者進行加星號脫敏后打出，具體有：
1） 身份證號，用戶密碼（含加密后），用戶手機號碼，用戶姓名，銀行卡號
2） 身份證號碼脫敏字段為生日時，生日在日志中不能打出
D、性能層面：
a) 接口響應時間： 接口處理數據的時間也是測試需要關注的一個點。牽扯到內部就是算法與代碼的優化
b) 接口數據包大小：接口傳遞的數據包大小也需要關注，特別是返回給前端的接口，要把不同接口數據包大小需要做限制。
c) 並發承載能力：多用戶並發時接口可以承載合同中的並發量。
三、接口測試常用工具
1、jmeter的使用
首先講下咱們平時腳本中經常使用的3點，分別是檢查點、關聯、參數化。
檢查點：首先jmeter的檢查點是用斷言來實現的，在lr中是有專門的檢查點函數，那么為啥要使用檢查點呢？其實檢查點的作用就是自動檢測業務請求是否真正成功的，尤其是在壓測接口的時候我們通常強調事務請求的成功率，而工具判定請求是否成功是按照服務器返回的狀態碼來判定的，只要不是4XX(客戶端請求錯誤)或者是5XX（服務端異常）才會判定請求是錯誤的，但是登錄如果失敗，服務器不會返回上述4Xx和5XX的狀態碼，此時jmeter就會認為請求是成功的，所以像這類無法去判定請求業務的需要加檢查點去檢測請求是否成功。
關聯：啥時候使用關聯呢？就是后面的請求需要使用前面的請求返回的動態變化的值，不然請求就會被認為不合法被服務器拒絕請求。一般關聯的地方大致分為兩大類，一類是服務器需要校驗的動態變化的值，另一類是int類型的整數，在數據庫中與其他數據參數關聯關系，或者是補齊請求中where條件等。這里不再贅述。