Jmeter性能测试工具使用介绍
1.Jmeter安装
Jmeter为开源软件，由bat文件调用jar包的执行，所以jmeter无需安装，但是运行电脑需要32位的jdk环境（jdk安装目录为C:Program Files (x86)Javajdk1.8.0_144）
将jmeter解压到磁盘根目录下，切换到bin目录中，双击jmeter.bat即可启动
如果jmeter的启动过程中发生错误，一般是由于jdk环境变量配置存在问题，需要检查jdk环境变量的的配置
2.Jmeter主界面
双击jmeter.bat启动jmeter后，可以进入到jmeter的主页面，可以在option中选择主页面的外观以及语言
3. 使用jmeter 添加接口请求
3.1 在添加接口请求之前需要先添加线程组，用来管理所有接口请求，一般一个功能模块分为一个线程（右键测试计划---添加---线程---线程组）
3.2 添加好线程组后，右键点击线程组添加取样器中的http请求，http请求中可以配置接口的访问信息
3.3 运行http请求后发现无法查看接口的运行情况，此时需在线程组中新增监听器中的察看结果树
4. 使用Http请求默认值
Http默认值用于统一管理项目地址，例如接口连接中重复的服务器IP，重复提交的参数等，可以在HTTP请求默认值中做相关配置，这样一来可以在切换接口服务器IP时，在jmeter脚本中也可以快速修改（右键线程组--配置元件--Http请求默认中）
5. 添加响应断言&JSON断言
响应断言的作用在于可以自动判断接口返回数据是否符合预期，通过对比接口返回数据中的固定字符串，实现判断的目的
由于响应断言是判断接口返回的数据，所以需要添加到接口中而不是线程组中（右键Http请求--断言--响应断言/JSON断言）
在响应断言面板中配置响应断言相关的信息
要测试的字段：由于断言用来判断接口返回数据，所以判断的主体为响应文本
模式匹配规则：“包括”的意思为接口响应数据中包括预期的字段
“匹配”与“equals”的意思都是接口响应数据与预期字段相等
“Substring”的意思为子字符串
“否”代表在选择的条件上加否，比如选择包括+否，意思为不包括
要测试的模式：预期字段
当接口返回数据与响应断言中的不一致时，响应断言会作出相应提示
6.参数化
参数化就是将写死的值，替换成参数化文件，往参数化文件中添加数据后，使脚本每次执行的取值不一样
目的：
1.减少脚本的大小
2.提供不同的值，提高执行脚本的能力，从而更加真实的模拟生产环境的数据
3.解决重复数据导致的回放失败的问题，解决查重问题
6.1 添加参数化配置文件
6.2 配置参数化
配置参数名：参数名为参数文件的调用形式，在接口链接中通过参数名调用参数文件
选择参数文件：参数文件为文本类型，可以使用notpad++编辑，避免出现编码错误
选择编码格式：默认选择utf-8格式
6.3 配置多个参数
Jmeter支持在同一个文件中配置多个参数的方式
参数文件配置：参数文件中需要以逗号为分隔符
Jmeter参数配置：在变量名称中配置对应的参数名，多个参数名之间要以英文逗号为分隔符
参数的顺序为读取数据的顺序，例如变量名中配置的顺序为username,password 则username取参数文件中的第一列，password读取参数文件中的第二列
Jmeter中的参数格式默认为 ${参数名}的形式
7.正则表达式
作用：在接口的访问中，经常会出现动态验证的情况，例如xx接口中，登录接口返回数据中存在token参数，并且token参数会实时变化，并且其他接口在访问时需要使用动态变化的token值
在访问其他接口时，需要从登陆接口中获取到最新的token数据，所以需要调用正则表达式提取器
注：token为接口中的一种用户验证方式，通过动态变化提升接口的安全性
7.1 正则表达式原理
正则表达式提取器是利用正则表达式从接口返回数据中提取指定字符串，并将其保存在参数中，并提供给其他接口调用，正则表达式是一种模糊查询方式，可以使用固定组合匹配出任意字符
注意: 正则表达式是作用在接口的返回数据中，所以要添加到接口链接中（右键http请求---添加--后置处理器---正则表达式提取器）
7.2 添加正则表达式提取器
1.要检查的响应字段：主体为接口的响应数据 body以及信息头代表的是接口的其他部分，由于要提取的内容大部分在接口响应数据中，所以这里默认选择主体
2.引用名称：类似于参数文件中的参数名
3.正则表达式：通过表达式可以提取出指定字符，表达式一般为接口数据中字段与符号的组合
4.模板：默认写为$1$
5.匹配数字：当正则表达式可以匹配出多个值时，1 代表匹配结果中的第一个 0代表随机选择
6.缺省值：当正则表达式无法找到值时，会选择一个默认值
如不同线程组之间使用相同参数化变量，则需要使用到全局变量
8. 配置接口并发场景
1.线程数：虚拟用户数。一个虚拟用户占用一个进程或线程。设置多少虚拟用户数在这里也就是设置多少个线程数。
2. Ramp-Up Period(in seconds)准备时长：设置的虚拟用户数需要多长时间全部启动。如果线程数为50，准备时长为2，那么需要2秒钟启动50个线程，也就是每秒钟启动25个线程。
3. 循环次数：每个线程发送请求的次数。如果线程数为10，循环次数为100，那么每个线程发送100次请求。总请求数为10*100=1000 。如果勾选了“永远”，那么所有线程会一直发送请求，一到选择停止运行脚本。
4. Delay Thread creation until needed：直到需要时延迟线程的创建。
5. 调度器：设置线程组启动的开始时间和结束时间(配置调度器时，需要勾选循环次数为永远)
持续时间（秒）：测试持续时间，会覆盖结束时间
启动延迟（秒）：测试延迟启动时间，会覆盖启动时间
因为接口调试需要，我们暂时均使用默认设置，待后面真正执行性能测试时再回来配置。
8.1 分析测试报告
待性能测试执行完成后，打开聚合报告可以看到：
设置长时间跑接口，比如1秒50并发，持续了65s——发现实际接口请求数595个，时间65秒，TPS参数较稳定；
TPS大概在9左右，所以当前这个接口，系统能处理的事务在9个左右
TPS=请求数/时间 == 595/65
TPS: 一秒钟处理的事务数。TPS值越大，一秒钟处理的事务数就越多，说明处理速度越快，软件的效率就越好。
聚合报告参数详解：
1. Label：每个 JMeter 的 element（例如 HTTP Request）都有一个 Name 属性，这里显示的就是 Name 属性的值
2. #Samples：请求数——表示这次测试中一共发出了多少个请求，如果模拟10个用户，每个用户迭代10次，那么这里显示100
3. Average：平均响应时间——默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，以Transaction 为单位显示平均响应时间
4. Median：中位数，也就是 50％ 用户的响应时间
5. 90% Line：90％ 用户的响应时间
6. Min：最小响应时间
7. Max：最大响应时间
8. Error%：错误率——错误请求数/请求总数
9. Throughput：吞吐量——默认情况下表示每秒完成的请求数（Request per Second），当使用了 Transaction Controller 时，也可以表示类似 LoadRunner 的 Transaction per Second 数
10. KB/Sec：每秒从服务器端接收到的数据量，相当于LoadRunner中的Throughput/Sec
一般而言，性能测试中我们需要重点关注的数据有：
- #Samples ： 请求数，
- Average： 平均响应时间，
- Min： 最小响应时间，
- Max： 最大响应时间，
- Error%： 错误率
- Throughput： 吞吐量。
吞吐量：总的线程数/持续时间。吞吐量是指系统在单位时间内处理请求的数量，TPS、QPS都是吞吐量的常用量化指标。
并发数： 同一时刻系统同时处理的请求数(相对并发，绝对并发)
TPS：单位时间(每秒)处理的事务数 并发量 / 平均响应时间
QPS：单位时间(每秒)响应的请求数
RT： 响应时间，一般取平均响应时间
PV: 访问量（Page View）
计算QPS(TPS)=并发数/平均响应时间
性能测试参考博客：
https://blog.csdn.net/u013908944/article/details/97383303
https://www.cnblogs.com/hjhsysu/p/9189897.html
https://blog.csdn.net/paidaxing_dashu/article/details/102461709
https://blog.csdn.net/u011197146/article/details/83273879
举例：当前接口的性能需求为满足200个用户并发访问并且响应时间需要小于300ms
设计场景：1.设定线程数为200，持续时间5min，查看测试结束后接口响应时间的情况，如果接口响应时间远远大于300ms，则需要逐步减少设置的线程数，查看响应时间在300ms时对应的线程数
2.设定线程数为200，持续时间5min，查看测试结束后接口响应时间的情况，如果接口响应时间小于300ms，则需要逐步增加设置的线程数，查看响应时间在300ms时对应的线程数
3.综上：测试结果中应该用一组数据提现接口响应时间随用户数的变化，需要有目标并发用户数对应的响应时间，也需要提现目标响应时间对应的并发用户数
8.2 聚合报告
聚合报告中可以查看接口响应时间的情况，以及接口脚本执行过程中的错误率等情况，聚合报告中的时间单位为毫秒
表示的内容为每个接口请求正常处理后所消耗的时间
每秒点击量以及每秒事务数：
9.监控服务器性能
在执行性能测试的过程中可以监控服务器的硬件资源使用情况，可以选择spotlight监控，也可以选择使用jmeter自身监控；
资源指标：
CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%；
内存利用率：内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%；
磁盘I/O: 磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time （磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能；
网络带宽：一般使用计数器Bytes Total/sec来度量，其表示为发送和接收字节的速率，包括帧字符在内；判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较；
系统指标：
并发用户数：单位时间内与系统发生交互的用户数；
在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求；
平均响应时间：系统处理事务的响应时间的平均值；事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间；
事务成功率：性能测试中，定义事务用于度量一个或者多个业务流程的性能指标，如用户登录、保存订单、提交订单操作均可定义为事务，单位时间内系统可以成功完成多少个定义的事务， 在一定程度上反应了系统的处理能力，一般以事务成功率来度量；
超时错误率：主要指事务由于超时或系统内部其它错误导致失败占总事务的比率；
10.性能测试的方法有哪些？每类测试的目的？
基准测试：确保测试环境无问题，初步评估单一事务运行时，当前系统的响应时间是否够快，各个服务器的CPU，内存耗用是否合理。用一个用户测试脚本。目的是为了让我们估算指标。
单一事务并发测试：确保数据库不存在线程死锁等问题，评估在只是单独运行一个事务时，系统的响应时间是否够快，CPU,内存耗用是否合理
混合场景测试：模拟真实场景，评估系统各事务响应时间是否够快，CPU,内存耗用是否合理，VUG可以打开几个脚本，并发用户数可以设置百分比。
负载测试：逐步加压，根据业务及数据推算，加压到性能指标满足需求时，系统能承受最大负载压力的测试
压力测试：逐步加压，关注系统在何时达到临界点，记录到达临界点时的并发用户，点击率，以及吞吐率
稳定性测试：在满足业务负载的情况下执行稳定性测试，长时间运行查看系统的运行情况
大容量测试：一般针对数据库，对特定存储，统计，查询业务的测试
11. 发现的性能问题举例，以及对应的优化措施：
1.发现CPU使用率过高，超过80% ，备注：对数据库的操作比较消耗cpu资源
优化措施：例如查询场景，表数据量较大，建议开发做了索引，为一些常用查询做数据库视图，减少数据库服务器资源消耗，另外可以优化业务场景调用的SQL语句
2.发现内存泄漏 ，备注：代码中部分线程在执行完后没有正常释放占用的内存空间（java中，线程没有正常结束）
优化措施：建议增加服务器缓存/服务器内存；排查代码中无效的线程是否得到释放，优化代码，及时释放无效线程。
3.发现TPS达不到要求，失败率过高
优化措施：增加web服务器线程数，增加数据库连接池，增加代码中配置的线程数，优化数据库连接方式
4.响应时间较长
优化措施：优化图片格式，增加前端缓存，优化js脚本，优化sql查询语句。
5.硬盘占用过多
优化措施：查看日志打印机制，减少无用的日志打印，优化表结构以及数据存储的能力，增加硬盘磁阵
12. 怎么设置递增？
据并发的总用户数，如果并发的总用户少，递增用户就少设置一些，如果并发用户多，那么递增用户就多设置一些，前提是递增的用户数能够在压力机配置的承受范围内，递增的时间可以方便观察性能指标变化的过程，这样我们就可以观察到哪个并发输的时候会出现性能拐点
在确定并发用户的基础上，设计用户在5-10次增加完
具体例子（并发100，设置每10秒递增5个，持续10分钟）
基本原则是越慢越好，用户递增越慢 可以清楚的看到性能指标随用户数的变化，便于分析问题
Ramp Up 用户递增
Ramp Down 用户递减
13. 并发数怎么计算？
示例1：
比如XX项目的新建线索业务，每天集中在早上9点和下午17点录入信息，每天2小时产生约9000条
首先计算总TPS:
9000条/2h =4500条/h
4500/3600s=1.25条/s
假设用户新建线索的事务需要耗时10s
1条/10s = 0.1
总TPS除以单个用户的TPS=并发用户数
1.25/0.1=12
得到结果：9000条业务量的情况下对应的并发用户数是12，测试过程中的并发用户数设置以12为参考值，逐步增加用户，进行测试
示例2：
一个OA系统，员工每天都需要在系统中进行签到，签到的高峰期在早上的8：30-9:00，假设公司的员工为2000人，平均一个员工签到的时长为3分钟
计算系统QPS or TPS = 2000/30*60
平均在线时长为 3*60
并发用户数 = (2000/30*60)*(3*60) = 200人
14. 怎么进行性能分析？
1.怎样判定测试结果是否正常
如果测试结果为正常情况，需要满足的条件：
1.性能指标要满足性能需求中描述的值，例如响应时间，TPS等
2.在满足性能指标的同时，服务器资源使用情况为正常水平
3.其他性能指标均在正常变化范围内。
如果测试结果为异常，常出现的异常情况：
1.虚拟用户数无法按照设计的场景来增加.负载机问题。
2.连接数在用户数增加时，无法继续增加。服务器连接数限制了，修改连接数。
3.事务响应时间，没有达到性能需求中描述的值
4.TPS无法达到测试预期的值
5.点击量在用户数增加时，无法继续增加
6.吞吐量在点击量增加时，无法继续增加