Jmeter的操做流程

1.1 什麼是 JMeter

Apache JMeter 是 Apache 組織開發的基於 Java 的壓力測試工具。用於對軟件作壓力測試，它最初被設計用於 Web 應用測試，但後來擴展到其餘測試領域。 它能夠用於測試靜態和動態資源，例如靜態文件、Java 小服務程序、CGI 腳本、Java 對象、數據庫、FTP 服務器， 等等。JMeter 能夠用於對服務器、網絡或對象模擬巨大的負載，來自不一樣壓力類別下測試它們的強度和分析總體性能。另外，JMeter 可以對應用程序作功能/迴歸測試，經過建立帶有斷言的腳原本驗證你的程序返回了你指望的結果。爲了最大限度的靈活性，JMeter 容許使用正則表達式建立斷言。

Apache jmeter 能夠用於對靜態的和動態的資源（文件，Servlet，Perl 腳本，java 對象，數據庫和查詢，FTP 服務器等等）的性能進行測試。它能夠用於對服務器、網絡或對象模擬繁重的負載來測試它們的強度或分析不一樣壓力類型下的總體性能。你可使用它作性能的圖形分析或在大併發負載測試你的服務器/腳本/對象。

1.2 爲何是 JMeter

爲何選擇 JMeter，下面看看 JMeter 的特點。

1. 開源許可: Jmeter 是徹底免費的，並提供了源碼可供自定義開發

2. 圖形界面模式：提供了方便的圖形界面來編輯和開發測試腳本

3. 平臺無關：能夠輕易在 windows、linux、mac 上運行

4. 多線程框架：經過線程組，可以輕易的設置不一樣測試的併發用戶。

5. 圖形測試結果：提供了圖表、表格、樹、文件等格式的結果顯示。

6. 易於安裝：jmeter 不須要安裝，下載解壓便可用。

7. 高擴展性：jmeter 支持用戶自定義測試腳本，一樣還提供了各類插件。

8. 多測試類型支持：支持性能測試、分佈式測試、功能測試

9. 仿真模擬：支持多用戶併發測試

10. 多協議支持：支持 http、jdbc、ldap、soap、jms、ftp 等等協議

11. 錄製&回放：支持用 badboy 或 jmeter 錄製

12. 腳本測試:jmeter 支持 beanshell 和 selenium

1.3 JMeter 工做原理

JMeter 基本工做原理如圖：

JMeter 完整的工做原理如圖：

1.4 總結

本次對 jmeter 進行了簡單的基本介紹，主要讓你們對 jmeter 有個基本的瞭解。

第二篇 JMeter 目錄及關鍵配置分析

2.1 前言

學習一種工具，首先得對其關鍵配置及目錄等有一個基本的瞭解，這樣能更方便的深刻掌握該工具，下面咱們就 JMeter 的目錄及相關關鍵配置進行分析說明。

2.2 下載安裝

1. 安裝主程序

從 Apache JMeter 官網下最新版本：

http://jmeter.apache.org/download_jmeter.cgi

下載後直接解壓便可。

2. 安裝插件管理

從 https://jmeter-plugins.org/install/Install/ 或 https://jmeter-plugins.org/downloads/all/  下載插件管理包，如圖：

將下載的包放至 jmemter 解壓根目錄的 lib/ext 下後重啓jmeter便可。

 

 

2.3 目錄說明

先看一下解壓後的 JMeter 安裝目錄：

目錄說明：

  backups： 包含jmeter對測試計劃的自動備份保存

 bin： 包含啓動、配置等相關命令

 docs： 官方本地文檔目錄

 extras： 輔助庫

 lib： 核心庫，包含 JMeter 用到的各類基礎庫和插件

 licenses： 包含 non-ASF 軟件的許可證

 printable_docs： 可打印版本文檔目錄

 LICENSE： JMeter 許可說明

 NOTICE： JMeter 簡單信息說明

 README.md： JMeter 官方基本介紹

下面咱們重點看下 bin 目錄，如圖：

主要介紹 bin 目錄下咱們最關注幾個文件：

 jmeter.properties： JMeter 核心配置文件，各類配置基本在這完成

 log4j.conf： JMeter 日誌配置管理

 jmeter.log： JMeter 運行日誌記錄，什麼輸出信息、警告、報錯都在這裏進行了記錄

 jmeter.bat： windows 下 jmeter 啓動文件

 shutdown.cmd： windows 下 jmeter 關閉文件

 stoptest.cmd： windows 下 jmeter 測試中止文件

 jmeter-server.bat： windows 下 jmeter 服務器模式啓動文件

注：每個.cmd 文件都對應一個.sh 文件，.sh 是 linux 下的對應功能的文件，其餘文件的功能就不一一說明了，同時其餘目錄這裏也再也不進行闡述，有興趣的能夠本身深刻看下。

2.4 關鍵配置說明

1. jmeter.properties 配置說明

主要包含如下幾個方面的配置：

SSL 配置：

重點關注下面幾個配置

# 指定 HTTPS 協議層

https.default.protocol=TLS

# 指定 SSL 版本，實際應用中可能須要修改

https.default.protocol=SSLv3

# 設置啓動的協議

https.socket.protocols=SSLv2Hello SSLv3 TLSv1

# 緩存控制，控制 SSL 是否能夠在多個迭代中重用

https.use.cached.ssl.context=true

JMeter 界面顯示配置

這裏就不對其界面顯示控制進行說明了，通常狀況下默認界面能知足你們的應用了。

JMeter 測試項目自動備份配置

# 設置是否啓用自動備份，默認是 true

jmeter.gui.action.save.backup_on_save=true

# 設置自動備份目錄，默認備份至 JMeter 根目錄的 backups下

jmeter.gui.action.save.backup_directory=

# 設置自動備份項目數，默認爲最近 10 個

jmeter.gui.action.save.keep_backup_max_count=10

遠程主機配置

# 配置遠程主機的 IP，默認爲本機。用逗號","能夠設置多個遠程主機

remote_hosts=127.0.0.1

# 多個遠程主機指定示例以下,其中:後爲端口

remote_hosts=127.0.0.1:1099,127.0.0.1:1200,127.0.0.1:1300

對於 RMID 的配置請直接看配置文件中的選項說明

日誌管理配置

# 設置日誌格式

log_format_type=default

# 設置日誌輸出級別

log_level.jmeter=INFO

# 設置 junit 日誌輸出級別

log_level.jmeter.junit=DEBUG

# 設置日誌輸出目標文件，默認爲 jmeter.log

log_file=jmeter.log

等等其餘還有 10 多個配置大項（就不一一列舉了）

jmeter.bat 關鍵配置修改

爲了更優化的使用 jmeter，須要對 jmeter.bat 中的一些配置根據當前機器的配置進行優化，這裏進行關鍵配置項說明，找到這些配置，對其中的數值根據當前機器的硬件配置來修改。

set HEAP=-Xms2048m -Xmx2048m

set NEW=-XX:NewSize=512m -XX:MaxNewSize=512m

set SURVIVOR=-XX:SurvivorRatio=8 -

XX:TargetSurvivorRatio=50%

set TENURING=-XX:MaxTenuringThreshold=2

if %current_minor% LEQ "8" (

rem Increase MaxPermSize if you use a lot of Javascript in

your Test Plan :

set PERM=-XX:PermSize=512m -

XX:MaxPermSize=1024m

)

2.5 啓動 jmeter

在 bin 目錄下直接雙擊 jmeter.bat 便可

