能力验证：乙方通过性能测试向甲方证明自己所陈述的能力，出具报告
瓶颈分析：能力验证过程中发现性能瓶颈，找到性能问题
性能调优：针对发现的性能瓶颈和问题做调优
容量规划：着眼于未来。为将来可能出现的用户暴增做提前规划
测什么：了解性能需求，了解项目架构，了解业务内容
怎么测：用例设计，方案设计，场景设计，脚本设计运行
对不对：数据整理，需求对比，经验判断
了解性能需求
了解项目组织架构（mysql+nginx+tomcat+java....）
熟悉业务流程
设计用例和方案（并发数设计，测试场景设计）
准备测试数据（csv 参数化，jdbc...）
设计测试脚本（线程组设计，参数化，业务关联，断言）
运行观察脚本，获取性能数据（监听器，非 gui 的 html 报告...）
性能瓶颈分析（tps 衰减，响应时间异常，超时，内存泄漏）
性能调优（cpu 调优，内存调优，磁盘调优，网络调优...）
性能测试回归（直到测试结果满足需求）
出具测试报告
持续监听（grafana+influxdb）
并发测试
多线程在单位时间内同时发起单次请求，观察响应时间（注意集合点）
负载测试
持续不断的增加压力（并发用户/每秒请求），观察 tps 和响应时间的变化趋势，找到瓶颈点（性能衰减点）
基准测试
基准并发
基准负载
用并发基准点做一次简单的脚本测试，得到一个基线，为下一次的回归做理论依据
压力测试
稳定性压力测试
脚本以最大压力的 80% 做持续运行（1h，1d，1w）
破坏性压力测试
不考虑服务器的稳定性，直接以极限压力测试，目的是破坏服务器，直接找到异常（内存溢出，超时）
失效恢复测试
系统在出现异常之后，能否及时恢复
rps：request/persecond 每秒请求
tps：transaction/persecond 每秒传输（每秒处理）
rps 是可变的，不论是并发用户还是单位请求数，都会影响到 rps
tps 是有最大值的，衡量了服务器的性能瓶颈。tps 到达瓶颈点之后，就会出现性能衰减
瓶颈点之前：rps 增加，tps 也增加
瓶颈点之后：rps 增加，tps 不变或者下降
压力测试都是通过不断地调整 rps（增加并发，增加请求），测试 tps
基于协议：http，udp，ftp
多线程：模拟并发用户，设计压力值
场景设计：模拟用户的真实使用场景，获取准确的性能数据
核心工作原理：基于各种协议，通过多线程的方式，模拟各种用户场景去施压服务器，获取性能测试结果
Ramp up：线程延迟启动，让瞬时压力不是特别大
delay：延迟分配内存
ramp+delay=延迟分配线程内存
同 7
tcp 在传输层
应用 会话 表示 传输 网络 接口 物理
三次握手和四次挥手
线程启动是有时间的，所以请求并不是在同一时间发起
集合点的作用就是保证线程全部集合完毕，同时发起请求
强制等待：超时时间=0，一定会等到所有线程集合完毕再发起请求
隐式等待：超时时间!=0，在超时时间范围内，无论集合了多少线程都会优先发起
关联：让业务上下游衔接起来
比如新增 - 修改 - 删除
再比如：登录 - 后续请求
正则关联，json 关联，jdbc 关联，登录关联，xpath 关联，css 关联
TPS
HPS
RT
ERRROR
VU
抓包的时候可能会抓到很多静态资源，需要过滤掉
包含模式：.+(port).+
50%<sy+us<80%
首屏时间
脚本加载时间
帧率：一帧需要花费的时间，或者每秒有多少帧（fps）
持续不断的增加压力值（并发用户或者单位请求）
并发用户模型：阶梯加压线程组
单位请求模型：rps 定时器（基于最大线程范围内的 rps）
先确定并发用户数，假设 1000
准备用户数据（涉及 csv 参数化）
100 并发，加集合点
200 并发，加集合点
500 并发，加集合点
。。。
观察响应时间的变化趋势
基于 1000 并发的负载测试
观察 cpu 和内存的变化趋势
让登录并发和后续请求的并发保持关联性，同时又不影响后续的性能
保存登录的 session 数据（存本地或者存系统属性）。后续请求可以并发直接读取 session
为了数据的合理性，用户数据都会经过数据库。绕开数据库就会忽视掉一部分性能问题
latency：响应延迟
connect time：网络连接
服务处理时间
latency=网络时间 + 服务处理时间
剖析性能问题存在于网络还是服务端
out of memory ：内存溢出 调整 jvm，gc 频率
connect timeout：连接超时
port aready use：端口占用
jmeter 线程阻塞：调整本机的 java 内存
tps 波动剧烈：内存，cpu，磁盘都有可能
网络 IO 过多：数据包过多，分片过多
