接口測試總結及其用例設計方法

 接口測試的總結文檔

　　第一部分：主要從問題出發，引入接口測試的相關內容並與前端測試進行簡單對比，總結二者以前的區別與聯繫。但該部分只交代了怎麼作和如何作？並無解釋爲何要作？

　　第二部分：主要介紹爲何要作接口測試，並簡單總結接口持續集成和接口質量評估相關內容。

 

第一部分：

首先，在作接口測試的過程當中，常常有後端開發會問：

後端接口都測試什麼？怎麼測的？

後端接口測試一遍 ，前端也測試一遍，是否是重複測試了？

      因而，爲了向開發解釋上述問題，普及基本的測試常識，特地梳理了接口測試的相關內容以及其與前端測試的區別，使開發團隊與測試團隊在測試這件上達成基本的共識，提升團隊協做效率，從而更好的保證產品質量。

 

而後，咱們試着回答上面的問題：

問題1.1、後端接口都測試什麼？

--回答這個問題，咱們能夠從接口測試活動內容的角度下手，看一下面這張圖，基本反應了當前咱們項目後端接口測試的主要內容：

 

 

 

問題1.二、咱們怎麼作接口測試？

　　--因爲咱們項目先後端調用主要是基於http協議的接口，因此測試接口時主要是經過工具或代碼模擬http請求的發送與接收。工具備不少如：postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。

 

問題二、後端接口測試一遍 ，前端也測試一遍，是否是重複測試了？

　　--回答這個問題，咱們能夠直接對比接口測試和app端測試活動的內容，以下圖爲app測試時須要覆蓋或考慮內容：

 

 

 　　從上面這兩張圖對比能夠看出，兩個測試活動中相同的部分有功能測試、邊界分析測試和性能測試，其它部分因爲各自特性或關注點不一樣須要進行特殊的測試，在此不作討論。接下來咱們針對以上三部分相同的內容再進行分析：

1、基本功能測試：

　　因爲是針對基本業務功能進行測試，因此這部分是兩種測試重合度最高的一塊，開發同窗一般所指的也主要是這部分的內容。

2、邊界分析測試：

　　在基本功能測試的基礎上考慮輸入輸出的邊界條件，這部份內容也會有重複的部分（好比業務規則的邊界）。可是，前端的輸入輸出不少時候都是提供固守的值讓用戶選擇（以下拉框），在這種狀況下測試的邊界範圍就很是有限，但接口測試就不存在這方面的限制，相對來講接口能夠覆蓋的範圍更廣，一樣的，接口出現問題的機率也更高。

 3、性能測試：

　　這個比較容易區分，雖然都須要作性能測試，但關注點確大不相同。App端性能主要關注與手機相關的特性，如手機cpu、內存、流量、fps等。而接口性能主要關注接口響應時間、併發、服務端資源的使用狀況等。兩種測試時的策略和方法都有很大區別，因此這部份內容是須要分開單獨進行測試的，理論上來講這也是不一樣的部分。

 

綜論：

      一、接口測試和app測試的活動有部分重複的內容，主要集中在業務功能測試方面。除此以外，針對各自特性的測試都不同，須要分別進行有針對性的測試，才能確保整個產品的質量。

　　二、接口測試能夠關注於服務器邏輯驗證，而UI測試能夠關注於頁面展現邏輯及界面前端與服務器集成驗證

  

第二部分：

1、什麼是接口測試？

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

 

2、爲何要作接口測試?

　　a) 現在的系統複雜度不斷上升，傳統的測試方法成本急劇增長且測試效率大幅降低，接口測試能夠提供這種狀況下的解決方案。

　　b)  接口測試相對容易實現自動化持續集成，且相對UI自動化也比較穩定，能夠減小人工迴歸測試人力成本與時間，縮短測試周期，支持後端快速發版需求。接口持續集成是爲何能低成本高收益的根源。

　　c)   如今不少系統先後端架構是分離的，從安全層面來講：

     　　 一、只依賴前端進行限制已經徹底不能知足系統的安全要求（繞過前面實在太容易）， 須要後端一樣進行控制，在這種狀況下就須要從接口層面進行驗證。

     　　 二、先後端傳輸、日誌打印等信息是否加密傳輸也是須要驗證的，特別是涉及到用戶的隱私信息，如身份證，銀行卡等。

 

3、接口測試持續集成：

      對接口測試而言，持續集成自動化是核心內容，經過持自動化的手段咱們才能作到低成本高收益。目前咱們已經實現了接口自動化，主要應用於迴歸階段，後續還須要增強自動化的程度，包括但不限於下面的內容：

　　a) 流程方面：在迴歸階段增強接口異常場景的覆蓋度，並逐步向系統測試，冒煙測試階段延伸，最終達到全流程自動化。

　　b) 結果展現：更加豐富的結果展現、趨勢分析，質量統計和分析等

　　c) 問題定位：報錯信息、日誌更精準，方便問題復現與定位。

　　d) 結果校驗：增強自動化校驗能力，如數據庫信息校驗。

　　e) 代碼覆蓋率：不斷嘗試由目前的黑盒向白盒下探，提升代碼覆蓋率。

　　f) 性能需求：完善性能測試體系，經過自動化的手段監控接口性能指標是否正常。

 

4、接口測試質量評估標準：

　　a) 業務功能覆蓋是否完整

　　b) 業務規則覆蓋是否完整

　　c) 參數驗證是否達到要求（邊界、業務規則）

　　d) 接口異常場景覆蓋是否完整

　　e) 接口覆蓋率是否達到要求

　　f)  代碼覆蓋率是否達到要求

　　g) 性能指標是否知足要求

　　h) 安全指標是否知足要求

 

接口測試用例設計

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)         併發承載能力：多用戶併發時接口能夠承載合同中的併發量。