性能测试场景

Posted 2023-04-27

参考技术A 提到性能测试，常会提到压力测试、负载测试、稳定性测试、配置测试等等，但说到其各自的定义，实在是晦涩难懂。但若将性能测试，看作是在不同的场景下执行系统，获取系统的性能指标，再对数据进行监控分析的过程，就比较好理解了。
性能测试场景可以分为四类。

RT

线程

从上面的图可以得到以下判断：

4.重复以上步骤测试每一个业务，得到结果表格

Q：业务目标TPS和响应时间怎么定？
A：方法一：找同行业对比数据。方法二：到生产环境看用户使用情况并统计信息

Q：怎么得到业务比例？
A：根据生产环境的请求统计信息

Q：测试时为什么要逐步增压？
A：保证在测试过程中资源分配的合理性，可以看到整体的变化过程，例如递增过程中会不会出现系统动荡，便于分析性能瓶颈。

混合场景下，业务的TPS并没有达到预期，此处应进行分析调优。

确定场景的运行时间长度的加压数
运行时长取决于系统上线后的运维周期。例如指标是稳定运行一周，支持100万业务量。之前容量TPS能达到168，所以时长应该是10000000/168=6250秒=1.8小时。

Q：为什么用最大容量TPS跑稳定性？
A：有的观点是用最大TPS的80%去跑稳定性。跑稳定性的目的就是看系统会不会因为长时间处理业务而引发潜在瓶颈。只要系统正常处理，资源没有出问题也没有报错，就可以用最大TPS去跑。

全网火爆，Jmeter性能场景设计 - 压力负载测试性能场景+分析性能指标

目录：导读

• • 前言
  • 一、Python编程入门到精通
  • 二、接口自动化项目实战
  • 三、Web自动化项目实战
  • 四、App自动化项目实战
  • 五、一线大厂简历
  • 六、测试开发DevOps体系
  • 七、常用自动化测试工具
  • 八、JMeter性能测试
  • 九、总结（尾部小惊喜）

---

前言

负载测试性能场景–阶梯式

回顾一下负载测试的概念： 负载测试是逐步增加并发用户数，找到性能拐点。 关键词是“逐步增加并发用户”。

那么要做到逐步增加，肯定不能使用普通的线程组，不然每次增加用户数都得手动改一次线程数，那得改到什么时候。

所以这里就需要用到插件：jpgc
使用插件管理器，找到jpgc - Standard Set 插件并安装

然后添加新的线程组，但这里不是再添加普通的线程组了，而是添加jp@gc - Stepping Thread Group (deprecated)

This group will start：线程组最大启动的用户数；
First，wait for：首次启动用户时，将等待多少秒后才开始启动；
Then start：首次启动多少个用户数；
Next，add; every：这是一个组合，意思是接下来每次启动N个用户后持续运行N秒。Next，add是指每次启动的用户数，every是指持续运行时间
using ramp-up：每次启动用户的时长，其实就是在多少秒内启动多少个用户数；
Then hold load for： 所有用户启动后持续运行N秒；
Finally, stop； every: 这也是一个组合，意思是每个N秒停止N个用户；

场景实战

接下来就是实战了，利用负载测试找到性能的拐点。

举例，现在不知道当前系统或接口的性能拐点在哪，那么可以设置：一开始运行10个用户，然后每运行1分钟后增加10个用户，直到增加到50个用户后持续运行120秒，最后每秒停止10个用户。

另外由于现在使用的是阶梯性能场景，这个场景下是无法用聚合报告的，因为聚合报告是要计算持续时间内的平均值，一旦并发用户数改变了，这个平均值就不准确了。

所以这里使用到另外的监听器

jp@gc - Active Threads Over Time： 随着时间变化的并发用户数

jp@gc - Response Times Over Time： 随着时间变化的响应时间图

jp@gc - Transactions per Second： 随着时间变化的TPS图

上面的三张图由于不像聚合报告有具体的平均值，所以在看的时候可能对平均值的把握不会太准确。

但这个其实影响并不大，首先从上面三张图片可以看出： 随着并发用户数的增加，响应时间也在增加，有很明显的上升趋势；

而TPS的图由于波动比较大，不好判断中心线在哪，但其实也可以发现随着并发用户数的增加，TPS的波动幅度会越来越大。

经上述结果，可以简单得到一个结论是，当前系统的性能拐点大约在20~40个并发用户之间。

这还没完，在实际工作中，如果得到一个范围值且范围值符合业务期望值时，最好是根据当前范围值继续压，尽可能找到粒度尽可能小的数值，范围值一旦过大，对未来的性能测试并不能做到一个参考标准，那这次的性能测试基本就是白费了。

如当前系统的拐点大约在20~40个并发用户之间，那么可以设置为：一开始运行20个并发用户，每隔60秒后启动5个并发用户，直到启动到40个并发用户后，持续运行120秒。

以此类推，尽可能找到粒度尽可能小的值，而这个值就是最大的并发用户数。

备注
负载测试场景使用的阶梯线程组有一个弊端，它每次增加的并发用户数总是相同的，然而实际情况中，我们的并发用户数是时刻发生变化的，也正因如此，上述的这个线程组后面是标识了“deprecated”，意思就是这个线程组已经不推荐使用了，因为它只能解决这种单一的性能测试。其它在后面会讲到解决这个问题。

另外，阶梯线程组设计的规律：
缓起步，快结束；因为突然间一瞬间大量请求发给服务器，服务器可能会崩，在做负载测试阶段并不推荐做这种测试，后面再讲这种瞬间大量请求的场景该怎么设计。

压力测试性能场景

压力测试的关键词是：长时间、稳定的。

压力测试的并发用户数有两种选择：
最大并发用户数的20%；
最大并发用户数的80%；

根据情况来选择即可。

接下来是关于场景的设置，压力测试的场景设置不限制使用线程组，因为通常情况下压力测试的并发用户数是不变的，因此用普通线程组还是阶梯线程组都可以完成。

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

懒惰是意志薄弱者的隐藏所。人的活动如果没有理想的鼓舞，就会变得空虚而渺小。告诉你一个宝藏的地点，它就在你的生命里。

要想改变命运，首先改变自己。今天的成功是因为昨天的积累，明天的成功则依赖于今天的努力。成功需要一个过程。命运掌握在自己手里，命运的好坏由自己去创造。

用鞭子抽着，陀螺才会旋转。成功需要付出代价，不成功需要付出更高的代价。宁可失败在你喜欢的事情上，也不要成功在你所憎恶的事情上。