Test Pyramid + 完整測試類型全圖 — Unit / Integration / E2E / Smoke / Sanity / Regression 一次說清

「Smoke 跟 sanity 差在哪？」「Regression 跟 acceptance 是同個東西嗎？」是 QA 面試最常被搞混的問題。這篇用一張圖把所有測試類型講清楚 — 該寫多少、什麼時候跑、誰寫、為什麼。

為什麼是金字塔形狀

• 底層多：unit test 多、跑快、抓 bug 早、修便宜
• 上層少：E2E 慢、貴、flaky 風險高、只測 critical path

反金字塔（多 E2E 少 unit）= 開發地獄。

區分 Smoke vs Sanity

最容易搞混：

Smoke：「This build runs」（廣度淺、確認基本可用）
Sanity：「This change works」（深度但窄、確認改的對）

例子：

Dev 改了「結帳」功能 → push code

Smoke: 開首頁、登入、加購物車、結帳 — happy path 完整跑
Sanity: 結帳 form 各欄位驗證、信用卡輸入、優惠券、發票

Kent C. Dodds 提的、適合前端 React 應用：

• Static（TypeScript / ESLint）佔底
• Integration（React Testing Library）變主力
• Unit 變少（純函式還是寫）
• E2E 還是少

理由：前端的「unit」很難純粹、integration 更有 ROI。

Spotify 提的、適合微服務：

• 大量 integration test（服務間互動）
• 少量 unit（純邏輯）
• 少量 E2E（critical flow）

重點：金字塔不是唯一答案、看你的 stack 與痛點。

Unit Test

# 純函式、無外部依賴
def test_calculate_discount():
    assert calculate_discount(100, 0.1) == 90

• 速度：最快（毫秒級）
• 範圍：單一函式
• Mock 外部依賴

Integration Test

# 多個元件互動
def test_create_order_via_api(db, mock_payment):
    resp = client.post('/orders', json={...})
    assert resp.status_code == 201
    assert Order.objects.count() == 1
    mock_payment.assert_called_once()

• 速度：中（秒級）
• 範圍：多元件
• DB / Redis / API 真連、外部第三方 mock

E2E (System Test)

// 跨整個 stack
test('user can checkout', async ({ page }) => {
  await page.goto('/');
  await page.click('text=加入購物車');
  // ... 完整流程
  await expect(page).toHaveURL('/order-success');
});

• 速度：慢（分鐘級）
• 範圍：整個系統
• 全程真實

Acceptance Test

驗證 business 是否接受。

User Story: 使用者買 3 件以上 9 折
Acceptance Criteria:
  - 2 件無折扣
  - 3 件 9 折
  - 5 件 9 折（不疊加）
  - 跨類別也算

Confirmation Test

Bug 修了後確認真的修好。跟 regression 不同 — confirmation 是針對該 bug。

Performance Test

延伸閱讀：Performance Testing 入門

子類型：

• Load Test（正常量）
• Stress Test（超量找崩潰點）
• Spike Test（突發爆量）
• Soak Test（長時間找 memory leak）

Security Test

延伸閱讀：Security Testing OWASP

子類型：

• Penetration Testing
• Vulnerability Scan
• Auth / Permission Test
• Static Application Security Test (SAST)
• Dynamic Application Security Test (DAST)

Accessibility (a11y)

• WCAG 標準（A / AA / AAA）
• Screen reader compatibility
• Keyboard navigation
• 顏色對比度
• 工具：axe / Lighthouse / Wave

Usability Test

• 真實使用者操作
• 觀察 friction 點
• A/B test 變體
• User journey map

Compatibility Test

• 跨瀏覽器（Chrome / Firefox / Safari / Edge）
• 跨裝置（iOS / Android / Windows / Mac）
• 跨螢幕尺寸
• 跨網路（4G / WiFi / 慢速）
• 跨語系 / 地區

Shift-Left（往左 — 早抓）

• Spec review
• TDD / BDD
• Pair programming
• Pre-commit hooks
• 早期 unit test

抓 bug 在 dev 階段。

Shift-Right（往右 — Prod 測）

• Canary release（1% 流量試）
• Blue / Green
• Feature flags
• A/B testing
• Real-user monitoring
• Synthetic monitoring

真實環境抓 dev 抓不到的事。

現代 QA：兩個都做。

Netflix 等大公司：testing in production 是日常。

Mutation Testing

測試你的 test 好不好。

工具改你的 code（mutate）、看 test 抓不抓得到。

// 原 code
function isAdult(age) { return age >= 18; }

// Mutant 1
function isAdult(age) { return age > 18; }  // 改 >= 為 >

// 如果你的 test 還是 pass → test 不夠好
// 工具: Stryker (JS), PIT (Java), mutmut (Python)

Property-based Testing

不寫具體 case、寫「規律」。

from hypothesis import given, strategies as st

@given(st.lists(st.integers()))
def test_reverse_twice_is_identity(lst):
    assert reverse(reverse(lst)) == lst

Hypothesis 會自動產 100 個 case 試。

Visual Regression

比對 screenshot 差異。

await expect(page).toHaveScreenshot('homepage.png');

工具：Playwright snapshot / Percy / Applitools / Chromatic

Snapshot Testing

把 component 渲染結果存檔、改了就 diff。

// Jest
expect(render(<Button />).toJSON()).toMatchSnapshot();

Chaos Engineering

故意搞破壞、看系統撐不撐。

• 隨機 kill pod
• 切斷網路
• 延遲增加
• DB 過載

工具：Chaos Monkey / Litmus / Chaos Mesh

Unit: Dev 寫。QA 看 coverage、推動寫。
Integration: Dev + QA 一起。QA review test scenario。
E2E: QA 主力。Dev 偶爾協助。
Smoke: 自動化、QA 設計、CI 跑。
Regression: QA 維護 + 自動化、Release 跑。
Acceptance: QA 主導、PM 簽核。
Performance / Security / A11y: 特定 QA 或 specialist。
Exploratory: QA 個人能力。

Q: 解釋 Test Pyramid

好答案：

由下而上 unit（最多）、integration、E2E（最少）。底層多因為快、便宜、抓邏輯 bug；上層少因為慢、貴、易 flaky。比例約 70/25/5。但這是經典 — 現代有變形如 Testing Trophy（前端）跟 Honeycomb（微服務）— 重點是依 stack 跟痛點選比例。

Q: Smoke 跟 sanity 差在哪

好答案：

Smoke 是「廣度淺」確認 build 還能用；sanity 是「深度窄」確認剛改的功能對。Smoke 每次 build 跑、sanity 改某模組後跑。

Q: 你怎麼決定要寫 unit 還是 E2E

好答案：

看抓的 bug 類型。純邏輯 / 純函式 → unit；多元件契約 / 服務間 → integration；使用者完整流程 → E2E。原則：能在底層抓就在底層抓、E2E 留 critical path。

1. Pyramid 不是 dogma、是 starting point
2. 每個類型該寫多少看你的 stack + 痛點
3. Smoke vs Sanity vs Regression 分清楚是 process 健康指標
4. Shift-left + Shift-right 兩個都要
5. 比起背名詞、設計合適你 team 的測試組合更重要

懂測試類型的 framework 不是炫術語、是幫你決定該寫什麼、跑什麼、跳過什麼。team 沒 unit test → 推 dev 開始寫；E2E 過多 → 改成 integration；regression 越跑越慢 → 分 smoke + 主力。理論工具拿來解現實問題、才有價值。