武大胆

性能測試方案#

明確測試目標#

• 業務需求：確定關鍵業務場景（如登錄、支付、查詢等）的性能指標（響應時間、吞吐量、錯誤率等）。
• 性能指標：設定基準值（如 95% 請求響應時間不超過 2 秒）、峰值（如支持 10 萬用戶並發）和容錯能力。
• 非功能需求：穩定性、擴展性、資源利用率（CPU、內存、磁碟 I/O、網絡帶寬）等。

測試範圍#

• 系統範圍：被測系統（SUT）的邊界（前端、後端、資料庫、第三方服務等）。
• 測試類型：負載測試、壓力測試、穩定性測試、容量測試等。

測試環境#

• 環境搭建：儘可能與生產環境一致（硬體配置、網絡拓撲、資料庫規模）。
• 數據準備：使用真實或模擬數據（需覆蓋典型場景，避免數據傾斜）。

場景設計#

• 單場景測試：針對單一功能（如用戶登錄）的性能測試。
• 混合場景測試：模擬真實用戶行為（如同時登錄、下單、查詢）。
• 峰值測試：模擬突發流量（如秒殺活動）。
• 穩定性測試：長時間運行（如 7×24 小時）觀察內存洩漏或性能下降。

執行策略#

• 逐步加壓：從低負載逐步增加到峰值負載，觀察性能拐點。
• 多輪迭代：優化後重複測試，驗證改進效果。

結果分析與報告#

• 性能基線：記錄當前性能狀態作為基準。
• 問題定位：結合日誌、監控數據定位瓶頸（如資料庫慢查詢、代碼死鎖）。
• 優化建議：提出代碼、配置或架構層面的優化方案。

性能測試關注點#

系統層面#

• CPU、內存、磁碟 I/O、網絡帶寬的使用率。
• 操作系統參數配置（如 Linux 內核參數）。

應用層面#

• 代碼執行效率（如算法複雜度、線程池配置）。
• 資料庫性能（慢查詢、索引缺失、連接池配置）。
• 中間件性能（如 Redis 快取命中率、消息隊列堆積）。

網絡層面#

• 延遲、丟包率、帶寬瓶頸。
• CDN 或負載均衡器的性能。

業務層面#

• 用戶並發量、TPS（每秒事務數）、RT（響應時間）。
• 業務成功率（如錯誤率不超過 0.1%）。

性能測試方法#

基準測試（Benchmark Test）#

• 目的：確定系統在正常負載下的性能基線。
• 方法：單用戶或低並發場景測試。

負載測試（Load Test）#

• 目的：驗證系統在預期負載下的表現。
• 方法：逐步增加並發用戶數，觀察響應時間和資源消耗。

壓力測試（Stress Test）#

• 目的：找到系統性能極限和崩潰點。
• 方法：持續加壓直至系統崩潰，記錄最大承載能力。

並發測試（Concurrency Test）#

• 目的：驗證多用戶同時操作時的資源競爭問題。
• 方法：模擬高並發場景（如搶購）。

穩定性測試（Endurance Test）#

• 目的：檢測長時間運行下的內存洩漏或性能衰減。
• 方法：持續運行 12 小時以上，觀察資源佔用趨勢。

容量測試（Capacity Test）#

• 目的：確定系統最大處理能力，為擴容提供依據。
• 方法：逐步增加數據量或用戶數，直到性能不達標。

常用性能測試工具#

負載生成工具#

• JMeter（開源）：
  • 支持 HTTP、JDBC、FTP 等多種協議。
  • 可擴展性強，支持 BeanShell 腳本和插件。
  • 適合 Web 應用和 API 測試。
• LoadRunner（商業）：
  • 功能全面，支持複雜場景錄製和 IP 欺騙。
  • 適合企業級大型系統。
• Gatling（開源）：
  • 基於 Scala，高性能，報告直觀。
  • 適合高並發場景。
• Locust（開源）：
  • 基於 Python，分佈式壓測，支持自定義腳本。
  • 靈活性高。

