測試案例範本（Test Case Template）

參照標準：ISO/IEC/IEEE 29119-3:2021（取代 IEEE 829-2008）/ ISO/IEC/IEEE 29119-4:2021（Test Techniques）
文件用途：定義測試案例的標準格式，確保測試設計完整、可追溯、可重複執行
適用階段：測試設計與執行階段

📋 章節目錄

1. 文件資訊
2. 測試案例識別規範
3. 測試案例格式定義
4. 測試案例撰寫規範
5. 測試案例分類
6. 測試案例清單範本
7. 測試案例詳細格式
8. 測試資料規劃
9. 測試執行紀錄
10. 缺陷報告格式
11. 附錄

1. 文件資訊

📝 範本

📖 使用說明

• 測試案例文件承接測試計畫（Test Plan），為各測試項目設計具體的驗證步驟
• 每個功能模組可獨立一份測試案例文件，或匯整於單一文件中
• 文件需經 QA Lead 或測試經理審核後方可執行

💡 範例

2. 測試案例識別規範

📝 範本

2.1 編號規則

TC-{專案}-{模組}-{序號}

2.2 命名規範

測試案例名稱格式：[測試類型] {功能描述} - {情境描述}

📖 使用說明

• 編號需全域唯一，不可重複使用（即使案例被刪除）
• 命名需清楚表達測試目的，讓任何人看到名稱就能理解測什麼
• 測試類型標記：[正向]、[負向]、[邊界]、[異常]

💡 範例

3. 測試案例格式定義

📝 範本

每個測試案例包含以下欄位：

📖 使用說明

• 依據 ISO/IEC/IEEE 29119-3 Annex B「Test Case Specification」
• 前置條件必須具體可驗證（如「使用者已登入」而非「系統正常」）
• 測試步驟需足夠詳細，讓任何人都能依步驟重現
• 預期結果需與步驟一一對應，且可客觀判定通過/失敗

💡 範例

見第 7 節「測試案例詳細格式」

4. 測試案例撰寫規範

📝 範本

4.1 撰寫原則

4.2 撰寫步驟格式

步驟描述格式：{動作} {對象} {內容}

4.3 預期結果格式

📖 使用說明

• 避免「驗證結果正確」此類模糊預期，應具體描述何謂「正確」
• 每個步驟只做一個動作，避免「輸入 A 並點擊 B 然後確認 C」
• 使用 Given-When-Then 思維：Given（前置條件）→ When（步驟）→ Then（預期結果）

💡 範例

模糊寫法（不佳）： 「填寫請假資料後送出，確認結果正確」

明確寫法（良好）：

5. 測試案例分類

📝 範本

5.1 依測試類型分類

5.2 依測試優先級分類

📖 使用說明

• 正向：負向建議比例約 4:6（負向情境通常更多）
• 優先級由需求優先級與風險程度共同決定
• P1 案例應優先自動化，確保迴歸效率

💡 範例

假勤模組測試案例分類統計：

6. 測試案例清單範本

📝 範本

模組：{模組名稱}

📖 使用說明

• 測試案例清單提供全覽視角，方便進度追蹤
• 狀態欄位在測試執行期間更新
• 此表可作為測試進度 Dashboard 的資料來源

💡 範例

模組：假勤管理（Leave Management）

7. 測試案例詳細格式

📝 範本

測試案例：TC-{xxx}-{nnn}

前置條件（Preconditions）：

1. {條件 1}
2. {條件 2}

測試資料（Test Data）：

測試步驟與預期結果：

後置條件（Postconditions）：

• {系統預期狀態}

備註：

• {特殊注意事項}

📖 使用說明

• 前置條件：列出所有必須先完成的準備（登入、建立資料等）
• 測試資料：明確列出每個輸入欄位的測試值
• 「實際結果」與「Pass/Fail」：在測試執行時由執行者填寫
• 一個測試案例建議不超過 10 個步驟，過複雜應拆分

💡 範例

測試案例：TC-HRM-LV-001

前置條件：

1. 測試帳號 E20260001（王小明）已登入系統
2. 該帳號特休假剩餘 10 天
3. 測試日期為工作日

測試資料：

測試步驟與預期結果：

後置條件：

• 假勤紀錄中新增一筆申請，狀態 = 待審核
• 主管（E20260002）收到待審核通知
• 剩餘特休假額仍為 10 天（審核通過後才扣除）

測試案例：TC-HRM-LV-002

前置條件：

1. 測試帳號 E20260003（張小剛）已登入系統
2. 該帳號特休假剩餘 2 天

測試資料：

測試步驟與預期結果：

8. 測試資料規劃

📝 範本

8.1 測試帳號

8.2 基礎測試資料

8.3 資料清理策略

📖 使用說明

• 測試帳號需涵蓋所有角色（Admin / Manager / Employee 等）
• 測試資料不可使用真實個資，需脫敏或虛構
• 資料清理確保每輪測試起始狀態一致，避免髒資料影響結果

💡 範例

8.1 測試帳號

9. 測試執行紀錄

📝 範本

9.1 每日測試進度

9.2 測試進度彙整

📖 使用說明

• 每日更新測試進度，提供專案透明度
• 「阻塞」表示因環境或依賴問題無法執行
• 進度報告建議搭配圖表（如 Burndown Chart）呈現

💡 範例

9.2 測試進度彙整

10. 缺陷報告格式

📝 範本

重現步驟：

1. {步驟 1}
2. {步驟 2}
3. {步驟 3}

預期結果：{預期行為}

實際結果：{實際行為}

附件：{截圖 / 影片 / Log 檔案}

📖 使用說明

• 缺陷報告需提供足夠資訊讓開發者重現問題
• 「重現步驟」需具體到開發者可依步驟 100% 重現
• 附件（截圖、Log）能大幅加速問題定位
• 嚴重度定義參考測試計畫附錄的缺陷嚴重度標準

💡 範例

重現步驟：

1. 以帳號 E20260001 登入
2. 進入「請假申請」，填寫特休假 2026-06-10 ~ 2026-06-11
3. 點擊「送出申請」
4. 以主管帳號 E20260002 登入查看通知

預期結果：主管 E20260002 收到待審核通知（系統通知 + Email）

實際結果：系統通知未出現，Email 未收到。資料庫確認請假紀錄已建立。

附件：notification_error_log_20260918.txt

11. 附錄

📝 範本

11.1 測試覆蓋率矩陣

11.2 測試環境版本記錄

📖 使用說明

• 測試覆蓋率矩陣確保每個需求都有對應的測試案例
• 「未覆蓋」的需求需評估是否因範圍排除或遺漏

💡 範例

11.1 測試覆蓋率矩陣

📌 範本使用注意事項

1. 本範本依據 ISO/IEC/IEEE 29119-3:2021 及 29119-4:2021 標準編製
2. 可搭配測試管理工具（如 TestRail、Azure Test Plans、Xray）使用
3. 測試案例設計完成後需經 QA Lead 審核（Peer Review）
4. 自動化測試案例的腳本應與案例 ID 對應，便於追溯
5. 搭配「測試計畫範本」使用，構成完整的測試文件體系