1. 程式人生 > >JMeter性能測試的基礎知識和個人理解

JMeter性能測試的基礎知識和個人理解

技術 csv文件 自己 html 永遠 htm 響應 sse 報表文件

JMeter性能測試的基礎知識和個人理解

1. JMeter的簡介

??JMeter是Apache組織開發的開源項目,設計之初是用於做性能測試的,同時它在實現對各種接口的調用方面做的比較成熟,因此,常被用做接口功能測試和性能測試。它能夠很好的支持各種常見接口,如HTTP(S)、WebService、JDBC、JAVA、FTP等,並以多種形式展現測試結果。

2. 組成部分

??這部分主要是自己使用過的一些組件和配置的整合,不會詳細的講解每一個組件,有很多的組件都沒有介紹到,詳細的還請參考JMeter的官方文檔:https://wiki.apache.org/jmeter。

2.1 Thread Group(線程組)

??線程組模擬多個用戶,同時或者有順序的去執行任務。一個線程組可設置多個線程,每個線程之間互不影響。通過線程組模擬多個用戶用來進行服務器的並發或者負載測試。

??前提是創建一個Test Plan,對於Test Plan的創建,從File選項就可以創建了。關於線程組的創建,右鍵TestPlan,選擇【Add->Threads->Thread Group】,如下圖:

技術分享圖片

?? 添加完畢,如下圖是線程組的一些詳細的設置,具體的描述參考下文:

技術分享圖片

?? 關於【Action to be taken after a Sampler error】這裏設置的是當有一個請求出現了錯誤時,要怎麽做。

?? Continue:

出錯不會影響到其他的請求

??Start Next Thread Loop:停止當前這一次的Thread Loop,不管當前Thread Loop的請求是否完成,直接進入下一次。

??Stop Thread:會停止了當前的線程組

??Stop Test:停止這一次測試,會等待最後執行的請求的響應。

??Stop Test Now:強制停止這次測試,不會等待最後執行的請求的響應。

??關於 【Thread Properties】則是每一個線程的屬性

??Numbers of Threads:模擬的用戶或者線程數量

??Ramp-Up Period: 所有的線程在指定的時間內完成啟動

??Loop Count:

這一組線程執行的次數,舉個例子,線程數10,Loop Count為5,則這個測試最終會發起50個請求。

??Scheduler:指定一個線程組測試配置開始和結束時間,例如:指定Duration為3600,則一個小時後該測試就結束了。

2.2 Sampler(請求的類型)

??Sampler是JMeter的取樣器,采樣器用於發送請求到不同類型的服務器。其實通俗的理解可以將它看作是一種請求(不是很準確),例如HTTP,FTP等,實際上它可以執行許多的取樣。我一般使用的多是HTTP,所以就舉HTTP例子來講解下。

??添加一個HTTP Sampler,右鍵單擊線程組,依次選擇【Add->Sampler->HTTP Request】即可,如下圖:

技術分享圖片

??添加完HTTP取樣器後,配置該HTTP請求的一些參數以及URL等,途中的一些配置使用的是自定義變量進行填入的,後面會提到該組件,HTTP請求具體如下圖:

技術分享圖片

??配置的HTTP Sampler將是前面的線程組中的每一個線程要執行的具體的操作,那些線程組會按照線程組的配置,發送向指定的服務器應用發送HTTP請求。

2.3 Configuration Element(配置組件)

??主要用於定義一些配置和一些變量,提供給其他的組件使用,例如自定義變量,像上面的HTTP Sampler中使用到的${host},${port}等變量,可以使得測試的配置更加的靈活。

??添加一個自定義的變量,右鍵單擊線程組,依次選擇【Add->Config Element->User Defined Variables】即可,如下圖:

技術分享圖片

??添加完該組件後,定義一些自定義變量,如下圖所示:

技術分享圖片

2.4 Listener(監聽器)

??Listener提供的組件可以用來對請求的數據和響應的結果進行分析和統計,例如Summary Report可以統計測試信息的概要信息,View Result Tree可以監聽攔截到每一次請求的數據和響應的數據結果。

2.4.1 Summary Report

??添加Summary Report,右鍵單擊線程組,依次選擇【Add->Listener->Summary Report】即可,如下圖:

技術分享圖片

??Summary Report主要包括了請求數,平均響應時間,最小響應時間,最大響應時間,出錯率,吞吐量,每秒接收數據和每秒發送數據等,詳細如下圖所示:

技術分享圖片

2.4.1 View Result Tree

??添加View Result Tree,右鍵單擊線程組,依次選擇【Add->Listener->View Result Tree】即可,如下圖:

技術分享圖片

??View Result Tree主要監聽了請求的信息和響應的數據信息,詳細如下圖所示,

技術分享圖片

??對於Listener而言,是沒有什麽需要配置的,主要是通過這些組件,將數據可視化,方便測試人員分析和統計結果。

2.5 Timer(定時器)

??JMeter可以使用定時器來定義請求之間的等待時間。如果不指定,JMeter會一個請求完成後立即執行下一個請求,沒有任何等待時間。