監控與分析工具#

• Prometheus + Grafana：
  • 實時監控系統資源、應用指標和自定義指標。
  • 可視化展示性能趨勢。
• APM 工具（如 New Relic、SkyWalking）：
  • 追蹤代碼級性能問題（如慢 SQL、方法耗時）。
• JVM 監控工具（如 JConsole、VisualVM）：
  • 分析 Java 應用內存、線程、GC 情況。
• 資料庫工具（如 Percona Toolkit、MySQL 慢查詢日誌）：
  • 定位 SQL 性能問題。

雲測試平台#

• BlazeMeter：兼容 JMeter 腳本的雲端壓測服務。
• AWS Load Testing：基於 AWS 的分佈式壓測方案。

測試場景和測試用例#

根據測試關注點#

系統層面#

1. CPU 使用率

• 場景：高並發用戶請求導致 CPU 負載上升。
  • 用例：模擬 1000 並發用戶執行查詢操作，持續 10 分鐘。
    • 步驟：
      1. 使用 JMeter 配置 1000 線程組循環執行查詢 API。
      2. 監控伺服器 CPU 使用率（如通過 Prometheus+Grafana）。
    • 預期結果：CPU 使用率峰值≤80%，無持續滿載現象。
    • 通過標準：CPU 未達到瓶頸，系統未崩潰。

2. 內存洩漏

• 場景：系統長時間運行後內存未釋放。
  • 用例：持續運行系統 48 小時，模擬用戶登錄、操作、退出流程。
    • 步驟：
      1. 使用 Locust 模擬每日活躍用戶行為（如每小時 500 用戶）。
      2. 監控 JVM 堆內存（如通過 VisualVM）。
    • 預期結果：內存佔用曲線平穩，無持續增長趨勢。
    • 通過標準：內存使用率波動在 ±5% 以內。

3. 磁碟 I/O 性能

• 場景：大量文件上傳 / 下載導致磁碟讀寫瓶頸。
  • 用例：模擬 100 用戶同時上傳 1GB 文件。
    • 步驟：
      1. 使用 JMeter 的 HTTP 請求上傳大文件。
      2. 監控磁碟 IOPS 和讀寫延遲（如通過 Linux iostat）。
    • 預期結果：磁碟利用率≤90%，平均延遲≤50ms。
    • 通過標準：文件上傳成功且無超時錯誤。

應用層面#

1. 資料庫慢查詢

• 場景：複雜 SQL 查詢導致響應時間過長。
  • 用例：執行多表關聯查詢（10 萬條數據）。
    • 步驟：
      1. 通過應用觸發查詢接口，記錄 SQL 執行時間。
      2. 檢查 MySQL 慢查詢日誌是否記錄該語句。
    • 預期結果：查詢時間≤2 秒，慢查詢日誌無記錄。
    • 通過標準：優化索引後查詢時間下降 50%。

2. Redis 快取命中率

• 場景：快取失效導致頻繁穿透到資料庫。
  • 用例：模擬 90% 快取命中率的讀取場景。
    • 步驟：
      1. 使用 Gatling 模擬用戶高頻讀取熱點數據（如商品詳情）。
      2. 監控 Redis 的keyspace_hits和keyspace_misses指標。
    • 預期結果：快取命中率≥90%。
    • 通過標準：資料庫查詢次數顯著減少（如下降 80%）。

3. 線程池配置

• 場景：線程池過小導致請求排隊。
  • 用例：模擬突發流量（如 500 並發請求，線程池容量 100）。
    • 步驟：
      1. 使用 JMeter 發送 500 並發請求至後端服務。
      2. 監控線程池活躍線程數和隊列堆積情況（如通過 Spring Boot Actuator）。
    • 預期結果：隊列等待時間≤1 秒，無請求被拒絕。
    • 通過標準：調整線程池後吞吐量提升 30%。

網絡層面#

1. 高延遲場景

