測試計畫範本（Test Plan）#
參照標準：ISO/IEC/IEEE 29119-3:2021（取代 IEEE 829-2008）
文件用途：定義測試範圍、策略、資源、時程與風險，指導整體測試活動
適用階段：測試準備階段（Test Planning Phase）
📋 章節目錄#
- 文件資訊
- 測試計畫識別
- 引言
- 測試項目
- 測試策略與方法
- 通過與失敗標準
- 暫停與恢復準則
- 測試交付物
- 測試環境需求
- 職責分工
- 時程與里程碑
- 風險與緩解措施
- 附錄
1. 文件資訊#
📝 範本#
| 項目 | 內容 |
|---|
| 文件編號 | TP-{專案代碼}-{序號} |
| 文件名稱 | {系統名稱} 測試計畫 |
| 版本 | v{主版本}.{次版本} |
| 狀態 | 草稿 / 審核中 / 核定 |
| 建立日期 | {YYYY-MM-DD} |
| 最後更新 | {YYYY-MM-DD} |
| 撰寫者 | {姓名/角色} |
| 審核者 | {姓名/角色} |
| 對應 FRD | {FRD 文件編號} |
| 測試層級 | {Unit / Integration / System / UAT} |
版本歷程
| 版本 | 日期 | 修改人 | 修改內容摘要 |
|---|
| v0.1 | {YYYY-MM-DD} | {姓名} | 初版建立 |
📖 使用說明#
- 依據 ISO/IEC/IEEE 29119-3:2021 第 7 節「Test Plan documentation」
- 測試計畫可依測試層級分開撰寫（如 SIT 測試計畫、UAT 測試計畫）
- 一個專案可有多份測試計畫，也可合併為一份主測試計畫（Master Test Plan）
💡 範例#
| 項目 | 內容 |
|---|
| 文件編號 | TP-HRM-001 |
| 文件名稱 | 人力資源管理系統 系統整合測試計畫 |
| 測試層級 | System Integration Test (SIT) |
| 對應 FRD | FRD-HRM-001 v2.1 |
2. 測試計畫識別#
📝 範本#
| 項目 | 內容 |
|---|
| 專案名稱 | {專案正式名稱} |
| 受測系統 | {系統名稱及版本} |
| 測試階段 | {SIT / UAT / Performance / Security} |
| 測試期間 | {起始日期} ~ {結束日期} |
| 測試團隊 | {團隊名稱} |
📖 使用說明#
- 明確識別「測什麼」、「測多久」、「誰來測」
- 測試期間需與專案整體時程對齊
💡 範例#
| 項目 | 內容 |
|---|
| 專案名稱 | 人力資源管理系統建置專案 |
| 受測系統 | HRMS v1.0.0 |
| 測試階段 | SIT（系統整合測試） |
| 測試期間 | 2026-09-01 ~ 2026-09-30 |
| 測試團隊 | QA 品質保證組 |
3. 引言#
📝 範本#
3.1 測試目的#
{描述本次測試活動的目標}
3.2 測試範圍#
包含範圍（In Scope）：
排除範圍（Out of Scope）：
3.3 參考文件#
| 文件編號 | 文件名稱 | 版本 | 用途 |
|---|
| {編號} | {名稱} | {版本} | {與本計畫的關係} |
📖 使用說明#
- 測試目的：明確陳述測試要驗證什麼（如「驗證所有 Must have 功能需求正確實作」）
- 測試範圍：與 FRD 需求清單對齊，明確列出哪些需求在此次測試涵蓋
- 排除範圍需說明原因（如「效能測試另有專屬計畫」）
💡 範例#
3.1 測試目的#
驗證 HRMS v1.0 系統整合後各模組間的互動正確性，確認：
- 所有 Must have 功能需求（FR-LV-001
004, FR-PY-001002）正確實作 - 模組間資料傳遞完整且一致
- 與外部系統（AD、ERP）介接正常
3.2 測試範圍#
包含範圍：
- 假勤管理模組（申請、審核、假額計算）
- 薪資管理模組（月薪計算、加班費）
- 員工自助服務（查詢、修改個人資料）
- AD 整合（SSO 登入）
- ERP 介接（薪資拋轉）
排除範圍：
- 效能壓力測試（另有 TP-HRM-002 效能測試計畫）
- 行動裝置 App 測試（Phase 2 範圍）
4. 測試項目#
📝 範本#
4.1 功能測試項目#
| 測試項目 ID | 對應需求 | 模組 | 測試項目描述 | 優先級 |
|---|
| TI-{xxx}-001 | FR-{xxx}-001 | {模組} | {測試什麼} | 高/中/低 |
| TI-{xxx}-002 | FR-{xxx}-002 | {模組} | {測試什麼} | 高/中/低 |
4.2 非功能測試項目#
| 測試項目 ID | 對應需求 | 類型 | 測試項目描述 | 優先級 |
|---|
| TI-NFR-001 | NFR-{xxx} | {效能/安全/可用} | {測試什麼} | 高/中/低 |
4.3 不測試的功能#
📖 使用說明#
- 依據 ISO/IEC/IEEE 29119-3 第 7.3 節「Test items」
- 測試項目應可追溯回 FRD 的需求編號
- 優先級決定測試執行順序與資源分配
- 明確列出「不測試的功能」避免遺漏被誤解為疏忽
💡 範例#
4.1 功能測試項目#
| 測試項目 ID | 對應需求 | 模組 | 測試項目描述 | 優先級 |
|---|
| TI-LV-001 | FR-LV-001 | 假勤管理 | 驗證線上請假申請功能，含各假別 | 高 |
| TI-LV-002 | FR-LV-002 | 假勤管理 | 驗證假額不足時拒絕申請 | 高 |
| TI-LV-003 | FR-LV-003 | 假勤管理 | 驗證申請建立後通知主管 | 高 |
| TI-PY-001 | FR-PY-001 | 薪資管理 | 驗證月薪自動計算正確性 | 高 |
5. 測試策略與方法#
📝 範本#
5.1 測試層級策略#
| 測試層級 | 測試類型 | 負責人 | 自動化程度 | 工具 |
|---|
| Unit Test | 白箱測試 | 開發工程師 | {%} | {工具} |
| Integration Test | 灰箱測試 | 開發 + QA | {%} | {工具} |
| System Test (SIT) | 黑箱測試 | QA 團隊 | {%} | {工具} |
| UAT | 業務驗收 | 業務人員 | 手動 | {工具} |
5.2 測試設計技術#
| 技術名稱 | 適用場景 | 說明 |
|---|
| 等價類別劃分 | 輸入值驗證 | 將輸入分為有效/無效等價類 |
| 邊界值分析 | 數值範圍測試 | 測試邊界條件 |
| 決策表 | 多條件組合 | 列出所有條件組合 |
| 狀態轉換 | 流程狀態測試 | 驗證狀態轉換合法性 |
| 探索性測試 | 補充覆蓋 | 基於經驗的自由測試 |
5.3 迴歸測試策略#
| 項目 | 策略 |
|---|
| 觸發條件 | {每次 Build / 每日 / 每個 Sprint} |
| 範圍 | {全量 / 影響範圍 + 核心功能} |
| 自動化比例 | {目標 %} |
| 執行時間預算 | {時間限制} |
📖 使用說明#
- 依據 ISO/IEC/IEEE 29119-3 第 7.4 節「Test approach」
- 測試金字塔原則：Unit（多）> Integration（中）> E2E（少）
- 自動化目標應務實，不追求 100%（投資報酬率最重要）
- 迴歸測試是品質防線，需明確定義觸發條件與範圍
💡 範例#
5.1 測試層級策略#
| 測試層級 | 測試類型 | 負責人 | 自動化程度 | 工具 |
|---|
| Unit Test | 白箱測試 | 開發工程師 | 90% | xUnit + Moq |
| Integration Test | API 測試 | QA 工程師 | 70% | Postman + Newman |
| System Test | E2E 功能測試 | QA 團隊 | 40% | Playwright |
| UAT | 業務場景驗收 | 人資部 | 手動 | TestRail（案例管理） |
6. 通過與失敗標準#
📝 範本#
6.1 測試完成標準（Exit Criteria）#
| 標準類型 | 指標 | 目標值 |
|---|
| 測試案例執行率 | 已執行 / 總案例數 | ≥ {%} |
| 測試案例通過率 | 通過 / 已執行 | ≥ {%} |
| 嚴重缺陷 | Critical + High 未修復數 | = {N} |
| 缺陷修復率 | 已修復 / 總發現 | ≥ {%} |
| 需求覆蓋率 | 已驗證需求 / 總需求 | = {%} |
6.2 測試中止標準#
📖 使用說明#
- 依據 ISO/IEC/IEEE 29119-3 第 7.5 節「Completion criteria」
- Exit Criteria 決定「什麼時候可以停止測試」
- 建議 Critical/High 缺陷數 = 0 作為上線前提
- 目標值需與專案經理及業務方共同確認
💡 範例#
6.1 測試完成標準#
| 標準類型 | 指標 | 目標值 |
|---|
| 測試案例執行率 | 已執行 / 總案例數 | ≥ 100%（Must have 需求） |
| 測試案例通過率 | 通過 / 已執行 | ≥ 95% |
| Critical 缺陷 | 未修復數 | = 0 |
| High 缺陷 | 未修復數 | = 0 |
| Medium 缺陷 | 未修復數 | ≤ 5（需有 Workaround） |
| 需求覆蓋率 | Must have 需求已驗證 | = 100% |
6.2 測試中止標準#
| 條件 | 處理方式 |
|---|
| 環境持續不穩定超過 2 個工作天 | 暫停測試，升級至 PM 處理 |
| 單日新增 Critical 缺陷 > 5 件 | 暫停測試，開發團隊優先修復 |
| 受測系統無法正常啟動 | 暫停測試，通知 DevOps 排除 |
7. 暫停與恢復準則#
📝 範本#
7.1 暫停準則#
| 編號 | 暫停條件 | 決策者 |
|---|
| S-01 | {暫停條件描述} | {角色} |
| S-02 | {暫停條件描述} | {角色} |
7.2 恢復準則#
| 編號 | 恢復條件 | 確認者 |
|---|
| R-01 | {恢復條件描述} | {角色} |
| R-02 | {恢復條件描述} | {角色} |
📖 使用說明#
- 明確定義何時暫停可避免在不穩定環境中浪費測試資源
- 恢復準則確保問題真正解決後才重啟測試
- 暫停/恢復需有正式通知流程
💡 範例#
7.1 暫停準則#
| 編號 | 暫停條件 | 決策者 |
|---|
| S-01 | 測試環境無法存取超過 4 小時 | 測試經理 |
| S-02 | 核心功能（登入/請假/薪資計算）完全無法運作 | 測試經理 |
| S-03 | 新版本部署導致超過 50% 測試案例失敗 | QA Lead |
7.2 恢復準則#
| 編號 | 恢復條件 | 確認者 |
|---|
| R-01 | 環境穩定運行 2 小時以上無異常 | DevOps |
| R-02 | 開發團隊確認修復完成並重新部署 | 開發 Lead |
| R-03 | Smoke Test 通過 | QA 工程師 |
8. 測試交付物#
📝 範本#
| 交付物 | 格式 | 產出時間 | 負責人 |
|---|
| 測試計畫 | Markdown / Word | 測試準備期 | 測試經理 |
| 測試案例 | {工具/格式} | 測試設計期 | QA 工程師 |
| 測試資料 | {格式} | 測試準備期 | QA 工程師 |
| 每日測試報告 | {格式} | 測試執行期間 | 測試經理 |
| 缺陷報告 | {工具} | 測試執行期間 | QA 工程師 |
| 測試總結報告 | Markdown / Word | 測試結束 | 測試經理 |
| 自動化測試腳本 | {語言} | 測試設計期 | QA 工程師 |
📖 使用說明#
- 依據 ISO/IEC/IEEE 29119-3 第 7.6 節「Test deliverables」
- 明確列出所有測試活動的產出物，確保可追溯性
- 每日測試報告提供專案進度透明度
💡 範例#
| 交付物 | 格式 | 產出時間 | 負責人 |
|---|
| 測試計畫 | Markdown (本文件) | 2026-08-15 | 林測試經理 |
| 測試案例 | TestRail | 2026-08-30 | QA 團隊 |
| 測試資料 | SQL Script + CSV | 2026-08-30 | QA 工程師 |
| 每日測試報告 | Email + Dashboard | 測試期間每日 | 林測試經理 |
| 缺陷報告 | Azure DevOps Work Items | 測試期間 | QA 工程師 |
| 測試總結報告 | Markdown | 2026-10-05 | 林測試經理 |
9. 測試環境需求#
📝 範本#
9.1 環境配置#
| 項目 | 規格 |
|---|
| 伺服器 | {規格描述} |
| 作業系統 | {OS 版本} |
| 資料庫 | {DB 版本} |
| 中介軟體 | {清單} |
| 網路 | {網段/存取控制} |
9.2 測試工具#
| 工具名稱 | 用途 | 版本 | 授權 |
|---|
| {工具} | {用途} | {版本} | {授權方式} |
9.3 測試資料需求#
| 資料類別 | 筆數 | 來源 | 脫敏方式 |
|---|
| {類別} | {筆數} | {來源} | {脫敏策略} |
9.4 外部系統模擬#
| 外部系統 | 模擬方式 | 工具 | 負責人 |
|---|
| {系統} | {Mock / Stub / 實際連接} | {工具} | {姓名} |
📖 使用說明#
- 測試環境應盡可能貼近正式環境（尤其 SIT/UAT）
- 測試資料禁止使用正式環境個資，需進行脫敏處理
- 外部系統依賴若不穩定，建議使用 Mock/Stub 提高測試可控性
- 環境準備是測試啟動的前置條件，需提早安排
💡 範例#
9.3 測試資料需求#
| 資料類別 | 筆數 | 來源 | 脫敏方式 |
|---|
| 員工基本資料 | 500 筆 | 正式環境脫敏複製 | 姓名亂碼、身分證遮罩 |
| 歷史假勤紀錄 | 10,000 筆 | 自動產生 | N/A（模擬資料） |
| 薪資結構資料 | 500 筆 | 正式環境脫敏複製 | 金額加減隨機偏移 |
9.4 外部系統模擬#
| 外部系統 | 模擬方式 | 工具 | 負責人 |
|---|
| Active Directory | Mock Server | WireMock | DevOps |
| ERP 財務模組 | Stub（固定回應） | Postman Mock | QA 工程師 |
| 電子郵件系統 | 測試 SMTP | MailHog | DevOps |
10. 職責分工#
📝 範本#
| 角色 | 職責 | 人員 |
|---|
| 測試經理 | 測試計畫制定、進度追蹤、風險管理 | {姓名} |
| QA Lead | 測試案例設計、測試團隊指導 | {姓名} |
| QA 工程師 | 測試案例執行、缺陷提報 | {姓名} |
| 自動化工程師 | 自動化腳本開發與維護 | {姓名} |
| 開發工程師 | 缺陷修復、技術支援 | {姓名} |
| DevOps | 環境建置、部署支援 | {姓名} |
| 業務代表 | UAT 執行、業務確認 | {姓名} |
📖 使用說明#
- 依據 ISO/IEC/IEEE 29119-3 第 7.8 節「Responsibilities」
- 明確的職責分工避免工作重疊或遺漏
- 建議標明備援人力（Backup），防止單點失敗
💡 範例#
| 角色 | 職責 | 人員 |
|---|
| 測試經理 | 測試計畫制定、進度報告、與 PM 對接 | 林品質 |
| QA Lead | 測試案例審核、缺陷分類 | 張驗收 |
| QA 工程師 | 手動測試執行、缺陷回報 | 王測試、李測試 |
| 自動化工程師 | API 自動化測試、CI 整合 | 陳自動 |
| 開發 Lead | 缺陷優先級確認、修復協調 | 吳開發 |
11. 時程與里程碑#
📝 範本#
11.1 測試時程#
| 階段 | 活動 | 起始日期 | 結束日期 | 負責人 |
|---|
| 準備期 | 測試計畫撰寫 | {日期} | {日期} | {姓名} |
| 準備期 | 測試案例設計 | {日期} | {日期} | {姓名} |
| 準備期 | 環境與資料準備 | {日期} | {日期} | {姓名} |
| 執行期 | 第一輪測試 | {日期} | {日期} | {姓名} |
| 執行期 | 缺陷修復 | {日期} | {日期} | {姓名} |
| 執行期 | 第二輪迴歸測試 | {日期} | {日期} | {姓名} |
| 收尾期 | 測試總結報告 | {日期} | {日期} | {姓名} |
11.2 關鍵里程碑#
| 里程碑 | 日期 | 判定標準 |
|---|
| 測試就緒（Test Ready） | {日期} | {標準} |
| 第一輪測試完成 | {日期} | {標準} |
| 迴歸測試通過 | {日期} | {標準} |
| 測試簽核（Sign-off） | {日期} | {標準} |
📖 使用說明#
- 時程需預留缺陷修復與迴歸測試的緩衝時間
- 通常規劃 2-3 輪測試（首輪 → 修復 → 迴歸 → 再修復 → 最終確認）
- 里程碑判定標準需與 Exit Criteria 對齊
💡 範例#
11.1 測試時程#
| 階段 | 活動 | 起始日期 | 結束日期 | 負責人 |
|---|
| 準備期 | 測試計畫撰寫 | 2026-08-01 | 2026-08-15 | 林品質 |
| 準備期 | 測試案例設計 | 2026-08-10 | 2026-08-30 | QA 團隊 |
| 準備期 | 環境與資料準備 | 2026-08-20 | 2026-08-31 | DevOps + QA |
| 執行期 | 第一輪 SIT | 2026-09-01 | 2026-09-15 | QA 團隊 |
| 執行期 | 缺陷修復 | 2026-09-16 | 2026-09-22 | 開發團隊 |
| 執行期 | 第二輪迴歸測試 | 2026-09-23 | 2026-09-30 | QA 團隊 |
| 收尾期 | 測試總結報告 | 2026-10-01 | 2026-10-05 | 林品質 |
12. 風險與緩解措施#
📝 範本#
| 風險編號 | 風險描述 | 機率 | 影響 | 風險等級 | 緩解措施 |
|---|
| TR-01 | {測試相關風險} | 高/中/低 | 高/中/低 | {等級} | {措施} |
| TR-02 | {測試相關風險} | 高/中/低 | 高/中/低 | {等級} | {措施} |
📖 使用說明#
- 依據 ISO/IEC/IEEE 29119-3 第 7.10 節「Risks and contingencies」
- 常見測試風險：環境不穩定、需求變更、人力不足、測試時程壓縮
- 每個高風險項目需有具體的應變計畫
💡 範例#
| 風險編號 | 風險描述 | 機率 | 影響 | 風險等級 | 緩解措施 |
|---|
| TR-01 | 測試環境建置延遲，壓縮測試時間 | 中 | 高 | 高 | 提早 2 週啟動環境準備；備妥 Docker 本地測試方案 |
| TR-02 | 開發交付延遲，功能未完成即需開始測試 | 中 | 高 | 高 | 依模組分批交付測試；優先測試已完成模組 |
| TR-03 | QA 人力不足（僅 2 人） | 低 | 中 | 中 | 開發工程師支援撰寫自動化測試 |
| TR-04 | 外部系統 Mock 與實際行為不一致 | 中 | 中 | 中 | SIT 後期安排實際串接驗證 |
13. 附錄#
📝 範本#
13.1 測試案例數量預估#
| 模組 | 功能需求數 | 預估測試案例數 | 自動化案例數 |
|---|
| {模組} | {N} | {N} | {N} |
| 合計 | {N} | {N} | {N} |
13.2 缺陷嚴重度定義#
| 嚴重度 | 定義 | 修復時限 |
|---|
| Critical | 系統當機、資料遺失、安全漏洞 | 4 小時內 |
| High | 核心功能無法使用、無 Workaround | 1 工作天 |
| Medium | 功能異常但有 Workaround | 3 工作天 |
| Low | 介面問題、錯字、不影響功能 | 下一版本修復 |
13.3 術語定義#
| 術語 | 定義 |
|---|
| SIT | System Integration Test，系統整合測試 |
| UAT | User Acceptance Test，使用者驗收測試 |
| Smoke Test | 冒煙測試，快速驗證核心功能是否運作 |
| Regression Test | 迴歸測試，確認修改未引入新缺陷 |
📖 使用說明#
- 缺陷嚴重度定義需全團隊共識，避免分類爭議
- 測試案例數量預估有助於工作量評估與資源配置
- 術語定義確保所有參與者對同一詞彙有一致理解
💡 範例#
13.1 測試案例數量預估#
| 模組 | 功能需求數 | 預估測試案例數 | 自動化案例數 |
|---|
| 假勤管理 | 8 | 45 | 20 |
| 薪資管理 | 5 | 35 | 15 |
| 員工自助 | 4 | 20 | 10 |
| 系統管理 | 3 | 15 | 5 |
| 外部介接 | 4 | 20 | 12 |
| 合計 | 24 | 135 | 62（46%） |
📌 範本使用注意事項
- 本範本依據 ISO/IEC/IEEE 29119-3:2021 標準結構編製
- 可依測試層級分開撰寫（SIT Plan、UAT Plan、Performance Test Plan）
- 測試計畫為「活文件」，隨專案進展更新
- 測試計畫核定後，變更需走正式 Change Request 流程
- 搭配「測試案例範本」使用，完成測試設計