Jmeter(3)Jmeter常用目录、常用测试计划元件介绍
JMeter常用目录介绍
启动JMeter时,我们会发现一些提示信息:

这几句话的意思是:不要使用GUI模式来进行压力测试(负载测试),此模式仅适用于测试创建和测试调试,对于压力测试,请使用CLI命令行模式(Non GUI) 。
既然有可能要使用CLI命令行模式,那我们就来了解一些JMeter常用的目录的作用。

bin目录
bin目录:
examples: 目录中有CSV样例
jmeter.bat windows系统的启动文件
jmeter.sh linux系统的启动文件
jmeter.log jmeter的运行日志文件
jmeter.properties jmeter的系统配置文件
- jmeter.properties配置文件有修改时,要重启jmeter
jmeter-server.bat windows分布式测试要用到的服务器配置
jmeters-server linux分布式测试要用的服务器配置
利用jmeter.properties配置文件可以进行一些jmeter的界面显示配置,如设置jmeter的GUI语言,GUI图标大小比例, 功能区工具栏图标大小,视图区目录树图标大小等等,参考链接:https://zhuanlan.zhihu.com/p/92582351
另外,说一下SSL:
什么是SSL?https、SSL和TSL之间的关系?
如果您能使用 https:// 来访问某个网站,就表示此网站是部署了SSL证书。一般来讲,如果此网站部署了SSL证书,则在需要加密的页面会自动从 http:// 变为 https:// ,如果没有变,你认为此页面应该加密,您也可以尝试直接手动在浏览器地址栏的http后面加上一个英文字母“ s ”后回车,如果能正常访问并出现安全锁,则表明此网站实际上是部署了SSL证书,只是此页面没有做 https:// 链接;如果不能访问,则表明此网站没有部署 SSL证书。

请注意:有些部署了 SSL证书的网站会有不安全因素警告 ( 如下图所示 ) ,表明此页面中含有指向其他没有部署 SSL证书的页面,为了安全起见,建议您选择“否”,浏览器就不显示不安全的内容,这些内容一般都是 Flash 动画或 Java Script ,如果选择“是”,则浏览器不会显示安全锁标志。
起初是因为HTTP在传输数据时使用的是明文(虽然说POST提交的数据时放在报体里看不到的,但是还是可以通过抓包工具窃取到)是不安全的,为了解决这一隐患网景公司推出了SSL安全套接字协议层,SSL是基于HTTP之下TCP之上的一个协议层,是基于HTTP标准并对TCP传输数据时进行加密,所以HPPTS是HTTP+SSL/TCP的简称。
SSL的版本介绍
由于HTTPS的推出受到了很多人的欢迎,在SSL更新到3.0时,IETF对SSL3.0进行了标准化,并添加了少数机制(但是几乎和SSL3.0无差异),标准化后的IETF更名为TLS1.0(Transport Layer Security 安全传输层协议),可以说TLS就是SSL的新版本3.1,TLS1.0和SSL3.0几乎没有区别
下面看一下SSL在jmeter.properties里面的常见设置:
# 指定HTTPS协议层
https.default.protocol=TLS
# 指定SSL版本,实际应用中可能需要修改
https.default.protocol=SSLv3
# 设置启动的协议
https.socket.protocols=SSLv2Hello SSLv3 TLSv1
# 缓存控制,控制SSL是否可以在多个迭代中重用
https.use.cached.ssl.context=true
其它目录
docs目录
jmeter接口文档目录。jmeter是开源,支持二次开发,所以对外提供了一些二次开发的接口api。

docs/api就是jmeter接口文档的目录,双击index.html就可以看到接口信息:

extras目录
扩展插件目录。提供了对Ant的支持,可以使用Ant来实现自动化测试,例如批量脚本执行,产生html格式的报表,测试运行时,可以把测试数据记录下来,jmeter会自动生成一个.jtl文件,将该文件放到extras目录下,运行“ant-Dtest=文件名 report",就可以生成测试统计报表。
lib目录
所用到插件目录,里面均为jar包。jmeter会自动在jmeter HOME/lib和ext目录下寻找需要的类,lib下存放JMeter所依赖的外部jar,如httpclient.jar、httpcore.jar、httpmime.jar等等。
其中lib\ext目录下存放有Jmeter依赖的核心jar包,ApacheJMeter_core.jar、ApacheJMeter_java.jar在写client端需要引用,JMeter插件包也在此目录下。
lib\junit下存放junit测试脚本。
Licenses目录
jmeter证书目录。
printable_docs目录
printable_docs的usermanual子目录下的内容是JMeter的用户手册文档,其中usermanual下的component_reference.html是最常用的核心元件帮助文档。

