Test Case 撰寫範本 — 從 Title 到 Expected Result 的 7 個欄位

寫 test case 不是把 spec 抄一遍就好。一份好的 case 要能讓完全沒接觸過產品的人照著跑出一致的結果。這篇是我累積五年寫測試案例的固定模板。

一份 test case 該有的 7 個欄位

欄位 必填 用途
ID ✓ 唯一識別、追蹤、引用
Title ✓ 一句話描述「測什麼」
Preconditions ✓ 執行前必須成立的狀態
Test Data ✓ 具體輸入值（不要寫「合法 email」要寫 [email protected]）
Steps ✓ 編號的操作步驟
Expected Result ✓ 每步的預期結果（或最終結果）
Priority — P0/P1/P2，回歸時用

少了任何一個都會讓後續維護痛苦。

Title 怎麼寫

爛例子：「測試登入」、「驗證密碼」

好例子：「以正確 email + 錯誤密碼登入時，顯示『帳號或密碼錯誤』錯誤訊息」

公式：<前置條件>，<操作>，<預期>

寫到能在 sprint review 上唸出來別人就懂，這個 title 才合格。

Preconditions：別讓人去猜環境

例：使用者已註冊但尚未驗證 email、購物車有 1 件商品、後台 feature flag new_checkout=true 已開啟

最常見錯誤：把 preconditions 寫成第一個 step。例如「1. 註冊一個帳號」其實應該是 precondition。原則：測試重點之外的所有狀態都是 precondition。

Test Data：寫死，不要寫類別

爛例子：

  • 帳號：一個合法帳號
  • 密碼：一個合法密碼

好例子：

如果 case 用「合法帳號」這種模糊描述，不同人會準備不同資料，結果會不一樣。Test data 要寫死，要讓人能 copy-paste。

Steps & Expected Result：1:1 對齊

Step                          Expected Result
1. 開啟首頁                    1. 看到 Login 按鈕在右上
2. 點 Login                    2. 跳出 Login Modal
3. 輸入 qa-test-001@...       3. Email 欄位顯示輸入值
4. 輸入錯誤密碼 wrong123       4. Password 欄位顯示為遮罩
5. 點「登入」                  5. 顯示紅色錯誤「帳號或密碼錯誤」
                              且 stay on Login Modal

每個 step 都有對應 expected。不要把 5 個 expected 都寫在最後一行，會看不出來哪一步壞了。

完整實例

ID: TC-LOGIN-007
Title: 帳號鎖定後重試 — 連續輸錯 5 次後第 6 次應顯示鎖定訊息
Priority: P0
Preconditions:
  - 已存在帳號 [email protected]，狀態為 active
  - 該帳號未曾被鎖定
  - 系統設定：MAX_FAIL_ATTEMPTS=5、LOCK_DURATION=15min
Test Data:
  - email: [email protected]
  - 正確密碼: Test@123456
  - 錯誤密碼: wrong000

Steps                                Expected Result
1. 開啟 /login                       1. Login 表單可見
2-6. 用 wrong000 連續登入 5 次       2-6. 每次顯示「帳號或密碼錯誤」
7. 第 6 次仍用 wrong000              7. 顯示「帳號已鎖定，15 分鐘後重試」
                                        且按鈕變灰
8. 此時改用正確密碼 Test@123456      8. 仍顯示「帳號已鎖定」（不應放行）
9. 等待 15 分鐘                      9. —
10. 再以正確密碼登入                 10. 登入成功進入 /dashboard

常見錯誤一覽

  1. 把多個情境塞同一個 case — 「測 login 各種情況」會變一坨。每個情境 = 一個 case。
  2. Steps 寫得像功能說明 — 「系統應該驗證 email 格式」這是 spec，不是 step。Step 是「使用者輸入 abc 並點下一步」。
  3. Expected 寫「正確」 — 不可量測。要寫「畫面跳轉到 /dashboard」「右上角顯示使用者名稱」。
  4. 太依賴前一個 case — 一個 case fail 就會連環倒。除非真的有 dependency，每個 case 都該能獨立跑。
  5. 不留環境/版本 — 線上修了之後跑回歸發現 case 不對，是因為 spec 改了沒同步。在 case 末加 Spec ref: confluence/login-v2。

工具差異不大

  • Excel/Sheets：起步最快，但難追 history、難跨 case 引用
  • Notion：適合小團隊，搜尋好用
  • TestRail / Xray / Zephyr：適合中大型團隊，能跑 test run、出報表
  • JSON/Markdown + Git：適合自動化 + 手動混合的團隊，diff 看得到改了什麼

工具決定樣式，內容結構不變。先把上面 7 個欄位寫好，換工具就只是 copy-paste。

最後

Test case 寫起來無聊，但測試案例品質 = 測試覆蓋率。寧可花一小時寫一份能傳承的 case，也不要花一週每次都重新摸索。先有範本，再有效率。