【基礎】性能測試，從0到實戰（手把手教，非常實用）

一、性能基礎

什麼是性能測試—>本質?

基於協議來模擬用戶發送的請求（業務模擬），對伺服器形成一定負載。
關注點：時間性能、空間性能
與介面無關

性能測試分類

性能測試（狹義）

性能測試方法是通過模擬生產環境運行的業務壓力量和使用場景組合，測試系統性能是否滿足生產性能要求。通俗地講，這種方法就是要在特定的運行條件下來驗證系統能力狀態。
負載測試

通過在被測系統上進行不斷加壓，直到性能指標達到極限，例如「響應時間」超過了預定指標或都某種資源已經達到了飽和狀態。
壓力測試（強度測試）

壓力測試方法，測試系統在一定飽和狀態下，例如cpu、記憶體在飽和使用情況下，系統能夠處理的會話能力，及系統是否會出現錯誤。
並發測試

並發測試方法通過模擬用戶並發的訪問，測試多用戶並發訪問同一應用、同一模組或數據記錄時，是否死鎖或其他性能問題。
配置測試

配置測試方法通過對被測系統軟\硬體環境調整，了解各種不同對系統性能影響程度，找到系統各項資源最優分配原則。
可靠性測試

在給系統載入一定業務壓力情況下，使系統運行一定時間，來檢測系統是否穩定。

常見的性能測試指標

用戶數
並發用戶數

在同一時間向伺服器發送請求的用戶數量
與每秒的並發請求數不同，一定要確認需求的目的是並發用戶數還是並發請求數
吞吐量（Throughput）

說明：單位時間內處理客戶端請求數量，直接體現軟體系統性能承載能力。
通常情況下，吞吐量用”請求數/秒”或”頁面數/秒”來衡量。

提示：
1.從業務角度看，吞吐量可以用”業務數/小時”、”訪問人數/天”、”業務數/天”，”業務訪問量/天”去衡量。
2.從網路角度看，還可以用”位元組數/天”、”位元組數/小時”等來衡量網路流量。
3.每秒事務數（TPS）、每秒查詢數（QPS）都歸屬吞吐量，區別是TPS\QPS描述伺服器具體性能處理的能力。

並發數

說明：並發測試的用戶數

擴展：
並發用戶數：某一物理時刻同時向系統發送請求的用戶數。
在線用戶數：某段時間內訪問系統的用戶數，這些用戶不一定都是同時向系統來提交請求。
系統用戶數：系統註冊的總用戶數據。

響應時間

說明：用戶從客戶端發起一個請求開始，到客戶端接收到從伺服器端返回結果整個過程中所消耗的時間。
點擊數

說明：衡量web伺服器處理能力的重要指標。

提示：
1.點擊數並不是大家認為的訪問一個頁面就是1個點擊數，點擊數是頁面中包含的元素（如：圖片、鏈接等）向web伺服器發出請求數數量。
2.通常會用每秒點擊次數（Hits per Second）指標來衡量web伺服器的處理能力。
注意：
只有web項目才有指標。

資源利用率

說明：指系統各種資源的使用情況，使用率=已使用的資源/全部的資源x100%

常見的資源使用率指標：
CPU，不超過80%
記憶體，不超過80%
磁碟，不高於90%
網路，不超過80%
如果資源利用率太小，也是造成資源浪費

錯誤率

說明：指系統各個資源的使用情況，一般使用”資源的使用量/總的資源可用量x100%”生成資源利用率的數據。

提示：通常，沒有什麼特殊需求的話
1.不同系統對錯誤率要求不同，但一般不超過千分之五—（根據實際項目而定萬分之五等等）。
2.穩定性較好的系統，其錯誤率應該是由超時引起的—超時率。

TPS（Transactions Per Second）

說明：每秒的事務數（單位時間內系統處理客戶端請求事務次數）
計算：tps=並發數/平均響應時間

事務：業務站在程式碼角度的統稱，可以理解為一段或多段程式碼。
提示：TPS歸屬吞吐量

QPS（Query Per Second）

說明：每秒查詢數（衡量web伺服器處理能力的一個重要指標）

應用：控制伺服器每秒處理指定請求數（如：控制伺服器達到每秒60qps，伺服器的性能各項性能指標是否正常）。

二、性能測試流程

流程圖

需求分析

測試對象
常用的
- 核心的，重要的
- 數據量、並發量
- 例子：
  
  註冊、登錄、搜索、添加購物車、下訂單、支付

確定性能指標

吞吐量、TPS
伺服器每秒處理的請求數量
響應時間