• 場景：跨地域訪問導致網絡延遲增加。
  • 用例：從不同地區（如美東、歐洲）調用 API。
    • 步驟：
      1. 使用 BlazeMeter 配置多地理節點壓測。
      2. 測量平均響應時間（RT）。
    • 預期結果：RT≤3 秒（跨國訪問）。
    • 通過標準：啟用 CDN 後 RT 下降至≤1 秒。

2. 帶寬瓶頸

• 場景：視頻流媒體服務佔用大量帶寬。
  • 用例：模擬 1000 用戶同時觀看 1080P 直播。
    • 步驟：
      1. 使用 LoadRunner 模擬視頻流請求。
      2. 監控伺服器出口帶寬（如通過iftop）。
    • 預期結果：帶寬利用率≤80%，無卡頓現象。
    • 通過標準：啟用負載均衡後帶寬分配均衡。

業務層面#

1. 高並發下單（電商場景）

• 場景：秒殺活動導致瞬時流量激增。
  • 用例：模擬 1 萬用戶同時搶購 100 件商品。
    • 步驟：
      1. 使用 JMeter 配置 1 萬線程在 1 秒內啟動。
      2. 驗證訂單成功率及庫存一致性。
    • 預期結果：成功訂單數 = 100，無超賣或重複下單。
    • 通過標準：資料庫事務隔離級別優化後無髒讀。

2. 業務成功率

• 場景：支付接口在高負載下的錯誤率。
  • 用例：模擬每秒 500 筆支付請求（持續 5 分鐘）。
    • 步驟：
      1. 使用 Gatling 發送支付請求，監控 HTTP 狀態碼。
      2. 統計錯誤率（如 5xx 錯誤佔比）。
    • 預期結果：錯誤率≤0.1%。
    • 通過標準：熔斷機制觸發後錯誤率降至 0%。

3. 混合場景性能

• 場景：用戶同時執行登錄、瀏覽、下單操作。
  • 用例：模擬 70% 用戶瀏覽、20% 用戶加購、10% 用戶支付。
    • 步驟：
      1. 使用 Locust 按比例分配行為模型。
      2. 監控整體 TPS 和 RT（如 95 分位數≤2 秒）。
    • 預期結果：TPS≥500，業務鏈路無阻塞。
    • 通過標準：各接口響應時間波動在 ±10% 以內。

根據測試方法#

基準測試（Benchmark Test）#

目標

確定系統在低負載或單用戶場景下的性能基線，為後續測試提供對比依據。

場景

• 單用戶操作：無並發壓力，測試系統最優性能表現。
• 典型用例：用戶登錄、商品詳情頁加載、簡單查詢。

測試用例

用例 1：單用戶登錄響應時間

• 步驟：
  1. 使用 JMeter 配置 1 個線程（用戶），循環 10 次執行登錄接口請求。
  2. 記錄每次請求的響應時間（RT）。
• 預期結果：
  • 平均 RT ≤ 500ms，標準差 ≤ 50ms。
• 通過標準：
  • 無 HTTP 錯誤，RT 波動在 10% 以內。

負載測試（Load Test）#

目標

驗證系統在預期最大負載下的表現，如響應時間、吞吐量是否符合需求。

場景

• 預期並發用戶：模擬日常高峰流量（如電商大促期間 5000 並發用戶）。
• 典型用例：多用戶同時下單、查詢庫存、支付。

測試用例

用例 2：5000 並發用戶商品搜索

• 步驟：
  1. 使用 LoadRunner 模擬 5000 用戶同時執行商品關鍵詞搜索（如 “手機”）。
  2. 逐步加壓：每 30 秒增加 500 用戶，直至達到 5000 並發。
  3. 監控指標：TPS（每秒事務數）、RT（95 分位數）、錯誤率。
• 預期結果：
  • TPS ≥ 1000，RT ≤ 2 秒，錯誤率 ≤ 0.5%。
• 通過標準：
  • 吞吐量穩定，無資源（CPU / 內存）持續超過 80%。

壓力測試（Stress Test）#

目標