2.5.1 Synchronizing Timer(模擬並發)

??性能測試中我們經常提到一個概念就是“並發”,其實在實際真實的性能測試中是不存在真正的並發的。為了更真實的模擬對一個請求的並發測試場景,我們通常設置一個聚合請求的點,JMeter中提供了這樣的一個功能設置,就是Timer中的Synchronizing Timer,它通過設置一個請求總數和一個等待時間,保證在指定時間內達到設置的請求數時,作為一組請求發送出去。舉個例子:請求數為20,等待時間無限長(即設置為0),那麽需要請求數達到20個時(原有的線程數一定要有20個或者以上,否則永遠將無法滿足這個條件,就不會發送了),JMeter才會發送請求,這樣保證了最接近並發的場景。
??添加一個Synchronizing Timer的步驟:右鍵單擊線程組,依次選擇【Add->Timer->Synchronizing Timer】即可,如下圖:

技術分享圖片

??設置Synchronizing Timer的一組請求的數量和等待請求數達到設置的數量值時的等待時間,即超時時間,如果為0表示一直等待,如果請求數達不到設置的值則一直不會發送。如果設置了值則如果指定時間內沒有達到那麽多個請求,時間到了也會將請求都發送出去,基本設置如下圖:

技術分享圖片

??註意:這個請求數量和超時時間的設置不合理會導致不會發請求。如果超時時間設置為0了,那麽一定要保證Synchronizing Timer設置的請求數小於線程總數,才能保證可以集合到指定的請求數。如果設置了超時時間則可以避免這種情況的出現,達到超時時間後無論是否滿足了設置的請求數都會發送出去。

??關於模擬並發的一些理解,如果使用Synchronizing Timer模擬50個並發,那麽假設我們使用了一個有50個線程的線程組,超時時間設置為0,則該測試每次都會等到有50個線程準備好了,一起發送請求,這樣就模擬了指定時刻50個用戶像系統並發請求的場景。這種請求往往是一瞬間的事情,如果只有50個線程,那麽下一次發起這個請求肯定需要等到所有的請求和響應完成,才能發起,至於這期間的間隔時間是多少就是不確定的,可能是1s,可能是5s,也可能是10s甚至是100s,都有可能;如果想要持續的發起50個並發,讓兩組並發之間的時間盡可能的短,則可能需要將線程數進行調大,設置為200,300或者500,其實這個值越大未必越好,或者說不斷的發起指定的並發請求未必是合理的,因為並發越大,每次並發的間隔越短的話,系統接收到的請求越多,那麽很可能會已經超出了系統的負載,那麽服務器就會處理超時,其實這樣也沒什麽意義了。所以對於這個並發的設置該怎麽測,要怎麽的效果,還需要根據實際的情況進行調整,尋找系統合適的並發數,做一定持續時間的並發數反而比設置短時間的持續並發來的有意義些。

2.5.2 Constant Throughput Timer(常數吞吐量計時器)

??常數吞吐量計時器,可以對測試計劃設置指定的吞吐量,以指定的吞吐量測試系統。

??添加一個 Constant Throughput Timer的步驟:右鍵單擊線程組,依次選擇【Add->Timer-> Constant Throughput Timer】即可,如下圖:

技術分享圖片

??常數吞吐量計時器,指定吞吐量,如下圖的吞吐量設置為了每分鐘3000,則TPS為50,即每秒50個請求,然後還有個選項是設置這個吞吐量是基於哪一些線程的,如果選擇This thread only則控制每個線程的吞吐量,選擇這種模式時,總的吞吐量為設置的target Throughput 乘以該線程的數量。例如該測試計劃總共開啟來的10個線程,每分鐘吞吐量為600(即每秒10個請求),那麽總的吞吐量就為10個線程*10個請求,每秒的吞吐量為100。其他的選項分別問所有激活的線程組成或者線程組的組成,例如基於線程組則表明,該線程組的吞吐量控制為指定的數量。具體如下圖:

技術分享圖片

??關於吞吐量的理解,假設有一個場景,我想要測試一組數據維持1min,然後每秒的吞吐量控制為50TPS;對於這種場景,我進行了一組測試,新建了個測試計劃,添加的一個線程組,配置的用戶數為1個(即線程數為1),然後添加一個Constant Throughput Timer,設置每分鐘的吞吐量為3000,即50TPS(每秒的請求數),然後進行測試。雖然只使用了一個用戶或者說線程,但是依然可以模擬出每秒50個請求的場景,這個就是Constant Throghput Timer的作用。

??至於它和上面的Synchronizing Timer有什麽區別?其實他們兩個使用的場景或者目標是不一樣的,Synchronizing Timer控制的是為測試計劃或者線程組的所有線程設置一個閾值,只有線程到達了某個值才統一一起發送,這就像某個指定時刻像系統發起指定的請求。而Synchronizing Timer控制的是指定的線程或者線程組它們的吞吐量,通過指定吞吐量來進行一定吞吐量對系統進行持久性測試。