從瀏覽器發出請求，伺服器處理，到收到響應所需要的處理時間
用戶數
資源利用率
例子：

例子一：要求每天完成交易額2億,求每秒鐘最大交易數？
客單價:200-500,以300計算
採用28定律換算得出，以24小時計算
2/8原則：80%的用戶請求，集中在20%的熱點數據上，或時間段
計算公式：(200000000/300*0.8)/(24/0.2)/3600s=30.86個/s

例子二:每天8小時系統支付500萬用戶訪問
1.500萬在8小時內完成，500萬/8*3600，一般不採用，除非系統負載比較平穩/平均
2.先分析流量分布，再根據2/8定律估算每秒請求
80%的用戶數：500*0.8=400w
20%的時間內：8*0.2=1.6h
計算得出伺服器需要支援694次/s--->500*0.8/(8*0.2)/3600s
每小時的平均負載*4（估算，不建議此計算）

測試場景
- 單一場景
  
  登錄
  
  註冊
  
  搜索
  
  添加購物車
  
  下單、支付
- 混合場景
  
  用戶使用場景
  
  系統使用場景

測試計劃

測試目標
測試人員組織
壓測進度安排
壓力機
- 配置
- 要求
- 數量
風險

測試方案

測試工具

loadrunner

jmeter
測試環境

資料庫

伺服器

架構設計

有條件的情況下盡量和生產環境一致
測試策略
單一場景
混合場景
監控工具
- Linux
  nmon
  rpc
  jvisualVm
  Spotlight
- windows
  Spotlight
  perfmon.exe

用例設計

測試腳本
基於腳本的用例
場景設計
基於場景的用例

測試執行

腳本編寫

場景監控設計
業務設計

場景搭建

說明：測試場景設計重要的原則就是依據測試用例，把用例設計場景進行展現出來。

提示：
1.虛擬用戶數量及啟動虛擬用戶方式
2.場景相關的設置（如：集合點）
3.腳本是否有依賴關係（如：登錄與註冊）

運行場景

說明：運行腳本就是運行場景

1.負載的測試機不能夠運行設定的虛擬用戶數
2.沒有"預熱"過程
3.沒有模擬用戶的真實環境
4.性能用例運行次數過少

監控場景
測試報告

定位分析問題

後端
- 程式碼
- 軟體（服務）
  資料庫
  應用伺服器
- 硬體
前端
網路
測試定位問題順序：硬體問題—>網路問題—>應用伺服器、資料庫伺服器配置問題—>源程式碼、資料庫腳本—>系統架構問題

性能調優

性能測試人員經過對測試結果的對比，發現系統性能的瓶頸。

提示：
1.調優人員：以開發為主導，資料庫管理員、系統管理員、網路管理員、性能測試分析人員配合進行性能問題的調優
2.驗證：性能測試驗證通常需要很多輪；每輪迴歸時需要對所有的測試指標進行全方位的對比

系統調優由易到難的順序：

硬體問題
網路問題
應用伺服器、資料庫伺服器配置問題
源程式碼、資料庫腳本
系統架構問題

測試報告

對整體性能測試階段的回顧（覆蓋需求、測試不同階段的進度和產物、性能測試結果的分析）—>技術角度
對整體性能測試階段風險的管理—>管理的角度
對項目性能測試結果的總結（是否通過，經驗、教訓）

三、工具介紹及選型

LoadRunner

工業化的性能測試工具，能支援大量用戶，提供詳細的報表來提供測試分析的數量
支援的協議多
使用C語言來編寫的

優點

1.支援用戶量大（以萬為單位）
2.提供精確的報表
3.支援ip欺騙

缺點

1.收費
2.體積大
3.無法訂製

Jmeter

jmeter是Apache組織基於java開發的一款性能測試軟體。多協議（HTTP/HTTPS、JDBC、JAVA…等等)

優點

1.開源免費
2.體積小
3.有豐富的第三方插件

缺點

1.不支援ip欺騙
2.報表的精度比LR要差

LoadRunner與Jmeter之間該如何選擇？

優選選擇Jmeter
Jmeter能解決用Jmeter，Jmeter解決不了的用LoadRunner

四、Jmeter工具使用

文件目錄介紹

1.1 bin目錄

存放可執行文件和配置文件

jmeter.bat:windows的啟動文件
jmeter.log：日誌文件
jmeter.sh：linux的啟動文件
jmeter-properties：系統配置文件
jmeter-server.bat：windows分散式測試要用到的伺服器配置
jmeter-server：linux分散式測試要用到的伺服器配置

1.2 docs目錄

docs：是Jmeter的api文檔，可打開api/index.html頁面來查看

