性能测试（二）

性能测试的方法

负载测试

在被测系统上持续不断的增加压力，直到性能指标(响应时间等)超过预定指标或者某种资源(CPU&内存)使用已达到饱和状态。核心是找到系统的处理极限，为系统调优提供数据，从而达到了解系统性能的容量。

负载测试的目的

1、验证服务被部署的系统出现资源瓶颈的时候，服务依然能够提供产品的特性。

2、找到系统的最大饱和状态，或者是最大的处理极限，为系统后续的容量规划提供参考的数据。

压力测试

该方法是指系统在一定饱和状态下，具体如CPU，内存等饱和使用的情况下，系统能够处理的会话能力，以及系统是否会出现错误，比如TimeOut,OOM，OverStackExpection（堆栈异常）。

压力测试的特点：

• 检查系统在处于压力情况下时应用的性能表现

• 等价于负载测试，使系统的资源处于一个瓶颈的状态（建议CPU和内存在75%以上）

• 这种方式一般用于测试系统的稳定性稳定性：指的是系统在最大的极限下，依然能够正常的访问，不会对客户造成任何的影响。

验收负载测试

在QA的环境模拟生产运行的业务压力和使用场景组合，测试系统的性能是否满足生产环境的性能诉求。

流量回放：获取生产环境的网络请求，拿到QA的环境执行。

配置测试

被测环境软硬件环境参数的调整，达到最优的分配原则。

JVM：CPU，内存

MySQL：连接数，超时参数

操作系统监控：CPU和内存使用率达到多少的时候触发报警机制。

达到一个好的系统的表现：服务在客户端高并发的情况下依然能够正常的为客户提供业务的能力和服务。

并发测试

死锁： A和B两个，为了保持线程同步，那么A操作B的时候，锁定B，B操作A的时候，锁定A。

高并发情况下：

1、线程同步

2、死锁

业务：文件读写的时候特别容易发生

模拟用户的并发访问，测试多用户并发访问同一个应用时是否存在死锁或者其他的问题，

并发测试的特点是：

• 发现系统中可能隐藏的并发访问（线程同步和死锁）的问题

• 关注系统可能存在的并发问题，如内存泄露，线程锁，资源争用（调度算法）情况

• 使用的测试工具如profiler等。

可靠性测试

给系统加载一定的业务压力，让应用持续运行一段时间，测试系统在这种条件下是否能稳定运行。

稳定性测试与可靠性测试区别：

稳定性测试指在客户端持续不断的发送请请求，测试系统在这种条件下是否能稳定运行；而可靠性测试指的是给系统加载一定的业务压力，让应用持续运行一段时间，测试系统在这种条件下是否能稳定运行。

性能测试实战

JMeter性能测试实战

JMeter执⾏原理

JMerer通过线程组来驱动多个(也可以理解为LR⼯具⾥⾯的虚拟⽤户)运⾏测试脚本对⽬标服务器发起⼤量的⽹络请求，在每个客户端上可以运⾏多个线程组，也就是说⼀个测试计划⾥⾯可以包含N个线程组。

场景设置

取样器错误后要执行的动作

继续

如果有⼀个请求错误，其他的请求会继续，不会因为有⼀个请求错误的导致其他请求终⽌。

启动下一个进程循环

如果请求出现问题，同⼀脚本中的其他请求就都不再执⾏，直接执⾏下⼀个进程的信息。如登录后下⼀个请求是查看个⼈主⻚，但是因为登录出错，下个接⼝查看个⼈主⻚就不会被执⾏。

停⽌线程

停⽌线程指的是如果请求失败，就停⽌当前线程执⾏，不再继续执⾏。如果线程数很多的，那么导致的结果是停⽌的线程就会很多，处于真正运⾏的线程会很少，最后导致服务器的负载不够，⼀般不建议勾选改选项。

停⽌测试

如果请求失败，那么停⽌所有线程执⾏，也就是说停⽌整个测试。

⽴即停⽌测试

如果请求失败，⽴即停⽌整个测试场景的执⾏。

线程属性

线程数

⼀个线程可以理解为对应模拟⼀个⽤户，所以线程数越多，那么也就认为可以模拟的⽤户数越多。

Ramp-Up时间(秒)

该属性指的是所有线程从启动到开始运⾏的时间间隔，单位是秒，也就是说所有线程在多⻓时间内开始执⾏，如线程数设置50，设置的时间为5秒，那么计算的公式为:

设置虚拟用户数是：1000，每秒并发50个用户

循环次数

循环次数可以理解为，请求的重复次数。如果选择“永远”，那么请求将⼀直进⾏（用于做稳定性测试），不建议这样操作。

调度器

所谓调度器可以理解为设置何时开始运⾏。

持续时间

测试计划持续多⻓时间

启动延迟

从当前时间延迟多⻓时间开始运⾏测试，也就是说点击执⾏后，仅仅是做初始化的场景，不会执⾏测试，等待延迟到达后开始运⾏测试，执⾏的时间为持续时间设置的时间。

Jmeter监听器

聚合报告

Label:取样器名称

Samples:取样器运⾏次数

Average:单个请求的平均响应时间

Median:50%请求的响应时间

90%Line:90%请求响应时间

95%Line:95%请求响应时间

99%Line:99%请求的响应时间

Min:请求的最⼩响应时间

Max:请求的最⼤响应时间

Std.Dev:响应时间的标准⽅差

Error%:事务错误率

Throughput:吞吐率，也就是TPS KB/sec:每秒数据包流量

Avg.Bytes:平均数据流量 Received KB/sec:每秒从服务器端接收到的数据量

SentKB/sec:每秒从客户端发送的请求的数量

测试场景：

1、总的虚拟用户数是50，每秒启动5个用户，并发测试50个用户（10秒加载完所有用户，然后同时执行）

线程组参数设置情况

查看结果树展示情况

聚合报告展示情况

2、总的虚拟用户数是100，Ramp-Up时间为12，并发测试50个用户（8秒加载完所有的用户，然后同时执行）

线程组参数设置情况

查看结果树展示情况

聚合报告展示情况

汇总报告

添加汇总报告

查看汇总报告

SD：标准偏差为您提供了一定程度的稳定性，但是，只需注意，标准偏差不会显示最慢和最快的响应，而是有助于识别响应趋势。

低标准偏差意味着系统内的性能更稳定或更一致。线程数（即虚拟用户数越多，标准偏差一般情况下较大，系统越不稳定；但是也存在线程数增大，标准偏差不是很大，但是吞吐量增加了的情况（即并发能力增强了，同时处理的任务数增多了））

响应时间图

添加响应时间图

线程组参数设置情况

查看响应时间图结果

后端监听器

JMeter里面使用后端监听器，结合influxdb的时序数据库以及grafana可以打造性能测试的平台后端监听器：把JMeter执行过程中的数据写到influxDB的时序数据库 influxDB：时序数据库，用来存储JMeter发送请求的数据 Grafana：从influx DB获取数据，展示在Grafana的平台上

添加后端监听器