API 測試的具體實現

目錄

• API 測試的具體實現
  • 基於 Spring Boot 構建的 API
  • 使用 cURL 命令行工具進行測試
  • 使用圖形界面工具 Postman 進行測試
  • 如何應對複雜場景的 API 測試？
  • 總結

API 測試的具體實現

基於 Spring Boot 構建的 API

由於基於 Spring Boot 從 0 到 1 構建一個 API，並非本文的重點，爲了避免影響你對文章主要內容的把握，我直接採用了一個預先開發好的 Account API 爲例展開講解。你能夠從https://github.com/SpectoLabs/spring-cloud-contract-blog下載完整的代碼。

這個 Account API 的功能很是簡單，就是基於你提供的 ID 值建立一個 Account 對象，並返回這個新建立 Account 對象。

好比，若是你的請求是「account/ID008」，那麼返回的 response 就應該是「{「id」:「ID008」,「type」:「friends」,「email」:「robin@api.io」}」。

這個 Account API 的功能邏輯實現很是簡單，圖 1 和圖 2 列出了主要的代碼邏輯。

圖 1 中，代碼的第 21 行說明了 API 的 endpoint 以及對應的操做是 GET 方法，第 22 行明確說明了 GET 方法具體的業務邏輯是由 accountService.getById() 方法實現的。

圖 1 RestController 的實現

圖 2 中，代碼的第 8 行實現了 accountService.getById() 方法，具體邏輯就是返回一個以傳入 ID 爲 ID 的 Account 對象。

圖 2 具體業務邏輯的實現

我推薦使用 IntelliJ 打開這個下載的項目，而後直接啓動其中的 account-service。啓動成功後，account-service 會運行在本地機器的 8080 端口。啓動成功後的界面如圖 3 所示。

圖 3 成功啓動基於 Spring Boot 的 Account API

使用 cURL 命令行工具進行測試

首先，你須要下載安裝 cURL，而後就能夠經過如下命令發起 Account API 的調用。調用結束後的界面如圖 4 所示。

curl -i -H "Accept: application/json" -X GET "http://127.0.0.1:8080/account/ID008"
複製代碼

圖 4 使用 cURL 測試 Account API

這行命令中參數的含義以下：

• 第一個參數「-i」，說明須要顯示 response 的 header 信息；
• 第二個參數「-H」，用於設定 request 中的 header；
• 第三個參數「-X」，用於指定執行的方法，這裏使用了 GET 方法，其餘常見的方法還有 POST、PUT 和 DELETE 等，若是不指定「-X」，那麼默認的方法就是 GET。
• 最後「 http://127.0.0.1:8080/account/ID008 」，指明瞭被測 API 的 endpoint 以及具體的 ID 值是「ID008」。

當使用 cURL 進行 API 測試時，經常使用參數還有兩個：

• 「-d」：用於設定 http 參數，http 參數能夠直接加在 URL 的 query string，也能夠用「-d」帶入參數。參數之間能夠用「&」串接，或使用多個「-d」。
• 「-b」：當須要傳遞 cookie 時，用於指定 cookie 文件的路徑。

須要注意的是這些參數都是大小寫敏感的。

瞭解了這幾個最經常使用的參數後，我再來分析一些最經常使用的 cURL 命令以及使用的場景，包括 Session 的場景和 Cookie 的場景。

第一，Session 的場景

若是後端工程師使用 session 記錄使用者登入信息，那麼後端一般會傳一個 session ID 給前端。以後，前端在發給後端的 requests 的 header 中就須要設置此 session ID，後端便會以此 session ID 識別出前端是屬於具體哪一個 session，此時 cURL 的命令行以下所示：

curl -i -H "sessionid:XXXXXXXXXX" -X GET "http://XXX/api/demoAPI"
複製代碼

第二，Cookie 的場景

若是是使用 cookie，在認證成功後，後端會返回 cookie 給前端，前端能夠把該 cookie 保存成爲文件，當須要再次使用該 cookie 時，再用「-b cookie_File」 的方式在 request 中植入 cookie 便可正常使用。具體的 cURL 的命令行以下所示：

// 將 cookie 保存爲文件
curl -i -X POST -d username=robin -d password=password123 -c ~/cookie.txt "http://XXX/auth"
 
// 載入 cookie 到 request 中
curl -i -H "Accept:application/json" -X GET -b ~/cookie.txt "http://XXX/api/demoAPI"

最後，須要特別說明的是，cURL 只能發起 API 調用，而其自己並不具有結果驗證能力（結果驗證由人完成），因此嚴格意義上說 cURL 並不屬於測試工具的範疇。可是因爲 cURL 足夠輕量級，常常被不少開發人員和測試人員使用，因此我在這裏作了簡單的介紹。

接下來，咱們再來看看如何使用目前主流的 Postman 完成 API 測試。

使用圖形界面工具 Postman 進行測試

