測試策略（一）：「在我電腦上可以跑」不是測試策略

cover

「在我電腦上可以跑」不是測試策略

一句話總結：好的測試策略不是寫更多測試，是在對的層級寫對的測試。

結論先講：測試金字塔存在的意義，是讓你用最少的成本得到最大的信心。底層多寫、頂層少寫，這個順序反過來你就完了。

「It works on my machine.」

每個工程師都說過或聽過這句話。它之所以變成業界經典笑話，是因為它精準揭露了一個問題——你不是在測試，你只是在碰運氣。

沒有系統化測試策略的團隊，生活長這樣：

部署恐懼症：每次上線都像拆炸彈，沒人敢保證不會炸掉舊功能
重構癱瘓：沒有測試保護網，沒人敢動既有程式碼，技術債越疊越高
Bug 回歸：修一個 bug 順便引入三個新 bug
信心危機：問「這個版本穩嗎？」所有人面面相覷

你有沒有想過，為什麼有些團隊能每天部署好幾次，而有些團隊一個月部署一次都在抖？差別不在技術能力，在測試策略。

測試金字塔：一張圖搞定分層邏輯

測試金字塔是 Mike Cohn 提出的概念，核心就一句話：越底層的測試寫越多，越頂層的測試寫越少。

為什麼？因為底層測試跑得快、維護成本低、問題定位精準。頂層測試跑得慢、容易壞、出問題還不知道壞在哪。

         Manual / Exploratory（最少）
              ↑ 慢、貴
           E2E Tests（少量）
              ↑
        Integration Tests（適中）
              ↑
         Unit Tests（大量）
              ↑ 快、便宜

具體的比例建議：

Unit Test：70%，毫秒級執行，驗證單一函式的正確性
Integration Test：20%，秒級執行，驗證元件之間的互動
E2E Test：5-8%，分鐘級執行，驗證使用者完整流程
Manual Test：2-5%，探索性測試，發現自動化漏掉的東西

這不是死規定，但如果你的比例是反過來的——E2E 寫最多、Unit Test 寫最少——那你的 CI pipeline 一定慢到令人崩潰，而且測試還天天在 flaky。

測試覆蓋率：是指標，不是目標

很多團隊把覆蓋率當 KPI 追。「我們要達到 90% 覆蓋率！」聽起來很有紀律，但你知道邊際遞減效應嗎？

從 0% 到 70%：每 1% 的提升都有顯著價值
從 70% 到 85%：開始要花更多心力在邊界條件上
從 90% 到 95%：你在測試一些生產環境幾乎不會走到的路徑

合理的覆蓋率目標：

核心業務邏輯（計費、權限、狀態轉換）：90%+
一般業務邏輯（CRUD、資料轉換）：70-80%
工具函式：80-90%
UI 元件：50-70%

不要為了追數字而寫無意義的測試。 一個只是 expect(true).toBe(true) 的測試，覆蓋率是上去了，但保護力是零。

TDD 和 BDD：兩種不同的思維起點

這兩個方法不是互斥的，它們在不同層級各有用處。

**TDD（Test-Driven Development）**的循環是 Red → Green → Refactor：先寫一個會失敗的測試，然後寫最少的 code 讓它通過，最後重構。TDD 特別適合單元測試層級，當你很清楚函式的輸入輸出時效果最好。

**BDD（Behavior-Driven Development）**用 Given-When-Then 來描述行為：前提條件是什麼、觸發什麼操作、預期什麼結果。BDD 更適合整合測試和 E2E 測試，尤其是需求來自非技術人員的時候。

兩者的哲學差異和更深入的比較，可以參考 SDD 測試驅動開發那篇。

這篇的重點回顧

測試策略的核心是分層——底層多寫、頂層少寫。覆蓋率是溫度計不是目標，用來衡量健康度但不要為了數字寫垃圾測試。

接下來我們進入實戰。下一篇聊 Unit Test 和 Integration Test 怎麼寫、用什麼工具、有什麼坑。

系列文章：

Terry Yao's Blog

分類

目錄