1.3 printable_docs目錄

printable_docs的usermanual子目錄下的內容是Jmeter的用戶手冊文檔。
usermanual下component_reference.html是最常用到的核心元件幫助文檔。

提示：printable_docs的demos子目錄下有些常用Jmeter腳本案例，可以參考。

1.4 lib目錄

該目錄用來存放Jmeter依賴的jar包和用戶擴展所依賴的jar包。

基礎配置

漢化設置

臨時修改：

options—>language—>choose language—>Chinese
永久修改：
1. 打開jmeter.properties
2. 修改language=zh_CN
3. 重啟jmeter

主題修改

選項—>主題—>選擇對應的主題，重啟jmeter

基本操作

啟動jmeter
添加執行緒組
添加http請求的取樣器，並配置
添加查詢結果樹的監聽器
點擊”啟動”運行jmeter，並查看結果

基本元件

執行緒組：模擬用戶的。
配置元件：進行測試環境和測試數據初始化—>比如自動化腳本中setup
前置處理器：對要發送請求進行預處理—>比如自動化腳本中參數化
取樣器：往伺服器發送請求—>比如自動化腳本中發請求的程式碼
後置處理器：對收到伺服器的響應進行數據提取—>比如自動化腳本中獲取響應中特定欄位語句
斷言：將收到響應結果又預期結果做對比—>比如自動化腳本中斷言
監聽器：查看測試腳本運行後結果和日誌—>比如自動化腳本中測試報告
定時器：等待一段時間—>比如自動化腳本中sleep
測試片段：封裝基本功能，不單獨執行，需要通過腳本的調用才能執行—>比如自動化腳本中封裝函數

作用域

核心：根據測試計劃中的樹形結構的父子節點來確定的

原則：

取樣器是沒有作用域的。
邏輯控制器：只對其子節點下的所有元件有效。
其他的元件。
- 如果其父節點是取樣器，則只對父節點取樣器有效。
- 如果其父節點不是取樣器，對父節點下所有子節點及節點中子節點有效。

元件的執行順序

順序：配置元件—>前置處理器—>定時器—>取樣器—>後置處理器—>斷言—>監聽器

注意:

配置元件、前置處理器、後置處理器都需要依賴取樣器才能運行
在同一個作用域下，相同類型元件執行順序是從上到下來按順序執行

Jemter重要的三個組件

執行緒組

作用：通過配置執行緒組中的執行緒數來模擬用戶。執行緒數就是用戶數，執行緒組是用戶組

特點：

模擬多用戶
取樣器和邏輯控制器必須在執行緒組下使用
一個測試計划下可以添加多個執行緒組，可以並行或串列執行
- 並行：默認情況下執行緒組為並行執行
- 串列：在測試計划下勾上”獨立運行每個執行緒組”

執行緒組的分類：

setup執行緒組：擁有測試前預處理操作，在所有執行緒組中最先執行
普通執行緒組：來執行業務測試腳本
teardown執行緒組：用來測試後的後置處理（數據、恢復環境）的操作，在所有的執行緒組中最後執行

執行緒組的屬性

執行緒數：模擬虛擬用戶數

Ramp-up時間：虛擬用戶啟動所需要的時間

循環次數：

配置指定次數：控制腳本運行執行的次數
配置循環永遠
- 需要調度器配置使用
- 運行時間：腳本執行的時間
- 延遲啟動時間：腳本等待特定的時間才能開始運行

http請求

http協議：可以填寫為HTTP或者HTTPS，默認不填寫為HTTP協議

http主機名/ip：如：//baidu.com 80

埠：可以填寫為任意值。默認不填寫時為80埠

請求發方法：HTTP協議所有支援的所有方法

路徑：目錄+參數

編碼格式：默認IOS國際標準，推薦使用utf-8

查看結果樹

取樣器結果：統計請求相關的資訊

請求：HTTP請求的請求頭和請求體的詳情資訊

響應：HTTP響應的響應頭和響應體的詳情資訊

jmeter響應中出現亂碼時：

修改jmeter.properties文件中，sampleresult.default.encoding=utf-8
重啟jmeter

Jmeter參數化常用方式

用戶定義的變數

方式1：

添加：執行緒組--->配置元件--->用戶自定義變數
配置：參數名+參數值
使用：在HTTP請求的取樣器中引用定義變數。$(參數名)

方式2：

配置：在測試計劃中去配置用戶定義變數
使用：在HTTP請求的取樣器中引用定義變數。$(參數名)
應用場景：當大量腳本中的參數值需要修改時候，直接修改用戶定義變數中值會更方便