双击打开主页index.html

重点学习文档:usermanual/component_reference.html:

测试计划元件
测试计划(Test plan)
描述一个性能测试,包含本次测试的所有相关功能
线程组(Thread Group)
线程组元件是任何一个测试计划的开始点。

一个线程组可以看做一个虚拟用户组,线程组中的每个线程都可以理解为一个虚拟用户。多个用户同时去执行相同的一批次任务。每个线程之间都是隔离的,互不影响的。一个线程的执行过程中,操作的变量,不会影响其他线程的变量值。
线程组的相关配置解释如下:
1、取样器错误后要执行的动作:

- 继续:忽略错误,继续执行
- Start Next Thread Loop: 忽略错误,线程当前循环终止,执行下一个循环。
- 停止线程:当前线程停止执行,不影响其他线程正常执行。
- 停止测试:整个测试会在所有当前正在执行的线程执行完毕后停止
- Stop test now:整个测试会立即停止执行,当前正在执行的取样器可能会被中断。
这几个配置项控制了“当遇到错误的时候测试的执行策略”是否会继续执行。
2、设置线程数
线程数也就是并发数,每个线程将会完全独立的运行测试计划,互不干扰。多个线程用于模仿对服务器的并发访问。默认是1个。

3、ramp-up period
- ramp-up period用于设置启动所有线程所需要的时间。注意是启动所有线程的时间,不是执行完所有线程的时间。如果选择了10个线程,并且ramp-up period是100秒,那么JMeter将使用100秒使10个线程启动并运行。每个线程将在前一个线程启动后10(100/10)秒后启动。
- 当这个值设置的很小、线程数又设置的很大时,在刚开始执行时会对服务器产生很大的负荷。
- 下图的线程配置中,5个线程,5秒启动时间,每个线程执行两次循环。那么每个线程之间启动延迟为 1 秒。

- 如果 ramp-up 时间内,所有线程不能启动运行完的话,时间则会顺延下去
- Ramp-up设置注意事项:

4、设置循环次数
该项设置线程组在结束前每个线程循环的次数,如果次数设置为1,那么JMeter在停止前只执行测试计划一次。

设置了多个线程或循环次数大于1时,向服务器发送了多个请求,查看观察树的效果大致如下:

5、Delay Thread creation until needed
延迟创建线程直到需要。
- 默认情况下,测试开始的时候,所有线程就被创建完了。如果勾选了此选项,那么线程只会在合适的需要用到的时候创建。
- 延迟创建线程,直到线程被需要、采样器开始执行时才会被创建,避免资源浪费
6、Specify Thread Lifetime【调度器】
调度器的作用:控制每个线程组运行的持续时间以及它在多少秒后再启动
Duration (seconds) :持续时间;线程组运行的持续时间
Startup Delay (seconds):启动延迟;测试计划开始后,线程组的线程将在多少秒后再启动运行

调度器和循环次数的关系:
- 循环次数有固定值且 ≠ -1,持续时间不会生效,以循环次数为准
- 循环次数设置为永远或 -1 时,持续时间才会生效
调度器注意事项:
- 当线程组运行完持续时间后,会逐步释放线程,不会一下子把所有线程释放掉,而释放线程也是需要时间的~
- 所以测试计划总的时间(右上角的时间)会 > 持续时间+启动延迟