啓動後的界面以下：

2.6 總結

本次就 jmeter 的安裝和配置及關鍵配置項進行了分享，你們能夠深刻的去研究下其餘的一些配置，以便進一步的熟悉 jmeter 的原理和應用。

第三篇 HTTP 協議報文結構及示例

3 3 .1 前言

從事性能測試必不可繞過的就是協議，對基本知識的瞭解也還，仍是深刻掌握協議的機制，都能讓你在從事性能測試實施時顯得更加順手。下面咱們就 HTTP 協議及性能測試過程必須掌握的一些分析工具來進行分享。重點分享性能測試實施過程當中必須掌握的關鍵技術、工具。更細節的請參考 HTTP 相關書籍或 RFC 文檔。

3.2 HTTP 基本架構

下面咱們用一張簡單的流程圖來展現 HTTP 協議基本架構，以便你們先有個基本的瞭解。

Web Client 能夠是瀏覽器、搜索引擎、機器人等等一切基於HTTP 協議發起 http 請求的工具。

Web Server 能夠是任何的能解析 HTTP 請求，並返回給Web Client 可識別的響應的服務，常見的有 apache、nginx、IIS 等等 web 服務器。

濃縮就是精華，看下最簡潔的 HTTP 交互圖：

3.3 HTTP 報文結構

3.3.1 請求報文

HTTP 請求報文由請求行、請求頭、空行和請求內容 4 個部分構成。

以下圖所示：

下面對上圖進行簡單的分析：

請求行

由請求方法字段、URL 字段、協議版本字段三部分構成，它們之間由空格隔開。

經常使用的請求方法有：GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。

請求方法（全部方法全爲大寫）有多種，各個方法的解釋以下：
GET     請求獲取Request-URI所標識的資源
POST    在Request-URI所標識的資源後附加新的數據
HEAD    請求獲取由Request-URI所標識的資源的響應消息報頭
PUT     請求服務器存儲一個資源，並用Request-URI做爲其標識
DELETE  請求服務器刪除Request-URI所標識的資源
TRACE   請求服務器回送收到的請求信息，主要用於測試或診斷
CONNECT 保留未來使用
OPTIONS 請求查詢服務器的性能，或者查詢與資源相關的選項和需求

最經常使用：
GET方法：在瀏覽器的地址欄中輸入網址的方式訪問網頁時，瀏覽器採用GET方法向服務器獲取資源

POS方法：要求被請求服務器接受附在請求後面的數據，經常使用於提交表單

https://blog.csdn.net/wyvbboy/article/details/51093831

http://www.javashuo.com/article/p-pqoyzfwc-cq.html

請求頭

請求頭由 key/value 對組成，每行爲一對，key 和 value 之間經過冒號(:)分割。請求頭的做用主要用於通知服務端有關於客戶端的請求信息。

典型的請求頭有：

User-Agent：生成請求的瀏覽器類型