用戶參數

添加：執行緒組—>前置處理器—>用戶參數
配置：

參數：添加變數
參數值：添加用戶—>針對每個用戶配置不同的參數值

使用：在HTTP請求的取樣器中引用定義的變數。$(參數名)

應用場景：可以針對不同的用戶獲取到不同的參數值

CSV Data Set Config

添加：執行緒組—>配置元件—>CSV數據文件設置

編寫CSV數據文件（.csv作為後綴）：

多個參數寫為多列，其中用逗號分隔
多組參數值，則使用多行來設置

配置：

路徑
文件編碼：UTF-8
變數名稱：從CSV數據文件中讀取的數據需要保存變數名。有多個變數時用逗號分隔
是否忽略首行：是否從CSV文件第一行中開始讀取
分隔符：要求與CSV數據文件中多列的分隔符一致
遇到文件結束符是否再次循環：默認TRUE
遇到文件結束符是否停止執行緒：當前一個參數為FALSE，該參數有效，一般設置為TRUE

函數

counter：

TRUE：每個用戶使用獨立計數器
FALSE：所有的用戶使用全局計數器

引用：在取樣器中使用$(__counter(FALSE,))來引用對應值

建議大家使用函數方式

Jmeter斷言

作用：讓腳本自動化執行過程中，能夠自動判定執行結果是否符合要求時候，需要添加斷言

響應斷言

添加：執行緒組—>HTTP請求—>斷言—>響應斷言

配置：

測試欄位：需要檢查的欄位
模式匹配規則：需要使用什麼規則來進行檢查
測試模式：需要校驗的值

Json斷言

適用於返回的HTTP響應為JSON格式

添加：執行緒組—>HTTP請求—>斷言—>JSON斷言

配置：

JSON PATH：$.weatherinfo.city
勾選”Addltonal assert value”
在expected value里填寫期望值

斷言持續時間：

適用於性能測試時，檢查HTTP請求的響應時間是否超過預期值

添加：執行緒組—>HTTP請求—>斷言—>斷言持續時間

配置：預期時間

Jmeter關聯（提取器、資料庫、邏輯控制器等）

當多個請求之間有依賴關係，後一個請求的參數需要使用前一個請求的響應數據時，需要用到關聯。

分類：

正則表達式提取器
xpath提取器
Json提取器

提取器

正則提取器

添加：執行緒組—>HTTP請求—>後置處理器—>正則表達式提取器

配置：

要檢查的響應欄位：默認主體
引用名稱：匹配後的數據要存儲的變數名
正則表達式：<p>(.*?)</p>，"()"里是要保存的數據
模板：$1$
- 數據1代表上面正則表達式中第幾個()
匹配數字：0代表隨機值、1代表第一個結果，-1代表所有結果
預設值：當沒有匹配上時將該值保存到變數里

xpath提取器

添加：執行緒組—>HTTP請求—>後置處理器—>xpath提取器

配置：

引用名稱：匹配後的數據要存儲的變數名
xpath path：xpath匹配規則
匹配數字：0代表隨機值、1代表第一個結果，-1代表所有結果
預設值：當沒有匹配上時將該值保存到變數里

json提取器

添加：執行緒組—>HTTP請求—>後置處理器—>json提取器

配置：

引用名稱：匹配後的數據要存儲的變數名
json path：json路徑。$.weatherinfo.city

引用：直接引用變數名即可

資料庫

連接準備：

打開資料庫，確定資料庫的表及對應的欄位
載入mysql的jdbc驅動
- 方法一：將jdbc驅動通過測試計劃，瀏覽的方式添加
- 方式二：將jdbc驅動jar包放入到lib\ext目錄下，並重啟jmeter
配置jdbc connection configuration
- created pool name：給連接池命名，用於後續引用
- 資料庫URL：jdbc:mysql://127.0.0.1:3306/test
- 用戶名
- 密碼

直連資料庫使用：

添加JDBC Request：取樣器下添加
配置：
- 配置連接池名稱
- 配置SQL語句
- 配置保存的變數名
  - 如果SQL語句返回了多個參數，輸入相同個數的變數名來保存
HTTP斷言中，就可以引用變數來進行判斷

邏輯控制器

控制元件的執行順序

if控制器

添加：執行緒組—>邏輯控制器—>if控制器

配置：

使用JS預發：”${name}”==”baidu”
使用jmeter函數的方式：${__jexl3(“${name}”==”baidu”,)}
推薦使用函數的方式

循環控制器

指定HTTP請求執行特定的次數

添加：執行緒組—>邏輯控制器—>循環控制器

配置：次數

