「在自動化測試的世界裡，UI 測試就像是搭乘浪漫的大西洋郵輪——風景優美但又慢又貴；而 API 測試則是搭乘超音速高鐵——雖然沒有漂亮的風景，但能以 10 倍的速度把你精準送達目的地。」

大家好，我是 Jane，一個每天在第一線處理跨平台（Web & App）自動化測試、跟 CI/CD Pipeline 與各種測試層級奮戰的自動化測試工程師（SDET）。

在上集 Day 18 中，我們聊到了如何處理外部服務，以及使用 Mock 與 Stub 隔離環境。

在經歷了 Day 11~15 關於 UI 自動化測試各種「脆弱性（Flaky）」的折磨後，許多剛接觸自動化的 QA 常會發出這樣的感嘆：

• 「Jane，我們每天花幾小時修 Web/App 的 DOM 改版與 Timeout，到底有沒有更划算、更穩定的自動化測試作法？」

答案是：有的，那就是『API 自動化測試』！

身為同時把關 Web 與 App 品質的 SDET，如果有人問我「有限的資源下，最推薦先投資哪一種自動化測試？」我的答案絕對是 API 測試。

今天這篇文章，我們就來從速度、穩定性、問題定位、涵蓋能力與維護成本等 5 個維度，深度剖析為什麼 API 測試通常比 UI 測試划算 10 倍！

一、 5 維度硬核對比：API 測試 vs. UI 測試

我們用一張對照表，直觀看懂這兩種測試層級的本質差異：

| 評估維度 | API 自動化測試 | Web / App UI 自動化測試 |
| 1. 執行速度 (Speed) | 極快（單個 API 毫秒級，數百個案例 1 分鐘跑完）。 | 緩慢（需啟動瀏覽器/模擬器，單案例需 10~30 秒）。 |
| 2. 穩定性 (Stability) | 極高（JSON Schema 與 HTTP 狀態碼極少變動）。 | 脆弱 (Brittle)（容易受 DOM 改版、動畫、網路卡頓影響）。 |
| 3. 問題定位 (MTTR) | 精準（直接指出是哪個 API、欄位或狀態碼錯誤）。 | 模糊（只知道「按鈕點不到」或「頁面卡住」，需排查原因）。 |
| 4. 商業邏輯涵蓋 (Coverage) | 完整（可輕易驗證邊界值、極端欄位、權限控管）。 | 局限（許多後端商業邏輯與邊界值無法透過 UI 觸發）。 |
| 5. 維護成本 (Maintenance) | 低廉（後端規格穩定，重構成本低）。 | 高昂（UI 樣式與元件頻繁改版，需持續微調定位器）。 |

二、 為什麼說 API 測試「划算 10 倍」？3 大核心優勢

                    ┌─────────────────────────┐
                    │   API 測試 3 大超能力     │
                    └────────────┬────────────┘
                                 │
     ┌───────────────────────────┼───────────────────────────┐
     ▼                           ▼                           ▼
1. 快速回饋 (Shift-Left)   2. 跨平台共通性 (Web & App)   3. 輕鬆覆蓋極端邊界情境

1. 左移測試（Shift-Left）：在 UI 還沒蓋好前就能開始測試

在 Web 與 App 的開發流程中，後端 API 往往比前端 UI 更早完成（或是先定義好 API Doc / OpenAPI 規範）。

• UI 測試：必須等前端工程師切好版、串好 API、把頁面刻出來後，QA 才能開始寫腳本。
• API 測試：後端程式碼一 Commit，SDET 就能立刻寫 API 自動化去打死各種邏輯 Bug。發現 Bug 的時間點越早，修復的成本就越低！

2. 跨平台共通性（Cross-Platform Consistency）

不管你的產品是 Web 網頁、iOS App 還是 Android App，它們底層呼叫的後端 API 通常是同一套！

寫好一套 API 自動化測試，就能同時為 Web、iOS 與 Android 三端把關最核心的商業邏輯。這比分別寫 Web Playwright、iOS Appium、Android Espresso 划算太多了。

3. 輕鬆覆蓋 UI 根本摸不到的「極端邊界情境」

假設你要測試「購買數量為 -1 時系統的反應」：

• 前端 UI 通常會在 <input type="number"> 做限制，根本不讓你輸入負數。

• 但黑客或惡意使用者可能會繞過 UI，直接透過 HTTP 請求發送 quantity: -1。

  API 測試能輕鬆繞過前端表單驗證，直接檢驗後端 API 的防護力（Validation）與安全性。

三、 Python / pytest 實戰：API 測試範例

在 Python 生態系中，寫 API 測試極度簡單且優雅。我們只需要 pytest + requests（或是 Playwright 的 api_request_context）：

Python

# tests/api/test_checkout_api.py
import pytest
import requests
from config.settings import settings

def test_checkout_should_fail_when_quantity_is_negative(auth_headers: dict):
    """
    測試情境：直接驗證 API 針對極端邊界值 (負數數量) 的防禦力
    """
    payload = {
        "product_id": "PROD_9981",
        "quantity": -1,  # 極端邊界值
        "coupon_code": "DISCOUNT100"
    }

    # 直接發送 POST 請求，執行速度只需 50 毫秒！
    response = requests.post(
        f"{settings.BASE_URL}/api/v1/checkout",
        json=payload,
        headers=auth_headers
    )

    # 精準斷言：驗證 HTTP 狀態碼與 JSON 回傳的錯誤訊息
    assert response.status_code == 400
    res_data = response.json()
    assert res_data["code"] == "INVALID_QUANTITY"
    assert "數量不能為負數" in res_data["message"]

比起寫一段開啟瀏覽器、登入、點擊購物車、輸入 -1 的 UI 腳本，上面這段 API 測試：

1. 執行速度快了 50 倍（50ms vs. 2.5s）。
2. 不會因為 UI 跑版而 Flaky。
3. 失敗時能立刻知道是後端沒擋好（400 變 200）還是欄位名稱改了。

四、 SDET 的心法：不是放棄 UI，而是「層級下沉」

看到這裡，你可能會問：「Jane，照你這麼說，我們完全不需要寫 UI 自動化測試了嗎？」

當然不是！ 測試金字塔（Day 3）依然成立：

• UI 自動化：保留 10%~20%，專注在最核心的 Happy Path / Critical Path（例如：確保使用者真的能從首頁一路點到付款成功），以及 Web/App 特有的 UI 互動與動畫。
• API 自動化：扛下 70%~80% 的商業邏輯、邊界條件、權限控管與資料驗證。

資深 SDET 的功力，在於懂得把『邏輯驗證』從脆弱的 UI 層下沉到穩固的 API 層！

明日預告

既然 API 自動化測試這麼划算，那我們該如何設計一套真正「有價值」的 API 測試？

許多工程師寫 API 測試時，只驗證了 status_code == 200，結果 Response 裡面的 JSON 欄位全空或是資料全錯，測試依然亮綠燈！

明天 Day 20，我們將深入探討：《 Day 20｜如何設計有價值的 API 自動化測試：除了 200 OK 以外的關鍵驗證 》。