Test Strategy vs Test Plan vs Test Case — 三層計畫的差別與寫法完整指南

90% 的 QA 把 Strategy / Plan / Case 混為一談。這篇用一張圖講清楚三者層級、各層該寫什麼、誰負責寫、什麼時候用。附完整範本。

QA test-strategy test-plan test-case documentation qa-fundamentals

編輯整理：Mark Liu (劉紋瑋) · 最後更新 2026-06-12 · 最後審閱 2026-08-30

💡 本文原刊於 qa.9niche.com，2026-08 併入 9niche.com 懶人包，內容照原文完整搬遷。

1. 前言

「我們有 test plan 嗎？」「你說的是 plan 還是 strategy？」是中型公司常見的對話災難。Strategy 是公司級、Plan 是專案級、Case 是執行級 — 用錯詞 = 溝通成本爆掉。

2. 一張圖看懂三層關係

層級	範圍	誰寫	多久寫一次	篇幅
Strategy	公司 / 部門	QA Lead / Manager / Architect	1-2 年	10-30 頁
Plan	專案 / Release	QA Lead / Senior QA	每個 release	3-10 頁
Case	單一功能 / scenario	任何 QA	持續	1 頁 / case

flowchart TB S[Test Strategy 公司 / 部門級 Why & How] P[Test Plan 專案 / Release 級 What & When] C[Test Case 執行級 Steps] S --> P P --> C S --> SD["長期、變更慢 1-2 年 review 一次"] P --> PD["專案 / sprint 起點 每次 release 寫"] C --> CD["每個功能 持續寫 + 維護"] style S fill:#06b6d4,color:#fff style P fill:#a855f7,color:#fff style C fill:#10b981,color:#fff

3. Test Strategy — 公司級的 Why & How

內容

寫範本（一頁開頭）

# [Company] QA Strategy 2026-2028

mindmap root((Test Strategy)) 為什麼測 - 目標 Quality vision 可接受 bug 等級 Trade-off 哲學測什麼 - 範圍 Product scope Quality attributes Out of scope 怎麼測 - 方法 Test pyramid Shift-left vs shift-right Manual vs automation 比例用什麼 - 工具自動化框架 CI/CD Bug tracker 什麼角色 - 組織 Team 結構 Dev vs QA 分工跨部門關係什麼指標 - 量化 KPI / OKR SLA Quality gate 什麼風險 - Risk Top 3 風險 Mitigation

4. Quality Vision

我們相信 quality 是團隊全員責任、不是 QA 獨佔。 QA 的角色是 quality coach、不是 gatekeeper。

5. Quality Goals

Production P0 incident: < 1 / month
Customer satisfaction (CSAT) on quality: > 4.5/5
Test cycle time: 從 PR 到 merge < 4 hr

6. Test Approach

Test Pyramid: 70% unit / 25% integration / 5% E2E
Automation 優先：所有 happy path 自動化
Exploratory testing 補強：每 sprint 4 hr session
Shift-left：QA 從 grooming 介入

7. Tools

Automation: Playwright (web), Detox (mobile), pytest (API)
CI: GitHub Actions
Bug: Linear
Test mgmt: 自建 dashboard

8. Team Structure

Embedded QA model：每 product team 1 QA
平台 QA team：建框架、跨團隊推 process
Quality champion：每 dev team 1 人輪流當

9. KPIs

[參考 OKR 文章]

10. Out of Scope

Performance optimization → SRE 負責
Security pentest → Security team
Mobile native 自動化 → Phase 2

11. Review Cycle

每年 H1 review 一次。


### Strategy 文件壽命

**1-2 年改一次**。**不應該每 sprint 改**。改太頻繁代表沒抓到原則。

### Strategy 反例

❌ 「我們會用 Selenium 寫 100 個 case」 → 這是 plan、不是 strategy

❌ 「我們很重視品質」 → 沒方向、空話

❌ 30 頁細節到「每個按鈕都要測 click」 → 變 case，不是 strategy

12. Test Plan — 專案 / Release 級的 What & When

內容