2.6 Assertions(斷言)

??斷言就是斷定測試結果的正確性,通過斷言可以根據我們知道的結果來判斷請求響應是否正確。用於檢查測試中得到的響應數據等是否符合預期,用以保證性能測試過程中的數據交互與預期一致。

2.6.1 Response Assertion

??JMeteer可以通過,右鍵【Test Plan或者 Thread Group】添加斷言,選擇【Add->Assertions->Response Assertion】,具體如下圖所示:

技術分享圖片

??添加完後,下面是響應斷言的一些配置選項,可以設置斷言應用到那些請求,斷言的目標對象是什麽,例如針對"Text Respone"斷言等,還有添加斷言的期待值,具體如下圖:

技術分享圖片

2.6.2 JSON Assertion

??JMeteer可以通過,右鍵【Test Plan或者 Thread Group】添加斷言,選擇【Add->Assertions->Json Assertion】,具體如下圖所示:

技術分享圖片

??添加完後,下面是JSON斷言的一些配置選項,JSON斷言主要是針對響應的JSON數據,可以通過$.符號來取JSON得值,然後與斷言的期望值匹配,進而決定請求的響應有沒達到了期望,具體如下圖:

技術分享圖片

??對於Jmeter的斷言來說,基本上是這樣進行添加和配置。用於檢查測試中得到的響應數據等是否符合預期,用以保證性能測試過程中的數據交互與預期一致,通過斷言可以幫助我們篩選正確的響應。

3.運行JMeter

3.1 GUI的JMeter運行

??GUI的JMeter運行就上面的圖示一般,運行只需要點擊按鈕就好,如下圖:

技術分享圖片

??一般來說說,JMeter的GUI運行方式,會比較好系統的資源,所以需要比較多的內存,容易出現Out Of Menmory問題,用於實踐不是太長的測試場景效果會比較好,否則可能會出現卡死的現象。幾個小時甚至十幾個小時的測試都可以采用GUI方式測試,但如果時持續好幾天甚至超長時間,推薦使用命令運行。

3.1 命令行的JMeter運行(最佳實踐)

??命令行的運行方式是官方推薦的方式,這種方式沒那沒好系統的資源,不用渲染GUI界面,可以長時間穩定的運行,但是由於是命令行所以一些結果的分析沒那沒詳細和直接,需要使用圖形界面的工具解析測試的日誌和結果得到詳細的分析結果。

??參考下面的表中的JMeter的一些常用的參數釋義:
| 命令參數 | 命令參數釋義 |
| ------------ | ------------ |
| -n | 設置命令行模式,在非 GUI 模式下運行 JMeter |
| -t | 指定JMX腳本路徑,參數為:JMX腳本路徑,如果非當前目錄需要使用全路徑或者相對路徑 |
| -l | 指定結果文件路徑(jtl或者csv文件),參數為:結果文件路徑,如果不存在會自動創建 |
| -j | 指定執行日誌路徑,參數為:日誌路徑,如果路徑不存在,不會自動創建,同事將日誌輸出到控制臺即命令行。 |
| -g | 指定測試結果文件路徑。僅用於生成測試報表。參數為:csv結果文件 |
| -e | 設置測試完成後生成測試報表 |
| -o | 指定測試報表生成文件夾。文件夾必須為空或者不存在,參數為:報表文件夾路徑。 |

??命令行運行測試計劃:

#windows方式(CMD需要進入到JMeter的bin目錄下),Linux也是進入到JMeter的bin目錄下
#1.普通的執行測試
jmeter -n -t test.jmx 
#2.指定結果文件及日誌路徑的測試
jmeter -n -t test.jmx  -l report\testresult.csv -j reporttestog.log
#3.特別註意如果使用SSH連接到Linux執行命令,那麽需要使用nohup和&來保證進程在session關閉時不會退出,&表示測試程序會在後臺運行。
nohup  jmeter -n -t test.jmx  &
nohup jmeter -n -t test.jmx  -l report\testresult.csv -j reporttestog.log &

?? 針對生成的testresult.csv,可以使用GUI的JMeter創建Listener的聚合器等組件來對日誌進行詳細的分析,方便以圖形的方式展現測試的結果以及日誌。

??停止測試計劃的命令:

#停止測試計劃的命令有兩種,推薦第一種。
#1.使用shutdown.sh(Linux)或者shutdown.cmd(widnows)
./shutdown.sh
或者
./shutdown.cmd
#2.使用stoptest.sh(Linux)或者stoptest.cmd(widnows)
./stoptest.sh
或者
./stoptest.cmd

??使用shutdown腳本停止測試,如果有的線程還沒運行完畢也會等待它們執行結束;如果使用stoptest腳本停止測試則直接結束測試不管是否還有線程還未執行完畢。一般推薦shutdown的方式,除非卡住了的情況才是用stoptest方式。

4.參考文檔

?? http://jmeter.apache.org/

??https://www.cnblogs.com/fengpingfan/p/5586711.html

?

JMeter性能測試的基礎知識和個人理解