整合測試與資料傳遞

在之前的單元測試中，我們關注的是單個端點是否正常運作。然而，在現實世界中，API 很少孤立存在。它們通常需要協同工作，其中一個 API 的輸出成為另一個 API 的輸入。

整合測試 (Integration Testing) 是驗證這些組件在組合時是否正確運作的過程。在本章中，我們將深入探討如何在 Apidog 中建構強大的整合測試場景，並掌握自動化測試的核心技能：資料傳遞 (Data Passing)。

什麼是整合測試？

如果單元測試檢查「輪胎是否圓」或「引擎是否轉動」，那麼整合測試檢查的是「當安裝了輪胎和引擎後，汽車能否行駛」。

在 API 測試中，整合測試主要關注：

組件互動：資料是否在 API 之間順利流動？

業務工作流程：完整的使用者任務（例如「使用者註冊 -> 登入 -> 購買」）能否成功完成？

狀態一致性：一系列操作後，資料庫中的資料狀態是否正確？

為什麼它至關重要？

許多 Bug 只有在多個組件互動時才會暴露出來。例如，註冊介面可能成功返回使用者 ID，但如果此 ID 的格式不符合登入介面的要求，那麼即使註冊和登入的單獨測試通過，使用者仍然無法完成業務流程。

為什麼我們需要資料傳遞

在 測試場景 中，後續步驟通常依賴於先前步驟的結果。這就是為什麼我們需要 資料傳遞。

典型場景包括：

驗證流程：登入 介面返回一個 token，所有後續介面需要在 Header 中攜帶此 token。

資源操作：建立使用者 介面返回一個 userId，後續的 獲取、更新 和 刪除 使用者介面需要使用此 userId。

列表處理：獲取列表 介面返回一組資料，後續步驟需要從中提取特定 ID 進行處理。

Apidog 提供了兩種主要機制來實現資料傳遞：獲取前一步驟資料 (Retrieve Pre-step Data) 和 提取變數 (Extract Variables)。

方法 1：獲取前一步驟資料

這是 Apidog 獨有的一個方便功能，允許您直接「伸手」獲取先前步驟生成的資料，而無需建立變數。

使用案例

資料僅在緊接著的後續步驟中使用 1-2 次。

您不想污染全域或環境變數列表。

快速建構簡單的測試鏈路。

如何使用

假設我們要測試：步驟 1 登入 -> 步驟 2 獲取使用者資訊。步驟 2 需要使用步驟 1 返回的 Token。

將這兩個步驟新增到測試場景中。

點擊步驟 2 中參數輸入框旁邊的 魔術棒圖標 🪄。

選擇 Retrieve pre-step data。

在彈出介面中：

Step：選擇「步驟 1：登入」。

Result Type：選擇「Response Body」。

JSONPath：輸入或點擊選擇要提取的欄位，例如 $.token。

點擊插入，您將看到參數值變成像這樣的動態引用：{{$.2.response.body.token}}。

語法分解：

$：根節點

2：步驟 ID

response.body：資料來源（Response Body）

token：特定欄位路徑

注意：這種引用方法僅在 運行整個測試場景 時生效，因為先前步驟的真實資料僅在運行時生成。在除錯單個步驟時，您可能無法獲取值。

方法 2：提取變數

這是一個更通用和標準的方法，類似於 Postman 中的概念。它提取資料並將其儲存為 變數 (Variables)，這些變數可以透過 {{variable_name}} 在任何後續步驟中重複使用。

使用案例

資料需要在多個後續步驟中重複使用（例如 Token）。

資料需要在不同測試場景之間共享。

提取的資料在使用前需要處理（例如透過腳本）。

如何使用

同樣是 步驟 1 登入 -> 步驟 2 獲取使用者資訊。

點擊 Steps 1: 登入 並前往 Post-processors 分頁。

新增一個 Extract Variable 動作。

配置提取規則：

JSONPath：$.token（從回應中提取值的路徑）

Variable Name：accessToken（您定義的變數名稱）