循環控制器中的循環次數配置m與執行緒組中的循環次數n配置對比：

關係：如果同時配置，循環控制器下HTTP請求實際執行的次數應該是n*m
區別：這兩個循環次數作用域不同

ForEach控制器

與用戶定義的變數或正則表達式提取器配合使用，循環讀取返回的變數值，執行一次或多次。

與用戶定義的變數配合

添加：執行緒組—>邏輯控制器—>ForEach控制器

配置：
- 用戶定義的變數
  - 變數名：固定前綴+連續數字
- ForEach控制器
  - 變數前綴：用戶定義的變數中配置的固定前綴
  - 起始數字：連續數字的最小值-1
  - 結束數字：連續數字的最大值
  - 輸出變數名稱：依次讀取變數值後存儲到參數中，共HTTP請求來引用
- HTTP請求：
  - 引用輸出的變數名稱
與正則表達式配合使用
- 先通過正則表達式提取器，提取出請求中所有滿足條件數據
- 添加ForEach控制器，並配置提取所有滿足條件的數據，並保存為變數
- 在其子節點下，添加HTTP請求並引用變數，可循環讀取正則表達式里匹配的所有數據

定時器

同步定時器

需要進行大量用戶的並發測試時，為了讓用戶能真正同時執行，添加”同步定時器”使其阻塞執行緒，直到執行緒達到了預先設置數值，才開始進行取樣器操作。

配置：

並發數：同時達到多少用戶才開始發請求
超時時間：
- 必須配置：否則當虛擬用戶數無法被並發數整除時，會導致有部分用戶掛起無法執行
- 配置不能太短：必須比並發數載入時間要長。否則無法達到並發數的要求，數據就會被釋放掉

常數吞吐量定時器

用於性能測試中模擬用戶產生業務壓力，通過給定QPS來對伺服器發送固定頻率要求。

添加：執行緒組—>HTTP取樣器—>常數吞吐量定時器

配置：吞吐量的值QPS*60

分散式

原理：

分散式測試時分為一台控制機和多台代理機
控制機負責發布測試任務給代理機
代理機接收任務並向伺服器發送請求，並接收伺服器返回的響應，然後將測試結果返回給控制機
由控制機對測試結果數據進行匯總統計

分散式相關注意事項：

所有的測試機防火牆都已經關閉
所有的測試機及伺服器在同一個網路內
所有的測試機的jmeter版本和JDK版本完全相同
關閉jmeter里的RMI SSL開關

分散式配置

配置

代理機
- server_port：不重複。如果使用多個機器做代理機，可不用配置
- 關閉RMI SSL
控制機
- remote_server：所有代理機的IP+port，有多個代理機時要使用逗號分隔
- 關閉RMI SSL

運行

代理機
- jmeter-server.bat運行
控制機：
- jmeter.bat運行
- 控制代理機執行腳本，運行—>遠程啟動所有

性能測試常用術語解釋

性能測試，有些專業術語，為了方便大家的理解，這裡用通俗易懂的語言來解釋下，若有不準地方，謝謝糾正。

並發：tps
執行緒數：跑道中參加賽跑的人數
迭代：每人跑多少圈
循環：一次迭代裡面，循環跑其中的一條腳本，就是重複來回跑其中一條跑道
參數值：發請求時用的數據
參數化：這是一種策略，上面有介紹到它的具體用法
思考時間：模擬用戶等待時間
關聯：下一個請求入參依賴上一個請求中的某個返回值
檢查點：判斷請求的是否成功，一般只有查詢請求才會加檢查點，也就是斷言
集合點：等待所有用戶，同一時刻去發起請求，主要應用場景是購物中的秒殺
事務：一般把被測試中某個或者某幾個請求一起定義成一個事務，是人為的測試定義，可以是整個下單流程，也可以是下單中的一個請求
負載：伺服器的繁忙程度，如果一個伺服器，每次可以同時處理8個請求，如果請求數量大，後面請求就排隊，排隊請求越多，伺服器負載就越高
平均響應時間（art）：每個事務處理時間，從發送請求到接收到的響應
tps：每秒處理事務數
每秒點擊率（數）：每秒處理請求數，而不是用戶每秒發送請求數

性能學習路線:
jmeter→java基礎→beanshell→架構知識→linux分析調優→各種中間件等定位調優

性能測試，從0到實戰(包含熱門主流技術docker、k8s、skywalking、全鏈路、微服務、性能調優等)

熱門實戰性能測試：//www.cnblogs.com/upstudy/p/15916266.html

Tags: B-01【測試基礎】 B-02→ 測試理論 D-01【性能測試】