1. Project Overview（這次 release 是什麼）
2. Scope & Out of scope
3. Test approach（用什麼 type 的測試）
4. Resources（誰測、用多少時間）
5. Schedule（什麼時候測完）
6. Deliverables（產出什麼）
7. Entry criteria（什麼時候可以開始測）
8. Exit criteria（什麼時候算測完）
9. Risk & Mitigation
10. Test environment

寫範本

# Test Plan: User Profile v2.0 Release

13. 1. Project Overview

新增 User Profile：頭像、bio、隱私設定、social link。預計影響：登入後 user、20+ API endpoints。

14. 2. Scope

In scope

新增 / 編輯 / 刪除 profile
上傳頭像（多格式、大小限制）
隱私設定（public / friends / private）
跨 6 個瀏覽器 + iOS / Android

Out of scope

Profile 推送 / 通知（v2.1）
Profile analytics（不在 H1）

15. 3. Test Approach

Test Type	Coverage	Tool
Unit	Dev 寫、CI gate	pytest
API	QA 寫、CI gate	pytest + requests
E2E happy path	自動化	Playwright
Edge case	手動	—
Visual regression	Playwright snapshot	Playwright
A11y	manual checklist	axe
Performance	1000 concurrent upload	k6

16. 4. Resources

QA: Alice (lead), Bob (web), Carol (mobile)
Total: 12 person-days

17. 5. Schedule

Phase	Date	Owner
Test plan review	Jun 5	Alice
API test ready	Jun 8	Alice
E2E test ready	Jun 10	Bob
Mobile test	Jun 12-14	Carol
Regression	Jun 15	All
Sign-off	Jun 16	Alice

18. 6. Entry Criteria

All API endpoints documented
Staging env up
Test data ready
No P0 spec issue open

19. 7. Exit Criteria

All P0 / P1 case pass
Auto coverage ≥ 80% on happy path
0 open P0 bug、< 3 open P1 bug
Performance pass（p95 < 500ms）
A11y level AA

20. 8. Risks

Risk	Impact	Likelihood	Mitigation
上傳功能跨平台問題	High	Medium	跨裝置真機測試
Migration 影響舊資料	Critical	Low	Staging full data backup

21. 9. Test Environment

Web: staging.example.com
Mobile: TestFlight / Firebase
DB: snapshot from prod (anonymized)
3rd party: Stripe sandbox / SendGrid sandbox


### Plan 的壽命

**每次 release / 大專案寫一次**。Sprint 內小功能可以不寫、用 ticket 的 acceptance criteria。

### Plan 反例

❌ 一頁紙：「測試 user profile，全部跑過」 → 不夠細，沒 entry / exit criteria

❌ 100 頁含所有 case → 太細，case 應該在 test management 工具

❌ 寫完不 review、不更新 → 一週後跟現實脫節

22. Test Case — 執行級的 Steps

完整指南見 Test Case 撰寫範本。

ID: TC-PROFILE-001
Title: 上傳 < 5MB JPG 頭像成功
Priority: P0
Preconditions: 已登入、有 < 5MB JPG 圖檔
Test Data: profile-pic-2mb.jpg
Steps:
  1. 進 /profile
  2. 點「更換頭像」
  3. 選 profile-pic-2mb.jpg
  4. 點「儲存」
Expected:
  1-3. 略
  4. 頭像更新、看到「儲存成功」、URL 包含 CDN 路徑

23. 三者關係實例

一份 strategy → 多個 plan → 每個 plan 含多個 case。

flowchart TB Strat["Strategy: 我們做 mobile-first SaaS auto coverage > 70%、quality coach 模式"] Strat --> P1["Plan: v2.0 release 含 5 個 feature 2 週測試窗口、3 個 QA"] Strat --> P2["Plan: hotfix release 1 天緊急、smoke only"] P1 --> C1["Case: profile 編輯 15 個 case"] P1 --> C2["Case: 上傳頭像 22 個 case"] P2 --> C3["Case: smoke - 登入 / 結帳 10 個 case"] style Strat fill:#06b6d4,color:#fff style P1 fill:#a855f7,color:#fff style P2 fill:#a855f7,color:#fff style C1 fill:#10b981,color:#fff style C2 fill:#10b981,color:#fff style C3 fill:#10b981,color:#fff

24. 何時用哪個

