接口測試用例設計方法

 本篇的目的是簡明的完成一份接口測試用例設計的撰寫，維護的文檔，須要你們共同努力，不斷完善，存在的不足以及往後在實際使用中暴露出來的問題，但願你們及時出，以便更新文檔。

 

1、    用例設計過程：

羅馬不是一天建成的，用例不是一次完成的；書寫測試用例自己和完善代碼同樣，也是一個按部就班的過程。

 

首先，必須熟讀需求說明書和接口設計文檔，瞭解每一個接口具體的使用場景，明白軟件的性能指標。

 

其次，設計接口測試用例：開始在編碼階段，測試人員根據需求說明書和接口設計文檔設計接口測試用例。

 

而後，code review：開發完成編碼後，在時間充裕的條件下，要進行 code review，一方面是檢查開發的代碼功能邏輯是否正確，另外一方面經過review開發的代碼來補充接口測試用例。

 

      最後，完成用例後，隨着對系統瞭解的增多，不斷提升用例精度，對測試用例須要進行按期review，一旦測試需求發生變化，測試用例必須從新維護。

 

2、接口測試用例構思結構：

 

階段一：開發在編碼，測試拿到需求文檔和接口設計文檔：

1、基本功能測試（業務測試）：

根據需求文檔和接口設計文檔的轉譯，須要清楚業務流程規則和每一個接口的使用場景方式，設計符合業務邏輯和接口使用場景的用例。

 

2、邊界分析測試：

在基本功能的基礎上，開始考慮接口輸入輸出參數的影響。主要採用等價類劃分、邊界值分析方法等。

l  覆蓋全部的必選參數

l   組合可選參數

l  參數有無、或爲null

l  參數的順序、個數、類型

l  參數類型數值大小、輸入的數值的範圍

l  參數字串長短，Null-max-max+1

l  參數包含特殊字符

 

3、參數組合測試：

      在邊界分析的基礎上，考慮輸入條件的各類組合、輸入條件之間的相互制約關係。主要使用因果圖法進行用例設計。

 

4、異常狀況測試：

接口實現是否對異常狀況都進行了處理，接口輸入參數雖然合法，可是在接口實現中，也會出現異常，由於內部的異常不必定是輸入的數據形成的，而有多是其餘邏輯形成的，程序須要對任何異常都進行處理，好比：某個接口須要先登陸獲取 sesssion，若是直接調用該接口應該給出相應提示。

 

 

5、冪等級測試：

     簡單說就時針對連續重複提交的狀況的進行測試，特別是涉及到交易金額的場景，須要驗證軟件是如何處理的。

 

6、併發測試：

     兩個以上用戶同時操做使用同一場景時，可能引導爭奪資源，死鎖等現象。

 

7、事務性測試：

     一個業務流程包含多個操做步驟，若是某個操做失敗，那麼整個操做須要回滾。或者調用前一個步驟的逆向接口進行操做取消。

 

8、大數據量時測試

     數據庫裏數據量較大時（百萬級），測試對DB進行增刪改查操做的效率。

9、環境異常測試

   關聯繫統出現宕機、超時或者無響應的狀態時，接口返回提示正確，業務邏輯正確，不可存在事務性不一致的狀況

 

 

 

階段二：開發完成編碼，測試時間充裕的條件下，須要對開發的代碼進行code review

 

一、      review開發的代碼實際業務邏輯是否正確

2、隱含條件測試：

進行code review，檢查代碼中是否有隱含的默認條件。例如：F項目中的getRecommendArticleList接口，代碼中默認查詢返回4條記錄（以下圖），但在接口文檔中並未提到，若是不review code而開發也不告訴咱們的話，這種狀況確定會漏測。

 

 

 

 

 

3、SQL測試：

針對須要進行數據庫操做的接口，查看相關sql，對sql的正確性進行驗證。以下圖，通常sql的過濾條件都會比開發告訴咱們的要多，因此查看sql進行驗證是最保險的方式，特別須要設計組合條件的場景進行驗證：

 

 

 

 

 

 

3、測試過程驗證點：

1、接口返回數據

a)         返回json數據的層次關係是否與文檔一致

b)        數值類型數據: 特別是金額，負數、小數轉爲json輸出是否正確

c)         接口返回數據與接口文檔一致

d)        接口返回數據和數據庫一致

e)         接口返回數據符合業務邏輯（好比轉帳功能，從一個帳戶扣款，另外一個要增長相應金額）

f)          對於列表，應該根據請求參數，也應該驗證列表的長度是否與指望值一致

g)         負面測試用例，應驗證ERROR INFO是否與實際相匹配

 

 

 

2、數據庫

a)         接口傳入數據與插入DB的數據一致性：

b)        前端某個操做涉及後臺DB多張表時，每張表都要檢驗數據正確性。

 

3、安全層面：

a)         後端接口返回給前端的數據包含敏感信息（如：姓名、身份證號、卡號、手機號、加密後的密碼等）時，不能明文傳輸，須要加密。

b)        後臺打日誌要求對於敏感信息不能打出，或者進行加星號脫敏後打出，具體有：

1）          身份證號，用戶密碼（含加密後），用戶手機號碼，用戶姓名，銀行卡號

2）          身份證號碼脫敏字段爲生日時，生日在日誌中不能打出

 

4、性能層面：

a)         接口響應時間：  接口處理數據的時間也是測試須要關注的一個點。牽扯到內部就是算法與代碼的優化

b)        接口數據包大小：接口傳遞的數據包大小也須要關注，特別是返回給前端的接口，要把不一樣接口數據包大小須要作限制。

c)         併發承載能力：多用戶併發時接口能夠承載合同中的併發量。