16-负载、压力、面向目标测试场景
负载测试场景
负载测试：逐步增加并发用户数，拐点区间
jmeter如何逐步增加并发用户数：
安装jpgc - Standard Set插件
在「测试计划」右键添加「线程」的时候可以发现多了很多项
选择「jp@gc - Stepping Thread Group (deprecated)」
x轴：时间
y轴：用户数
- This group will start 「100」 threads：将启动100个线程数
- First，wair for 「0」 seconds： 首先等待0秒
- Then start 「0」threads：然后 启动0个用户
- Next，add「10」 threads every 「30」seconds，using ramp-up 「5」 seconds：每5秒钟，增加10个线程数，然后运行30秒
- Then hold load for 「60」seconds：然后持续运行60秒
- Finally，stop「5」threads every 「1」 seconds：最后，没1秒停止5个线程数
缓起步，快结束
结束时间不能太短，也不能太长
- 太短：可能导致出错，这个出错是场景设计的问题，不是性能问题
- 太长：导致性能指标值与实际值偏差太大
如果330正常，在360出现异常，出现拐点区间。
所以拐点范围为[330,360]，通过缩小范围，找到拐点值
想要寻找某个接口的最大并发用户数，通过最大并发用户数，获取性能指标值？
- 设置一个阶梯线程组，自己设置一个最大值
- 运行，找到拐点值
- 缩小拐点区间，找到最大并发用户数
- 进行性能测试
如何找到拐点值
在添加插件后可以看到「监听器」中新增了部分内容
- Active Threads Over Time：随着时间变化的活跃线程数
- PerfMon Metrics Collecotr：性能监控器
- Response Times Over Time：随着时间变化的响应时间
- Transactions per Second：TPS
Active Threads Over Time
Response Times Over Time
Transactions per Second]
是否有报错
响应时间是否超过1.5s：用户满意度指数：500ms是可以接受，超过1.5s不能接受
tps 不上升，反而下降
响应时间+活跃线程数=>不同线程数时的平均响应时间
活跃线程数+TPS=>不同线程数的平均tps
注意：一般不会在一个线程组下挂载多个接口，因为 监听器图标中，会把所有接口数据合并在一个图标中，数据太多，不利于分析
压力测试场景
- 持续运行比较长时间，看服务器的稳定性
- 普通线程组：调度器持续运行时间，设置比较长
- 阶梯线程组：hold load时间设置比较长
面向目标的场景
需求：有一个页面，需要做性能测试。看能否支持一秒钟5000人访问
相当于：1秒钟要处理500人的请求事务=>500tps
一般的公司，接口tps范围数50～200
添加一个「bzm - Arrivals Thread Group」
