性能测试基本概念
性能测试
性能测试工具：
1.并发用户数
就是模拟每秒多少人同时操作系统，当前，未来三年，极大值【卡死，但只要停掉系统就可恢复】
2.高峰周期
在哪个时间段访问系统用户数量最多（与项目团队评估）
3.场景
正确使用场景，模拟用户真实操作，每个测试场景就是一个用例
4.协议和请求
性能测试都是走协议的，创建HTTP请求，用Fidder抓包，将脚本导入Jmeter
5.为了场景正确，要关联和参数化
6.事务控制器
把请求结合到一起，看响应时间
7.事物成功率
看错误率和添加断言
8.汇总报告和聚合报告
（看平均事物响应时间，90%响应时间（90%的用户同时操作的响应时间），错误率（低于0.01%）），汇总报告看平均时间，与聚合报告内容有点不同，没有90%、95%、99%等响应时间
9.nmon资源监控
a.在Linux系统下操作，主要看CPU，不能长时间超过90%，短时间都行（低于85%），就算可以
b.看内存空闲，跑程序时还剩多少内存，一般剩个10%勉强接受，跑完程序会释放，如果没释放叫内存泄露，有新的请求过来，查看内存，内存越来越少，直到崩掉，证明内存泄露了
c.看磁盘IO，有读有写就行，过程中有空闲就行
d.网络低于50%，占用的网络低于50%就还可以
性能测试概念：
1.并发用户数
每秒多少人同时操作系统
2.在线用户数
就是当前时间访问系统的用户数
3.系统用户数
系统注册用户数，说大一点就是访问过系统的用户数
4.性能测试
以性能预期目标为前提，对系统不断增加压力，验证系统是否能正确处理
5.负载测试
不断增加压力，在不同负载用户数量下，验证系统是否正确，一般为当前负载数量，后一年的负载数量（老板告知预计增长用户数量百分比）及未来负载
6.压力测试
在系统超过预期负载时，能顶住的最大压力
7.并发测试
模拟用户同时进行操作，Jmeter中要做到绝对并发，添加一个同步定时器（例如秒杀）
8.稳定性测试
模拟多个用户同时操作系统，查看异常率，异常率越低，稳定性越强
9.可靠性测试
用户同时操作系统，加长Jmeter中线程组的持续时间，查看不引起系统失效的概率
10.响应时间
用户发送请求到服务器返回结果的整个过程的时间
11.事务成功率
如果事物失败，返回的响应时间是假的，没意义，所以需要在请求下添加断言，保证事务正确，一般异常率不超过0.01%
12.TPS每秒事务数
服务器每秒钟处理的事务个数
13.HPS每秒点击数
每秒请求的数量
14.性能测试模型
可以理解为不同的用例，也就是不同的使用场景
15.加压方式
可以理解为线程数，Ramp-up及持续时间的不同组合方式
16.拐点、瓶颈
拐点就是性能报告图表中的数据突然上升、下降或趋于平稳的点，可以利用拐点来做测试分析和定位
瓶颈就是限制系统性能的关键因素，通过监控器查看导致使用场景响应时间增加的有问题的区域
17.吞吐量
服务器每秒处理请求的个数，一般可看出是否有网络瓶颈问题
性能测试核心解决的三个问题：
1.并发用户数如何获取（也就是性能需求分析如何做）
2.性能测试场景如何模拟（抓包和使用Jmeter录制脚本）
3.结果检查和性能问题分析
性能测试用例怎么写
就是根据性能需求文档，在Jmeter中录制脚本，设置测试场景，为了保证场景正确，需要做关联和参数化，不同的并发数测试场景就是一个用例，比如负载测试，一般采用阶梯式的并发数，当前所支持的并发用户数，三年后可支持的并发数，那这两个就都是性能测试用例，或者组合场景，用户做不同操作，设置测试场景并发数，执行脚本，这也是一个用例
性能测试方案（解决怎么做性能测试）
1.做什么？（测试内容说明，测试的环境说明）
2.需求是什么？（并发用户数的计算过程）
3.场景说明：（Jmeter中多种不同的设置会产生多种不同的测试方法，相当于性能测试的测试用例）
4.结果检查项：指标说明，指标的参考标准
5.用例（就是把Jmeter中的操作全部结合起来，就是用例）
JMeter中性能报告图表名词解释：
Active Threads Over Time：随时间变化的活动线程
Bytes Throughput Over Time：随时间变化的字节吞吐量
Connect Times Over Time：连接时间随时间变化
Hits per Second：达到每秒、每秒点击次数
Response Codes per Second：每秒响应码
Response Latencies Over Time：响应延迟时间
Response Times Over Time：响应时间
Transactions per Second：每秒事务数、事务处理速率 、每秒处理事项数
怎么算并发用户数
假设某电商平台，用户数量为20万，高峰时段为15分钟，一般采用2-8原则，80%的用户在20%的时间内完成操作，20万x80%=16万人，15分x20%=3分钟，3分钟就是180秒，16万/180秒=889人/秒，并发用户就是每秒889人
怎么定位系统问题
一般查看测试报告中，CPU使用情况：系统占用CPU低于85%就还可以，长时间占用超过90%就不行
内存使用情况：内存一般剩余10%勉强接受，超过则说明不行，还要注意看内存有没有被释放，就是看内存最后是不是呈下降趋势
磁盘情况：一般有读有写，有忙有空闲就没问题
查看响应时间：一般采用2-5-8定律（2秒以内很好，2-5秒还不错，5-8）
看每秒事务数、每秒点击数、吞吐量、每秒连接数：这几个都是相关的，一个有问题，其他几个一定有问题，走向有高有低，中间如果有大量空闲则说明服务器在那个空闲时间段没有处理请求，系统可能是卡死状态
50个用户和80个用户的测试报告是如何发现性能瓶颈的
首先50个用户并发，平均事务响应时间中服务器有3分钟没有响应，每秒事务数有两段1分钟服务器没有处理事务，接下来的每秒点击次数、吞吐量情况、连接数情况、每秒连接数量多个报表都指向同一个问题，出现两段没有请求或处理，说明系统遭遇长时间卡死
其实从50个并发用户数就可以看出系统性能已经有问题了，到80个并发用户数可想而知必出问题，平均事务响应时间报表可以看出服务器长时间没有响应，相应的每秒事务数、每秒点击次数、吞吐量情况、连接数情况服务器都出现相同三段长时间没有请求或处理，说明到80个并发用户，性能不能通过
性能测试是怎么做的
性能测试是怎么做的
1.拿到性能需求文档后，根据性能需求和业务主流程进行性能场景分析（算并发数或者组合场景）
2.编写性能需求方案
3.开发性能测试脚本，通过Fidder抓包，导入Jmeter脚本
4.主要脚本功能实现后，对脚本进性关联，参数化
5.脚本准备完成后，使用Jmeter执行，进行性能测试，收集性能数据及监控性能资源
6.测试完成后，对结果进行分析，如果不符合预期，交给开发进行调试，并回归测试，直到达到预期性能
7.测试结果通过后，编写性能测试报告
