性能测试工具Jmeter由于其体积小、使用方便、学习成本低等原因，在现在的性能测试过程中，使用率越来越高，但其本身也有一定的缺点，比如提供的测试结果可视化做的很一般，尤其是那些蛋疼的报表简直low到爆。不过从3.0版本开始，jmeter引入了Dashboard Report模块，用于生成HTML类型的可视化图形报告（3.0版本的Dashboard Report模块会中文乱码，建议使用3.0以上的版本）
JMeter可以运行模式有两种，一种是GUI图形，另一种是命令模式运行也就是非GUI模式。两种模式的区别还是挺大的。
GUI：由于是图形界面，所以在运行时会消耗很多资源，而且图形界面运行时结果是保存在Jmeter运行的内存中，如果是做长时的性能测试，内存就会占用的很高，首先就是影响性能结果的准确性，其次当内存增长到一定程度，就会报错，甚至可能出现卡死/宕机。
非GUI优势：命令模式运行可以将实时的log文件保存到本地，位置可以自定义，不会占用太多机器的资源，可以长时间运行。
1、节约系统资源：无需启动界面，节约系统资源
2、便捷快速：仅需启动命令行，输入命令便可执行，是为命令达人最爱
3、易于持续集成：可通过shell脚本命令执行
非GUI运行命令部分：
- -h 帮助 -> 打印出有用的信息并退出
- -n 非 GUI 模式 -> 在非 GUI 模式下运行 JMeter
- -t 测试文件 -> 要运行的 JMeter 测试脚本文件
- -l 结果文件路径 -> 记录结果的文件，路径不存在时会自动创建格式为jtl或csv
- -r 远程执行 -> 在Jmter.properties文件中指定的所有远程服务器
- -R 远程执行 -> 执行指定的服务器
- -j 指定执行日志路径 -> 路径不存在时不会自动创建
- -e 设置测试完成后生成测试报表
- -g CSV结果文件 --> 指定测试执行结果文件路径，仅用于生成测试报表
- -o 报表文件夹路径 --> 执行测试报表生成文件夹，文件夹必须为空或者不存在
- -H 代理主机IP -> 设置 JMeter 使用的代理主机
- -P 代理端口号 -> 设置 JMeter 使用的代理主机的端口号
非GUI运行示例：
jmeter -h
含义为：获取jmeter的命令帮助
jmeter -n -t test.jmx
含义为：以命令模式运行test.jmx文件
jmeter -n -t test.jmx -l report 1-result.csv -j report 1-log.log
含义为：以命令模式运行test测试文件并保存结果及日志文件，需要注意的是如果日志路径不存在将不会自动创建，且日志会输出在命令行窗口，生成的结果文件可以在JMeter的图形界面下的聚合报告中导入结果文件进行查看。
jmeter -n -t test.jmx -r -l report 1-result.csv -j report 1-log.log
含义为：以命令模式远程调用remote_hosts中配置的所有服务器运行test测试文件并保存结果及日志文件，需要注意的是执行端的日志文件默认生成在用户目录下
jmeter -n -t test.jmx -R 192.168.21.40:1029 -l report 1-result.csv -j report 1-log.log
含义为：以命令模式远程调用192.168.21.40服务器运行test测试文件并保存结果及日志文件
为方便管理起见，在Jmeter安装目录下的bin目录下创建一个文件夹用来存放脚本（.jmx文件），再创建一个文件夹用来存放脚本执行后的结果文件。
结果文件是可以在Jmeter可视化界面打开的，它保存了脚本执行过程中的各种结果非常全面，结果树、聚合报告、表格查看结果等都可以将它打开看到响应的数据。
执行方法
生成HTML测试报告的两种方式
1、利用已有.jtl文件生成报告
如果已经有经过测试生成的.jtl文件，可以利用该文件直接生成HTML可视化测试报告，进入jmeter的bin目录下，输入如下命令：
jmeter -g test.jtl -o /path # -g：后跟test.jtl文件所在的路径 # -o：后跟生成的HTML文件存放的路径
如果是在Windows环境命令行运行，必须指定生成的HTML文件存放文件夹，否则会报错；如果是linux环境，如指定路径下不存在该文件夹，会生成对应的文件夹存放报告文件！
2、无.jtl文件生成测试报告
如果还未生成.jtl文件，则可以通过如下命令，一次性完成测试执行和生成HTML可视化报告的操作，进入jmeter的bin目录下，输入如下命令：
jmeter -n -t test.jmx -l test.jtl -e -o /path# -n：
以非GUI形式运行Jmeter # -t：source.jmx 脚本路径 # -l：result.jtl 运行结果保存路径（.jtl）,此文件必须不存在 # -e：在脚本运行结束后生成html报告 # -o：用于存放html报告的目录
Windows
1、在图形界面中写好脚本，配置好线程数等参数，配置思路如下：
线程是操作系统能进行调度运算的最小单位，线程组可以理解为模拟的用户数，假设线程数为100，就相当于模拟100个虚拟用户。
Ramp-Up时间（秒）：启动时设置线程数耗时时长。如要使用大量线程的话，一般不要设置成零，当设置成零时，Jmeter将会在测试的开始就建立全部线程并立即发送访问请求， 这样一来就很轻易使服务器饱和，更重要的是会隐性地增加了负载。
循环次数：执行任务的次数，设置为永远会一直执行，除非手动停止，否则不会停止，类似LR中运行时设置中迭代次数
调度器：持续时间（秒）、持续延迟（秒）
2、找到测试脚本位置，设置好聚合报告（jtl文件，可用jmeter打开）需要放置的位置，执行命令cmd打开命令行模式
3、执行命令：jmeter -n -t D:apache-jmeter-3.2PressureTest ental.jmx -l rental.jtl -e -o D:apache-jmeter-3.2PressureTestHttpReport（执行结果文件也可以保存为.cvs后缀）
ps：结尾的 HttpReport 是自己手动创建的报告文件夹。每次启动命令之前，文件夹中内容必须和 jtl 文件一起清空，之前考虑过每次执行命令都要先去目录下清空报告文件夹和jtl，还要敲命令，很烦。那就是写个bat，每次执行bat都自动去清空之前的报告，然后执行命令
del /s /Q D:apache-jmeter-3.2PressureTest esult.jtl rd /s /Q D:apache-jmeter-3.2PressureTestHttpReport md D:apache-jmeter-3.2PressureTestHttpReport jmeter -n -t D:apache-jmeter-3.2PressureTest ental.jmx -l rental.jtl -e -o D:apache-jmeter-3.2PressureTestHttpReport
4、执行完毕后，用浏览器打开生成的文件目录下的index文件，效果展示如下：
在脚本运行过程中，由于无界面，命令窗口会每隔一段时间打印一下当前的运行状态，在窗口中可以看到类似下面的信息：
summary+ 是开始这个时点的报告。
summary= 是总结它之前的报告，呈现出的是当前时点之前总的情况，通常是均值。
最后一个summary=是本次压测总的情况，如果脚本按时正常结束的话，最后一次summary里面的值应该和你从GUI打开聚合报告或概括报告的值一致。
HTML报告详解
测试报告分为两部分，Dashboard和Charts，下面分开解析
一、Dashboard（概览仪表盘）
1、Test and Report informations（测试和报告信息）
Source file ---- 生成报告的源文件
Start Time ---- 开始时间
End Time ---- 结束时间
2、APDEX (应用性能指标，计算每笔交易APDEX的容忍和满足阈值基于可配置的值，范围在 0-1 之间，1表示达到所有用户均满意）
Apdex：应用程序性能指标(0~1)，1表示所有用户请求均满意，反之0则表示均不满意
T(Toleration threshold)：可接受（容忍或满意）阈值，即用户可接受的响应时间
F(Frustration threshold)：不可接受（失败）阈值，即用户不可接受响应时间
Lable：采样器名称
关于APDEX的相关信息，应用性能指标请参考这里：http://oneapm.udesk.cn/hc/articles/515
3、Requests Summary（请求总结，成功与失败的请求占比，KO指失败率，OK指成功率 ）
4、statistics（数据分析），类似于Jmeter聚合报告
Label：Sample采样器名称（各个模拟测试的名称）
Samples：总共发送请求数(线程数 * 循环次数)，如果模拟10个用户，循环10次，那么就显示100
KO：失败次数
Error%：请求失败率，本次测试中出现错误的请求的数量/请求的总数
Average：平均响应时间，默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，也可以以Transaction 为单位显示平均响应时间
Min：最小响应时间
Max：最大响应时间
90%Line：90%线，90%用户响应不超过该时间
95%Line：95%线，95%用户响应不超过该时间
99%Line：99%线，99%用户响应不超过该时间
Throughput：吞吐量，一般情况下可看做每秒完成请求数(和QPS类似)，当使用了 Transaction Controller 时，也可以表示类似 LoadRunner 的 Transaction per Second 数
Received：每秒从服务器端接收到的数据量，相当于LoadRunner中的Throughput/Sec
Sent：每秒从客户端发送的请求的数量
5、Errors（错误情况，主要就是统计请求出现错误）
6、Top 5 Errors by sampler（采样器的5大错误，主要是统计TOP5发生错误的采样器信息，这里如果全部通过，就不会有统计）
二、Charts（详细信息图表， 包括Over Time(时间变化) 、Throughput（吞吐量） 、Response Times（响应时间））
由于详细信息图表有点多，这里我挑几个性能测试过程中比较关键的图表解析！
1、Over Time
①、Response Times Over Time（响应时间变化曲线），类似于JMeter Plugins上的jp@gc - Response Times Over Time
说明：一条线代表一个事务（请求），由于应用需要初始化建立连接以及CPU、内存等分配都会消耗资源，随着系统趋于稳定，响应时间也会趋于稳定，可以根据响应时间和变化和TPS以及模拟的并发数变化，判断性能拐点的范围，
②、 Response Time Percentiles Over Time (successful responses)，类似于jmeter聚合报告中的Min、Max、90%、95%、99%
说明：脚本运行期间成功的请求响应时间百分比分布图，可以理解为聚合报告里面不同%的数据，图形化展示的结果。
③、Active Threads Over Time（活动线程时间变化曲线图），一个线程组对应一条线
说明：活跃线程变化趋势，即并发用户数趋势。相当于我们模拟的并发用户发出请求随着时间变化的趋势
④、Bytes Throughput Over Time（脚本运行期间的吞吐量变化趋势图），蓝色为每秒发送字节数，黄色为每秒接收字节数
说明：在容量规划、可用性测试和大文件上传下载场景中，吞吐量是很重要的一个监控和分析指标。
⑤、 Latencies Over Time（延迟时间曲线图），记录的是客户端发送请求完成后，服务器端返回请求之前的这段时间，在高并发场景或者业务强数据一致性场景，延时是个很严重的影响因素
说明：可以理解为从发送请求到收到第一个响应所花费的时间，包括事务控制器样本结果，在高并发场景或者强业务强数据一致性场景，延时是个很严重的影响因素
⑥、Connect Time Over Time（连接时间变化曲线图），随着时间变化，每个时间节点花费在连接上的平均时间
说明：脚本运行期间，事务（请求）建立连接所花费的平均时间变化趋势图，包括 SSL 三次握手的时间，当出现链 Connection Time Out 的错误时，Connect Time 就会等于链接超时时间
2、Throughput（吞吐量)
①、Hits Per Second（每秒点击率），类似于JMeter Plugins上的jp@gc - Hits per Second，也叫每秒请求数
②、Codes Per Second（每秒状态码数量）即每秒响应状态码数量，这里主要是对200响应成功的状态码进行记录统计
③、Transactions Per Second（每秒事务数）
说明：每秒事务数，即TPS，是性能测试中很重要的一个指标，它是用来衡量系统处理能力的一个重要指标。类似于JMeter Plugins在UI上的jp@gc - Transactions per Second，如果没有开启事务，那么TPS也可看做QPS
④、Total Transactions Per Second（每秒总事务数）
⑤、Response Time Vs Request（响应时间点请求的成功或失败数），即响应时间和请求数对比关系，如果请求数量太小就只有一些散点。
⑥、Latency Vs Request（延迟时间点请求的成功或失败数）
3、Response Times
①、 Response Time Percentiles（响应时间百分比分布曲线图）
说明：即响应时间在某个范围内的请求在所有请求数中所占的比率，相比于平均响应时间，这个值更适合用来衡量系统的稳定性。
②、Response Time Overview（响应时间概述）
说明：响应时间概述，仔细看下面这种图不难发现，横坐标所绘制的区间和我们最开始看到的APDEX应用程序性能指数中划分的区间一致。
③、Time Vs Threads（平均响应时间和线程数的对应变化曲线）
说明：即活跃线程数和响应时间对比关系，可以通过这个对应的变化曲线来作为确定性能拐点的一个参考值。
配置测试报告
1、从JMeter3.0开始在bin目录就有reportgenerator.properties文件，保存了所有关于图形化HTML报告生成模块的默认配置，要变更配置，建议不要直接编辑该文件，而是推荐在user.properties中去配置和覆盖1、user.properties中配置，基本配置都是以jmeter.reportgenerator.为前缀的
（1）定义采样点粒度（overall_granularity）user.properties中overall_granularity（采样点粒度）默认为60000ms，在我们测试过程中需要更小的粒度，如2秒，所以在上图中将60000修改为2000，也可以在文档末尾加上jmeter.reportgenerator.overall_granularity=2000；
（2）定义报告的标题（report_title）
（3）定义Apdex评估中满意的阈值(单位ms)（apdex_satisfied_threshold）
（4）定义Apdex评估中可容忍的阈值（apdex_tolerated_threshold）
（5）修改响应时间的百分比，在 jmeter.properties中，有三个默认的响应时间的百分比，如果需要修改这三个默认值，可以在user.properties文档末尾加上这三个字段名称，并重新赋值
2、关于HTML报告模板
（1）JMeter的HTML报告生成时是使用了固定的模板，模板文件路径为./bin/report-template，进入该目录可以看到报告的每个，页面都有一个.fmkr模板文件，包括index.html.fmkr和./content/pages路径下的几个文件，可以利用这几个文件，修改对应的名称，html报告的页面标题默认为Apache JMeter Dashboard，如果想改为这个页面标题，可以通过user.properties中的jmeter.reportgenerator.report_title来修改，通过这种方式来修改，那改变的是所有的页面标题
（2）HTML模板汉化，Jmeter生成的html报告都是英文的，如果看不懂，我专门准备了Jmeter 4.x 和Jmeter5.x 两套汉化模板：https://gitee.com/smooth00/jmeter-cn-report-template，使用方法也简单，下载我给的模板，将report-template目录替换apache-jmeter-x.xin eport-template目录即可，新生成的报告就被汉化了
Linux
1、使用linux命令进入Jmeter安装目录下的bin目录
2、执行命令：jmeter -n -t testscriptBaidu.jmx -l testresult 1-reslut.jtl（执行结果文件也可以保存为.cvs后缀）
3、把结果文件下载到windows机器上，使用Jmeter打开结果文件
无界面分布式压测
当并发量过大单机无法承担需要做分布式压测，分布式的配置同以前文章介绍的一样，再次不做赘述。
执行方法：
1、把脚本和参数文件存放到各台终端相同目录下
2、将每台终端的jmerter-server.bat打开等待主机发号施令
3、在主机命令窗口键入类似以下命令： jmeter.bat -n -t testscript/Baidu.jmx -R 192.168.182.129:1100,192.168.182.130:1200 -l testresult/01-result.jtl
命令中-R代表远程 remote ，后面跟随的是每台终端机jmeter-server窗口显示的 ip 和端口，同样，多台终端之间由逗号隔开，其他都与单机命令一样。于是可以看到各台终端机的jmeter-server窗口有关运行和阶段性summary的信息直至运行结束。总体的报告都在你主机保存的那个.jtl文件里。
执行结果：