Scope：Environment 或 Local（臨時變數，僅對此運行有效）。通常建議使用 Local 變數以避免污染環境。

在 步驟 2 及所有後續步驟 中，直接在參數值中使用 {{accessToken}}。

查看詳情：在請求之間傳遞資料

建構整合測試場景：使用者生命週期

讓我們透過建構一個經典的 CRUD（建立、讀取、更新、刪除）迴圈來練習整合測試。我們將建構一個 「使用者生命週期測試」 場景。

規劃測試步驟

步驟 1: 建立使用者
       --> 提取 userId 到變數 {{newUserId}}
       --> 提取 username 到變數 {{newUserName}}

步驟 2: 登入
       --> 使用 {{newUserName}} 登入
       --> 提取 token 到變數 {{authToken}}

步驟 3: 獲取使用者
       --> URL 參數使用 {{newUserId}}
       --> Header 使用 {{authToken}}

步驟 4: 更新使用者
       --> URL 參數使用 {{newUserId}}
       --> Body 使用 {{newUserName}} 和其他新資料
       --> Header 使用 {{authToken}}

步驟 5: 刪除使用者
       --> URL 參數使用 {{newUserId}}
       --> Header 使用 {{authToken}}

步驟 6: 驗證刪除
       --> 嘗試再次獲取使用者 {{newUserId}}
       --> 預期結果: 404 Not Found

指南

建立新測試場景：命名為「使用者生命週期整合」。

匯入步驟：將上述 5 個介面從 API 列表匯入場景。

配置步驟 1 (建立)：

在 Post-processors 中新增兩個變數提取：

$.id -> newUserId

$.username -> newUserName

配置步驟 2 (登入)：

修改 Body 參數，將使用者名稱值設定為 {{newUserName}}。

在 Post-processors 中提取變數：

$.token -> authToken

配置步驟 3-5：

修改 URL 中的 Path 參數 id，值為 {{newUserId}}。

在 Header 中新增 Authorization（如果未自動繼承），值為 Bearer {{authToken}}。

配置步驟 6 (驗證)：

這是一個負面測試。複製步驟 3 的請求。

修改其斷言（我們將在下一章詳細解釋斷言），期望狀態碼為 404。

最佳實踐

環境隔離：使用隨機生成的資料（例如 {{$randomUserName}}）註冊使用者，以避免多次運行導致的「使用者已存在」錯誤。

資料清理 (Teardown)：正如我們在「使用者生命週期」案例中所做的那樣，最好在測試的最後步驟刪除測試期間生成的垃圾資料（例如新使用者），以保持環境清潔。

變數命名約定：為變數新增前綴，例如 TEST_USER_ID vs GLOBAL_CONFIG_ID，以區分測試期間生成的臨時變數和全域配置。

關鍵重點

使用 獲取前一步驟資料 進行簡單的一次性資料傳遞

使用 提取變數 在多個步驟或場景中重複使用資料

建構涵蓋完整業務生命週期的全面 整合測試場景

驗證錯誤處理和跨模組互動

下一步

既然您可以將多個請求串聯成一個場景，您需要確保它們實際上按預期運作。僅僅因為請求返回「200 OK」並不意味著資料是正確的。

在下一章中，我們將學習如何使用 動態值 生成隨機資料（如唯一電子郵件）以防止測試期間的重複鍵錯誤。

繼續閱讀 → 動態值

整合測試與資料傳遞

什麼是整合測試？#

為什麼它至關重要？#

為什麼我們需要資料傳遞#

方法 1：獲取前一步驟資料#

使用案例#

如何使用#

方法 2：提取變數#

使用案例#

如何使用#

建構整合測試場景：使用者生命週期#

規劃測試步驟#

指南#

最佳實踐#

關鍵重點#

下一步#

什麼是整合測試？

為什麼它至關重要？

為什麼我們需要資料傳遞

方法 1：獲取前一步驟資料

使用案例

如何使用

方法 2：提取變數

使用案例

如何使用

建構整合測試場景：使用者生命週期

規劃測試步驟

指南

最佳實踐

關鍵重點

下一步