预习系统吞吐量(TPS)
- 总的完成请求数 = 线程总数 * 循环次数
- 平均TPS = 总请求数 / 线程运行总时间【上图,右上角黄色三角形的时间】
- 平均TPS(即聚合报告的TPS)是仅供参考的
- 实际的TPS是由响应时间决定的,需要通过响应时间结果图和TPS结果图来最后得出
一个系统的吞度量(承压能力)与request对CPU的消耗、外部接口、IO等等紧密关联。
单个reqeust 对CPU消耗越高,外部系统接口、IO影响速度越慢,系统吞吐能力越低,反之越高。
系统吞吐量几个重要参数:QPS(TPS)、并发数、响应时间
QPS(TPS):每秒钟request/事务 数量
并发数: 系统同时处理的request/事务数
响应时间: 一般取平均响应时间
(很多人经常会把并发数和TPS理解混淆)
理解了上面三个要素的意义之后,就能推算出它们之间的关系:
QPS(TPS)= 并发数/平均响应时间
一个系统吞吐量通常由QPS(TPS)、并发数两个因素决定,每套系统这两个值都有一个相对极限值,在应用场景访问压力下,只要某一项达到系统最高值,系统的吞吐量就上不去了,如果压力继续增大,系统的吞吐量反而会下降,原因是系统超负荷工作,上下文切换、内存等等其它消耗导致系统性能下降。
setup thread group
一种特殊类型的ThreadGroup,用于在执行常规线程组之前执行一些必要的操作。在“setup thread group ”下提到的线程行为与普通线程组完全相同。不同的是执行顺序---它会在普通线程组执行之前被触发。
应用场景举例:
A、测试数据库操作功能时,用于执行打开数据库连接的操作。
B、测试用户购物功能时,用于执行用户的注册、登录等操作。

teardown thread group
一种特殊类型的ThreadGroup,用于在执行常规线程组完成后执行一些必要的操作。在“teardown thread group ”下提到的线程行为与普通线程组完全相同。不同的是执行顺序---它会在普通线程组执行之后被触发。
应用场景举例:
A、测试数据库操作功能时,用于执行关闭数据库连接的操作。
B、测试用户购物功能时,用于执行用户的退出等操作。
tips:
默认情况下,如果测试按预期完成,则TearDown线程组将不会运行。如果你想要运行它,则需要从Test Plan界面中选中复选框“Run tearDown Thread Groups after shutdown of main threads”。
-----------------------------------------------------------
可能你还是不太理解他们与普通的线程组有什么不同。但是如果你用过junit,想必你应该对setup ,teardown这两个字眼不陌生。

取样器(Sampler)
取样器(Sampler)是性能测试中向服务器发送请求,记录响应信息,记录响应时间的最小单元,JMeter原生支持多种不同的sampler,如HTTP Request Sampler、FTP Request Sampler、TCP Request Sampler、JDBC Request Sampler等,每一种不同类型的sampler可以根据设置的参宿向服务器发出不同类型的请求。
在Jmeter的所有Sampler中,Java Request Sampler与BeanShell Request Sampler是两种特殊的可定制的Sampler。
一个取样器常进行三部分的工作:向服务器发送请求,记录服务器的响应数据和记录响应时间信息。


逻辑控制器(Logic Controller)
逻辑控制器,包括两类元件,一类是用于控制testplan中sampler节点发送请求的逻辑顺序的控制器,常用的有如果(If)控制器、switchController、Runtime Controller、循环控制器等。另一类是用来组织可控制sampler节点的,如事物控制器、吞吐量控制器。

配置元件(Config Element)
配置元件(config element)用于提供对静态数据配置的支持。CSV Data Set config可以将本地数据文件形成数据池(Data Pool), 而对应于HTTP Request Sampler和TCP Request Sampler等类型的配置元件则可以修改Sampler的默认数据。例如,HTTP Cookie Manager可以用于对HTTP Request Sampler的cookie进行管理(可保持登录状态)。HTTP请求默认值不会出发Jmeter发送http请求,而只是定义HTTP请求的默认属性。

定时器(Timer)
用于操作之间设置等待时间,等待时间使性能测试中常用的控制客户端QPS(系统吞吐量)的手段,jmeter定义了Constant Times、Constant Throughput Times、Guass Ramdon Times等不同类型的Times。


前置处理器(Pre Processors)
用于在实际请求发出之前对即将发出的请求进行特殊处理。
例如:Count处理器可以实现自增操作,自增后生成的数据可以被将要发出的请求使用,而HTTP URL Re-Writing Modifier处理器可以实现URL重写,当URL中有sessionID一类的session信息时,可以通过该处理器填充发出请求实际的sessionID。

后置处理器(post processors)

断言(assertion)
用于检查测试中得到的响应数据等是否符合语气,Assertions一般用来设置检查点,用以保证性能测试过程中的数据交互与预期一致。

监听器(listener)
对测试结果进行处理和可视化展示的一系列组件,常用的有图形结果、查看结果树、聚合报告等。

浙公网安备 33010602011771号