一、性能測試注意點
1. 用jmeter測試時使用BeanShell腳本獲取隨機參數值，會導致請求時間過長，TPS過低。應改為使用csv讀取參數值，記錄的TPS會更加準確。

? 注：進行性能測試時，應注意會影響請求時間的操作，盡量避免因為測試方法不當影響測試結果。

2. 進行穩定性測試前，盡量對Jmeter進行減負，避免運行時間過長，導致Jmeter卡死。

減負方式：

（1）參數寫死或者直接讀取csv的數值，減少程序負荷

（2）并發線程不要設置太高，設置200以下

（3）“察看結果樹”勾選“僅日志錯誤”，盡可能減少jvm內存使用

（4）可添加“Simple Data Writer”且保存為csv格式數據

（5）其他監聽組件可以都禁掉，通過保存的數據線下生成圖標報告

?3. 注意如果服務重啟后，PID會發生變化，通過命令行方式收集CPU、內存使用數據時，要使用最新的PID進行采集：

ps -ef | grep test ?查詢進程號，test為服務名關鍵字

top -b -d 1 -p 34012 > 1117_log ?其中34012為PID，1117_log為需要記錄的日志名（不存在會自動新建文檔）

4. 如果勾選了CPU等監聽組件，需要先啟動代理服務:

cd ../tmp/ServerAgent-2.2.3

執行./startAgent.sh

5.使用jp@gc - PerfMon Metrics Collector性能測試工具時，要在運行壓力測試前開啟性能監控，否則可能會造成壓力測試期間的性能測試數據缺失而造成性能分析不準確。

6. 進行壓力測試時，逐步增加并發量，直至能夠明顯看出性能瓶頸為止

二、性能指標分析

聚合報告各項性能指標

聚合報告常用指標

Label

每個JMeter的element（例如 HTTP Request）都有一個Name屬性，這里顯示的就是Name屬性的值

Samples

請求次數（=線程數*循環次數）

Average

平均響應時間

Median

中位數,也就是50％用戶的響應時間

90% Line

90％用戶的響應時間

95% Line

95％用戶的響應時間

Min

最小響應時間

Max

最大響應時間

Error%

本次測試中出現錯誤的請求的數量/請求的總數

Throughput

吞吐量——默認情況下表示每秒完成的請求數（Request per Second）

KB/Sec

每秒從服務器端接收到的數據量

接口性能測試指標一般通過標準：

性能測試指標通過標準

需滿足的并發數
（舉例：每天8W用戶訪問，平均在線時長10分鐘，1天用戶24小時內使用系統）
C = 80000 * 0.166/24=553
注：0.166為10/60得出

C = nL/T
C^= C + 3*根號C?
其中C為平均并發用戶數，n為login session的數量，L是login session的平均長度，T是值考察的時間長度
C^為并發用戶數峰值

需要滿足的TPS
TPS = （80000*80%）/(20%*8*60*60)=11/sec

根據二八原則：
20%常用時間，滿足80%業務量
TPS = n*80%/(20%*活躍時間*60*60)
注：活躍時間一般為8小時

響應時間

根據在并發情況下的響應時間2/5/10原則，最長不能超過10s

錯誤率

具體系統具體要求，一般小于萬分之一

緩存命中率

具體系統具體要求，一般大于85%通過

CPU占用率

70% 好，85% 壞，90%+ 很差

內存使用率

一般小于80%通過
?

?感謝每一個認真閱讀我文章的人！！！

?我個人整理了我這幾年軟件測試生涯整理的一些技術資料，包含：電子書，簡歷模塊，各種工作模板，面試寶典，自學項目等。歡迎大家點擊下方名片免費領取，千萬不要錯過哦。

?文檔獲取方式：點擊右邊鏈接領取：軟件測試全套資料分享??????