效能測試--JMeter 主要元件介紹
JMeter主要元件:
1、測試計劃是使用 JMeter 進行測試的基礎,是執行緒組及其他一切元件的容器。
2、執行緒組:承載一個請求或者一個場景的容器,可以模擬單使用者單次請求,也可以模擬一定數量的併發使用者,實現併發使用者傳送請求。
3、取樣器(Sampler):模擬各種請求,所有實際的請求發起都由取樣器承擔,存在很多種請求,如:HTTP 、ftp、WebSocket請求等等。
4、監聽器:負責收集測試結果,同時也被告知了結果顯示的方式。功能是對取樣器的請求結果顯示、統計一些資料(吞吐量、KB/S……)等。
5、邏輯控制器:允許自定義JMeter傳送請求的行為邏輯,它與Sampler結合使用可以模擬複雜的請求序列。
6、斷言:用於來判斷請求響應的結果是否如使用者所期望,是否正確。它可以用來隔離問題域,即在確保功能正確的前提下執行壓力測試。這個限制對於有效的測試是非常有用的。
7、定時器:負責定義請求(執行緒)之間的延遲間隔,模擬對伺服器的連續請求。
8、配置元件維護Sampler需要的配置資訊,並根據實際的需要會修改請求的內容。
9、前置處理器和後置處理器負責在生成請求之前和之後完成工作。前置處理器常常用來修改請求的設定,後置處理器則常常用來處理響應的資料。
一.測試計劃
1、測試計劃就是一個完整的場景;
2、獨立執行每個執行緒組 :勾選以後所有的執行緒組都是順序執行的了。一般不勾選,讓所有 的執行緒組併發啟動。
3、函式測試模式 :勾選後會有詳細的請求記錄,消耗資源,影響客戶端效能,一般不勾選。
4、使用者定義的變數:全域性變數,測試計劃上可以新增使用者定義的變數。一般新增一些系統常用的配置,在用到此變數的時候直接用${變數名}引用即可。
如果測試過程中想切換環境,切換配置,一般不建議在測試計劃上新增變數;
5、新增目錄或jar包到ClassPath:新增執行中需要自己編寫加解密演算法,或者其他輔助類功能指令碼的jar包、檔案等。
二.執行緒組
1、thread group(執行緒組):通常新增執行的執行緒,理解為一個執行緒組,可以看做一個虛擬使用者組,執行緒組中的每個執行緒都可以理解為一個虛擬使用者。
2、setup thread group:一種特殊型別的ThreadGroup的,可用於執行預測試操作。
這些型別的執行緒執行測試前進行定期執行緒組的執行;類似LoadRunner的init,測試開始時進行初始化的工作。
3、teardown thread group:一種特殊型別的ThreadGroup的,可用於執行測試後動作。
這些型別的執行緒執行測試結束後執行定期的執行緒組;類似LoadRunnner的end,測試結束時進行回收工作。
參考部落格:https://www.cnblogs.com/poloyy/p/12782140.html
1.1、執行緒數:設定傳送請求的使用者數目,即併發數,執行緒數的設定建議不超過1000,
windows下,2g的 java記憶體,1m 的棧空間,最大啟動執行緒數=1000;
Linux下,2g的 java記憶體,1m 的棧空間,最大啟動執行緒數=2000;
JMeter執行記憶體參考部落格:JMeter執行記憶體設定
1.2、Ramp-Up 時間(秒):執行緒間的時間間隔,單位是秒,即所有執行緒在多少秒內啟動。
1.3、迴圈次數:請求的重複次數,如果選擇永遠✔,那麼請求將一直繼續。如果不選擇forever,而在輸入框中輸入數字,
那麼請求將重複指定的次數,如果輸入1,那麼請求將執行一次,如果是0,會出現問題。
1.4、Same user on each iteration:
【選中】每次迴圈用第一次的cookie,不再更新;可以理解為每次迴圈都是同一個使用者。
【不選中】每次迴圈都是用新的cookie值;可以理解為每次迴圈都是不同的使用者。
1.5、持續建立執行緒直到需要:延遲建立執行緒,直到執行緒被需要、取樣器開始執行時才會被建立,避免資源浪費。
1.6、持續時間(秒):執行緒組執行的持續時間。
1.7、啟動延遲(秒):測試計劃開始後,執行緒組的執行緒將在多少秒後再啟動執行。
連結部落格:Jmeter命令列執行指令碼_動態引數設定
三.取樣器(Http請求)
1、名稱:用於標識一個sample,建議使用一個有意義的名稱,如對應介面文件的中文或者英文名稱;
2、註釋:對於測試沒任何影響,僅用來記錄使用者可讀的註釋資訊;
3、協議:向目標伺服器傳送http請求時的協議,http/https,大小寫不敏感,預設http;
4、伺服器名稱或IP:http請求傳送的目標伺服器名稱或者IP地址,比如http://www.baidu.com;
5、埠號:目標伺服器的埠號,預設值為80,可不填;
6、方法:傳送請求的方法,參考部落格:http://www.cnblogs.com/imyalost/p/5630940.html
7、Content encoding:內容的編碼方式(Content-Type=application/json;charset=utf-8)
8、路徑:目標的URL路徑(不包括伺服器地址和埠)
9、自動重定向:如果選中該項,發出的http請求得到響應是301/302,jmeter會重定向到新的介面
10、使用KeepAlive:jmeter 和目標伺服器之間使用 Keep-Alive方式進行HTTP通訊(預設選中)
11、對POST使用multipart/from-data:當傳送HTTP POST 請求時,使用使用Use multipart/from-data方法傳送,預設不選中。比如可以用它來做檔案上傳。
12、瀏覽器相容模式(Browser-compatible headers):如果使用Use multipart/from-data for HTTP POST,建議勾選此項。
13、引數(Parameters)、訊息體資料(Body Data)以及檔案上傳(Files Upload)的區別:
13.1、引數(parameter)是指函式定義中引數,而argument指的是函式呼叫時的實際引數,簡略描述為:parameter=形參(formal parameter), argument=實參(actual parameter);
13.2、訊息體資料(Body Data)指的是實體資料,就是請求報文時的請求體,介面文件都會提供,如截圖欄位也可以引數化;
13.3、檔案上傳(Files Upload)指的是同請求一起傳送的檔案。MIME型別有STRICT、RFC6532、BROWSER_COMPATTIBLE等,如不知道MIME型別,可以使用抓包工具獲取。
四.監聽器
這裡常用的監控器主要是檢視結果樹、彙總報告、聚合報告、後端監聽器;
下面的部分是外掛新增的監控器,主要是監聽伺服器等,參考部落格:監聽器之jp@gc系列。
jp@gc - Actiive Threads Over Time: 不同時間活動使用者數量展示;
jp@gc - Bytes Throughput Over Time:不同時間吞吐量展示(圖表),聚合報告裡,Throughput是按請求個數來展示的,
比如說1.9/sec,就是每s傳送1.9個請求;而這裡的展示是按位元組Bytes來展示的圖表
jp@gc - Composite Graph: 混合圖表,在它的Graphs裡面可以設定多少個圖表一起展示,它可以同時展示多個圖表;
jp@gc - Hits per Second:每秒點選量;
jp@gc - PerfMon Metrics Collector:伺服器效能監測控制元件,包括CPU,Memory,Network,I/O等等;
jp@gc - Reponse Latencies Over Time:記錄客戶端傳送請求完成後,伺服器端返回請求之前這段時間;
jp@gc - Reponse Times Distribution: 顯示測試的響應時間分佈,X軸顯示由時間間隔分組的響應時間,Y軸包含每個區間的樣本數;
jp@gc - Transactions per Second: 每秒事務數,伺服器每秒處理的事務數;
引申參考部落格:全元件目錄
檢視結果樹:
顯示全部請求的響應和請求資料,無論成功或是失敗;
用表格察看結果:
表格式的察看結果樹,為每個樣本建立一行,使用大量記憶體。用於快速估計被測系統的行為。
Sample#:每個請求的序號。
Start Time:每個請求開始時間。(時:分:秒.毫秒)
Thread Name:每個執行緒的名稱(執行緒序號-第N次迴圈次數)。
Label:每個請求的自定義名稱(無修改時預設顯示請求型別,如Http,FTP等請求)。
Sample Time(ms):每個請求的響應時間。(單位:毫秒)
Status:請求狀態,如果為勾則表示成功,如果為叉表示失敗。
Bytes:響應的位元組數,請求的位元組數。
Sent Bytes:傳送的位元組數。
Latency:延遲的時間,等待時長。(單位:毫秒)
Connect Time(ms):連線伺服器的時間。(單位:毫秒)
樣本數目:所有請求個數,樣本數目 = 執行緒數(請求使用者數)* 請求次數 。(單位:個)
平均:所有請求的平均響應時間。(單位:毫秒)
最新樣本:最新樣本響應時間,表示伺服器響應最後一個請求的時間。(單位:毫秒)
偏離:伺服器響應時間變化、離散程度測量值的大小,或者,換句話說,就是資料的分佈。
聚合報告:
聚合報告為測試中的每個不同命名的請求建立一個錶行,展示請求響應時間,吞吐量等資料結果。
Label:每個JMeter的element的Name值。例如HTTP Request的Name
#樣本(Samples):樣本數量,多少個請求;
平均值(Average):平均響應時間,單位ms;預設是單個Request的平均響應時間,
當使用了TransactionController時,也可以以Transaction為單位顯示平均響應時間;
中位數(Median):也就是50%使用者的響應時間;
90%百分位(90%Line):90%使用者的響應時間
95%百分位(95%Line):95%使用者的響應時間
99%百分位(99%Line):99%使用者的響應時間
注:為什麼要用%使用者的響應時間:因為在評估一次測試的結果時,僅僅有平均事物響應時間是不夠的。
假如有一次測試,總共有100個請求被響應,其中最小響應時間為0.02秒,最大響應時間為110秒,平均事務響應時間為4.7秒,
你會不會想到最小和最大響應時間如此大的偏差是否會導致平均值本身並不可信?
我們可以在95 th之後繼續新增96/ 97/ 98/ 99/ 99.9/ 99.99 th,並利用Excel的圖表功能畫一條曲線,來更加清晰表現出系統響應時間的分佈情況。
這時候你也許會發現,那個最大值的出現機率只不過是千分之一甚至萬分之一,而且99%的使用者請求的響應時間都是在效能需求所定義的範圍之內的。
最小值(Min):最小響應時間;
最大值(Max):最大響應時間;
異常%(Error%):本次測試中出現錯誤的請求的數量/請求的總數;
吞吐量(Throughput):預設情況下標示每秒完成的請求數,也就是指伺服器處理能力,吞吐量=請求數/總時間;TPS越高說明伺服器處理能力越好;
接收 KB/sec:每秒從伺服器端接收到的資料量,即:收到的千位元組每秒的吞吐量測試;
傳送 KB/sec:每秒從伺服器端傳送到的資料量,同上。
五.邏輯控制器
參考部落格:邏輯控制器
如果(if)控制器:允許使用者控制該控制器下面的取樣器/控制器是否執行該節點下的子節點;
吞吐量控制器:jmeter自帶的翻譯這裡是錯誤的,因為它並不能控制吞吐量(吞吐量的概念請自行百度);其實質作用是允許使用者控制執行的頻率
總共有兩種執行模式:百分比執行和總執行
總執行(Total Executions):使控制器停止執行一定數量的測試計劃;
百分比執行(Percent Executions):使控制器按一定比例執行迭代的測試計劃;
流量(Throughput):對應上面的執行數量或者比例;
每個使用者(Per User):每個使用者
如果勾選此項,將導致控制器計算是否應該執行在每個使用者(每個執行緒)的基礎上;如果不加以控制,那麼將計算全部所有使用者。
迴圈控制器:可以設定請求的迴圈次數或永遠迴圈(如果選中永遠的話)。
僅一次控制器(once only controller):在多執行緒迴圈的時候,將使其子節點下的取樣器請求只執行一次
事務控制器:可以將多個請求放在同一個事務中。
如果選中Gegerate parentsample,則聚合報告中只顯示事務控制器的資料,而不會顯示其中的各個請求的資料,反之則全部顯示。
事務控制器會生產一個額外的取樣器,用來統計該控制器子結點的所有時間。
七.斷言——檢查點
斷言(Assertions)可以用來判斷請求響應的結果是否如使用者所期望的。它可以用來隔離問題域,即在確保功能正確的前提下執行壓力測試。這個限制對於有效的測試是非常有用的。
八.前置處理器和後置處理器
前置處理器(Pre Processors)和後置處理器(Post Processors)負責在生成請求之前和之後完成工作。前置處理器常常用來修改請求的設定,後置處理器則常常用來處理響應的資料。我們主要在動態關聯中用到後置處理器的正規表示式提取器。
九.定時器
參考文件:定時器
定時器(Timer)負責定義請求之間的延遲間隔;
元件執行順序(此順序參考網上的資料,若有錯誤之處,敬請指正)
在同一作用域名範圍內(不考慮邏輯控制器),測試計劃中的元件按照如下順序執行。
(1)配置元件(config elements )
(2)前置處理程式(Per-processors)
(3)定時器(timers )
(4)取樣器(Sampler)
(5)後置處理程式(Post-processors) (除非Sampler 得到的返回結果為空)
(6)斷言(Assertions)(除非Sampler 得到的返回結果為空)
(7)監聽器(Listeners)(除非Sampler 得到的返回結果為空)
我本渺小,但山峰,我一次次絕頂!
再小的帆也能遠航!
北海不是海!
相關文章
- 『動善時』JMeter基礎 — 8、JMeter主要元件介紹JMeter元件
- 軟體測試學習教程—Jmeter元件介紹(二)JMeter元件
- JMeter 測試元件介紹 - 物聯網大併發測試實戰 02JMeter元件
- 開源測試工具 JMeter 介紹JMeter
- Jmeter介面測試+效能測試JMeter
- 效能測試:主流壓測工具介紹
- Jmeter效能測試實戰JMeter
- Jmeter效能測試:高併發分散式效能測試JMeter分散式
- sitespeedio前端效能測試工具介紹前端
- Jmeter TCP協議效能測試JMeterTCP協議
- Jmeter效能測試 —— 壓力模式JMeter模式
- Jmeter效能測試簡單使用JMeter
- JMeter:效能測試利器全解析JMeter
- fio效能測試-環境搭建,功能介紹,測試講解
- Java基準效能測試--JMH使用介紹Java
- 伺服器效能測試典型工具介紹伺服器
- 測試開發之效能篇-JMeter介面測試JMeter
- 開源測試工具 JMeter 介紹 - 物聯網大併發測試實戰 01JMeter
- JMeter效能測試工具使用入門JMeter
- Jmeter做效能測試——HTTP請求JMeterHTTP
- 效能測試 —— Jmeter 命令列詳細JMeter命令列
- JMeter——非同步請求效能測試JMeter非同步
- 混沌測試介紹
- jmeter 效能測試入門手冊分享JMeter
- 效能壓力測試JMeter替代:LoadjitsuJMeter
- 基於jmeter的效能全流程測試JMeter
- 效能測試的流程及常用工具介紹
- [原創]H5前端效能測試工具介紹H5前端
- Jmeter效能測試 —— jmeter之使用ServerAgent監控伺服器JMeterServer伺服器
- 效能測試監控工具--Jmeter + Grafana + InfluxDBJMeterGrafanaUX
- 如何用 JMeter 編寫效能測試指令碼?JMeter指令碼
- 效能測試工具 jmeter 原始碼剖析:jmeter 分散式壓測啟動過程JMeter原始碼分散式
- 大話效能測試系列(1)- 效能測試概念與主要指標指標
- 介面效能測試 —— Jmeter併發與持續性壓測JMeter
- 簡單介紹.Net效能測試框架Crank的使用方法框架
- Jmeter效能測試場景的建立和執行JMeter
- jmeter介面效能測試-高併發分散式部署JMeter分散式
- Jmeter——效能測試的認知以及思考bug(一)JMeter