接口測試用例設計

接口測試

接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。

接口測試的意義

按照分層測試模型，處於中間層的接口測試，在穩定性，效率，成本，技術，實施難度上綜合來講，是收益最大的。相較於傳統的UI層次的測試，接口測試把測試提前了（時間上，架構上），並且能夠覆蓋到一些UI測試無法觸及的功能點，提高了測試的覆蓋率，對質量控制提升了信心。接口測試也更容易實現自動化持續集成，支持后端快速發版需求，利於CT（持續測試）的開展。

 

（分層測試模型 - 圖片摘自 51testing 網站）

接口用例設計方法

接口測試用例設計的重點，在於功能性的業務邏輯檢查和參數檢查。

1.功能：檢查接口基礎功能，是否完成了業務邏輯要求。此處的用例設計方法，和普通的測試用例設計方法一樣。可以把接口當作一個待測模塊，分析接口功能需求，利用常規用例方法設計測試用例。可供參考的用例設計方法如下：

1.等價類划分法
2.邊界值分析法
3.錯誤推測法
4.因果圖法
5.判定表驅動法
6.正交試驗法
7.功能圖法
8.場景圖法

2.數據：分析接口的輸入參數，覆蓋各種可能的場景。

（1）檢查接口的輸入，數據格式、數據類型、數據范圍等

（2）檢查接口的參數邊界（傳遞的參數足夠大或者為負、空值時）

（3）檢查接口的參數的組合，可選、必選等

（4）檢查接口的約束條件，不符合約束條件的，不需要設計用例

3.性能：接口是否造成性能瓶頸，能承受的壓力范圍

4. 安全：接口是否涉及安全性

 

接口用例設計舉例

下面以一個web接口作為案例，接口說明文檔如下：

接口名稱：獲取用戶訂單
請求URL：{$url}/getUserOrder
請求方式：POST
返回舉例：
略

 

請求參數：

名稱	必填	類型	說明
uid	Y	String	用戶id
orderNum	N	Int	訂單數量

根據（1）業務流程（2）輸入參數（3）輸出返回（4）性能（5）安全 5塊內容對接口進行用例設計。用例參考如下：

業務流程用例
	獲取用戶訂單成功
	用戶訂單不存在
	用戶不存在
	獲取用戶訂單異常
輸入參數用例
	uid不為空，orderNum不為空
	uid為空，orderNum為空
	uid為空，orderNum不為空
	uid不為空，orderNum為空
	uid正確，orderNum不為空
	uid正確，orderNum為空
	uid錯誤，orderNum不為空
	uid錯誤，orderNum為空
	orderNum=-1
	orderNum=0
	orderNum=1
	orderNum=5
	orderNum=100000
	orderNum
	uid數據格式錯誤
	orderNum數據格式錯誤
輸出結果用例
	返回空值
	返回有效訂單
	返回錯誤信息
	返回超時信息
性能用例
	…
安全用例
	…

 

用例篩選：

此接口，接近30個用例，已經比較全面了，但實際上有點冗余。比如，如果調用接口的界面是個用戶選擇界面，那么參數上，會受到約束，uid/orderNum都從前端傳入，是一些固定的值，那么就不會產生一些特殊情況。類似以下情況，就不會在實際中遇到，因此這些用例的價值趨於0，完全可以在用例文檔中去除。

uid為空，orderNum為空

uid為空，orderNum為空

orderNum=-1

orderNum=0

orderNum=100000

orderNum數據格式錯誤

uid數據格式錯誤

uid錯誤，orderNum不為空

uid錯誤，orderNum為空

設計的用例在考慮全面之后，需要再做一次減法，保證用例的實效性。對無法出現的場景設計出來的用例，毫無價值，只會增加我們的工作量，對產品質量提升沒有幫助。因此，測試用例並不是越多越好，在於該用例是否能真正預防bug。

接口測試質量評估

接口測試用例在執行了一段時間后，需要對用例進行質量評估，即是對用例進行維護和優化。評估的內容可以參考如下幾條：

（1）業務功能需求覆蓋率；

（2）異常場景覆蓋是否完整；

（3）代碼覆蓋率；

（4）用例的有效性，檢查出bug的概率；

（5）用例的錯誤率，bug誤報指數；

（6）測試數據維護成本，mock數據的准確性；

通過評估，可以得到接口測試的一些結果數據，對下一階段接口測試的進行有參考意義，也有助於不斷提高測試的質量和效益。

 

 

胡亂寫了一些，有不足之處，請指正。