Postman 是目前使用最普遍的 Http 請求模擬工具之一，經常被用於 Web Service API 的測試。

早期的 Postman，是以 Chrome 瀏覽器的插件（plugin）形式存在的，最新版本的 Postman 已是獨立的應用了。我猜測是由於這個工具的應用日益普遍，因此纔有了今天的獨立版本。

你能夠經過官方網站下載對應於 Mac、Windows 和 Linux 操做系統的不一樣版本，截止文章寫做完成時，最新的 Mac 版本是 6.2.2。

接下來，我就會以 Mac 6.2.2 版本爲例，跟你分享如何用 Postman 完成你的 API 測試。若是你使用瀏覽器的 plugin 版本，或者是基於其餘操做系統的版本，這都沒問題，基本的操做和步驟都是同樣的。

具體的操做，主要包括：

1. 發起 API 調用；
2. 添加結果驗證；
3. 保存測試用例；
4. 基於 Postman 的測試代碼自動生成。

第一步，發起 API 調用

咱們的目標是對 Account API 作測試，因此這裏你須要選擇 Postmant 的「Request」模塊。進入相應界面後，你須要按照圖 5 的提示依次執行如下三步操做，發起 Account API 的調用。

1. 在 endpoint 輸入框中輸入「http://127.0.0.1:8080/account/ID_008」；
2. 選擇「GET」方法；
3. 點擊「Send」按鈕發起 API 調用。

圖 5 Postman 發起 Account API 的測試

完成以上步驟後，界面如圖 6 所示。咱們看到返回的 response 默認以 JSON 文件的形式顯示在下面的 Body 中。

圖 6 Postman 執行 GET 後的界面

這樣就完成了一次 Account API 的調用，是否是很是簡單。但問題是，這只是一個 API 調用，並無對調用結果進行自動化驗證。接下來，咱們就加上結果驗證的部分，一塊兒看看會有什麼效果。

第二步，添加結果驗證

在 Postman 中添加結果驗證也很是方便，假定咱們在 Account API 測試過程當中有如下四個驗證點：

1. 請求的返回狀態碼（Status Code）應該是 200；
2. 請求的響應時間應該小於 200 ms；
3. 請求返回的 response header 中應該包含「Content-Type」參數；
4. 請求返回的 response body 中，「type」的值應該是「friends」；

那麼，接下來咱們一塊兒來看看如何使用 Postman 來添加這四個驗證點。

爲此，咱們首先打開「Tests」界面，而後在右下角的「SNIPPETS」中依次點擊：

1. 「Status code: Code is 200」
2. 「Response time is less than 200 ms」
3. 「Response headers：Content-Type header check」
4. 「Response body: JSON value check」

完成以上操做後，「Tests」中會自動生成驗證代碼，接着只要按照具體的測試要求，對這些生成的代碼進行一些小修改就能夠了。

在這個例子中，你只需修改須要驗證的 JSON 鍵值對便可，即代碼的第 15 行。修改完成後咱們能夠再次點擊「Send」按鈕發起測試。測試經過的界面如圖 7 所示，最下面的「Test Results」顯示四個測試所有經過。

圖 7 測試經過的界面

第三步，保存測試用例

測試經過後，咱們每每但願能夠把這個測試 request 保存下來，以方便後續使用，爲此 Postman 提供了保存測試 request 的功能，並提供了 Collection 來分類管理保存多個測試 request。

Collection 是用來保存測試 request 的一個集合，Collection 內部還能夠創建目錄結構以方便進一步的分類和管理。

這裏咱們點擊「Save As」按鈕，在彈出的對話框中能夠創建 Collection，而且能夠命名測試 request 並將其保存到 Collection 中。

我創建了「API Test Demo」的 Collection，而且將剛纔的測試 request 命名爲「AccountAPI」保存到這個 Collection 中。

之後再要使用這個測試 request 時，直接在 Collection 中打開它，便可使用。同時你若是申請註冊了一個 Postman 帳號，就能夠很方便地在多個環境中共享這個 Collection 了。

第四步，基於 Postman 的測試代碼自動生成

至此，你已經掌握了 Postman 最基本的使用方法，但還有一個問題沒有解決。不少時候，你但願將你的測試 request 做爲迴歸測試用例集成到 CI/CD 的流程中，這就要求能夠經過命令行的方式執行你的測試。爲了達到這個目的，目前有兩種作法：

1. 將 Postman 中的測試 request 用自動化的方式直接轉換成 API 測試的代碼。 目前 Postman 已經支持這個功能了，能夠將保存的測試 request 自動化轉換成常見測試框架直接支持的代碼，並且支持多語言。
   好比，基於 Java 的「OK HTTP」和「Unirest」，基於 Python 的「http.client」和「Requests」，基於 NodeJS 的「Native」「Request」和「Unirest」，基於 JavaScript 的「JQuery AJAX」和「XHR」等等。你能夠點擊如圖 8 所示的「Code」按鈕進入代碼生成界面。

