这里写目录标题
一、性能测试环境准备
1、性能测试环境：服务器配置
1、硬件型号：尽量一致
2、服务器数量：
在生产环境可能有20多台机器，大公司甚至有上千台机器，是不是在性能测试环境下，把整个服务器数量全部罗列到性能测试环境？不需要
基准测试：
同理可得，以此类推，
例如：1台机器能够承载1000/s的并发；理论上说1000台机器能够承载100000/s的并发
并没有严格要求性能测试环境服务器数量。
2、数据准备
a、纯数据库SQL
b、用代码去生成数据，导入的SQL语句：比较常用
技巧：
衍生已有的数据，
随机生成
c、用代码/工具，去调用接口/UI自动化生成
注意事项：
a、注意数据的状态分布
b、比如造订单数据- 多种状态（尽量贴合生产环境分布情况）
数据分布，决定了数据库层面的性能情况
c、极端数据情况？
做性能测试是基于正常的场景，大批量用户（用户是分散的），性能场景如果脱离了业务场景，这种性能测试是没有必要的。
二、性能测试执行工具（Jmeter）
版本：5.4.1
依赖java环境：JDK1.8
第三方插件：
放到下面的目录下
apache-jmeter-5.4.1\lib\ext
线程模型：多线程并行执行
线程数：同时多少个虚拟用户在干活，干活的内容就是线程组里面的内容
多个线程会同时开干
同一个线程去执行线程组内的任务：是有序的
1、用户定义的变量：
2、事务控制器：
使用场景：当我们测试的场景中包含了多个接口的时候，需要做整体的数据统计
多个操作，当作一个事务去统计合算
事务中任一操作失败，则整个事务状态执行异常；虽然整个事务中大多数的接口没有问题，只有某个接口错误，事务执行失败。
3、测试结果查看
a、汇总报告
缺点：只能查看最终的结果，无法看到过程，无法分析出哪一个阶段系统达到了性能拐点
Label
接口名称
样本
接口请求次数
平均值（ms）
以第一个接口为例：总共发起1000次请求，每次请求相加除以1000得到平均响应时间
最小值（ms）：
第一个接口最短为10ms；第二个接口最短为1ms，以此类推
最大值（ms）
第一个接口最长为115ms；第二个接口最长为15ms，以此类推
标准偏差
表示浮动大不大，也就是说：第一次请求、第二次请求等等响应时间的差距
异常%
接口请求出错的个数/总的请求数
吞吐量
每秒完成的请求数，从jmeter发出请求到服务端处理完请求返回到jmeter整个过程为1——》业务吞吐量
首页-点击热榜单个接口，系统最高能处理每秒28.6个请求
整个事务，系统最高能处理每秒19.2个请求
吞吐量不分tps和qps
tps：数据变更的场景
qps：数据查询的场景
接收KB/sec：
网络接收速度——》网络吞吐量
发送KB/sec：
网络发送速度——》网络吞吐量
平均字节数
网络吞吐量
b、梯度线程组
c、图形插件
三、用例执行过程
1、基准测试
场景1：线上服务器资源规划
性能基准：极少的并发去测试每一次用户操作需要占用的资源，以及性能指标
基准测试结果分析：
1024KB——》1MB
1024MB——> 1GB
接收KB/sec：3341.10KB/sec：意味着网络带宽有3M，那并发量能达到每秒40个请求
1、根据网络吞吐量（接收）- 如果服务器带宽不能支持每秒传输3M左右的数据，则服务器无法实现40/s吞吐量
2、一个线程模拟40个并发，想要模拟4000/s并发，理论需要100个线程模拟虚拟用户
2、负载测试
不断增加系统并发压力，直到系统达不到我们的性能要求
响应时间
吞吐量
资源占用
场景1：线上预计达到4000/s的并发，系统能不能抗住？
4000/s：性能需求分析时得到的。
梯度压测——》手法
注意事项：当负载测试的结果与预估的结果有出入，调整线程数
比如吞吐量，理论来说：系统的吞吐量曲线
a、吞吐量模型：
回顾银行小例子，把银行比作系统项目
银行有10个柜员窗口（窗口不会增加，原因是系统资源是有限的），每次处理一笔业务需要1秒
第一秒来了1个人，吞吐量为1
第二秒来了5个人，吞吐量为5
第三秒来了8个人，吞吐量为8
第四秒来了12个人，吞吐量为10
第五秒来了20个人，吞吐量为10，剩下的人在大厅等待排队第五秒来了20个人，第1s很快处理完毕，后面10个人需要等待1s才能处理完毕——》响应时间增加；吞吐量持平了。这并不说明系统出现问题了。
银行承诺3s内完成所有的请求，如果超过3s银行系统需要升级了。
综合上述：吞吐量持平，响应时间一定会增加
第一种可能
后续的人越多，导致银行没有地方站了——人挤满了，没有空气呼吸了
最终导致银行柜员没有空气呼吸了，晕倒1个，晕倒2个…10个，系统垮掉了。——》此处的空气、大厅都是系统资源。
第二种可能：
人达到一定的数量，银行保安直接关门，不允许继续进入
预期现象：
第一个阶段：并发量增加——》吞吐量也会增加
第二个阶段：并发量增加——》吞吐量持平不会增加，响应时间会变长
吞吐量不变，认为系统处理不过来了，新的请求会等待/积压（积压会占用资源，资源是有限的，不会无限的积压，最终会崩溃）
第三个阶段——崩溃：并发量增加——》
1、吞吐量下降，
系统不断积压请求，资源不够用
2、请求错误率提高
无法请求，请求超时
系统拒绝新请求
基准测试汇总报告
1个线程——》吞吐量为40/sec
想法：根据基准测试结果，负载测试时：响应时间应该和基准测试时一致，吞吐量翻倍。
负载测试汇总报告
60个线程——》吞吐量为134/sec，理论上40/sec*60，没有达到理想的点
结论：
接口变慢了
四、性能测试领域-细分概念
基准测试：收集系统在极低并发场景中的性能基线
基准测试线程数为什么是1？
对线程数要求：系统100%能够承载的情况下（可以是2，可以是10），1是最小的模拟单位</font>
负载测试：目的是为了发现程序系统的实际处理能力
负载测试线程数量
根据基准测试里面每个线程能够在每秒模拟多少次并发，例如基准测试中1个线程能够模拟40/s并发
目标：测试系统是否能够承载4000/s
初步线程数量=目标并发/单线程模拟并发数量
五、jmeter相关
表示1s启动100个线程去干活，运行1次
具体干活的内容为：
3个人干活3次，一共干了9次
这3个人是同时去干活的
循环次数：表示每个线程数要干活的次数
jmeter的执行顺序
1、对于同一个线程而言，http请求是有先后顺序的，先执行1任务再执行2任务
2、如果有3个线程同时干这2件任务，是没有顺序的。
可能线程1执行到任务2了，线程2才开始执行任务1