flowchart TD Question[QA 工作問題] --> Q1{範圍多大?} Q1 -->|公司方向| Strat[寫 / 更新 Strategy] Q1 -->|某個 release| Plan[寫 Test Plan] Q1 -->|某個功能 / scenario| Case[寫 Test Cases] Q1 -->|某個 sprint story| Q2{有沒有大改變?} Q2 -->|有，影響跨 team| Plan Q2 -->|小、單 team| AC["寫 Acceptance Criteria 不用 plan"] style Strat fill:#06b6d4,color:#fff style Plan fill:#a855f7,color:#fff style Case fill:#10b981,color:#fff style AC fill:#f59e0b,color:#fff

25. 簡化版（給小團隊）

5 人以下小團隊不一定需要全部三層：

Strategy：1 頁的 README.md 寫原則就夠
Plan：跳過、直接用 Linear / Jira issue 的 acceptance
Case：寫在 spreadsheet 或 testing tool（不用 word）

過度文檔化 = 沒人讀 = 等於沒寫。

26. 給 QA Lead 的建議

flowchart TB Stage{你的公司階段} --> S1[早期 / 新創 < 10 人] Stage --> S2[成長期 10-50 人] Stage --> S3[成熟期 50+ 人] S1 --> A1[只需 1 頁 Strategy 跳過 Plan Case 用 spreadsheet] S2 --> A2[Strategy 一份 每 release 寫 Plan Case 進 test mgmt tool] S3 --> A3[完整三層 含跨 team strategy process 自動化] style S1 fill:#06b6d4,color:#fff style S2 fill:#a855f7,color:#fff style S3 fill:#10b981,color:#fff

27. 反模式

flowchart TD Anti[三層計畫反模式] --> A1["把 strategy 寫成 case 清單"] Anti --> A2["plan 寫了沒人 follow"] Anti --> A3["case 寫完不 maintain"] Anti --> A4["strategy 每 sprint 改"] Anti --> A5["小團隊強推 100 頁 plan"] Anti --> A6["寫 plan 不寫 exit criteria"] Anti --> A7["寫 case 跳過 expected result"] style A1 fill:#ef4444,color:#fff style A2 fill:#ef4444,color:#fff style A3 fill:#ef4444,color:#fff style A4 fill:#ef4444,color:#fff style A5 fill:#ef4444,color:#fff style A6 fill:#ef4444,color:#fff style A7 fill:#ef4444,color:#fff

28. 面試題目（這個常考）

Q: Test Strategy 跟 Test Plan 差在哪？

好答案：

Strategy 是公司 / 部門級的 Why 與 How，1-2 年才改一次，內容講 quality vision、test pyramid 比例、工具選型、組織結構。Plan 是專案 / release 級的 What 與 When，每次發版寫，含 scope、schedule、entry / exit criteria、risk。
簡單講：Strategy 是「我們怎麼測這家公司」、Plan 是「這次發版怎麼測」。

Q: 你在以前公司寫過 Test Strategy 嗎？

如果你是 Senior +，答得出來 = 加分。Junior 答「沒寫過、但讀過」也 OK。

29. 範本下載

Minimal Strategy（1 頁）

# QA Strategy

30. Vision

[Quality 是什麼、誰負責]

31. Goals

[Bug metric]
[Cycle time]
[User satisfaction]

32. Approach

Test pyramid: X% / Y% / Z%
Manual vs Auto: ...
Shift-left: ...

33. Tools

Auto: ...
CI: ...

34. Out of scope


### Minimal Plan（半頁）

Scope: ... Out of scope: ... Owner: [Name] Timeline: [Date] ~ [Date]

35. Test approach

[Type 1]: ...
[Type 2]: ...

36. Entry criteria

[ ] ...

37. Exit criteria

[ ] All P0 case pass
[ ] < 3 open P1 bug

38. Risks

[Risk 1]: [Mitigation]

39. 最後

三層計畫的核心：Strategy 是相信什麼、Plan 是這次怎麼做、Case 是步驟。中型團隊以上這三層都要有。新公司可以從簡化版開始 — 一頁 strategy + 半頁 plan + spreadsheet case，逐步成長。混為一談 = 沒人知道你在說哪一層 = 溝通成本翻倍。

偏好設定

外觀

行為

隱私