接口測試的原則、用例與流程詳解

🍅?點擊文末小卡片，免費獲取軟件測試全套資料，資料在手，漲薪更快??

一、接口的介紹

軟件測試中，常說的接口有兩種：圖形用戶接口（GUI，人與程序的接口）、應用程序編程接口（API）。

接口（API）是系統與系統之間，模塊與模塊之間或者服務與服務之間相互調用的入口。它的本質：其實就是一種約定，在開發前期，我們約定接口會接收什么數據；在處理完成后，它又會返回什么數據。

開發崗位分為前端和后端，他們相互配合完成工作，會協商接口的定義方法。一般后端定義接口，前端調用接口。前后端分離是web應用開發的發展趨勢，優勢有：

后端不用精通前端技術，只專注與數據的處理，對外提供API即可。
前端的專業性越來越強，通過API獲取數據，并專注與頁面設計。
前后端分離可擴大接口的應用范圍，開發接口即可應用到web應用上，也可應用到app上。

接口的分類：HTTP接口、Web Service接口、RESTful接口。【文末有配套視頻學習】

二、接口測試的定義、必要性/優點、原理

1、接口測試的定義：接口測試是測試系統組件間接口的一種測試。接口測試主要用于檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。（--百度百科）

接口測試，其實就是驗證接口內部處理邏輯是否正確；我們既要保證單接口的正確性，也要保證接口的業務邏輯正確性，主要體現在兩方面：

輸入正確的測試數據，驗證接口正常處理后返回的結果是否正確（數據結構&數據內容）
輸入異常的測試數據，驗證接口能否正確處理異常數據并返回特定提示，是否合理，是否健壯

接口測試目的：測試接口的正確性和穩定性（持續集成是接口測試的核心）

2、接口測試的必要性/優點：

開展接口測試可以及早發現問題，有效降低測試成本
接口一般較UI相對穩定，更利于進行自動化和持續集成
特別適用于高復雜性的平臺，可以帶來高效的缺陷監測和質量監督能力（平臺越復雜，系統越龐大，接口測試的效果越明顯：提高測試效率，提升用戶體驗，降低研發成本）

PS：以保證系統的正確和穩定為核心，以持續集成為手段，提高測試效率，提升用戶體驗，降低產品研發成本。（持續集成是接口測試的低成本、高收益的根源，是接口測試的靈魂。沒有持續集成接口測試帶來工作量會成指數增長！）

3、接口測試的原理：測試借助工具模擬客戶端向服務器發送請求報文，服務器接收請求報文后對相應的報文做處理并向客戶端返回應答，工具模擬客戶端接收應答，然后測試人員檢查應答是否準確。

三、接口測試的范圍、原則、重難點

1、接口測試的范圍：

1. 需要測試的接口：

隨著系統的復雜性越來越高，接口越來越多，覆蓋所有接口是很困難的事。通常主要測試最外層的兩類接口：數據進入系統接口（調用外部系統的參數為本系統使用）和數據流出系統的接口（驗證系統處理后的數據是否正常）。

2. 被測接口需要測試的方面：

關注被測接口的功能是否實現，性能是否達標，安全性是否滿足。重點關注數據的交換、傳遞、處理次數、以及控制管理過程。可參考下面用例設計中的接口測試點。

2、編寫和執行測試時的原則：

不同的接口參數覆蓋不同的業務場景；
在后臺構造合適的數據來滿足接口的測試用例；
根據接口的返回值，斷言其是否返回期望結果，并查看數據庫驗證；
測試用例涉及多個步驟的，應對涉及的步驟都驗證
刪除測試過程中產生的結果，確保每個用例執行前都是一個清潔的環境

3、接口測試的重難點：

動態變量參數化
接口依賴及中間變量問題
異步接口結果驗證問題
相應參數及嵌套很多的驗證問題
接口測試框架的穩定性問題
資源清理問題
多接口場景測試

四、接口測試的用例設計

