bin目录文件

Jmeter.bat：windows下的启动文件
Jmeter.log：日志文件
Jmeter.sh：Linux的启动文件
Jmeter.properties：系统配置文件
Jmeter-server.bat：windows分布式测试要用到的服务器配置
Jmeter-server：Linux分布式测试要用到的服务器配置

工具组成部分

资源生成器：用于生成测试过程中服务器、负载机的资源代码
用户运行器：通常是一个脚本运行引擎，根据脚本要求模拟指定的用户行为
报表生成器：根据测试中实时的数据生成报表，提供可视化的数据显示方式
负载发生器：用于产生负载，通常以多线程或者多进程的方式模拟用户行为

测试计划

用于描述一次性能测试，包含与本次性能测试所有有关的功能，也就是说本次性能测试的所有内容是基于一个计划的

Threads（Users）线程用户

setup thread group
特殊的线程组，执行预测试操作，即测试前，执行该定期线程组，类似init
teardown thread group
特殊的线程组，执行测试后操作，即测试结束后，执行该定期线程组，类似end
thread group（线程组）
可以看做一个虚拟用户组，线程组中每一个线程都是一个虚拟用户，线程组中包含的线程数量在测试执行过程中是不会发生改变的，类似action

Test Fragment（测试片段）
特殊的线程组，在测试计划中与线程组（Threads）处于一个层级，但是不被执行，除非它是一个模块控制器或者是被控制器所引用时才会被执行

Config Element（配置元件）
提供对静态数据配置的支持，如CSV Date Set Config可以将本地数据文件形成数据池（Date Pool）

Timer（定时器）
用于操作之间设置等待时间，等待时间是性能测试中常用的控制客户端QPS的手段

QPS：Query Per Second 每秒查询率，是一台查询服务器每秒能够处理的查询次数，在因特网上，作为域名系统服务器的性能经常用每秒查询率来衡量

Per Processors（前置处理器）
用于在实际的请求发出之前对即将发出的请求进行特殊处理。例如，HTTP URL重写修复符可以实现URL重写，当URL中有sessionID一类的session信息时，可以通过该处理器填充发出请求的实际的sessionID

Post Processors（后置处理器）
用于对Sampler发出请求后得到的服务器响应进行处理，一般用来提取响应中的特定数据

Assertions（断言）
用于检查测试中得到的相应数据等是否符合预期，一般用来设置检查点，用以保证性能测试过程中的数据交互是否与预期一致

Listener（监听器）
用来对测试结果数据进行处理和可视化展示的一系列元件。注意：不是用来监听系统资源的元件

Sample（取样器）
向服务器发送请求，记录响应信息，记录响应时间的最小单元

逻辑控制器
两类元件
一、用于控制test plan中sampler节点发送请求的逻辑顺序的控制器，常用的有if、switch Controller、Runtime Controller等
二、用来组织可控制sampler节点的，如事务控制器、吞吐量控制器
sample必须位于逻辑控制器下

Jmeter元件作用域和执行顺序

元件作用域
8类可执行元件（测试计划和线程组不属于可执行元件），其中，sample（取样器）是典型的不与其他元件发生交互作用的元件，逻辑控制器只对其子节点的取样器有效，而其他元件（配置元件，定时器，断言，监听器）需要与sample等元件进行交互
在Jmeter中，元件的作用域是靠测试计划的树型结构中元件的父子关系来确定的，作用域的原则是：

取样器（sample）元件不和其他元件相互作用，因此不存在作用域的问题
逻辑控制器（Logic Controller）元件只对其子节点的取样器和逻辑控制器作用
除Sample（取样器）和Logic Controller（逻辑控制器）元件外，其他6类元件，如果是某个取样器的子节点，则该元件对其父子节点起作用，如果其父节点不是取样器，则其作用域是该元件父节点下的其他所有后代节点（包括子节点，子节点的子节点等）

元件执行顺序

配置元件（config elements）
前置处理程序（Per-processors）
定时器（Timers）
取样器（samples）
后置处理程序（Post-processors）
断言（Assertions）
监听器（Listeners）

注意：
1.前置处理器、后置处理器和断言等元件功能只对取样器作用，因此，如果在它们的作用域内没有任何取样器，则不会被执行
2.如果在同一作用域范围内有多个同一类型的元件，则这些元件按照它们在测试计划中的上下顺序依次执行

小练习

测试计划----添加----Threads-----线程组
线程组----添加----Sample----Http请求
HTTP请求----添加----定时器----Constant Throughput Timer

Constant Throughpout Timer---->Target throughput：目标吞吐量，注意这里是每分钟发送的请求数，实际填的数值为：60 *QPS，比如要测负载达到30QPS，那就是30 *60

Http请求----添加----监听器----查看结果树/聚合报告

聚合报告参数解析：
Label：每个Jmeter的element（例如Http Request）都有一个Name属性，这里显示的是Name属性的值
#Samples（样本）：表示这次测试一共发送了多少请求，如果模拟10个用户，每个用户迭代十次，那么这里就是100
Average：平均响应时间——默认情况下是单个Request的平均响应时间，当使用了Transaction Controller时，也可以以Transaction为单位显示平均响应时间
Median：中位数，50%用户的响应时间小于该值，注意它与average平均响应时间的区别
90%Line：90%的请求耗时都在这个时间之下
Min：最小响应时间
Max：最大响应时间
Error%：本次测试中出现的错误的数量/请求的总数
Throughput：吞吐量——默认情况下表示每秒完成的请求数，当使用了Transaction Controller（事务控制器）时，也可以表示类似Load Runner中的Transaction per Second数
KB/sec：每秒从服务器端接受的数据量，相当于LoadRunner中的Throughput/Sec
时间单位都是毫秒

Jmeter断言（检查点）

断言是在请求的返回层面上增加一层判断机制，因为请求成功了并不代表结果一定正确，因此需要检测机制提高测试准确性

1. 响应断言

微信截图_20190514144637.png

模式匹配规则：
包括：返回结果包括你返回的内容
匹配：根据指定内容进行匹配
Equals：返回结果与你指定的结果一致
Substring：返回结果是指定结果的字串
否：不进行匹配

2. Size Assertion
输入指定的字节，通过选择判断符来进行比较

微信截图_20190514152150.png

3. Duration Assertion（断言持续时间）
如果响应时间大于设置的持续时间，则断言失败，反之成功

参数化

前置处理器----用户参数

微信截图_20190514153555.png

微信截图_20190514153619.png
CSV数据配置
1.线程组设置循环次数，线程组下插入的HTTP请求负责插入数据
2.创建一个文本文档，标准的CSV格式文件，每一行数据对应文档一条记录，不用字段之间使用英文 , 分隔
3.创建一个CSV元件，声明数据源以及编码集以及解析格式
Filename：文件路径
File encoding：编码集
Variable Names：变量名
Delimiter：分隔符
4.要将CSV中解析的数据设置进JSON格式的数据报文，语法${变量名}
随机参数化
选项----函数助手对话框----_Random----设置最小值最大值，拷贝生成的变量表达式----粘贴到sample当中的参数值当中

Jmeter集合点

在需要集合的元件前-----添加定时器------Synchronizing Timer

参数说明
Number of Simulated Users to Group by------集合点的集合数
Timeout in milliseconds------到达设置的集合数之后等待的时间（单位：毫秒）

Jmeter性能测试