斷言與驗證

到目前為止，我們已經建立了發送請求和傳遞資料的測試場景。但是我們如何知道 API 是否真的正常運作？請求可能會返回 200 OK 但傳回空資料，或者更糟的是，錯誤的資料。

斷言 (Assertions) 是您測試的檢查點。它們自動驗證 API 回應是否符合您的期望。在本章中，我們將掌握標準回應斷言和強大的資料庫驗證。

什麼是斷言？

斷言只是一個必須為真才能通過測試的陳述。沒有斷言，您的測試本質上是在說：「我發送了一個請求，伺服器回覆了。」它確認了通訊，但沒有確認正確性。

有了斷言，您的測試變得具體：「我發送了一個請求，我期望狀態碼是 201，並且返回的使用者 ID 是一個數字。」如果這個期望未被滿足，測試會立即失敗，提醒您問題所在。

為什麼使用斷言？

您可能會想：「我只要看一眼回應就知道它是否正確。」對於單次手動測試，當然，您可以目測 JSON 並說：「嗯，看起來不錯。」

但自動化測試是盲目的。電腦需要明確的指令——斷言——來判斷通過或失敗。這在 回歸測試 期間變得至關重要。如果您每週部署新版本，您需要一個安全網來立即驗證數百個測試案例。您不能每次都手動檢查歷史回應；斷言為您做這件事。

新增您的第一個斷言

Apidog 使得新增斷言變得非常容易——對於大多數常見情況無需編碼。

方法：「後置操作 (Post-processors)」分頁

打開您的請求（例如 POST /users）。

前往 Post-processors 分頁。

點擊 Add Post-processor -> Assertion。

選擇斷言目標

您可以檢查幾乎任何東西：狀態碼、標頭、JSON Body 等。

您將看到一個用於配置斷言規則的詳細表單：

Name：給您的斷言一個清晰的名稱（例如「驗證使用者 ID」）。

Target Object：選擇資料來源（通常是 Response JSON 或 Response Header）。

JSONPath Expression：您想檢查的特定欄位（例如 $.data.id）。

Assertion：要應用的規則（例如 Equals、Is Not Null）和期望值。

常見斷言模式

以下是您應該檢查的最常見事項：

狀態碼：第一道防線。

Response.status.code Equals 200 (Success)

Response.status.code Equals 404 (Not Found)

回應時間：確保效能。

Response.time Less than 500 (ms)

JSON Body 值：驗證特定資料。

$.email Equals test@example.com

$.id Exists (Not null)

標頭值：檢查內容類型或驗證標頭。

Response.header.Content-Type Contains application/json

查看詳情斷言

專業提示：您也可以直接從 APIs > Request 分頁點擊回應欄位來新增斷言！

自動回應驗證

厭倦了手動檢查每個欄位？Apidog 有一個內建功能稱為 Response Validation（回應驗證），為您處理繁重的工作。

啟用後，Apidog 會將實際 API 回應與您在 API 文件中定義的 Response Definition (Schema) 進行比較。

在您的請求設定中，找到 Response Validation 開關。

如果 API 返回字串而預期是數字，或者缺少必填欄位，測試將自動失敗。

這確保您的實作與您的 API 設計契約保持嚴格同步。

真實案例：驗證使用者註冊

讓我們驗證上一章的 POST /users 端點。當我們建立使用者時，我們期望一個非常具體的結果。

我們的期望：

狀態必須是 201 Created（或 200）。

回應必須包含新的 id。

回應必須包含我們發送的相同 email。

回應必須不包含 password（安全檢查）。

在 Apidog 中的配置：

Subject	Comparator	Value	Description
`Response.status.code`	Equals	`201`	驗證建立成功
`$.id`	Exist	(Empty)	驗證返回了 ID
`$.email`	Equals	`{{newUserName}}`	驗證電子郵件匹配輸入
`$.password`	Is Null	(Empty)	驗證密碼已隱藏

配置完成後，運行請求。如果這些條件中有任何一個未被滿足，Apidog 將標記測試為失敗。

使用資料庫操作進行驗證

回應斷言很棒，但它們只告訴您 API 說它做了什麼。資料真的到達資料庫了嗎？

Database Operations（資料庫操作）允許您在測試步驟中直接連接到您的 SQL 資料庫，以驗證「基本事實」。

為什麼您需要這個

資料完整性：API 說「使用者已建立」，但記錄真的在 users 表中嗎？

狀態驗證：在狀態更新（例如「訂單已支付」）後，資料庫欄位是否正確更新？

資料清理：在測試完成後刪除測試期間建立的資料。

如何使用資料庫操作

配置連接：前往 Settings -> Database Connections 並新增您的 MySQL/PostgreSQL/Oracle 詳細資訊。

新增後置操作：在您的請求中，新增 Database Operation。

填寫表單：

Operation Name：例如「驗證使用者已建立」。

Database Connections：選擇您預配置的連接。

SQL Command：輸入您的查詢。您可以使用變數！

Extract Result To Variable：將查詢結果映射到變數以供將來斷言使用。

Variable：db_user_id

JSONPath Expression：$[0].id（從第一行提取 'id'）

斷言：現在您可以新增一個斷言步驟來檢查 {{db_user_id}} 是否匹配 API 回應 id。

查看詳情：Apidog 中的資料庫操作

進階：使用 `pm.dataSource` 編寫腳本

對於複雜驗證，您可以使用腳本一次性進行查詢和斷言。

最佳實踐

斷言一切：每個測試步驟都應該至少有一個狀態碼斷言。

具體明確：不要只檢查 200 OK。檢查 id 是一個數字且 status 是 "active"。

負面測試：建立預期失敗的測試案例。例如，發送無效的電子郵件並斷言狀態碼是 400 且錯誤訊息包含 "Invalid email"。

資料庫清潔：在工作流程結束時（Teardown）使用 DB 操作刪除測試期間建立的使用者。

關鍵重點

斷言對於可靠的自動化是強制性的；沒有它們，測試就是盲目的。

使用 視覺化斷言 滿足您 90% 的需求（狀態、Body、標頭）。

使用 資料庫操作 驗證資料完整性並真實驗證系統狀態。

結合 API 回應檢查與資料庫檢查，實現 全端 QA。

下一步

我們現在可以運行一個場景並驗證它是否運作。但是如果我們需要使用不同的名稱運行測試 100 次怎麼辦？或者根據條件跳過一個步驟？

在下一章中，我們將介紹 流程控制 (Flow Control) 和 迴圈 (Looping)，以在您的測試中建立邏輯。

繼續閱讀 → 流程控制：If, For, ForEach

什麼是斷言？#

為什麼使用斷言？#

新增您的第一個斷言#

方法：「後置操作 (Post-processors)」分頁#

選擇斷言目標#

常見斷言模式#

自動回應驗證#

真實案例：驗證使用者註冊#

使用資料庫操作進行驗證#

為什麼您需要這個#

如何使用資料庫操作#

進階：使用 pm.dataSource 編寫腳本#

最佳實踐#

關鍵重點#

下一步#