性能測試分類

客戶端性能：測試APP自身的性能，例如CPU、內存消耗；web頁面元素渲染速度
服務端性能：測試服務端項目程序的支持的并發、處理能力、響應時間等，主要通過接口來做性能測試

性能測試指標

并發

同時向服務器發送請求的用戶數。

TPS/QPS

TPS：Transaction Per Second，每秒鐘處理的事務數。在服務端接口性能測試中，事務可以理解成一次接口調用并返回，所以TPS其實就是每秒鐘處理多少次接口調用。TPS越高，處理能力越高，性能越好。

QPS：也是指每秒處理的請求

平均響應時間

響應時間=網絡傳輸的總時間+各組件業務處理時間

響應時間Response Time，簡稱RT，指的是服務端處理完一個請求所花費的時間，通常時間單位為毫秒ms。
平均響應時間就是n多個請求響應時間的平均值。
平均響應時間越短，代表性能越好，TPS就越高。

TOP響應時間

將所有請求的響應時間先從大到小進行排序，計算指定比例的請求都是小于某個時間。該指標統計
的是大多數請求的耗時。
Tp90（90%響應時間）：90%的請求耗時都低于某個時間
Tp95（95%響應時間）：95%的請求耗時都低于某個時間
Tp99（99%響應時間）：99%的請求耗時都低于某個時間

并發數/虛擬用戶（Vuser）

壓測工具中設置的并發線程/進程數量

成功率

請求的成功率

PV（Page View）

頁面/接口的訪問量

UV（Unique Visitor）

頁面/接口的每日唯一訪客

吞吐量

網絡中的流量，TPS越高，吞吐量越大

TPS、響應時間和并發數的關系

在系統達到性能瓶頸之前，TPS和并發數成正比關系，即并發數越高，TPS越高；達到瓶頸后，并發數增加，TPS
不會繼續增高（甚至會下降），這個最高的tps出現的點，叫做拐點
TPS和平均響應時間成反比關系，即平均響應時間越小，TPS就越高
響應時間單位為秒的情況下
TPS = 1 / 響應時間 * 并發數
TPS = 并發數 / 響應時間

性能監控指標

操作系統級別監控

CPU使用率、內存使用率、網絡IO（input/output）、磁盤（read/write/util）

中間件監控

連接數、長短連接、使用內存

應用層監控

線程狀態、JVM參數、GC頻率、鎖

DB層監控

連接數、鎖、緩存、內存、SQL效率

性能測試流程

需求調研

項目背景
測試范圍
業務邏輯 & 數據流向
系統架構
配置信息
測試數據量（量級要一致）
外部依賴
系統使用場景，業務比例
日常業務量
預期指標
上線時間

測試計劃

項目描述
業務模型及性能指標
測試環境說明
測試資源
測試方法以及場景設計原則（基準測試、單交易負載測試、混合場景測試、高可用性測試、穩定性測試、其他特殊場景）
測試進度安排及測試準則

環境搭建

測試機器硬件配置盡量和線上一致
系統版本與線上一致
測試環境部署線上最小單元模塊
應用、中間件、數據庫配置要與線上一致
其他特殊配置

數據準備

測試數據分為兩部分：基礎數據和參數化數據
通常采用以下三種方法進行構造
調業務接口
– 適合數據表關系復雜
– 優點：數據完整性比較好
執行SQL
– 適合表數量少，簡單
– 優點：速度最快

腳本編寫

選擇工具（Loadrunner、Jmeter、Locust等）
選擇協議（Http、TCP、RPC）
參數化
關聯
檢查點
事務判斷

壓測執行

選擇工具（Loadrunner、Jmeter、Locust等）
選擇協議（Http、TCP、RPC）
參數化
關聯
檢查點
事務判斷

調優回歸

性能調優需要整個團隊完成
反復嘗試
回歸驗證
監控工具
全鏈路排查
日志分析
模塊隔離

測試報告

概述
測試環境
結果與分析
調優說明
項目時間表
結論
建議

性能測試工具

Loadrunner（功能強大、重量級、商業軟件）
Jmeter（小巧靈活、輕量級、開源）
Locust（Python開源框架）
Ngrinder（ 開源壓測平臺）