知其然亦知其所以然，接口測試沒有那么復雜，但也沒有那么簡單。

本文作者：張敏，軟件測試工程師，就職于一家容器平臺解決方案公司，負責 DevOps 產品的測試。

什么是 API

API(Application Programming Interface)是一些預先定義的函數，或指軟件系統不同組成部分銜接的約定。也可以理解為是兩個應用程序之間通信的機制，或者使用一組規則和協議的組件或計算機硬件。

提供應用程序與開發人員基于某軟件或硬件得以訪問一組例程的能力，而又無需訪問源代碼，或理解內部工作機制的細節。

API 被編寫并使用在以下幾個地方：

• 基于 Web 的應用程序
• 電腦操作系統
• 數據庫系統
• 計算機硬件
• 軟件庫

上面是很廣義的 API 的概念，包含了硬件和軟件，但我們常說的 API 其實是很狹義的 Web Service 或者說 Web API 。

Web Service

Web Service 是一個平臺獨立的，低耦合的，自包含的、基于可編程的 web 的應用程序，可使用開放的 XML(標準通用標記語言下的一個子集)標準來描述、發布、發現、協調和配置這些應用程序，用于開發分布式的交互操作的應用程序。

百度百科

Web Service 是 API 的實現，用于通過網絡(通常是 http/https)在 2 個應用程序之間進行通信。

所以 Web Service 和 Web API 是兩個概念：

• Web Service 是包裝在 HTTP 中的 API
• Web Service 需要網絡，然而，API 不需要網絡
• 所有的 Web Service 都是 APIs，但是并不是所有的 API 都是 Web Service

而實現 Web Service 的方式有三種：

• 【面向方法】RPC 遠程過程調用的架構：包括 XML-RPC/JSON-RPC 協議
• 【面向消息】SOA 面向服務的架構：包括 SOAP 協議
• 【面向資源】REST 表現層狀態轉化的架構

REST & RESTful

我們大多數時間最常接觸到的就是 REST 風格的 Web Service

REST 是 Web 服務的一種架構風格，一種設計風格，是一種思想，非協議也非規范。

簡單看一下傳統 API 設計以及 REST API 設計：

非 REST 設計：

# 查詢用戶http://localhost:8080/admin/getUser# 新增用戶http://localhost:8080/admin/addUser# 更新用戶http://localhost:8080/admin/updateUser# 刪除用戶http://localhost:8080/admin/deleteUser

結論：以不同的 URL(主要為使用動詞)進行不同的操作。

REST 架構：

# 查詢用戶GET http://localhost:8080/admin/user # 新增用戶POST http://localhost:8080/admin/user # 更新用戶PUT http://localhost:8080/admin/user # 刪除用戶DELETE http://localhost:8080/admin/user

結論：URL 只指定資源，以 HTTP 方法動詞進行不同的操作。用 HTTP STATUS/CODE 定義操作結果。

RESTful 是一種常見的 REST 應用，是遵循 REST 風格的 Web 服務，REST 式的 Web Service 是一種 ROA(面向資源的架構)。并且有以下幾個特點：

• 每一個 URI 代表一種資源；
• 客戶端和服務器之間，傳遞這種資源的某種表現層；
• 客戶端通過四個 HTTP 動詞(get、post、put、delete)，對服務器端資源進行操作，實現“表現層狀態轉化”。

標準的 RESTful 只有這四種操作 GET、POST、PUT、DELETE。這四種動作對應資源的增刪改查操作。

• 查 GET
• 增 POST
• 改 PUT
• 刪 DELETE

而我們還常接觸的 HEAD、PATCH 其實不屬于標準的 RESTful，可以理解為是開發人員以 RESTful 為標準約定的一種簡單的方法。

所以目前我們所接觸的應用是沒有完全按照 RESTful 風格進行開發的，都是基于 RESTful 風格進行開發。

冪等性：對同一REST接口的多次訪問，得到的資源狀態是相同的。

安全性：對該REST接口訪問，不會使服務器端資源的狀態發生改變。

URI & URL

提到了 URI，就簡單了解一下 URI 和 URL 的區別

• URI：統一資源標識符
• URL：統一資源定位符

所有的 URL 都是 URI。

舉個簡單的例子，我們知道百度的地址是 https://www.baidu.com/，但如果我們想閱讀一篇關于 API 的文章，不能通過 https://www.baidu.com/ 這個地址去瀏覽想要閱讀的文章，需要在后面加上一定的參數，比如文章的 ID 等等。

所以，https://www.baidu.com/ 就是一個 URI，它只是標識了一個資源，但是并沒有定位到某一具體的資源。而某篇文章的具體地址就是 URL ，它定位了一個資源，我們可以通過這個 URL 找尋到該文章的位置。

所以 REST 架構是面向資源的架構，它的每一條 URL 代表的就是一個具體的資源。

什么是 API 測試

直接測試應用程序編程接口(API)，并作為集成測試的一部分來確定它們是否滿足功能、可靠性、性能和安全性的期望。這就是 API 測試。

API 測試的優勢

• 更早期的測試