找到系統性能極限及崩潰點，驗證超負載下的容錯能力。

場景

• 超出預期負載：模擬遠超設計容量的突發流量（如 10 倍日常峰值）。
• 典型用例：秒殺活動流量暴增、API 被惡意刷量。

測試用例

用例 3：10 萬並發用戶搶購壓測

• 步驟：
  1. 使用 Gatling 配置 10 萬用戶瞬間啟動，請求秒殺接口。
  2. 持續加壓直至系統崩潰（如出現大量 5xx 錯誤或服務不可用）。
  3. 記錄崩潰時的並發量、錯誤類型及恢復時間。
• 預期結果：
  • 系統在崩潰前至少承載 8 萬並發，崩潰後 10 分鐘內自動恢復。
• 通過標準：
  • 關鍵服務（如訂單庫存）未出現數據不一致。

並發測試（Concurrency Test）#

目標

驗證多用戶同時操作時的資源競爭與同步問題（如死鎖、數據髒讀）。

場景

• 高競爭操作：同一資源被頻繁修改（如庫存扣減、賬戶餘額更新）。
• 典型用例：多人同時修改同一訂單、搶票場景。

測試用例

用例 4：100 用戶並發修改同一商品庫存

• 步驟：
  1. 使用 JMeter 配置 100 線程同時發送 “庫存扣減 1” 的請求。
  2. 初始庫存為 100，驗證最終庫存是否為 0。
  3. 檢查資料庫事務日誌是否存在死鎖或超時。
• 預期結果：
  • 最終庫存 = 0，無超賣或負數庫存。
• 通過標準：
  • 資料庫事務隔離級別（如使用樂觀鎖）有效避免髒讀。

穩定性測試（Endurance Test）#

目標

檢測系統在長時間運行下的性能衰減（如內存洩漏、連接池耗尽）。

場景

• 持續負載運行：模擬系統 7×24 小時服務，無間斷處理請求。
• 典型用例：金融系統日終批量處理、物聯網設備持續上報數據。

測試用例

用例 5：72 小時持續訂單處理

• 步驟：
  1. 使用 Locust 模擬每小時 1000 用戶下單，持續 72 小時。
  2. 監控 JVM 堆內存、資料庫連接池使用率、線程洩漏。
  3. 每 12 小時重啟一次壓測工具，避免工具自身資源洩漏。
• 預期結果：
  • 內存佔用波動範圍 ≤ 10%，無 OOM（內存溢出）錯誤。
• 通過標準：
  • 吞吐量（TPS）下降幅度 ≤ 5%。

容量測試（Capacity Test）#

目標

確定系統最大處理能力（用戶數 / 數據量），為擴容提供依據。

場景

• 數據量擴展：資料庫單表數據從百萬級增長到億級。
• 用戶量擴展：註冊用戶從 10 萬逐步增加到 100 萬。

測試用例

用例 6：億級數據量下的查詢性能

• 步驟：
  1. 向資料庫插入 1 億條測試數據，構建複合索引。
  2. 使用 JMeter 模擬 100 並發用戶執行分頁查詢（page=10000, size=10）。
  3. 監控 SQL 執行時間及磁碟 I/O。
• 預期結果：
  • 查詢時間 ≤ 1 秒，索引覆蓋率達 100%。
• 通過標準：
  • 分庫分表後查詢性能提升 50%。

最佳實踐#

1. 分層設計：

   • 基礎層：用基準測試覆蓋核心接口的單用戶性能（關注點：響應時間）。
   • 業務層：用負載 / 壓力測試驗證複雜場景（關注點：吞吐量、錯誤率）。
   • 系統層：用穩定性測試檢查資源洩漏（關注點：內存、連接池）。

2. 矩陣覆蓋法：
   將關注點與方法組成矩陣，確保每個關注點至少被一種方法覆蓋。例如：

   	負載測試	壓力測試	穩定性測試
   CPU 使用率	✅	✅
   內存洩漏			✅
   資料庫性能	✅	✅