在日常工作中，常見的接口測試主要包括：Web接口測試，應用程序接口（API, application programming interface）測試和數據庫測試。
前言：
在做接口測試用例之前，首先要做接口分析。主要需明確以下內容：
1）收否有接口文檔？接口文檔內容有哪些？
2）明確接口測試流程。
3）分析每一個接口：header，url，參數（含義、可選/必選、格式、類型等等），響應數據來源及數據量。
4）分析實際可做接口測試的測試點。
1、接口文檔
A、接口文檔五要素：接口地址、接口請求的方式、是否有請求參數（參數相關屬性）、返回參數說明（參數相關屬性）、返回結果樣例；
B、如果沒有接口文檔，到功能測試階段，需要自己抓包，抓包工具如Fiddler等。
2、接口測試流程
主要的流程包括：接口文檔 — 接口測試計划、方案 — 接口測試用例（評審）— 執行 — 集成到Jenkins — 接口反饋
3、測試點
A、單一接口功能的測試主要測試返回的數據結構是否和接口文檔給出的一致；
B、接口的正常功能是否完成；
C、接口的參數檢查測試，接口的異常測試；
D、多接口組合測試，實際上是在測試一個業務流；
E、在測試過程中一次調用多個接口。
在明確上述內容后，開始設計接口測試用例。（划重點啦）
1、輸入
在輸入參數方面，我們需要從以下幾個方面進行設計：
A、必填項校驗：在接口文檔中是否有必須填寫的相關內容（參考接口文檔即可）。
B、參數長度校驗：參數長度可以參考接口文檔。
C、參數值的有效性校驗：參數有效性的校驗就需要結合實際業務場景，判斷哪些數據是真實有效的數據，一定要確保所有真實有效的數據是可以驗證通過的。
舉個例子：身份證信息的校驗。
我們在做相關校驗時需要注意，雖然數據的長度符合設定規則，但並不代表它是真實有效的身份信息。（例：123456789012345678）
這種情況下，我們需注意身份證號的校驗規則設定。一般情況下，采用的現成的身份證號校驗器即可。但是，有些校驗算法是自己寫的，因此，要注意校對這種算法是否合理，
D、參數組合校驗：不同的參數組合可能會存在不同的業務場景；
E、如果參數是枚舉值，一定要各種枚舉值都要測試，因為可能不同的枚舉走的不同的業務流程；
F、參數值的默認值的校驗：參考接口文檔。
G、某些參數具有特定的生成規則，要單獨針對生成規則設計用例，一定要保證真實有效的數據是可以驗證通過的。
如：身份證號中間幾位***19860701*，本人就遇到過輸入***19861001*這種值校驗不正確；
2、接口邏輯
接口邏輯我用的設計方法是分支覆蓋—>路徑覆蓋—>場景覆蓋，同樣也是要結合實際業務場景，根本不發生的業務場景就是無效的測試用例。
A、流程圖
第一步先把業務流程圖畫出來；
B、異常情況
依據路程圖中的分支分別設計，不同分支不同的場景，這里就要把異常的場景考慮進去；如接口超時，接口異常，接口請求成功或失敗，成功后怎么處理，失敗后流程是否繼續執行，失敗后的數據怎么處理；
以付款接口為例：
付款結果為：成功或失敗。當付款成功后，應怎么處理，需要回寫打款成功狀態；若付款失敗，也需要回寫失敗狀態。失敗后的數據可以操作退回，也可以操作重新出款等等；
C、業務場景
測試邏輯設計完成后要想一想不同的業務場景怎么去測試，需要哪些人員協助，如：接口超時怎么去測試，請求重復怎么去測試，請求並發怎么去測試。
3、輸出
輸入結果：正常輸出和異常輸出，常用的方法有錯誤推斷法（列舉出程序中可能存在的錯誤或者異常，根據他們選擇測試用例）。
4、冗余
以上都完成后，要結合實際的業務場景去掉冗余的用例（即實際業務場景不存在的流程或者輸入數據）；
5、狀態轉換
如果業務流程涉及到狀態轉換，要單獨設計用戶—方法：狀態轉換圖；
6、正交試驗法
涉及到多個不同金額或者手續費的計算，可能還會用到正交實驗法去設計用例；
7、異常數據
另外，用例設計中還應當包含異常流程中產生的異常數據的處理流程；—通常所說的補償機制，這塊流程能大大的減輕人工運營的工作量，當然，這需要在做系統設計的時候就需要把這部分考慮進去。
在設計好測試用例后，接下來是調試接口腳本。可以使用jmeter，postman等接口工具，也可以自編接口測試腳本。在測試腳本過程中，應注意：
1）不斷調試腳本；
2）添加邏輯控制，對腳本內的數據進行參數化（包括：前置條件，測試步驟及測試數據）；
3）添加用例里的預期結果。
最后，執行測試和腳本，並對執行結果進行分析。包括：錯誤分析、響應結果分析、響應時間分析等等。