返回列表
CI/CD 中的測試策略：讓每次部署都有品質保障
分享如何在 CI/CD 管線中規劃測試策略，從 commit 到 deploy 每個階段該跑什麼測試、怎麼設定品質關卡。
QA
CI/CD
GitHub Actions
測試策略
品質關卡
DevOps
💡 本指南持續維護中，內容會隨工具版本與市場情況更新。如有實測新發現會逐步加入個人經驗段落。
本文以 GitHub Actions 為範例，其他 CI/CD 工具的設定方式可能不同。
目錄
1. 為什麼 CI/CD 需要 QA？
沒有自動化測試的 CI/CD，只是「快速把 bug 部署到 production」。品質關卡是 CI/CD 的靈魂。
2. Stage 1：Commit 階段（每次 push 觸發）
執行時間目標：< 5 分鐘
-
靜態分析
ESLint、Pylint、SonarQube
-
單元測試
快速、獨立、無外部依賴
-
程式碼覆蓋率
設定最低門檻（例如 80%）
3. Stage 2：整合測試階段
執行時間目標：< 15 分鐘
-
API 測試
驗證服務間的互動
-
資料庫測試
Migration、資料完整性
-
第三方服務 Mock
不依賴外部服務
4. Stage 3：E2E 測試階段
執行時間目標：< 30 分鐘
-
核心流程測試
登入、購買、支付等關鍵路徑
-
跨瀏覽器測試
Chrome、Firefox、Safari
-
視覺回歸測試
Percy、Chromatic
5. Stage 4：部署前關卡
最後一道品質防線：
-
效能測試
確保沒有效能退化
-
安全掃描
OWASP ZAP、Snyk
-
人工審核
需要時的手動 approval
6. 品質關卡（Quality Gate）設定
什麼情況下應該擋住部署：單元測試失敗（零容忍）、覆蓋率低於門檻、高嚴重度的安全漏洞、效能指標退化超過 10%、核心 E2E 測試失敗。
7. 常見的 CI/CD 測試陷阱
避免這些常見問題：
-
測試太慢
把慢的測試移到非阻塞的 nightly build
-
Flaky Test
不穩定的測試要馬上修或隔離，否則團隊會習慣忽略紅燈
-
環境不一致
用 Docker 確保 CI 環境和 production 一致
-
只測快樂路徑
負面測試和邊界情況一樣重要
相關懶人包
2026 QA 趨勢實戰：我看到的 5 個正在發生的轉變（AI / Shift-Left / Observability）
從手動 QA 到 AI 輔助、從測試金字塔到測試獎盃。這篇分享我這 10+ 年看 QA 從「測完才知道」到「shift-left + AI」的真實觀察。
API 測試入門：用 Postman 和 pytest 打造你的第一個 API 測試
API 測試是現代 QA 必備技能。從 HTTP 基礎概念到實際用 Postman 和 pytest 寫測試，帶你踏出 API 測試的第一步。
Bug 回報的藝術：讓開發者秒懂的 Bug Report 寫法
一份好的 Bug Report 能大幅加速修復速度。分享 Bug 回報的最佳實踐，包含模板、嚴重度分級、以及如何與開發有效溝通。
ℹ️
一般聲明
本站提供之資訊僅供參考，不保證其完整性與正確性。使用者應自行判斷資訊之適用性。