接口測試對象主要為接口，但隨著系統復雜度越來越高，接口越來越多，完全覆蓋是一件很困難的事情，且實際過程中任意接口的變動都可能導致我們接口測試用例不可用。

1、接口測試點參考：

2、接口用例設計優先級

優先級-->針對所有接口：

暴露在外面的接口，因為通常該接口會給第三方調用；
供系統內部調用的核心功能接口；
供系統內部調用非核心功能接口；

優先級-->針對單個接口：

正向用例優先測試，逆向（異常）用例次之 (通常情況，非絕對)；
是否滿足前提條件 > 是否攜帶默認參值參數 > 參數是否必填 > 參數之間是否存在關聯 > 參數數據類型限制 > 參數數據類型自身的數據范圍值限制
是否滿足前提條件：有些接口需要滿足前置條件，才可成功獲取數據。常見的，需要登陸 Token。逆向用例：針對是否滿足前置條件 (假設為 n 個條件)，設計 0~n 條用例；
是否攜帶默認值參數：設計 1 條正向用例，帶默認值的參數都不填寫、不傳參，必填參數都填寫正確且存在的 “常規” 值，非必填參數不填寫、不傳參；
業務規則、功能需求：根據實際情況結合接口參數說明，可能需要設計 n 條正向用例和逆向用例
參數是否必填：針對每個必填參數，都設計 1 條參數值為空的逆向用例
參數之間是否存在關聯：有些參數彼此之間存在相互制約的關系。逆向用例：根據實際情況，可能需要設計 0~n 條用例
參數數據類型限制：針對每個參數都設計 1 條參數值類型不符的逆向用例
參數數據類型自身的數據范圍值限制：針對所有參數，設計 1 條每個參數的參數值在數據范圍內為最大值的正向用例；針對每個參數 (假設 n 個)，設計 n 條每個參數的參數值都超出數據范圍最大值的逆向用例；針對每個參數 (假設 n 個)，設計 n 條每個參數的參數值都小于數據范圍最小值的逆向用例

以上幾個方面考慮全的話，基本可以做到如下幾個方面的覆蓋：主流程測試用例：正常的主流程功能校驗；分支流測試用例：正常的分支流功能校驗。異常流測試用例：異常容錯校驗

五、接口測試的流程

接口測試的流程和功能測試流程類似，依據的對象是需求說明書和接口需求，接口測試流程如下：

1、接口測試需求分析（從 UI 交互和接口參數分析接口的設計邏輯）

首先根據接口設計的技術架構方案，了解清楚被測接口對應的公共入參、入參、出參及返回數據的 Json 結構規范，根據測試場景進行測試。

理解接口參數，熟悉接口參數的輸入要求、輸入值范圍、必填項等；

理解接口輸出，熟悉返回 json 的結構構成、返回值類別、返回值范圍、返回 data 的不同類型等。

理解接口的邏輯、接口的業務關聯，熟悉技術方案中的接口相互關聯、依賴的關系，接口與接口之間的數據傳遞等。

尋找測試點，根據輸入 (參數名、取值范圍)、輸出 (參數名、返回值范圍)、關聯關系，進行測試點分析；

2、編寫接口測試計劃

接口測試計劃與功能測試計劃的目標一致，都是為了確認需求、確定測試環境及測試方法，為設計測試用例做準備，初步指定接口測試進度方案。接口測試計劃包括概述、測試資源、測試功能及重點、測試策略、測試風險、測試標準。

3、編寫、評審、執行接口測試用例

編寫的接口用例評審通過后，借助測試工具執行測試，上報發現的問題

接口數據準備：

4、接口自動化測試持續集成要點

項目測試時，接口會有變更，用例也會更新，需要借助工具（如github）來維護測試用例進行持續集成，通過自動化測試實時監控項目接口運行情況。接口自動化測試持續集成主要包括以下內容：