一旦實現了邏輯，就可以構建測試來驗證響應和數據的正確性，而不必等待構建前端。

• 更簡單的測試維護

UI是不斷變化的，但是 API 沒有這樣的挑戰，API 測試現在被認為是自動化測試的關鍵，因為 API 現在是應用程序邏輯的主要接口。

• 更快的解決問題

當 API 測試失敗時，我們確切地知道系統哪里壞了，哪里可以找到缺陷。

• 更快的測試速度和更廣的覆蓋范圍

300 個UI測試可能需要 30 小時才能運行。300 個 API 測試可能在 3 分鐘內運行。這意味著將在更短的時間內發現更多的 Bug，同時也將立即修復它們。

API 測試的內容

如何進行 API 測試

API 測試的開始時間并非在完成產品之后，在獲得接口文檔以后，就可以開始 API 測試。

API 測試的測試用例需要根據接口文檔進行撰寫，所以 API 測試十分依賴接口文檔，因此需要確保接口文檔的正確性。

測試前需要準備測試環境，如果沒有正式的測試環境，可以先進行 Mock。

API 測試的范圍很廣，包括異常情況測試，性能測試等等，需要根據測試的內容選擇合適的測試工具，抓包類的工具包括 Charles，Fiddler，Wireshark 等，測試腳本可以用過多種語言編寫，包括 Python，Java，Go 等，測試工具包括 JMeter，Postman，ACCELQ 等等。

測試執行時，一旦出現問題，可以十分快速的定位出現問題的部分，及時反饋給開發人員進行修復。

測試完成后，需要完成測試報告，對 API 測試進行整體的歸納總結。

API 測試評判標準

往更細的說，我們經常接觸的 API 測試其實就是對 URL 資源的操作。簡單來說，一個 URL 就是一個接口，而 URL 則由以下幾部分組成：

• 業務功能覆蓋是否完整
• 業務規則覆蓋是否完整
• 參數驗證是否達到要求(邊界、業務規則)
• 接口異常場景覆蓋是否完整
• 接口覆蓋率是否達到要求
• 代碼覆蓋率是否達到要求
• 性能指標是否滿足要求
• 安全指標是否滿足要求(SQL 注入)

單個 API 測試

往更細的說，我們經常接觸的 API 測試其實就是對 URL 資源的操作。簡單來說，一個 URL 就是一個接口，而 URL 則由以下幾部分組成：

• 請求協議：

http — 普通的 http 請求

https — 加密的 http 請求，傳輸數據更加安全

ftp — 文件傳輸協議，主要用來傳輸文件

• 請求 IP：服務器地址
• 請求端口：服務器所開放的端口，不填寫默認為80
• 接口路徑：被操作的資源路徑
• 接口參數：參數在接口路徑后，使用 “?” 與路徑進行區分，參數間使用 “&” 間隔

除以上部分，需要測試一個 API，還需要知道以下部分:

• http 請求方式：包括 GET /POST/PUT/DELETE 等
• http 請求頭：請求頭包含許多有關的客戶端環境和請求正文的有用信息。例如，請求頭可以聲明瀏覽器所用的語言，請求正文的長度。示例：

Accept: application/json, text/plain, */*Content-Type: application/json;charset=UTF-8Authorization:eyJhbGciOiJIUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36

• http 請求體：API 發送的 body 數據，有多種格式

json格式

xml格式

html格式

二進制格式( 多數用于圖片 )

字符串格式

當了解 API 的整個請求結構后，就能進行 API 測試了。而 API 測試主要測試的內容也是 API 的參數，設計測試用例時完全可以采用功能測試設計用例的方法來設計，比如正常發送請求，或者參數不傳值，傳值類型不正確等等多種異常情況。

API 測試步驟如下:

發送帶有必要輸入數據的請求

獲取具有輸出數據的響應

驗證響應是否按要求返回

該 API 測試的驗證方式就是通過 HTTP 響應碼，返回數據格式 ，返回數據類型，返回數據信息這四部分進行驗證。

• HTTP 響應碼：1xx(臨時響應) 、2xx (成功) 、3xx (重定向) 、4xx(請求錯誤) 、 5xx(服務器錯誤)
• 返回數據格式：json、xml
• 返回數據類型：string、int、Booleans
• 返回數據信息：檢驗是否符合預期，根據測試要求選擇是否比對數據庫數據，保證測試結果的準確性

總結來說，進行 API 測試的時候，可以考慮以下幾個方面:

• 理解 API 的需求
• 指定 API 輸出狀態(響應狀態代碼)
• 關注小型函數 API(登錄 API、獲取令牌 API、健康檢查 API)
• 對 API 進行分組(同一類別的 API 共享一些公共信息，如資源類型、路徑等)
• 利用自動化功能進行 API 測試
• 選擇合適的自動化工具
• 選擇合適的驗證方法
• 創建正面測試和負面測試
• 現場測試過程
• 不要低估 API 自動化測試

開始愉快的 API 測試之旅吧～

-- END --

總結

以上是生活随笔為你收集整理的接口传值后不起作用_聊一聊 API 接口测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。