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

https://www.cnblogs.com/alisapan/p/6169011.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、JSR223、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 變量

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

方式一、是在測試計划的用戶定義的變量處進行定義，如下圖

方式二、是“配置元件”中的“用戶定義的變量”來進行定義，如下圖

定義了變量，怎么引用呢？ 下面我們展示下引用格式：

${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參數化的四種方式，其中：

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

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

3、User Defined Variables一般用於test plan中不需要隨請求迭代的參數設置；

4、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:

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

2、JMeter variables：這個是我們自已定義的變量，定義的方式有如下這些：

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

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

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

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

12.2 綜合示例

為了涵蓋上面的四種情況，特意編寫如下腳本：

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

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

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

4、參數化，變量名為username，值為：tom

5、運行結果：

12.3 總結

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

2、在正式執行腳本時需要刪除Debug Sample

個人總結注意的地方

1、“用戶自定義變量”的變量值不能引用其他變量（在它更早之前的用戶自定義變量和測試計划中的用戶自定義變量則可以引用），一個變量一個值，當需要循環取不同變量時，可配合forEach控制器迭代變量。

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

3、“csv數據文件配置”的變量值不能引用其他變量，但一個變量能有多個值迭代功能，當需要循環取同一個變量不同值時，可配合多線程使用（未確定循環控制器是否無效）。

4、“forEach控制器”的star index 0 代表第一個，end index 后綴number值+1 代表最后一個，舉例：索引start index:0 ,end index：3  --》對應得到后綴number是0、1、2。

start索引值=后綴number值-1

end索引值=后綴number值+1

后綴number>=0

5、多個入參可以嵌套“forEach控制器”處理。

6、“事務控制器”的generate parent sample勾選后，在察看結果樹中可按事務層級結構顯示，否則事務會在同一層級顯示看不出事務層級關系。

7、“csv數據文件配置”的是否允許帶引號勾選后則參數值可以允許有引號等特殊字符。

8、一般函數的參數都不能引用別的變量，但是${__javaScript(,)}函數可以引用變量，如引用變量做加法：${__javaScript(${userPhone}+1,resl)}。另外函數不能引用函數。

9、“json extractor”提取多個參數時，variables間加分號“;”，json path expressions間也是加分號“;”，並且default values必須填默認值，多參數默認值間也是加分號“;”。

10、復雜的數據處理可以用javaScript和beanshell函數，js函數顯示的數字位數過大的時候需要做字符型轉化顯示才好${__javaScript(String(13760000000+1),)}，難度較高，需要學習javaScript，beanshell需要學習java。

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

12、quearySring參數和body參數都要作為請求的參數填寫。

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

14、在做接口測試時注意下請求頭(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不可缺少，不然服務器端會報錯。

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

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

$-1$:表示取所有值

$0$:表示隨機取值

$1$:表示取第1個

$2$:表示取第二個

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

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

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

17、正則表達式提取器，匹配數字（0代表隨機），0 代表隨機取值，1 代表全部取值。

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