先講結論
寫 Test Case 最常見的錯誤不是格式問題，是只寫快樂路徑。
快樂路徑大多數人都會手動試，真正有價值的測試是例外情境：輸入非法值時、第三方服務掛掉時、同時多人操作時、邊界值上下時。這些情境如果不在 Test Case 裡，就只能靠上線後才發現。
為什麼需要 Test Case
Test Case 解決三個問題：
- 溝通：QA 和開發對「這個功能正確」的定義達成共識
- 覆蓋率：確保測試涵蓋了正常、異常、邊界三種情境
- 回歸：下次修改時，有依據可以快速確認有沒有壞掉其他東西
命名規則
TC-[模組代碼]-[三位數編號]
TC-AUTH-001 → 認證模組第一個測試案例
TC-ORD-015 → 訂單模組第十五個測試案例
TC-INV-003 → 庫存模組第三個測試案例
模組代碼和 FRD 的 FR 命名一致，方便對照。
測試類型
| 類型 | 定義 | 範例 |
|---|---|---|
| 正向測試（Positive） | 正常輸入，預期成功 | 正確帳密登入成功 |
| 負向測試（Negative） | 錯誤輸入或例外情境，預期失敗或出現正確錯誤訊息 | 密碼錯誤顯示錯誤訊息 |
| 邊界測試（Boundary） | 邊界值，最大/最小/剛好超過 | 密碼剛好 8 碼（最小值）可以登入 |
優先級
| 優先級 | 說明 |
|---|---|
| P1 | 核心功能，每次上線前必測 |
| P2 | 重要功能，每個 Sprint 測 |
| P3 | 邊緣案例，定期測或有時間才測 |
Test Case 表格格式
| 欄位 | 說明 |
|---|---|
| 編號 | TC-[模組]-[編號] |
| 測試名稱 | 一句話說明這個 Case 測什麼 |
| 類型 | Positive / Negative / Boundary |
| 優先級 | P1 / P2 / P3 |
| 前置條件 | 執行測試前的系統狀態 |
| 測試步驟 | 步驟說明（人工測試）或 API 請求 |
| 測試資料 | 具體輸入值 |
| 預期結果 | 系統應該有什麼反應 |
| 實際結果 | 實際執行後的結果（填寫時留空） |
| 狀態 | ⬜ 待測 / ✅ 通過 / ❌ 失敗 / ⏭️ 略過 |
範例一：會員登入模組
| 編號 | 測試名稱 | 類型 | 優先級 | 前置條件 | 測試步驟 | 測試資料 | 預期結果 | 實際結果 | 狀態 |
|---|---|---|---|---|---|---|---|---|---|
| TC-AUTH-001 | 正常登入 | Positive | P1 | 帳號已存在且已驗證 | 1. 輸入正確 Email 2. 輸入正確密碼 3. 點擊登入 | email: test@example.com password: Test1234 | 登入成功，導向首頁，顯示歡迎訊息 | ⬜ | |
| TC-AUTH-002 | 密碼錯誤 | Negative | P1 | 帳號已存在 | 1. 輸入正確 Email 2. 輸入錯誤密碼 3. 點擊登入 | email: test@example.com password: WrongPass | 顯示「帳號或密碼錯誤」，停留登入頁 | ⬜ | |
| TC-AUTH-003 | Email 不存在 | Negative | P1 | 無 | 1. 輸入不存在的 Email 2. 輸入任意密碼 3. 點擊登入 | email: notexist@example.com | 顯示「帳號或密碼錯誤」（不透露帳號是否存在） | ⬜ | |
| TC-AUTH-004 | Email 格式錯誤 | Negative | P2 | 無 | 1. 輸入格式錯誤的 Email 2. 點擊登入 | email: notanemail | 顯示「Email 格式不正確」，不送出請求 | ⬜ | |
| TC-AUTH-005 | 連續錯誤 5 次鎖定 | Negative | P1 | 帳號已存在 | 1. 輸入正確 Email 2. 輸入錯誤密碼 3. 重複 5 次 | email: test@example.com password: Wrong × 5 | 第 5 次後顯示「已鎖定，請 30 分鐘後再試」 | ⬜ | |
| TC-AUTH-006 | 帳號未驗證 | Negative | P2 | 帳號已建立但未點驗證信 | 1. 輸入未驗證帳號的 Email 2. 輸入正確密碼 3. 點擊登入 | email: unverified@example.com | 顯示「Email 尚未驗證，是否重新發送驗證信？」 | ⬜ | |
| TC-AUTH-007 | 空白欄位送出 | Boundary | P2 | 無 | 1. 不填任何欄位 2. 點擊登入 | 空白 | Email 和密碼欄位都顯示必填錯誤 | ⬜ | |
| TC-AUTH-008 | 密碼最短 8 碼 | Boundary | P2 | 無 | 1. 輸入正確 Email 2. 輸入 8 碼密碼（最短值） 3. 點擊登入 | password: Ab1cd234（剛好 8 碼） | 登入成功（如帳號存在） | ⬜ | |
| TC-AUTH-009 | 密碼 7 碼（低於最短） | Boundary | P2 | 無 | 1. 輸入任意 Email 2. 輸入 7 碼密碼 | password: Ab1cd23（7 碼） | 顯示「密碼最少 8 個字元」，不送出請求 | ⬜ |
範例二：訂單建立模組
| 編號 | 測試名稱 | 類型 | 優先級 | 前置條件 | 測試步驟 | 測試資料 | 預期結果 | 實際結果 | 狀態 |
|---|---|---|---|---|---|---|---|---|---|
| TC-ORD-001 | 正常下單 | Positive | P1 | 已登入、商品庫存充足 | 1. 選擇商品加入購物車 2. 前往結帳 3. 確認訂單 | 商品ID: 1, 數量: 2 | 訂單建立成功，收到確認信，庫存減少 2 | ⬜ | |
| TC-ORD-002 | 庫存不足 | Negative | P1 | 商品庫存為 1 | 1. 選擇商品 2. 設定數量為 5 3. 嘗試結帳 | 商品ID: 1, 數量: 5, 庫存: 1 | 顯示「庫存不足」，無法建立訂單 | ⬜ | |
| TC-ORD-003 | 未登入下單 | Negative | P1 | 未登入 | 1. 直接呼叫 POST /orders | Bearer Token 空 | 回傳 401 Unauthorized | ⬜ | |
| TC-ORD-004 | 數量為 0 | Boundary | P2 | 已登入 | 1. 傳入數量為 0 的訂單 | quantity: 0 | 回傳 422，顯示「數量必須大於 0」 | ⬜ | |
| TC-ORD-005 | 數量為 1（最小值） | Boundary | P2 | 已登入、庫存充足 | 1. 傳入數量 1 | quantity: 1 | 訂單建立成功 | ⬜ | |
| TC-ORD-006 | 數量超過上限 | Boundary | P3 | 已登入、庫存充足 | 1. 傳入數量超過最大限制 | quantity: 1000 | 回傳 422，顯示「單次最多購買 999 件」 | ⬜ | |
| TC-ORD-007 | 購物車為空 | Negative | P1 | 已登入、購物車無商品 | 1. 點擊結帳 | 空購物車 | 結帳按鈕不可點擊（Grey out） | ⬜ |
缺陷記錄格式
當 Test Case 失敗時，在此記錄：
| 缺陷ID | 對應測試 | 嚴重程度 | 重現步驟 | 預期 | 實際 | 截圖 | 狀態 |
|---|---|---|---|---|---|---|---|
| BUG-001 | TC-AUTH-005 | High | 連續錯誤 5 次後繼續嘗試 | 第 5 次後鎖定 | 第 6 次才鎖定 | [連結] | 待修 |
嚴重程度：
| 等級 | 說明 |
|---|---|
| Critical | 核心功能完全無法使用，需立即修復 |
| High | 重要功能異常，影響大多數使用者 |
| Medium | 功能部分異常，有替代方案 |
| Low | 小問題或 UI 問題，不影響使用 |
測試環境記錄
| 項目 | 內容 |
|---|---|
| 測試環境 | Staging |
| 測試版本 | v1.2.3 |
| 測試日期 | ___ |
| 瀏覽器 | Chrome 124 |
| 測試帳號 | test@example.com |
| 資料庫狀態 | 已重置測試資料 |
現代替代方案：BDD Gherkin
Agile 環境中，Acceptance Criteria 常用 Gherkin 格式（Given-When-Then），可以直接串接自動化測試框架（Cucumber / Behave / Playwright BDD）。
Feature: 會員登入
Scenario: 正常登入
Given 帳號 test@example.com 已存在且已驗證
When 使用者輸入正確的 Email 和密碼並點擊登入
Then 系統導向首頁
And 顯示歡迎訊息
Scenario: 密碼錯誤
Given 帳號 test@example.com 已存在
When 使用者輸入正確 Email 但錯誤密碼
Then 顯示「帳號或密碼錯誤」
And 停留在登入頁
Scenario: 連續錯誤 5 次鎖定
Given 帳號 test@example.com 已存在
When 使用者輸入錯誤密碼 5 次
Then 顯示「已鎖定，請 30 分鐘後再試」
And 後續嘗試無法登入直到 30 分鐘過後Gherkin 的好處是格式本身就是文件，QA 寫的 Gherkin 可以直接變成自動化測試的 spec。
手動測試 vs 自動化測試決策
| 情境 | 建議 |
|---|---|
| 核心業務流程（P1） | 手動 + 自動化 |
| UI 細節、排版 | 手動（視覺測試） |
| API 契約測試 | 自動化（Postman / Pact） |
| 大量邊界值輸入 | 自動化（參數化測試） |
| 第三方整合（金流、簡訊） | 手動（Sandbox 環境） |
| 回歸測試 | 自動化 |