流程方面。在回歸階段加強接口異常場景的覆蓋，并逐步向系統測試、冒煙測試階段延伸，最終達到全流程自動化。
結果展示。更加豐富的結果展示、趨勢分析、質量統計和分析等。
問題定位。報錯信息、日志更精準，方便問題復現與定位。
結果校驗。加強自動化校驗能力，如數據庫信息校驗。
代碼覆蓋率。不斷嘗試有目前的黑盒向白盒下探，提高代碼覆蓋率。
性能需求。完善性能測試體系，通過自動化的手段監控接口性能指標是否正常。

5、接口測試流程例子

測試A借助Postman工具測試接口
每天或定期將最新的接口集合文件導出到本地
將最新的集合文件推送到git服務器
Jenkins每次運行接口測試時，先做一次文件拉取動作，再通過命令行執行接口測試
將測試結果通過郵件或釘釘發送給項目負責人

六、各種場景下的接口測試

1、單接口的測試

單接口測試的重點，其實就是保證該接口的正確性和健壯性。也就是說，你既要保證這個接口可以按照需求，正確處理傳入的參數，給出正確的返回；也可以按照需求，正確的拒絕傳入非正確的參數，給出正確的拒絕性返回。

總結：需要有足夠的用例保證接口能正確處理各種正常情況和異常情況

2、業務流程的接口測試（多接口測試）

主要是保障通過多個接口的串聯操作可以完成原來需求中提出的業務邏輯

總結：重點在于業務流程是否能跑通

拓展：我們更需要關心業務流和數據流的關系，要完成整體業務邏輯的接口測試，需要理清每個流程的數據流程，而數據流程驅動了業務流處理,。并不需要再過度關心如何用業務流的方法覆蓋更多的代碼邏輯異常

3、復雜場景的接口測試

測試場景一：被測業務操作是由多個API調用協作完成

背景：一個單一的前端操作可能會觸發后端一系列的API調用，此時API的測試用例就不再是簡單的單個API調用，而是一系列API的調用

存在的情況：存在后一個API需要使用前一個API返回結果的情況；需要根據前一個API的返回結果決定后面應該調用哪個API

存在問題：如何高效地獲取單個前端操作所觸發的API調用順序

解決上述問題思路：通過網絡監控手段，捕獲單個前端操作時所觸發的API調用順序，譬如Fiddler、Charles等抓包工具。也可以通過用戶行為日志，通過大數據手段來獲取調用順序

測試場景二：API 測試過程中的第三方依賴

背景：API 之間是存在依賴關系的，比如你的被測對象是 API A，但是 API A 的內部調用了 API B，此時如果由于某種原因，API B 在被測環境中處于不可用狀態，那么 API A 的測試就會受到影響。

在單體架構下，通常只會在涉及到第三方 API 集成的場景中才會遇到這個問題，所以還不算嚴重。但是，在微服務架構下，API 間相互耦合的依賴問題就會非常嚴重。

解決問題的核心思路：啟用 Mock Server 來代替真實的 API

測試場景三：異步 API 的測試

什么是異步API：調用后會立即返回，但是實際任務并沒有真正完成，而是需要稍后去查詢或者回調（Callback）的 API

對異步 API 的測試主要分為兩個部分：

測試異步調用是否成功：檢查返回值和后臺工作線程是否被創建兩個方面就可以了
測試異步調用的業務邏輯處理是否正確

測試異步調用的業務邏輯復雜性：因為異步 API 通常發生在一些比較慢的操作上，比如數據庫 I/O、消息隊列 I/O 等，此時測試往往需要去驗證數據庫中的值、消息隊列中的值等，這就需要測試代碼具有訪問和操作數據庫或者消息隊列的能力。在實際工程項目中，這些能力一般會在測試框架級別提供，也就是說要求 API 測試框架中包含對應的工具類去訪問和操作數據庫或者消息隊列等。

最后感謝每一個認真閱讀我文章的人，禮尚往來總是要有的，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走：