上線前未經負載測試的系統，如同未經碰撞測試的汽車。本文提供一份結構化、可落地的負載測試清單，涵蓋專案管理、工具選型、流程標準化、代碼審查與持續改進，助您在生產環境發生災難前攔截效能問題。
一、專案管理與組織保障
| 檢查項目 | 關鍵動作 | 產出物 |
|---|
| 方法論對齊 | 採用敏捷/瀑布統一流程，將負載測試列為 Definition of Done 必經關卡 | 測試計畫文件 |
| 高層贊助 | 向 IT 總監/VP 證明「修線上 Bug 成本 = 100x 測試成本」，爭取專項時間/預算 | 贊助郵件/會議紀要 |
| 效能需求量化 | 與業務協商：併發用戶數、TPS、P99 延遲、資料增長率、可接受停機窗口 | SLA/SLO 文件 |
| 使用者期望管理 | 明確功能測試 ≠ 效能測試，雙軌並行 | 測試策略文件 |
| 工期試算 | 依團隊資源估算腳本開發、環境佈建、執行分析、報告產出工時，納入專案排程 | 甘特圖/工時表 |
二、負載測試工具標準化
建議企業內部統一 1-2 款主流工具，沉澱腳本庫與最佳實踐：
- 企業級： Micro Focus LoadRunner (原 Mercury)、Neotys NeoLoad、Tricentis Flood
- 開源/輕量： Apache JMeter、k6 (Golang、腳本即代碼、CI/CD 友好)、Locust (Python)
- 資料庫專用： Quest Benchmark Factory、HammerDB、SQLQueryStress
- 雲端原生： Azure Load Testing、AWS Distributed Load Testing
避免「每人一套工具」導致腳本無法複用、報告無法對比、技能斷層。
三、負載測試流程標準化 (PDCA 循環)
- 規劃： 依 SLA 設計測試場景 (基準、壓力、尖峰、浸潤、恢復)
- 腳本開發： 錄製/手寫腳本 → 參數化 (資料池、思考時間) → 相關性處理 (動態 Token) → 驗證點 (斷言業務成功)
- 環境佈建： 生產鏡像環境 (資料量、索引、統計資料、硬體規格) 或按比例縮放並換算
- 執行監控： 應用層 (APM)、資料庫層 (DMV/Extended Events/Query Store)、OS 層 (PerfMon/Exporter)、網路層
- 結果分析： 瓶頸定位 (CPU/IO/Lock/Wait/Network/Code Path) → 根因分類 (Code/Config/Infra/Architecture)
- 報告產出： 結論、證據、建議、驗收標準、回歸測試計畫
- 知識沉澱： 腳本入庫、測試資料版本化、分析筆記標籤化
四、代碼審查雙重保障
- 開發自測： 單元測試覆蓋率 > 80%，含效能單測 (如單筆查詢 < 10ms)
- 同儕審查： 強制 Pull Request 至少 1 人審查，重點檢查 N+1 查詢、缺少索引、大交易、同步呼叫外部 API
- 專職 QA (若預算允許)： 專注探索式效能測試、邊界條件、混沌工程注入
五、流水線化：將負載測試內建於 CI/CD
- 每夜跑基準測試，趨勢圖自動生成 (Grafana/Kibana)
- PR 觸發微效能測試 (關鍵 API 100 VU 5 分鐘)，門檻：P99 < 基準 1.2x
- 發布前跑完整壓力測試，自動生成比對報告
- 失敗即阻斷部署，強制修復或回滾
六、漸進式擴展策略
資源有限時，優先測試：
- 曾發生效能事故的核心業務
- 高營收/高風險路徑 (下單、付款、核心查詢)
- 新架構/新框架首發專案
每輪測試產出「效能最佳實踐指南」輸入下一輪，形成正向循環。
七、避免將效能問題帶入生產的鐵律
- 無負載測試報告，不得上線 (強制品管閘)
- 測試環境資料量 < 生產 10% 時，必須有換算模型並標註不確定性
- 所有第三方元件 (套件、API、中介軟體) 必須納入測試範圍
- 資料庫變更 (DDL/索引/統計資料) 必須經過負載驗證
結語
負載測試不是成本，是 **風險投資** 的最高報酬率專案。以此清單為起點，結合團隊實況裁剪擴充，建立「效能內建」文化，讓 SQL Server 效能調優從「救火」轉向「防火」。