Accept：客戶端可識別的響應內容類型列表；星號* 用於按範圍將類型分組。*/*表示可接受所有類型，type/*表示可接受type 類型的全部子類型。

Accept-Language: 客戶端可接受的天然語言

Accept-Encoding: 客戶端可接受的編碼壓縮格式

Accept-Charset： 可接受的字符集

Host: 請求的主機名，容許多個域名綁定同一 IP 地址

connection：鏈接方式（close 或 keeplive）

Cookie: 存儲在客戶端的擴展字段

附：session 、cookie、token的區別：https://blog.csdn.net/jikeehuang/article/details/51488020

空行

最後一個請求頭以後就是空行，用於告訴服務端如下內容再也不是請求頭的內容了。

請求內容

請求內容主要用於 POST 請求，與 POST 請求方法配套的請求頭通常有 Content-Type（標識請求內容的類型）和 Content-Length（標識請求內容的長度）

 

3.3.2 響應報文

HTTP 響應報文由狀態行、響應頭、空行和響應內容 4 個部分構成。

以下圖所示：

下面對響應報文格式進行簡要的分析說明：

狀態行

由 HTTP 協議版本、狀態碼、狀態碼描述三部分構成，它們之間由空格隔開。

狀態碼由 3 位數字組成，第一位標識響應的類型，經常使用的 5 大類狀態碼以下：

1xx：表示服務器已接收了客戶端的請求，客戶端能夠繼續發送請求

2xx：表示服務器已成功接收到請求並進行處理

3xx：表示服務器要求客戶端重定向

4xx：表示客戶端的請求有==非法內容==

5xx：標識服務器未能正常處理客戶端的請求而出現意外錯誤

常見狀態碼說明：

200 OK： 表示客戶端請求成功

400 Bad Request： 表示客戶端請求有語法錯誤，不能被服務器端解析

401 Unauthonzed： 表示請求未經受權，該狀態碼必須與

WWW-Authenticate 報文頭一塊兒使用

404 Not Found：請求的資源不存在，例如輸入了錯誤的 url

500 Internal Server Error： 表示服務器發生了不可預期的錯誤，致使沒法完成客戶端的請求

503 Service Unavailable：表示服務器當前不能處理客戶端的請求，在一段時間後服務器可能恢復正常

響應頭

通常狀況下，響應頭會包含如下，甚至更多的信息。

Location：服務器返回給客戶端，用於重定向到新的位置

Server： 包含服務器用來處理請求的軟件信息及版本信息

Vary：標識不可緩存的請求頭列表

Connection: 鏈接方式。

對於==請求端==來說：close 是告訴服務端，斷開鏈接，不用等待後續的求請了。keeplive 則是告訴服務端，在完成本次請求的響應後，保持鏈接，等待本次鏈接後的後續請求。

對於==響應端==來說：close 表示鏈接已經關閉。keeplive 則表示鏈接保持中，能夠繼續處理後續請求。Keep-Alive 表示若是請求端保持鏈接，則該請求頭部信息代表指望服務端保持鏈接多長時間（秒），例如 300 秒，應該這樣寫 Keep-Alive: 300

空行

最後一個響應頭以後就是空行，用於告訴請求端如下內容再也不是響應頭的內容了。

響應內容

服務端返回給請求端的文本信息。

3.4 HTTP 報文示例

在這裏咱們在 Firefox 下用 firebug 隨意抓取一個 HTTP 包和上文的報文結構作下一一對應關係圖，以便你們瞭解實際的包和標準報文結構的對應關係。

3.5 總結

對於 HTTP 協議的交互過程這裏就再也不進行說明了，你們能夠搜索下相關的資料進行學習，上述的內容請務必熟練掌握、深入瞭解。更詳細的內容推薦你們學習 RFC 2616（http 協議 1.1 版本，有中文版本）

第四篇 JMeter 組件

4.1 前言

在 jmeter 中提供了一系列的不一樣的組件，每一種組件都提供了某類功能的實現，用於支持性能測試的實施。請看下圖，jmeter 的核心組件構成。

學習、研究 jmeter 以前，深刻了解 jmeter 的基本組件及其做用是必須的。接下來咱們開始討論基於 jmetere 進行性能測試必須掌握的組件，以便你們逐步掌握 jemter 的核心基本能力。

下面的幾個組件是入門 jmeter 必須掌握的：

 Thread Group

 Samplers

 Listeners

 Configuration

4.2 Thread Group( 線程組) )

線程組是一系列線程的集合，每個線程表明着一個正在使用應用程序的用戶。在 jmeter 中，每一個線程意味着模擬一個真實用戶向服務器發起請求。

在 jmeter 中，線程組組件運行用戶設置線程數量、初始化方式等等配置。

例如，若是你設置線程數爲 100，那麼 jmeter 將建立並模擬測試100 個用戶請求到服務器端。

以下圖所示：

4.3 Samplers(採樣)

咱們經常使用的 jmeter 測試有 HTTP、FTP、JDBC 協議，以及其餘各類支持的協議。（https協議網上有配置方法，本身找）

在上節咱們已經知道線程組件用於模擬用戶請求至服務器端。但還未講解如何在線程組件中實現某種請求類型（好比如何發起HTTP請求？）。

在本節中，咱們將演示如何利用 Samplers 組件的元素來實現各種請求類型。

咱們先看一下在 jmeter 中 Samplers 組件已經實現了哪些協議的支持。以下圖所示:

下面咱們就重要的 Samplers 組件元素進行一一講解，以便你們有個初步的瞭解。

 BeanShell Sampler

這個組件元素容許咱們在 jmeter 中寫 Bean Shell 腳本，寫這個腳本有什麼做用？意味着你能夠徹底的控制和實現本身的須要。靈活定製，天然也就有難度，你得有點腳本功底。

參見圖說明：

注：每個 Sampler 都有本身獨立的 beanshell 解析器，而且sampler 只能在本身的線程中調用（意味着不可跨線程使用）。

 FTP Request

FTP Request 元素提供了測試 ftp 服務器的能力，這個元素讓咱們

可以去測試 ftp 的上傳、下載功能。

下面咱們看一下 ftp 元素的基本配置說明：

注：咱們常常在 windows 和 linux 直接經過 ftp 進行文件傳輸，建議勾選 Use Binary Mode，避免編碼問題。

 HTTP Request

HTTP Request 提供了 HTTP/HTTPS 協議的測試支持能力。

下面咱們一塊兒看看 HTTP Request 元素的基本配置說明，瞭解下基

本的功能。

 Java Request

Java Request 提供了測試 java API 的支持，但要注意要測試的java API 須要有對應的測試類，該測試類必須繼承AbstractJavaSamplerClient。

示例以下：

待測類 class Sum; -> 生成 sum.jar繼承至 AbstractJavaSamplerClient 的測試類 ClassTestSum(AbstractJavaSamplerClient) -> 生成 testSum.jar

注：一個 java 測試應該要實現如下幾個方法，以便 jmeter javasampler 能夠正確調用：

更詳細的後續出專題講解，本篇不舉具體示例了。

注意 testSum.jar 要能調用 sum.jar。

將上述 sum.jar、testSum.jar 拷貝至 jmeter 安裝目錄的 lib/ext下。

下面咱們看看如何在 jmeter 配置 java 測試。

對於 JDBC Request、JMS Point-to-Point、JSR22三、SMTP、JUnit Request 等 Sampler 組件元素就不一一說明了在後續的分享中，主要基於 HTTP 和 java 請求來分享實戰。

4.4 Listeners( 監聽器) )

在 jmeter 中 Listeners 提供了執行結果生成和顯示能力的支持，提供了樹形結構、表、圖形和日誌方式。

下面咱們先看下幾種結果顯示示例圖。

圖形模式：

樹模式：

表模式：

日誌方式

4.5 Configuration Elements( 配置元件) )

配置元件包含了 Samplers 下各類 Sampler 的默認配置設置，若是有配置默認配置，在 Sampler 下對應的 sampler 就會使用該默認配置。

下面進行逐一的說明。

 CSV Data Set Config

CSV Data Set Config 主要用於讀取 csv 格式的文件中數據，實現參數化。

 HTTP Cookie Manager

該屬性管理器用於管理Test Plan運行時的全部Cookie。HTTP Cookie Manager能夠自動儲存服務器發送給客戶端的全部Cookie，並在發送請求時附加上合適的Cookie.

同時，用戶也能夠在HTTP Cookie Manager中手工添加一些Cookie，這些被手工添加的Cookie會在發送請求時被自動附加到請求。

 HTTP Request Defaults

HTTP Request Defaults 用於配置 HTTP request 的默認值，例如 IP、端口等等都設置好默認值後，在後續 HTTP request 元素裏就不須要重複設置，節省時間。

HTTP Authorization Manager

該屬性管理器用於設置自動對一些須要NTLM驗證的頁面進行認證和登陸。以下圖：監控tomcat

HTTP Cache Manager

該屬性管理器用於模擬瀏覽器的Cache行爲。爲Test Plan增長該屬性管理器後，Test Plan運行過程當中會使用Last-Modified、ETag和Expired等決定是否從Cache中獲取相應的元素。

 注意：若是Test Plan中的某個Sampler請求的元素是被Cache的元素，則Test Plan在運行過程當中會直接從Cache中讀取該元素，這樣Sampler獲得的返回值就會是空。在這種狀況下，若是爲該Sampler設置了Assertion檢查響應體中的制定內容是否存在，該Assertion就會失敗。

HTTP Header Manager

該屬性管理器用於定製Sampler發出的HTTP請求的請求頭的內容。不一樣的瀏覽器發出的HTTP請求具備不一樣的Agent，訪問某些有防盜鏈的頁面時須要正確的Refer...這些狀況下都須要經過HTTP Header Manager來保證發送的HTTP請求是正確的。以下圖：

4.6 總結

本次就 jmeter 經常使用的相關組件元素進行了大概的說明，以便你們有個基本的瞭解，爲後續深刻學習和實踐打下基礎。

第五篇 JMeter 接口性能測試基本過程及示例

5.1 前言

性能測試是咱們平常測試過程當中，必須掌握的技能。經過進行性能測試，咱們能分析服務端的總體性能、負載等，以便進一步評估咱們的業務系統是否能知足當前運營生產及將來業務增加狀況下如何進一步調整咱們的服務配置方案。

jmeter 爲性能測試提供了一下特點：

1  jmeter 能夠對測試靜態資源（例如 js、html 等）以及動態資源（例如 php、jsp、ajax 等等）進行性能測試

 2 jmeter 能夠挖掘出系統最大能處理的併發用戶數

 3 jmeter 提供了一系列各類形式的性能分析報告

使用 jmeter 通常用於如下兩種類型的性能測試

負載測試：經過測試系統在資源超負荷狀況下的表現，以發現設計上的錯誤或驗證系統的負載能力。

壓力測試：測試系統能承受的最大負載能力。目的在於發挖掘出目標服務系統能夠處理的最大負載。

5.2 基本過程

下面咱們看下使用 jmeter 進行性能測試的基本過程。

對上圖進行簡要的說明

 新增線程組

建立測試線程組，並設置線程數量及線程初始化啓動方式。

新增 JMeter 元組

建立各類默認元組及測試元組，填入目標測試靜態資源請求和動態資源請求參數及數據。

新增監聽器

建立各類形式的結果蒐集元組，以便在運行過程及運行結束後蒐集監控指標數據。

 運行&查看結果

調試運行，分析指標數據，挖掘性能瓶頸、評估系統性能狀態。

5.3 示例

下面咱們以打開百度演示上述過程。

 新增線程組

 在 jmeter 的 bin 目錄下雙擊 jmeter.bat 啓動 jmeter

 在左邊操做欄中選擇「測試計劃」，右擊新增一個線程組，如圖所示：

 初始化線程組相關信息，如圖：

 新增 JMeter 元組

 添加默認配置元素，添加以下默認配置，如圖

各默認組件配置如圖所示。

HTTP Cache Manager

HTTP Cookie 管理器

HTTP 請求默認值

添加 HTTP Request 元組

在線程組上右擊新增 HTTP 請求，如圖：

HTTP 請求設置如圖：

 新增監聽器

在這裏咱們添加以下監聽器，如圖所示

 

 運行&查看結果

若是啓動運行 jmeter，能夠單擊添加的監聽器查看運行過程當中的監

控指標數據，也能夠等運行結束後，再查看。

5.4 結果說明

下面咱們就監聽器所採集的結果圖進行簡要的說明：

圖形結果

察看結果樹

用表格查看結果

聚合報告

5.5 總結

本次就 jmeter 使用的基本過程如何使用進行了分享，並就訪問百度首頁進行了實際測試演示。在最後就經常使用的幾個監聽器中字段含義進行了說明。

第六篇 JMeter 定時器

6.1 前言

在默認狀況下，jmeter 發送每一個請求之間是沒有延時的，若是採用默認方式，若是線程數足夠大，瞬間就會將服務器壓死。再者在實際的業務過程當中，請求之間是有必定時間的停頓的因此在請求之間設置合理的延時是必須的，也是更接近用戶真實業務狀況。

在 jmeter 中，定時器組件提供了系列不一樣類型的延時控制。合理使用定時器組件，能讓你的性能測試更接近真實，更能挖掘出系統的瓶頸和評估系統的性能指標。

6.2 定時器類型

下面咱們看下 jmeter 提供了哪些定時器組件：

 固定定時器

 高斯隨機定時器

 Uniform Random Timer

 Synchronizing Timer

 Poisson Random Timer

 JSR223 Timer

 Constant Throughput Timer

 BeanShell Timer

6.3 固定定時器

這是最簡單的一種定時器，也是新手最經常使用的一種方式。下面咱們看下其具體設置：

因其是固定值，在實際模擬用戶請求的過程當中，會失去靈活性，不推薦大量使用該定時器。

6.4 高斯隨機定時器

高斯隨機定時器，又能夠稱做正態分佈隨機定時器，該定時器能夠設置在兩個請求間隨機延時時長。且總的延時是高斯分佈(正態分佈)的總和（均值：0.0、標準差 1.0）。在使用時須指定誤差延時值和偏移值。

下面咱們看下其具體設置：

例如在訪問百度首頁，而後輸入關鍵詞進行搜索，受網絡、人等各類因素影響，有的人打開首頁後 3s 後則進行了搜索，有時則是 10s或更多時間，在正常狀況下，打開百度而後進行搜索，假設用戶間隔在 3s-10s 之間，從統計學來看，這個間隔時間多是一個正態分佈或接近正態分佈。而不是一個固定的常量。從筆者在平常實踐中，也更推薦使用該定時器。能更接近模擬用戶實際狀況。

6.5 Synchronizing Timer

這個定時器應該是你們很指望的，它有在 LoadRunner 中有一個你們熟悉的名稱：集合點。是的，它實現了某種意義上的併發。

請注意 Timeout in milliseconds 儘可能填寫一個合理的值。

6.6 Uniform Random Timer

該定時器能夠在請求之間設置一個隨機延時，每一個隨機延時有相同的發生機率。總的延時等於隨機延時 + 偏移延時值。

該定時器也是經常使用之一。

6.7 Poisson Random Timer

相似高斯隨機定時器，只是其隨機延時值發生在一個特定的值。總的延時值呈現泊松分佈。

6.8 Constant Throughput Timer

經過控制每分鐘請求數（即控制吞吐的方式）來控制是否進行延時暫停。

例如，當咱們須要使服務端長期處於必定的壓力下時，能夠經過該定時器來控制吞吐。

注意：吞吐值能夠是常量，也可使用函數來動態生成，已達成更靈活的使用，知足不一樣的壓力場景。

 

6.9 JSr R223 Timer 和 和 BeanShell Timer

這兩種定時器就不細說了，簡單的說就是提供了腳本方式來進行控制，是更爲靈活的方式。通常狀況下，你們是不會用的。固然有興趣的，能夠去研究下，加強理解。

6.10 總結

本文就各類定時器進行了介紹，並大體介紹了其可能的應用場景。無論是哪一種定時器，都須要深刻理解業務的狀況下，統籌規劃使用。以更深刻的發揮其做用，模擬好真實應用場景，更好的挖掘性能瓶頸和評估目標服務的性能狀況。

第七篇 JMeter 斷言

7.1 前言

在 jmeter 中斷言用於驗證服務器返回的數據是否知足咱們的要求。

jmeter 提供瞭如下斷言類型：

下面咱們主要對響應斷言、XPath Assertion、jp@gc – JSON Path Assertion 進行分享，這幾個斷言類型也是平常壓測過程當中最經常使用的，對於其餘的斷言類型，請你們去看官方文檔。

jmeter 提供了多大十幾種斷言方式，但合理利用好經常使用的幾種斷言就足以在馳騁於實際的項目應用了。

7.2 響應斷言

響應斷言容許用戶經過添加模式字符串來比較驗證服務器返回的響應。

例如對響應返回的狀態碼進行驗證，或是對響應返回的本文內容驗證等等。

下面咱們對響應斷言進行詳細的說明：

 1）名稱、註釋

這裏根據你實際的須要填寫便可。

 2）Apply to

通常選擇 Main sample only 便可。若是一次發送多個請求，則須要根據實際斷言須要選擇其餘選項了。（例如一個 ajax請求，會發送多個 GET 或 POST 時。）

 3）要測試的響應字段

響應文本：

服務器響應文本，通常狀況下，咱們都是勾選改選項，用於驗證服務器返回值。

 Document（text）：

經過 Apache Tika 從各類的文檔中提取的文本進行驗證，包括響應文本，pdf、word 等等各類格式。jmeter 會用Apache Tika 去解析服務器響應內容，耗內存、也耗時間，解析易失敗，儘可能少用或不用。多用響應文本方式來進行斷言驗證。

 URL 樣本：

對請求的 url 進行斷言，若是請求沒有重定向(302)，那麼該url 即爲請求的 url；若是有重定向（切跟隨重定向），那麼url 則包含了請求 url 和重定向 url。

 響應代碼：

即 http 響應代碼，例如 200，404 等等，須要注意：因爲 jmeter 默認狀況下認爲 4xx，5xx 時該請求失敗，因此在斷言這類響應代碼時，須要同時勾選 Ingore Status，才能正常去作斷言。

 響應信息：

即響應代碼對應的信息，例如 OK， Not Found 等等這類的。

以下常見相似是響應信息:

HTTP/1.1 200 Ok

HTTP/1.1 302 Found

Response Header : 響應頭信息，例如

Server: Tengine

Date: Thu, 12 Mar 2015 09:43:52 GMT

Content-Type: text/html

Content-Length: 260

Connection: close

Location: http://www.baidu.com/404.html

 Response Headers：

即 http 響應頭信息，主要用於斷言當響應頭帶有惟一或特定意義時。

 Ingore Status：

請參見 4 響應代碼的使用說明。

4）模式匹配規則

包括： 指返回結果包含要測試的模式中指定的內容，支持正

則表達式

匹配：（1）至關於 equals。返回值是固定的，能夠以返回值作斷言，效果同 equals；（2)正則表達式匹配。用正則表達式來匹配返回結果，但必須所有匹配。即正則表達式必須能匹配整個返回值，而不是返回部分值，注意與包括模式的區別（包括是支持模糊匹配的）。

Equals：指返回結果與指定的測試模式徹底一致。

Substring：與「包括」模式差很少，都是指返回結果包括指定的內容，但 Substring 不支持正則表達式。

否：至關於取反。即若是上述斷言結果爲 true，勾選「否」選項後，則最終斷言結果爲 false。

注：在使用該斷言時，熟練掌握正則表達式是必備的能力。

7.3 XPath Assertion

若是服務器響應返回的是 xml 格式的內容，這時最佳的斷言驗證類型就是使用 XPath Assertion。

 1）Apply to

通常選擇 Main sample only 便可。若是一次發送多個請求，則須要根據實際斷言須要選擇其餘選項了。（例如一個 ajax請求，會發送多個 GET 或 POST 時。）

 2）XML Parsing Options

Use Tidy(tolerant parser):使用 Tidy（容錯解析器），默認選擇 quiet

Quiet：不顯示

Report errors：錯誤報告

Show warnings:顯示錯誤

Use Namespaces:使用名稱空間

Validate XML:驗證 XML（文件包/數據）

Ignore Whitespace:忽略空格（容許你指定語法分析器能夠忽略哪一個空格，而哪一個空格是重要的）

Fetch external DTDs:獲取外部 DTDs（一些 XML 元素具備屬性，屬性包含應用程序使用的信息，屬性僅在程序對元素進行讀、寫操做時，提供元素的額外信息，這時候須要在 DTDs中聲明）

 3）Path Assertion

輸入框中寫入 xpath 斷言，點擊 Validate 驗證其正確性

 4）True if nothing matches

確認都不匹配

7.4 jp@gc - - JSON Path Assertion

若是服務器響應返回的是 json 格式的內容，這時最佳的斷言驗證類型就是使用 jp@gc – JSON Path Assertion。

注： 默認下載的 jmeter 是不支持該方式的，須要安裝 json plugins，在選項-Plugins Manager-Available Plugins 找到 JSON Plugins 安裝好便可。

下面對 json path assertion 進行說明

 1）JSON Path

json 提取表達式，用於提取目標 json 串節點值。

 2）Validate against expected value

勾選該選項，則驗證目標指望結果

 3）Match as regular expression

勾選該選項，則指望值項，支持正則表達式

 4）Expected Value

自定義指望值

 5）Expect null

指望值爲 null，勾選該選項，則會斷言結果爲 null 的狀況

 6）Invert assertion(will fail if above condition met)

取反，若是上述兩種指望值斷言爲 true，勾選該選項，則斷言結果爲 fail；若是上述指望值斷言爲 fail，勾選該選項，則斷言結果爲 true。

7.5 總結

本次分享主要就響應斷言、XPath 斷言、JSON 斷言三種經常使用的斷言類型進行了說明，對於具體的示例，後續在實踐篇章會結合其餘基礎功能一一進行分享，這三種斷言應該說知足平常壓測過程斷言的大部分場景，你們須要深刻理解其各個選項的含義。

第八篇 JMeter 邏輯控制器

8.1 前言

在 jmeter 中邏輯控制器主要分類兩類：

 控制 jmeter 測試計劃中節點的邏輯執行順序等等

 對 jmeter 的節點進行分組，方便結果統計等等

進一步簡化下，筆者把邏輯控制器分爲

 邏輯控制類

 分組控制類

8.2 邏輯控制類

邏輯控制類控制器定義了在執行線程中請求的執行順序。

下面咱們就經常使用的邏輯控制器進行說明

8.2.1 若是(if) 控制器

控制其下面的子節點知足條件才執行，例如，咱們控制只有執行線程大於 10 個時，才執行其子節點。

這裏只是簡單舉例，你們能夠根據實際應用場景進行設計。

8.2.2 循環控制器

控制其下面的子節點運行次數。例如咱們設置其子節點執行 10次。

若是勾選永遠選項，則會一直執行下去。

8.2.3 僅一次控制器

控制其子節點在整個測試計劃執行期間的無論開多少個線程，整個計劃任務只執行一次，例

如咱們能夠用於等登陸動做。

8.2.4 隨機控制器

每次執行時，從其子節點中，隨機選擇一個進行執行，例如咱們百度首頁隨機請求不一樣的類型的資訊信息。

其餘的邏輯控制器就不一一進行說明了，你們能夠自行學習、實踐，去挖掘其實用場景。

8.3 分組控制類

分組控制類主要用於統計和控制其餘非邏輯執行。典型的應用場景，例如咱們常須要去統計一個業務流的執行時間，或是控制吞吐量等等。

下面咱們一塊兒看幾個典型的分組控制類的組件。

8.3.1 事務控制器

會產生一個額外的 sampler，用於統計該控制器下子節點的全部時間。該統計數據能夠在聚合報告中看到。

Generate parent sample：控制結果的顯示結構。若勾選，總時長和子節點時長按層級顯示，未勾選，平行顯示。

Include duration of timer and pre-post processors in generated sampler：勾選時，會統計定時器時間（默認僅統計採樣器時間）。

如上圖：經過事務控制器，咱們能夠統計出請求百度首頁、搜索開源優測、搜索 python、搜索 selenium4 個請求的時間總和，注意這裏統一出來的時間會略大於這 4 個請求的和。

8.3.2 吞吐控制器

容許用戶經過如下兩種方法控制執行頻率。

 1）Percent executions

這個控制器的命名不夠準確，由於它不是用來控制吞吐量的。

吞吐量控制器容許用戶控制執行頻率，jmeter 提供了兩種模式：執行百分比和執行總次數。

設置運行比例(1~100 之間)。

如線程循環次數設置爲 5，添加 Percent executions 爲 40%的吞吐量控制器，其下子節點則循環 2 次。

2） Total executions

設置運行次數

per user：此項被勾選後，在每一個線程的基礎上，每一個用戶都將根據控制器設置計算。未被勾選時，計算針對於全部用戶。

如：使用 total execution 模式，不勾選 per user 選項，執行次數=吞吐量值；勾選了 per user，執行次數=user數量（對應線程數） * 吞吐量值

8.4 總結

本次就經常使用的邏輯控制器：若是(if)控制器、循環控制器、僅一次控制器、隨機控制器、事務控制器、吞吐控制器進行了分享。對於這些控制器的應用場景，須要深入理解業務後再設計場景，切不可爲了用而用。

第九篇 JMeter 處理器

9.1 前言

在 jmeter 中提供了兩種處理器，用於修改請求數據或處理響應數據。

 

前置處理器

 後置處理器

9.2 前置處理器

前置處理器是在請求發送前作相關處理。能夠用於在請求發送前修改 HTTP 協議頭、數據部分等等各類須要修改或設置的數據。

其做用範圍內的每個 sampler 元件以前執行。

 Bean Shell PreProcessor

 HTML 連接解析器

 HTTP URL 重寫修飾符

 JDBC PreProcessor

 jp@gc - Raw Data Source PreProcessor

 JSR223 PreProcessor

 RegEx User Parameters

 Sample Timeout

 用戶參數

注： 通常狀況下，你們在實踐過程當中，用到前置處理器的機會比較少，這裏就不一一說明了，重點放在後置處理器的講解上。

9.3 後置處理器

後置處理器是取樣器被執行後被觸發執行的元素。可用於解析響應

數據，提取變量，以便後續使用。

==注： json 格式的支持須要安裝 json plugins 建立（4.0版本不須要安裝，已有這個插件）==

下面咱們對經常使用的後置處理器進行說明：

 1）JSON Extractor

用於處理響應結果爲 json 格式的內容。

Variable names : 變量名稱，提取到的值將存放在該變量裏，後續經過該變量便可引用提取到的數據

JSONPath Expression：JSON 表達式

Match Numbers：匹配哪一個，可爲空即默認第一個

Default Value：未取到值的時候默認值

示例

例如返回的 json 串爲，咱們提取 token：

{

"statusCode":200,

"data":{

"userId":"admin",

"token":"12312312312338a5bd20bd"

}

}

在 JSONPath Expression 填入：

$.data.token

來獲取 token 的值

例如返回的 json 串有數組，咱們提取第二個 token：

{

"statusCode":200,

"data":[{

"userId":"admin",

"token":"rwerwerwr0e6138a5bd20bd"

},{

"userId":"user",

"token":"123123123123123a5bd20bd"

}]

}

在 JSONPath Expression 填入：

$.data[1].token

來獲取第二個 token 的值（注：數組的索引從 0 開始表示第一個）

2） jp@gc - JSON Path Extractor

用於處理響應結果爲 json 格式的內容。

Destination Variable Name： 變量名稱，提取到的值將存放在該

變量裏，後續經過該變量便可引用提取到的數據

JSONPath Expression：JSON 表達式

Default Value：未取到值的時候默認值

具體示例請參見 JSON Extractor 的示例。這裏不作詳細示例了。

 3）XPath Extractor

用於處理響應結果爲 xml 格式的內容。

這裏對關鍵參數進行說明：

引用名稱：變量名稱，提取到的值將存放在該變量裏，後續經過該變量便可引用提取到的數據

XPath query：xpath 表達式

缺省值：未取到值的時候默認值

示例

假如服務端返回以下格式的內容

<title>Apache JMeter</title>

那麼咱們能夠經過，如下 xpath 表達式獲取到 Apache JMeter 字符串

//title/text()

將該 xpath 表達式填入在 XPath query 對應輸入框中。

 4）正則表達式提取器

這是萬能的提取模式了，支持使用正則表達式來提取知足要求的數據。固然你得熟練掌握正則表達式相關知識，才能遊刃有餘的應用。

引用名稱：變量名稱，提取到的值將存放在該變量裏，後續經過該變量便可引用提取到的數據

正則表達式：用於匹配目標數據的正則表達式

模板：表示使用提取到的第幾個值

$-1$:表示取全部值

$0$:表示隨機取值

$1$:表示取第 1 個

$2$:表示取第二個

以此類推:$n$:表示取第 n 個

匹配數字（0 表明隨機）： 0 表明隨機取值，1 表明所有取值

缺省值： 若是正則表達式沒有搜找到值，則使用此缺省值

具體的示例這裏就不列舉了，你們本身去嘗試。

9.4 總結

本次主要就後置處理器中經常使用的 json、xml 及正則表達式處理器進行了分享。在平常測試過程當中，這三種後置處理器是必須掌握的，須要深刻掌握理解，同時須要對 json、xpath、和正則表達式相關知識有所掌握才行。

第十篇 JMeter 監聽器

10 .1 前言

在 jmeter 中，經過監聽器組件來提供查看、保存、和讀取已保存的測試結果功能。

默認狀況下，測試結果將被存儲爲 xml 格式的文件，文件的後綴:".jtl"。另一種存儲格式爲 CSV 文件，該格式的好處就是效率更高，但存儲的信息不如 xml 格式詳細。

一般狀況下，監聽器有如下四種類型：

 樹（tree）

 表（table）

 圖形

 日誌文件

下面咱們選取集中經常使用的監聽器進行說明。

10.2 Summary Report

概要報告，提供了最簡要的測試結果信息，同時能夠配置將相應的信息保存至指定的文件中（支持 xml、csv 格式的文件）。

下面咱們就每一個標籤含義進行簡單的說明

Label： 請求名稱

#Smaples： 請求計數

Average: 請求響應平均耗時

Min： 請求響應最小耗時

Max： 請求響應最大耗時

Std. Dev: 請求響應時間的標準差

Error %： 請求錯誤率

Throughput： 吞吐量

Received KB/sec: 每秒接收（即響應）的數據量 KB

Sent KB/sec: 每秒發送的數據量 KB

Avg. Bytes: 服務端響應的數據的平均值

單擊 Configure 按鈕，能夠配置結果保存各類選項，具體這裏不作說明了。

該監聽器是筆者在調試 jmeter 項目時經常使用的監聽器之一。

10.3 察看結果樹

該監聽器有兩個做用

 查看請求結果，經過的測試一般爲綠色。紅色則表明失敗。

 查看對應 Sampler 的測試結果的請求、響應數據。

這是調試 jmeter 測試的的利器，必須掌握，也是經常使用的監聽器。

不過要注意的是，該監聽器推薦作調試用，在實際運行壓測時，應該禁用，由於大量請求時，該監聽器會形成大 IO 消耗，影響壓力機性能。不作壓測隨便用。

10.4 聚合報告

聚合報告應該是最詳細的報告了，也是最爲經常使用的報告。是你們在壓測過程當中最經常使用的監聽器。該監聽器對於每一個請求，它統計響應信息並提供請求數，平均值，最大，最小值，中位數、90%、95%、錯誤率，吞吐量(以請求數/秒爲單位)和以 kb/秒爲單位的吞吐量。

Label：請求名

#Samples： 請求計數

Average： 請求響應平均耗時

Meian： 中位數，表示 50%的請求在該耗時內完成

90% Line： 表示 90%的請求在該耗時內完成

95% Line： 表示 95%的請求在該耗時內完成

99% Line： 表示 99%的請求在該耗時內完成

Min： 請求響應最小耗時

Max： 請求響應最大耗時

Error %： 請求錯誤率

Throughput: 吞吐，每秒處理請求數

Received KB/sec: 每秒接收多少 KB 數據

Sent KB/sec: 每秒發送多少 KB 數據

單擊 Configure 按鈕，能夠配置結果保存各類選項，具體這裏不作說明了。

10.5 總結

上述三種監聽器是平常工做中經常使用的監聽器，對於其餘監聽器你們能夠自行研究。在實際的性能測試過程當中，通常使用第三方監控工具或系統。這裏就經常使用的三種進行說明。

第十一篇 JMeter 函數和變量

11.1 前言

在 jmeter 中提供了功能強大的內置函數來幫助咱們處理字符串、文件讀寫、計算、運行外部腳本等等能力。

要想在項目中切實運用來 jmeter 完成複雜的壓測場景，函數和變量是必須掌握的高階能力。

下面咱們就函數和變量進行一一講解。

11.2 函數

咱們在哪能夠知道 jmeter 支持哪些函數呢？經過在菜單 「選項」-> "函數助手對話框" 便可打開函數助手。

經過函數助手，咱們能夠快速的填充對應的參數來生成咱們所須要的函數。

下面咱們看一下函數調用示例說明:

${__functionName(param1, param2, param3)}

說明：

functionName： 指 jmeter 內置函數名稱

param1, param2, param3: 指該函數調用時須要傳入的參數

11.3 變量

在使用變量前，必須先定義變量，而定義變量有兩個地方。

方式1、是在測試計劃的用戶定義的變量處進行定義，以下圖

方式2、是「配置元件」中的「用戶定義的變量」來進行定義，以下圖

定義了變量，怎麼引用呢？ 下面咱們展現下引用格式：

${VARIABLE}

VARIABLE: 定義的變量名稱

引用前面定義的 username、password 則是

${username}

${password}

一樣的道理，引用用戶定義的變量組件中定義的 host、port、count 則是

${host}

${port}

${count}

 

下面咱們看下如何把函數和變量結合一塊兒應用的簡單示例，以下圖所示，先定義變量：

使用前面定義的變量，來參數化，HTTP 請求相關參數：

 

看下請求結果：

11.4 函數列表

下面咱們看下 jmeter 提供的全部內置函數的功能說明及使用示例。

總計七大類型。類型以下：

 信息類： 用於讀取線程、請求名等

 輸入類： 用於讀取文件等

 計算類： 用於計數、求和等

 腳本類： 用於運行各種腳本，例如 groovy、beanshell 等等

 屬性類： 讀取或設置 jmeter 配置

 變量類： 用於對變量進行操做

 字符串類： 用於字符串處理

11.4.1 信息類

主要用於獲取一些經常使用的基本信息或是日誌輸出控制。

11.4.2 輸入類

主要用於從外部文件讀取數據，進行參數化或是說關聯

11.4.3 計算類

主要用於計算或是隨機生成數據

11.4.4 腳本類

主要用於調用外部腳本或是解析執行腳本

11.4.5 屬性類

用於讀取和設置 jmeter 配置

11.4.6 變量類

主要用於驗證變量表達式引用是否正確

11.6.7 字符串類

用於字符串操做

11.5 必須掌握的函數

在上述內容中，並無把全部的函數都一一列出來，但基本把個大類中主要的函數都已列出，須要你們對其有個基本印象，知道有哪些內置函數，這些函數能解決什麼問題，以便在實際項目中走太多彎路。

下面把在實際項目中經常使用的函數重點列出來。我想這也是你們在項目中經常使用的，也是重點掌握的，必須熟練能熟練的應用。

從文件讀取數據，進行參數化

 StringFromFile

 CSVRead

 XPath

腳本支持

 BeanShell（推薦這個）

 groovy

隨機數據生成

 RandomString

 UUID

字符串處理

 urldecode

 urlencode

 char

注：並非其餘函數不重要，而是上述函數是平常項目實踐中用得最爲頻繁，建議必須掌握的。

11.6 變量的參數化

參數化是自動化測試腳本的一種經常使用技巧。簡單來講，參數化的通常用法就是將腳本中的某些輸入使用參數來代替，在腳本運行時指定參數的取值範圍和規則；

這樣，腳本在運行時就能夠根據須要選取不一樣的參數值做爲輸入。這種方式一般被稱爲數據驅動測試（Data Driven Test），參數的取值範圍被稱爲數據池（Data Pool）。

 

jmeter的test plan中，支持以下4種參數化方式：

函數助手：_CSVRead

CSV Data Set Config：CSV數據控件

User Defined Variables：用戶定義的變量

User Variables：用戶參數

 

首先新建一個測試腳本，能夠經過工具（badboy）錄製或者本身手動編寫

登陸請求的界面以下：

這裏咱們對登陸的用戶名密碼進行參數化，將用戶名密碼寫入txt文檔，保存爲.dat格式，編碼類型選擇UTF-8；

由於配置元件——CSV Data Set Config對參數化的格式要求比較嚴格，用戶名密碼一一對應，之間用半角英文逗號隔開

而後將保存的.dat文件放入計算機的某個盤裏，這裏我放入路徑爲：F:\jmeter\csvtest.dat

下面具體介紹參數化經常使用的的兩種方法：

 

11.6.1函數助手：_CSVRead

點擊jmeter的界面，功能欄選項→ 函數助手對話框→ _CSVRead

CSV file to get values from | *alias：CSV文件取值路徑，即這裏須要寫入以前的須要參數化的參數的文件路徑

CSV文件列號| next|*alias：文件起始列號：CSV文件列號是從0開始的，第一列爲0，第二列爲1，以此類推。。。

函數字符串：即生成的參數化後的參數，能夠直接在登錄請求中的參數中引用，第一列爲用戶名，函數字段號爲0，第二列爲密碼，函數字段號爲1，以此類推動行修改使用便可

替換參數化後的參數，而後修改線程數，執行腳本，經過監聽器裏結果樹的請求內容，能夠看到請求的參數都是參數化後的數據

 

11.6.2配置元件——CSV Data Set Config

點擊線程組添加配置元件→ CSV Data Set Config：

說明：

Filename：F:\jmeter\csvtest.dat文件名，保存參數化數據的文件目錄，可選擇相對或者絕對路徑（建議填寫相對路徑，避免腳本遷移時須要修改路徑）;

File encoding:UTF-8，F:\jmeter\csvtest.dat文件的編碼格式，在保存時保存編碼格式爲UTF-8便可;

Variable Names(comma-delimited)：對對應參數文件每列的變量名，相似excel文件的文件頭，起到標示做用，同時也是後續引用的標識符，建議採用有意義的英文標示;

 (如：有幾列參數，在這裏面就寫幾個參數名稱，每一個名稱中間用分隔符分割，這裏的 user,pwd，能夠被利用變量名來引用：user,user,{pwd};

Delimitet：參數文件分隔符，用來在「Variable Names」中分隔參數，與參數文件中的分隔符保持一致便可;

Allow quote data：是否容許引用數據，默認false，選項選爲「true」的時候對全角字符的處理出現亂碼 ;

Recycle on EOF？：是否循環讀取參數文件內容；由於CSV Data Set Config一次讀入一行，分割後存入若干變量中交給一個線程，若是線程數超過文本的記錄行數，那麼能夠選擇從頭再次讀入;

△ Ture：爲true時，當已讀取完參數文件內的測試用例數據，還需繼續獲取用例數據時，此時會循環讀取參數文件數據（即：讀取文件到結尾時，再重頭讀取文件）;

△False：爲false時，若已至文件末尾，則再也不繼續讀取測試數據；一般在「線程組線程數* 線程組循環次數＞參數文件行數」時，選用false（即：讀取文件到結尾時，中止讀取文件）;

Stop thread on EOF?：當Recycle on EOF爲False時（讀取文件到結尾），中止進程，當Recycle on EOF爲True時，此項無心義;

△若爲ture，則在讀取到參數文件行末尾時，終止參數文件讀取線程；

△若爲false，此時線程繼續讀取，但會請求錯誤，所以時讀取的數據爲EOF;

Sharing mode:共享模式，即參數文件的做用域，有如下幾種方式：

△All threads:當前測試計劃中的全部線程中的全部的線程都有效，默認;

△Current thread group:當前線程組中的線程有效;

△Current thread:當前線程有效;

 

完成以後，將剛纔生成的參數寫入參數對應的值裏面：

以上兩種常見的參數化的方法，推薦使用CSV控件方法（由於函數助手參數化功能相比其較弱）

11.6.3配置元件——User Defined Variables

點擊線程組添加配置元件→ User Defined Variables（用戶定義的變量）：

如上圖所示，在該參數組中已經定義了兩個參數，經過界面下方的添加、刪除按鈕能夠向參數列表增長和刪除參數，Up和Down能夠上下移動參數的位置；

PS：User Defined Variables中定義的參數值在test plan執行過程當中不能發生取值的改變，所以通常僅將test plan中不須要隨迭代發生改變的參數（只取一次的參數）

    設置在此處；例如：被測應用的host和port值。

 

11.6.4前置處理器——User Variables

點擊線程組添加前置處理器——User Variables（用戶參數）：

如上圖所示，在該參數組中已經設置了兩個參數，username和password分別有2組不一樣的取值，經過頁面下方的四個按鈕，能夠增長刪除參數的可能取值。

PS：User Variables中設置的參數能夠在test plan執行過程當中發生變化。

 

以上就是jmeter參數化的四種方式，其中：

一、函數助手_CSVRead的參數化功能相比CSV Data Set Config較弱；

二、CSV Data Set Config適用於參數取值範圍較大的時候使用，該方法具備更大的靈活性；

三、User Defined Variables通常用於test plan中不須要隨請求迭代的參數設置；

四、User Variables適用於參數取值範圍很小的時候使用；

 

PS：相比於loadrunner來講，jmeter參數化有如下不一樣：

1.jmeter參數文件第一行沒有列名稱

2.參數文件的編碼，儘可能保存爲UTF-8（編碼問題在使用CSV Data Set Config參數化時要求的比較嚴格）

3.Jmeter的參數化沒有LoadRunner作的出色，它是依賴於線程設置的（只有CSV Data Set Config參數化方法纔有）

 

11.7 總結

本文就 jmeter 函數和變量進行了分享，這是進一步掌握 jmeter 必備的技能。也是在項目實踐中進行參數化、關聯必備的技能。對於全部函數要作到心中有數，對於關鍵重點的函數要作到隨時會用，靈活應用。

第十二章 調試工具

12.1 Debug Sampler介紹：

　　使用Jmeter開發腳本時，不免須要調試，這時可使用Jmeter的Debug Sampler，它有三個選項：JMeter properties，JMeter variables，System properties:

一、JMeter properties和System properties：一般都選false，這兩個就是JMeter和系統的屬性，在Jmeter的bin的jmeter.properties中定義，通常都不會變。

二、JMeter variables：這個是咱們自已定義的變量，定義的方式有以下這些：

　　a) 選中測試計劃(Test plan)，在右邊的面板上添加User Defined Variables

　　b) 選中線程組，右鍵選擇 配置元件( config element)-->User Defined Variables

　　c) 經過後置處理器生成的變量：Jmeter關聯

　　d)使用csv參數化的變量：Jmeter參數化

12.2 綜合示例

爲了涵蓋上面的四種狀況，特地編寫以下腳本：

一、在Test plan右側面板添加變量：name=test，value=111

二、在sampler one(訪問百度首頁)下添加一個用戶變量：name=hello，value=222

三、在sampler one 下使用後置處理器（正則表達式處理器），獲取百度首頁title的信息

四、參數化，變量名爲username，值爲：tom

五、運行結果：

12.3 總結

一、Debug Sampler會把咱們自定義的變量輸出在response data中，方便咱們調試的時候使用

二、在正式執行腳本時須要刪除Debug Sample

我的總結注意的地方

一、「用戶自定義變量」的變量值不能引用其餘變量（在它更早以前的用戶自定義變量和測試計劃中的用戶自定義變量則能夠引用），一個變量一個值，當須要循環取不一樣變量時，可配合forEach控制器迭代變量。

二、「用戶參數」的變量值能引用其餘變量（注意引用變量對邏輯控制器的做用域，如用戶參數嵌套在邏輯控制器裏才能引用到該邏輯控制器的前一個http請求的json extractor提取值），且一個變量能有多個值迭代功能，當須要循環取同一個變量不一樣值時，可配合多線程迭代變量不一樣值和forEach控制器迭代多個變量使用（注意若用循環控制器搭配無心義，則不會循環同一變量不一樣值，也不會迭代多個變量，只會每次循環都一次性取全部變量的第一個值去循環）。

三、「csv數據文件配置」的變量值不能引用其餘變量，但一個變量能有多個值迭代功能，當須要循環取同一個變量不一樣值時，可配合多線程使用（未肯定循環控制器是否無效）。

四、「forEach控制器」的star index 0 表明第一個，end index 後綴number值+1 表明最後一個，舉例：索引start index:0 ,end index：3  --》對應獲得後綴number是0、一、2。

start索引值=後綴number值-1

end索引值=後綴number值+1

後綴number>=0

五、多個入參能夠嵌套「forEach控制器」處理。

六、「事務控制器」的generate parent sample勾選後，在察看結果樹中可按事務層級結構顯示，不然事務會在同一層級顯示看不出事務層級關係。

七、「csv數據文件配置」的是否容許帶引號勾選後則參數值能夠容許有引號等特殊字符。

八、通常函數的參數都不能引用別的變量，可是${__javaScript(,)}函數能夠引用變量，如引用變量作加法：${__javaScript(${userPhone}+1,resl)}。另外函數不能引用函數。

九、「json extractor」提取多個參數時，variables間加分號「;」，json path expressions間也是加分號「;」，而且default values必須填默認值，多參數默認值間也是加分號「;」。

十、複雜的數據處理能夠用javaScript和beanshell函數，js函數顯示的數字位數過大的時候須要作字符型轉化顯示纔好${__javaScript(String(13760000000+1),)}，難度較高，須要學習javaScript，beanshell須要學習java。

十一、有個坑就是引用提取變量的時候，會從新模擬執行一次屬於該提取變量的那個請求，但又不會真正的執行這個請求，致使引用的變量值就有可能在其餘請求過程當中變了，換句話說，引用的提取變量是實時獲取值的，不是在我第一次請求後置處理提取後把變量值固定下來。例如，「查詢用戶」（條件參數含有手機號）請求時有提取變量用於「刪除用戶」（條件參數也含有手機號）請求時引用，可是下一步「修改用戶」請求時修改了用戶手機號，致使最後一步「刪除用戶」請求時引用查詢用戶提取的變量爲空（json extractor提取空時取default values），由於查詢用戶請求條件手機號已變化，致使查詢用戶結果爲空，使得提取的變量也爲空，但又不會真正執行一次「查詢用戶」請求，只是jmeter內部模擬執行了一次。

十二、quearySring參數和body參數都要做爲請求的參數填寫。

1三、Jmeter接口參數Bodydata與Parameters的選取：A)若是是普通的post請求和上傳接口，選擇Parameters，B)若是是json和xml請求接口，選擇Bodydata。

1四、在作接口測試時注意下請求頭(Content-Type)：A)對於普通文本（Content-Type="text/plain"）、HTML（Content-Type="text/html"）類型的Content-Type可不寫。B)XML（Content-Type="text/xml"）、javascript（Content-Type="text/javascript"）、json（Content-Type="application/json"）類型時，Content-Type不可缺乏，否則服務器端會報錯。

1五、正則表達式提取器，填寫正則要匹配的部分寫上小括號，如"userId":(.*) 。

1六、正則表達式提取器，模板表示使用提取到的是正則表達式中第幾列的值：

$-1$:表示取全部值

$0$:表示隨機取值

$1$:表示取第1個

$2$:表示取第二個

以此類推:$n$:表示取第n個

如"userId":(.*？),"userName":(.*？)

上面$1$表示的是userid，$2$表示的是username，另外表達式最後加問號?是非貪婪模式，即精確匹配到這個位置不往右取。

1七、正則表達式提取器，匹配數字（0表明隨機），0 表明隨機取值，1 表明所有取值。

1八、正則表達式提取器，當匹配的值有多行結果時，若要指定某一行的值傳給變量，則在http請求參數中填寫${正則引用變量名_g數字}，如${extract_userId_g1}。