圖 8 自動生成 API 測試代碼

1. 利用 Newman 工具直接執行 Postman 的 Collection。 你須要先將 Postman 中的 Collection 導出爲 JSON 文件，而後執行如下命令行。

newman run examples/sample-collection.json;
複製代碼

如何應對複雜場景的 API 測試？

我在前面分享的 Restful API 測試案例中，只涉及到了最基本的 API 的測試方法，並且測試場景也很比較簡單（只是單個 API 的調用）。

但在實際項目中，除了這種單個 API 的測試場景外，還有不少複雜場景的 API 測試。因此，爲了解決你在實際項目中可能會碰到的一些問題，我再和你聊聊目前一些常見的典型複雜場景，以及相應的測試思路和方法。

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

不少狀況下，一個單一的前端操做可能會觸發後端一系列的 API 調用，因爲前端測試的相對不穩定性，或者因爲性能測試的要求，你必須直接從後端經過模擬 API 的順序調用來模擬測試過程。

這時，API 的測試用例就再也不是簡單的單個 API 調用了，而是一系列 API 的調用，而且常常存在後一個 API 須要使用前一個 API 返回結果的狀況，以及須要根據前一個 API 的返回結果決定後面應該調用哪一個 API 的狀況。

好在，咱們已經實現了 API 的調用和結果解析的代碼化，這也就意味着咱們能夠很靈活地直接用代碼來處理這些場景了。 好比，經過代碼將上個 API 調用返回的 response 中的某個值傳遞給下一個 API，再好比根據上一個 API 的返回結果決定下一個應該調用哪一個 API 等。

除此以外，咱們還須要迫切解決的一個問題是：如何才能高效地獲取單個前端操做所觸發的 API 調用序列。

解決這個問題的核心思路是，經過網絡監控的手段，捕獲單個前端操做所觸發的 API 調用序列。好比，經過相似於 Fiddler 之類的網絡抓包工具，獲取這個調用序列；又好比，目前不少互聯網公司還在考慮基於用戶行爲日誌，經過大數據手段來獲取這個序列。

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

API 之間是存在依賴關係的，好比你的被測對象是 API A，可是 API A 的內部調用了 API B，此時若是因爲某種緣由，API B 在被測環境中處於不可用狀態，那麼 API A 的測試就會受到影響。

在單體架構下，一般只會在涉及到第三方 API 集成的場景中才會遇到這個問題，因此還不算嚴重。可是，在微服務架構下，API 間相互耦合的依賴問題就會很是嚴重。

解決這個問題的核心思路是，啓用 Mock Server 來代替真實的 API。那麼，Mock Server 怎麼才能真實有效地模擬被替代的 API 呢？這個問題，我會在分享《緊跟時代步伐：微服務模式下 API 測試要怎麼作？》這個主題時，和你詳細探討。

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

異步 API 是指，調用後會當即返回，可是實際任務並無真正完成，而是須要稍後去查詢或者回調（Callback）的 API。

一直以來，異步 API 測試都是 API 測試中比較困難的部分。在我看來，對異步 API 的測試主要分爲兩個部分：一是，測試異步調用是否成功，二是，測試異步調用的業務邏輯處理是否正確。

• 異步調用是否成功，這個還比較簡單，主要檢查返回值和後臺工做線程是否被建立兩個方面就能夠了。
• 可是，對異步調用業務邏輯的測試就比較複雜了，由於異步 API 一般發生在一些比較慢的操做上，好比數據庫 I/O、消息隊列 I/O 等，此時測試每每須要去驗證數據庫中的值、消息隊列中的值等，這就須要測試代碼具備訪問和操做數據庫或者消息隊列的能力。
  在實際工程項目中，這些能力通常會在測試框架級別提供，也就是說要求 API 測試框架中包含對應的工具類去訪問和操做數據庫或者消息隊列等。

總結

一般狀況下，不管你採用什麼 API 測試工具，基本的測試步驟每每都是三步，即準備測試數據（並非全部的 API 測試都須要這一步）、經過 API 測試工具發起對被測 API 的 request、驗證返回結果的 response。

接下來，我經過一個簡單的 Restful API 測試爲例，和你分享了 cURL 和 Postman 這兩個經常使用 API 測試工具的使用。

其中，cURL 只具有發起 API 調用的功能，而不具有結果驗證能力，因此嚴格地說它並不屬於測試工具的範疇。Postman 經常被用於 Web Service API 的測試具體的操做，測試流程主要包括：發起 API 調用、添加結果驗證、保存測試用例、基於 Postman 的測試代碼自動生成。

最後，爲了幫你應對實際工程項目中複雜的 API 測試場景，我分享了被測業務操做是由多個 API 調用協做完成、API 測試過程當中的第三方依賴、異步 API 的測試，這三個複雜場景下的測試思路和方法。