性能測試基礎知識

1.性能測試的類型/劃分

1.1 壓力測試

壓力測試（stress testing）——測試系統在一定飽和狀态下，例如CPU、記憶體、磁盤等飽和使用情況下，系統能夠處理的會話能力，以及系統是否會出現錯誤。

特點：

1.目的：測試系統已經達到飽和狀态的業務處理能力；
2.手段：通過模拟負載使系統資源達到一個較高的水準；
3.該方法一般用于系統穩定性測試
           

壓力測試屬于負面測試。

負面測試：測試系統是否不執行它不應該完成的操作。
正面測試：測試系統是否完成了它應該完成的功能。
           

1.2 負載測試

負載測試（load testing）——通過逐漸增加系統負載，測試系統性能的變化，并最終确定在滿足性能名額的情況下，系統所能承受的最大負載量的測試。

負載測試主要是為了找到系統的最大負載能力，為性能調優提供資料。

1.目的：找到系統最大負載能力；
2.手段：不斷加壓，直到超過預定的名額或者部分資源已經達到飽和狀态。
           

1.3 性能測試

性能測試——模拟真實系統中使用者行為來測試系統的性能，以确定是否能否能滿足使用者要求

1.4穩定性測試

穩定性測試（Endurance testing）——通過負載測試得出的較穩定的并發數做一個長時間的測試，主要觀察系統是否存在記憶體等方面的問題。

2.性能測試的目的

• 能力驗證/性能名額驗證
• 規劃能力
• 性能調優
• 缺陷發現

3.性能測試不同角色的關注點

開發設計的關注點

• 架構設計是否合理——系統架構
• 資料庫設計是否存在問題——資料庫設計
• 代碼是否存在性能問題——代碼
• 系統是否有不合理的記憶體使用——代碼
• 系統是否有不合理的線程同步方式——設計或代碼
• 系統是否存在不合理的資源競争（異步）——設計或代碼

運維的關注點（測試也需要關注）

• 伺服器的資源使用是否合理——資源使用率
• 應用伺服器和資料庫資源使用是否合理——資源使用率
• 系統是否能實作擴充（架構也關注）——系統可擴充性
• 系統支援多少使用者通路，系統最大業務處理量是多少——系統容量
• 系統性能可能的瓶頸——系統可擴充性
• 系統能否支援7*24小時的通路——系統穩定性

使用者的關注點（測試也需要關注）

• GUI呈現時間（即速度、響應時間）
• 本地資源消耗是否合理

4.性能測試不同階段的測試方法

開發/技術預演階段：

• 架構設計、方案標明、資料庫設計——壓力測試，得出吞吐量（測試資料可以為公司積累沉澱用）
• 并發測試

系統測試/上線前：

• 負載測試——系統最大并發、最優并發、系統穩定——》響應時間、TPS（Transaction Per Second每秒事務處理量）、系統資源、系統所支援的使用者或者處理能力

5.性能測試的流程

（1）計劃測試

（2）測試設計

（3）建立腳本

（4）建立場景

（5）運作場景

（6）分析結果

6.性能測試前期規劃

（1）分析應用程式

• 1）确定系統元件
  • 系統體系架構（B/S、C/S）以及核心framework
  • 各元件直接協定（http、web、services、socket、oracle）
  • 采用的開發語言
  • 網絡拓撲結構
  • 各元件在系統架構中的作用
  • 軟體、硬體配置
• 2）分析負載模型
  • 确定關鍵測試用例
    • 關鍵業務
    • 高通路量
    • 複雜的動态内容
  • 業務層面
    • 使用者數
    • 關鍵用例吞吐率以及行為習慣——》負載測試
  • 使用者體驗
  • 資料來源：伺服器端監控/資料庫日志/專家估算
• 3）安全系數：在估計規模、成本、進度的時候，應該保留2~10的系數，以彌補我們在某個方面考慮的缺陷

（2）定義測試目标

• 度量最終使用者的響應時間
• 定義最優的硬體配置
• 檢查穩定性
• 度量系統容量
• 确定瓶頸
• ……

（3）制定測試計劃

• 組織架構以及各自職責
• 測試資源（人力/工具）
• 搭建測試環境（開發、系統工程師、測試）
• 進度計劃
• 溝通管理（例會、工作規範）
• 風險規避（技術攻關先行）

（4）制定測試方案

• 測試需求
• 測試方法與政策
• 測試環境
• 測試用例
• 測試場景
• 監控點

7.眼觀六路

• 調試腳本
  • VuGen（腳本生成器）單次回放
  • VuGen多次回放
  • Controller單腳本多使用者（并發性）
  • Controller多腳本多使用者（驗證是否腳本依賴）
  • extend log
• 壓力測試——增加并發TPS已經無法上升
  1. 确認施壓機資源是否充分（否——》下一步）
  2. 網絡是否存在瓶頸（否——》下一步）
  3. 确認服務端哪個元件出現瓶頸（否——》下一步）
  4. 說明資源使用率不足，若能達到性能标準，可以降低硬體标準；若沒有達到，需要考慮優化程式性能或者應用的配置
• 負載測試
  • 每秒處理的交易數—并發數關系：最佳并發數處理能力
  • 響應時間—并發數關系：最大并發數、使用者感受
• 網絡資源
  • 了解用戶端和服務端網絡帶寬
  • 了解測試請求的是占用上行還是下行大
  • 如果是下行多，可以觀察LR的throughput，是否存在瓶頸
  • 如果是上行大，可以通過sar -n DEV 12觀察rxbyt/s、txbyt/s來确認瓶頸
• 硬體資源
  1. Cpu %idle是否小于15~20%（N：不是CPU瓶頸；Y：CPU，記憶體或IO轉2）
  2. Cpu %wa是否大于10~15%(N：NO IO瓶頸為CPU瓶頸；Y： 記憶體或IO轉3)
  3. Free –m看swap是否有用到或free是否小于100M（N：NO記憶體瓶頸為IO瓶頸；Y：記憶體瓶頸）
  4. 常用linux檢視資源指令：top、free、vmstat、iostat、sar

PS：這是一篇複習/回顧文。

作者：AmyZYX

出處：http://www.cnblogs.com/amyzhu/

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利。