16-负载、压力、面向目标测试场景

负载测试场景

负载测试：逐步增加并发用户数，拐点区间

jmeter如何逐步增加并发用户数：

安装jpgc - Standard Set插件

jpgc

在「测试计划」右键添加「线程」的时候可以发现多了很多项

线程

选择「jp@gc - Stepping Thread Group (deprecated)」

jp@gc - Stepping Thread Group (deprecated)

x轴：时间

y轴：用户数

配置

1. This group will start 「100」 threads：将启动100个线程数
2. First，wair for 「0」 seconds：首先等待0秒
3. Then start 「0」threads：然后 启动0个用户
4. Next，add「10」 threads every 「30」seconds，using ramp-up 「5」 seconds：每5秒钟，增加10个线程数，然后运行30秒
5. Then hold load for 「60」seconds：然后持续运行60秒
6. Finally，stop「5」threads every 「1」 seconds：最后，没1秒停止5个线程数

图讲解

缓起步，快结束

结束时间不能太短，也不能太长

• 太短：可能导致出错，这个出错是场景设计的问题，不是性能问题
• 太长：导致性能指标值与实际值偏差太大

如果330正常，在360出现异常，出现拐点区间。

所以拐点范围为[330,360]，通过缩小范围，找到拐点值

寻找拐点

寻找拐点

想要寻找某个接口的最大并发用户数，通过最大并发用户数，获取性能指标值？

1. 设置一个阶梯线程组，自己设置一个最大值
2. 运行，找到拐点值
3. 缩小拐点区间，找到最大并发用户数
4. 进行性能测试

如何找到拐点值

在添加插件后可以看到「监听器」中新增了部分内容

监听器

• Active Threads Over Time：随着时间变化的活跃线程数
• PerfMon Metrics Collecotr：性能监控器
• Response Times Over Time：随着时间变化的响应时间
• Transactions per Second：TPS

线程组

Active Threads Over Time

Active Threads Over Time

Response Times Over Time

Response Times Over Time

Transactions per Second]

Transactions per Second

1. 是否有报错
2. 响应时间是否超过1.5s：用户满意度指数：500ms是可以接受，超过1.5s不能接受
3. tps 不上升，反而下降

响应时间+活跃线程数=>不同线程数时的平均响应时间

活跃线程数+TPS=>不同线程数的平均tps

注意：一般不会在一个线程组下挂载多个接口，因为 监听器图标中，会把所有接口数据合并在一个图标中，数据太多，不利于分析

多个接口

压力测试场景

• 持续运行比较长时间，看服务器的稳定性
• 普通线程组：调度器持续运行时间，设置比较长
• 阶梯线程组：hold load时间设置比较长

hold load

面向目标的场景

需求：有一个页面，需要做性能测试。看能否支持一秒钟5000人访问

相当于：1秒钟要处理500人的请求事务=>500tps

一般的公司，接口tps范围数50～200

添加一个「bzm - Arrivals Thread Group」

bzm - Arrivals Thread Group