效能測試驗證系統在各種負載條件下的表現，是確保系統穩定性和用戶體驗的關鍵環節。
效能測試指標#
三大核心指標#
| 指標 | 定義 | 說明 |
|---|
| 並行用戶數 | 同時使用系統的用戶數量 | 施加壓力的強度 |
| 回應時間 | 從請求發出到收到回應的時間 | 用戶體驗的直接指標 |
| 系統吞吐量 | 單位時間處理的請求數量 | 系統處理能力 |
體檢中心的類比#
把體檢中心想象成軟體系統：同時在體檢的人數是並行用戶數，完成體檢的時間是回應時間，每小時完成體檢的人數是系統吞吐量。
三者之間的關係#
負載與效能的關係曲線：
吞吐量
│ ┌─────────┐
│ / \
│ / \
│ / 線性增長 \
│ / 區間 \ 過飽和區間
│/ \
└────────────────────────→ 並行用戶數
空閒區間 ↑
拐點
回應時間
│ /
│ /
│ /
│ ────────/
│ ───────/
└────────────────────────→ 並行用戶數
| 區間 | 特徵 | 測試目的 |
|---|
| 空閒區間 | 用戶少，回應快，吞吐量低 | 基準測試 |
| 線性增長區間 | 吞吐量隨用戶數線性增長 | 效能測試 |
| 拐點 | 系統趨於飽和 | 壓力測試 |
| 過飽和區間 | 回應時間無限長，系統崩潰 | 極限測試 |
負載測試 vs 壓力測試#
| 測試類型 | 目標 | 負載設計 | 關注點 |
|---|
| 負載測試 | 驗證系統在預期負載下的表現 | 線性增長區間 | 回應時間、吞吐量 |
| 壓力測試 | 找到系統的極限和瓶頸 | 拐點及以上 | 系統穩定性、恢復能力 |
七種常用效能測試方法#
效能測試方法
├── 後端效能測試 ─────── 模擬並行用戶驗證效能需求
├── 前端效能測試 ─────── 頁面渲染、資源加載最佳化
├── 程式碼級效能測試 ───── 單元級別的效能評估
├── 壓力測試 ─────────── 驗證臨界飽和狀態的穩定性
├── 組態測試 ─────────── 不同組態下的效能表現
├── 並行測試 ─────────── 發現資源競爭和死鎖
└── 可靠性測試 ────────── 長時間執行的穩定性
效能測試工具#
後端效能測試工具比較#
| 工具 | 類型 | 適用場景 | 特點 |
|---|
| JMeter | 開源 | 互聯網企業 | 免費、可擴展、支持海量並行 |
| LoadRunner | 商業 | 傳統企業 | 功能強大、易用性好 |
| Gatling | 開源 | 開發者友好 | DSL 腳本、實時監控 |
| k6 | 開源 | 現代 DevOps | JavaScript 腳本、雲原生 |
選型建議：互聯網企業傾向選擇 JMeter（免費、支持海量並行），傳統企業傾向選擇 LoadRunner（功能強大、官方支持）。
效能測試工具原理#
┌─────────────────────────────────────────────────────────┐
│ 效能測試工具架構 │
│ │
│ ┌─────────────────┐ ┌─────────────────────┐ │
│ │ 虛擬用戶腳本生成器 │ │ 系統監控器 │ │
│ │ (錄製/開發腳本) │ │ (收集效能指標) │ │
│ └────────┬────────┘ └──────────┬──────────┘ │
│ │ │ │
│ ↓ │ │
│ ┌─────────────────┐ │ │
│ │ 壓力控制器 │←─────────────────┘ │
│ │ (調度協調) │ │
│ └────────┬────────┘ │
│ │ │
│ ┌─────┴─────┐ │
│ ↓ ↓ │
│ ┌──────┐ ┌──────┐ │
│ │壓力機1│ │壓力機2│ ... (壓力產生器) │
│ └───┬──┘ └──┬───┘ │
│ │ │ │
│ └────┬────┘ │
│ ↓ │
│ ┌─────────────────┐ │
│ │ 被測系統 │ │
│ └─────────────────┘ │
│ │
│ ┌─────────────────┐ │
│ │ 測試結果分析器 │ (生成報告、資料分析) │
│ └─────────────────┘ │
└─────────────────────────────────────────────────────────┘
效能測試場景設計#
效能測試場景定義了測試負載的具體內容：
# 效能測試場景示例
scenario:
name: "電商大促場景"
# 用戶組態
users:
total: 1000
ramp_up: "5 users/second"
hold_duration: "30 minutes"
ramp_down: "10 users/second"
# 業務配比
operations:
- name: "瀏覽商品"
percentage: 50%
- name: "搜索商品"
percentage: 30%
- name: "下單購買"
percentage: 15%
- name: "支付"
percentage: 5%
# 思考時間
think_time: "3-5 seconds"
# 監控組態
monitoring:
- "CPU 使用率"
- "內存使用率"
- "資料庫連線數"
- "回應時間分布"
前端效能測試#
前端效能指標#
| 指標 | 說明 | 理想值 |
|---|
| First Byte Time | 首字節時間 | < 1s |
| Start Render | 開始渲染時間 | < 3s |
| First Interactive | 最早可交互時間 | < 5s |
| Speed Index | 頁面渲染速度指數 | 越小越好 |
前端最佳化規則（雅虎 35 條精選）#
這些規則已經過實踐驗證，能顯著提升前端效能。
| 規則 | 說明 |
|---|
| 減少 HTTP 請求 | 合併圖片、腳本、樣式表 |
| 減少 DNS 查詢 | 減少不同域的資源引用 |
| 使用 CDN | 靜態資源就近獲取 |
| Gzip 壓縮 | 壓縮文本類資源 |
| 壓縮圖片 | 使用適當格式和尺寸 |
| 快取靜態內容 | 利用瀏覽器快取 |
前端效能測試工具#
| 工具 | 用途 |
|---|
| WebPagetest | 全面的前端效能分析 |
| Lighthouse | Chrome 內建效能審計 |
| PageSpeed Insights | Google 的頁面速度分析 |
全鏈路壓力測試#
全鏈路壓力測試是在真實生產環境中進行的，技術難度高，需要多方配合才能順利完成。
什麼是全鏈路壓力測試？#
基於真實生產環境，模擬海量並行用戶請求和資料，對整個業務鏈路進行壓力測試，找出所有潛在效能瓶頸點。
單系統壓力測試的局限性#
| 問題 | 說明 |
|---|
| 假設依賴無限 | 單系統測試假設依賴系統能力無限 |
| 缺少呼叫瓶頸 | 系統間呼叫問題無法體現 |
| 缺少資源競爭 | 網路帶寬、文件句柄競爭無法體現 |
| 非核心系統遺漏 | 只測核心系統，遺漏其他瓶頸 |
全鏈路壓力測試的技術難點#
全鏈路壓力測試四大難點
├── 海量並行請求的發起
│ ├── JMeter 分布式方案
│ └── Jenkins Job 調度控制
├── 流量和資料隔離
│ ├── 資料標記
│ └── 影子資料庫
├── 業務負載模擬
│ ├── 歷史流量錄製
│ └── 用戶模型估算
└── 資料清理
└── 自動化批量清理
流量隔離方案#
┌─────────────────────────────────────────────────────┐
│ 全鏈路壓力測試 │
│ │
│ 正常請求 ─────────────→ 正常資料庫 │
│ │ │ │
│ └──(無標記)──────────────┘ │
│ │
│ 壓力測試請求 ─────────────→ 影子資料庫 │
│ │ (帶特殊標記) │ │
│ └────────────────────────┘ │
│ │
│ 中間件改造：識別並傳遞特殊標記，路由到正確的資料庫 │
└─────────────────────────────────────────────────────┘
效能瓶頸分析#
常見瓶頸類型#
| 瓶頸類型 | 表現 | 排查方向 |
|---|
| CPU 瓶頸 | CPU 使用率持續 > 80% | 演算法最佳化、線程組態 |
| 內存瓶頸 | 內存使用率高、頻繁 GC | 內存洩漏、快取策略 |
| IO 瓶頸 | 磁盤 IO 等待高 | 索引最佳化、讀寫分離 |
| 網路瓶頸 | 帶寬飽和、延遲高 | CDN、壓縮、連線池 |
| 資料庫瓶頸 | 慢查詢、連線數滿 | SQL 最佳化、分庫分表 |
效能分析方法#
效能瓶頸定位流程：
1. 監控系統整體資源使用情況
2. 定位資源使用例外的服務
3. 分析該服務的呼叫鏈路
4. 找出耗時最長的操作
5. 深入分析程式碼或 SQL
6. 最佳化並驗證效果
效能測試四大應用領域#
| 領域 | 目標 | 常用方法 |
|---|
| 能力驗證 | 驗證是否滿足效能需求 | 後端效能測試、壓力測試 |
| 能力規劃 | 評估系統容量和擴展性 | 壓力測試、組態測試 |
| 效能調校 | 解決效能瓶頸問題 | 全部七種方法 |
| 缺陷發現 | 發現內存洩漏、死鎖等 | 並行測試、壓力測試 |
效能測試最佳實踐#
效能測試不是一次性活動，而應該融入持續整合流程，及早發現效能退化。
效能測試流程#
效能需求獲取
↓
效能場景設計
↓
效能測試腳本開發
↓
效能場景實現
↓
效能測試執行
↓
效能結果報告分析 ← 最關鍵的環節
↓
效能最佳化
↓
再驗證
關鍵注意事項#
- 測試環境：盡量與生產環境一致
- 資料準備：背景資料量要接近生產環境
- 監控全面：監控所有相關服務器的指標
- 基線對比：建立效能基線，對比每次測試結果
- 持續測試：將效能測試納入 CI/CD 流程