快速摘要
AI 可以幫你寫測試，但不能幫你決定「該測什麼」。這篇說明在 AI 輔助開發中，哪些測試絕對不能省、哪些可以用 AI 自動化、以及怎麼建立一個實用的測試策略。
為什麼 AI 程式碼更需要測試
AI 生成的程式碼看起來「很對」，但這反而是危險所在。人寫的程式碼如果有明顯的 bug，通常在寫的過程中就會發現。AI 生成的程式碼表面上很完整，但可能在邊界條件和安全性上有隱藏的問題。
你不能像審查自己寫的程式碼那樣審查 AI 的程式碼——因為你沒有「寫」的過程中建立的心智模型。測試是彌補這個差距的最好方式。
不能省的測試
1. 安全測試（絕對不能省）
- 輸入驗證：SQL Injection、XSS、Path Traversal
- 認證邊界：未登入使用者能不能存取受保護的 API
- 授權邊界：普通使用者能不能存取管理功能
- CSRF 保護：表單提交是否有 token 驗證
2. 核心邏輯測試
- 付款計算
- 權限判斷
- 資料轉換（特別是涉及金額、日期的轉換）
3. 邊界條件測試
- 空值、null、undefined
- 超大輸入
- 特殊字元（emoji、中文、RTL 文字）
- 並行操作（兩個人同時修改同一筆資料）
AI 可以幫忙的測試
- 單元測試骨架：AI 可以根據函式簽名自動生成基本測試
- 測試資料生成：AI 可以生成各種邊界值的測試資料
- E2E 測試腳本：AI 可以根據使用者故事生成 Playwright/Cypress 腳本
- Mock 資料：AI 可以根據 API schema 生成 mock 回應
最佳實踐：讓 AI 生成測試骨架 → 人工審查並補充邊界條件 → AI 生成測試資料 → 人工確認測試邏輯正確。
測試策略框架
| 層級 | 自動化 | AI 輔助 | 人工 |
|---|---|---|---|
| 單元測試 | 是 | 生成骨架 | 審查邊界 |
| 整合測試 | 是 | 生成 mock | 設計場景 |
| E2E 測試 | 是 | 生成腳本 | 定義流程 |
| 安全測試 | 部分 | 掃描工具 | 紅隊測試 |
| 效能測試 | 是 | 生成腳本 | 分析結果 |
推薦工具
- 單元測試：Jest（JS）、pytest（Python）
- E2E 測試：Playwright（推薦）、Cypress
- 安全掃描：Semgrep、Snyk
- 效能測試：k6、Lighthouse CI
- 覆蓋率：Istanbul（JS）、Coverage.py（Python）
常見問題
AI 寫的測試可以信任嗎？
AI 寫的測試可以覆蓋基本場景，但可能遺漏邊界條件和安全測試。建議用 AI 生成測試骨架，再手動補充關鍵場景。
Vibe Coding 也需要寫測試嗎？
如果只是做原型或一次性的頁面，可以不寫。但如果要上線給使用者用，最少需要：功能測試 + 安全測試。
測試覆蓋率要達到多少？
不要追求數字。重要的是覆蓋關鍵路徑和安全邊界，而不是達到 80% 或 100%。一個覆蓋率 40% 但測對地方的專案，比覆蓋率 90% 但都是 trivial 測試的專案更安全。