隨著測試分析和分層測試的深化，"接口測試"出現在我們視野的頻次越來越高。那麼接口測的用例設計常用哪些方法呢？本文將詳細描述。
1 接口測試
1.1 接口測試
接口：主要是子模塊或者子系統間交互並相互作用的部分。
這裡說的接口是廣義的，客戶端與後臺服務間的協議；插件間通信的接口；模塊間的接口；再小到一個類提供的方法；都可以理解為接口。
接口測試：是指針對模塊或系統間接口進行的測試。
1.2 接口測試發現的典型問題
接口測試經常遇到的bug和問題，如下：
（1）傳入參數處理不當，導致程序crash；
（2）類型溢出，導致數據讀出和寫入不一致；
（3）因對象權限未進行校驗，可以訪問其他用戶敏感信息；
（4）狀態處理不當，導致邏輯出現錯亂；
（5）邏輯校驗不完善，可利用漏洞獲取非正當利益等。
2 接口測試用例設計
上圖為一個典型的接口。一個接口通常是有輸入輸出的，輸入就是我們常見的入參，輸出有時有，有時沒有。調用相關接口，接口會執行相關處理邏輯。
接口測試的用例設計，主要從輸入和接口處理兩方面考慮：
1）針對輸入，可按照參數類型進行設計；
2）針對接口處理，可按照邏輯進行用例設計；
3）針對輸出，可根據結果進行分析設計。
2.1 針對輸入設計
對於接口來說，輸入就是入參。常見參數類型有:
（1）數值型(int,long,float,double等）
（2）字符串類型
（3）數組或鏈表
結構體
結構體(struct)是一些元素的結合，元素實際也是數值型，字符串型，數組或鏈表。
下面詳細說明數值型、字符串型、數組或鏈表三種參數類型用例設計。
2.1.1 數值型
數值型的參數主要考慮以下幾個方面設計：
如果參數規定了值的範圍，則需要考慮等價類取值範圍內、取值範圍外，取值的邊界，如有需要，可能會遍歷取值範圍內的各個值。
例如檢查權限的接口：TaskChecker.checkTask(int taskID) taskID的取值範圍是1-35，那麼設計時考慮：
●1-35範圍內和範圍外的值；
●1-35的邊界：0，1,35,36；
●類型的特殊值：-1,0
●數據類型的邊界值：int的最小值最大值；
●因為1-35代碼的權限ID不同，可能需要遍歷1-35的每個值。
常見問題和風險：
●特殊值處理不當導致程序異常退出；
●類型邊界溢出
●取值範圍外值未返回正確的錯誤信息等
2.1.2 字符串型
字符串型的參數，主要考慮字符串的長度和內容：
例如接口轉換設置鬧鐘的接口DateUtil.getDayOfDDHH(String ddhh)，用例可以考慮：
●長度為4位，比4位少，比4位多；
●邊界值：String的最大長度；
●特殊值：空字符；
●字符串內容可考慮類型：數字，非數字；
●特殊字符。
●如果是輸入用戶輸入且其他用戶可見的內容，則還需要考慮敏感字是否被正常過濾。
可能出現的問題和風險：
●傳入非特定類型程序異常退出
●超長字符未進行處理，導致存儲、顯示等異常
●其他用戶可見設置的敏感字
2.1.3 數組或鏈表類型
參數類型為數組或鏈表時，用例可以考慮：
例如批量提交任務的接口submitTask(int[] taskID)，參數用例設計考慮：
●正常取值：1-5個權限，範圍外：6個權限；
●邊界值：1-35的邊界值，請求允許最大最小值；
●特殊值：0個；
●合法ID和不合法的；
●重複的ID等。
可能存在的問題和風險：
●0個item時程序異常退出；
●重複的item處理時未去重導致結果異常等。
2.2 針對邏輯設計
接口需要進行一些邏輯處理的，那麼按邏輯設計用例可以從以下幾個角度分析。
2.2.1 約束條件分析
（1）數值限制：分數限制、金幣限制、等級限制等等。
例如：兌換Q幣活動要求積分>50才可參與。
（2）狀態限制：登錄狀態等。
例如：同步用戶信息需要先登錄賬號。
（3）關係限制：綁定的關係，好友關係等。
例如：幫家人防騙功能只能查詢綁定家人的來電信息。
（4）權限限制：管理員等。
約束條件的測試在功能測試中經常遇到，在接口測試中更為重要。它的意義在於：用戶進行操作時，在該操作的前端可以已經進行了約束條件的限制，故用戶無法直接觸發請求該接口。但是實際上，如果有其他手段：例如UI有bug或者通過技術手段直接調用接口，那麼接口是否針對這些條件進行了限制就尤為重要
