一、接口測試的依據主要是接口文檔，接口文檔的準確性至關重要。接口文檔的內容基本包括有：
- 接口名稱
- 接口類型
- 輸入參數：輸入參數一般包括，每個參數名，參數類型，參數業務含義，是否可爲空，參數單位
- 輸出結果：返回狀態的取值範圍及其業務含義
二、接口用例設計主要以下幾個方面進行設計：
1、 輸入參數主要從以下幾個方面設計：
- a、必填項校驗
- b、參數長度校驗
- c、參數值的有效性校驗
- d、參數組合校驗
- e、參數默認值校驗
- f、某些參數具有特定的生成規則要單獨針對生成規則設計用例
2、接口邏輯設計：分支覆蓋–路徑覆蓋–場景覆蓋，結合實際業務場景
- a、整理畫出對應流程圖
- b、依據路程圖中的分支分別設計，不同分支不同的場景,這裏就要把異常的場景考慮進去;如接口超時,接口異常，接口請求成功或失敗,成功後怎麼處理,失敗後流程是否繼續執行，失敗後的數據怎麼處理;以打款接口爲例:打款結果有打款成功或打款失敗，成功後怎麼處理,需要回寫打款成功狀態，失敗後怎麼處理，也需要回寫失敗狀態，失敗後的數據可以操作退回，也可以操作重新出款等等;
- c、測試邏輯設計完成後要想一想不同的業務場景怎麼去測試,需要哪些人員協助,如接口超時怎麼去測試,請求重複怎麼去測試，請求併發怎麼去測試
3、輸入結果:正常輸出和異常輸出,常用的方法有錯誤推斷法(列舉出程序中可能存在的錯誤或者異常,根據他們選擇測試用例)
- a、以上都完成後,要結合實際的業務場景去掉冗餘的用例(即實際業務場景不存在的流程或者輸入數據)
- b、如果業務流程涉及到狀態轉換,要單獨設計用戶—方法:狀態轉換圖;
- c、涉及到多個不同金額或者手續費的計算，可能還會用到正交實驗法去設計用例;
- d、另外用例設計中還應當包含異常流程中產生的異常數據的處理流程;通常所說的補償機制，這塊流程能大大的減輕人工運營的工作量,當然,這需要在做系統設計的時候就需要把這部分考慮進去。