---
title: Test Case 撰寫範本 — 從 Title 到 Expected Result 的 7 個欄位
description: 一份能用 5 年的 test case 範本：欄位定義、撰寫節奏、常見錯誤、Excel/Notion/TestRail 通用，附完整實例。
category: manual
tags: [test-case, 範本, 手動測試]
date: 2026-06-09
---

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

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

## 一份 test case 該有的 7 個欄位

| 欄位 | 必填 | 用途 |
|------|------|------|
| ID | ✓ | 唯一識別、追蹤、引用 |
| Title | ✓ | 一句話描述「測什麼」 |
| Preconditions | ✓ | 執行前必須成立的狀態 |
| Test Data | ✓ | 具體輸入值（不要寫「合法 email」要寫 `test@example.com`） |
| 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：寫死，不要寫類別

爛例子：

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

好例子：

- 帳號：`qa-test-001@example.com`
- 密碼：`Test@123456`

如果 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:
  - 已存在帳號 qa-test-007@example.com，狀態為 active
  - 該帳號未曾被鎖定
  - 系統設定：MAX_FAIL_ATTEMPTS=5、LOCK_DURATION=15min
Test Data:
  - email: qa-test-007@example.com
  - 正確密碼: 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，也不要花一週每次都重新摸索。先有範本，再有效率。