性能测试和Jmeter
文章目录
- 前言
- 性能测试理论知识
- 什么是性能?
- 什么是性能测试?
- 性能测试的作用
- 性能测试与功能测试的区别
- 性能测试常见术语
- 性能测试的策略
- 基准测试
- 负载测试
- 稳定性测试
- 压力测试
- 并发测试
- 常见性能测试指标
- 响应时间
- 并发数
- 吞吐量
- 点击数和错误率
- 资源使用率
- 性能测试的流程
- Jmeter模拟性能测试
- Jmeter组件
- 事务控制器
- 聚合报告
- 第三方插件PerfMon(仅作参考)
- 压力测试场景(仅供参考)
- 并发测试场景
- 补充:Jmeter生成测试报告
- 性能分析和调优
- 服务器资源瓶颈
- CPU
- 内存
- 磁盘IO
- 网络
- 数据库瓶颈
- 慢查询
- 数据库连接池
- 数据库锁
- JVM内存瓶颈
- 压测机瓶颈
- 参考目录
前言
阅读本文前请注意最后编辑时间,文章内容可能与目前最新的技术发展情况相去甚远。欢迎各位评论与私信,指出错误或是进行交流等。
性能测试理论知识
什么是性能?
通俗的讲, 时间特性指的就是软件系统处理用户请求的响应时间。资源特性指的是在软件系统运行过程中,系统资源的消耗情况。系统资源大致包括:CPU、内存、磁盘IO等
什么是性能测试?
性能测试就是测试人员借助性能测试工具,模拟系统在不同场景下,对系统的各项性能指标进行测试。
以电商软件为例,系统会出现以下常见场景:
- 日常在线用户500万(稳定运行情况下)
- 双11当天,在线用户3亿(超大量用户)
- 双11零点,有一千万用户同时秒杀抢购(大量用户同时使用)
性能测试的作用
- 系统上线时, 评估系统能力
- 系统上线后, 寻找性能瓶颈, 优化性能
- 评估软件能否满足未来的需要
性能测试与功能测试的区别
功能测试:
功能测试主要关注系统是否按照需求规格说明书中定义的功能进行正常运行,并符合用户的期望。其目的是验证软件的有效性或正确性,即确认软件在各种输入情况下能够按照业务逻辑正确地处理数据,并产生预期的输出结果。
性能测试:
性能测试主要关注系统在不同负载和压力下的表现和响应能力。它通过模拟实际使用场景或特定负载情况,评估系统的性能指标,例如响应时间、吞吐量、并发用户数等。性能测试的目的是评估系统的效率、可靠性和可扩展性,确保系统能够在预期的负载下稳定运行。
测试方法:
功能测试通常采用黑盒测试方法,测试人员基于需求规格说明书或用户需求进行测试,验证软件是否满足特定功能要求。
性能测试通常采用白盒测试方法,测试人员需要了解系统的内部机制和架构,并使用性能测试工具进行负载模拟和性能指标的监测与分析。
一般是功能测试通过之后做性能测试。
性能测试常见术语
-
并发:并发就是大量用户在同一时间访问同一系统。
业务层面的并发用户数:指的是同时向服务器发送请求的用户数量。
后端服务器层面的并发用户数:指的是同时向服务器发送请求的请求数量。 -
用户数
系统用户数:系统注册的用户
在线用户数:成功登陆系统用户数
并发用户数:同时使用系统的用户数量。
性能测试的策略
基准测试
基准测试狭义上又称单用户测试 ,当性能测试环境确定后,通常选取业务模型中的重要业务做基准测试,对被测系统施加⼀定压力,从而获取被测系统在单用户运行情况下的各项性能指标,并作为后续性能优化和比较、多用户并发测试和混合场景测试等的参考依据。
广义上讲, 基准测试是一种评估软件性能指标的活动。通过基准测试确定系统的性能基准线,当系统的软硬件发生变化后再进行测试,对比基准线来确定变化对性能的影响。
负载测试
负载测试通过逐步加载的方式,确定在满足系统性能指标的情况下,找出系统所能够承受的最大负载量的测试。
负载测试类似于举重运动,通过不断给运动员增加重量,确定运动员在其身体状况保持正常的情况下所能举起的最大重量。
例如,⼀个软件系统的响应时间要求不超过2秒,如果在这个前提下不断增加用户访问量,系统的响应时间就会变长。假设当访问量超过1万⼈时系统的响应时间超过2秒,那么就可以确定在系统响应时间不超过2秒的前提下,系统的最大负载量是1万⼈。
稳定性测试
稳定性测试是在服务器稳定运行(日常使用的业务负载)的情况下进行长时间测试,并保证服务器能满足业务需求。
场景一: 实际测试的最大负载达不到用户正常使用的15人,那么就说明设计不合理,不进行稳定性测试。 类比到软件上就应该回去检查代码是否出现了BUG、或者设计不合理等情况。
场景二:稳定运行的负载量为10。 要根据需求进行设定, 稳定性测试并不是在最大负载情况下进行长时间测试。
压力测试
压力测试用于评估被测系统在高于预期、高于指定容量负载需求或低于最少需求资源的条件下,查看系统是否有良好的容错能力和可恢复能力。
进行压力测试时通常采用逐步增加系统负载的方式,使系统某些资源达到饱和甚至失效,从而发现那些只有在高负载条件下才会出现的缺陷,如同步问题、内存泄漏等。
通过对被测系统进行压力测试,也能找出被测系统的性能拐点,获得系统所能提供的最大服务级别(系统所能承受的最大压力),评估系统在峰值负载或超出最大负载情况下的处理能力。
压力测试的方式:
如上图所示,随着用户数(负载)的逐步上升, 系统资源、吞吐量、系统响应时间的变化。
在A-B区间,随着系统用户数的增加,系统的处理能力会增大。(低负载区)
在B-C区间,随着系统用户数的增加,系统的处理能力基本不变。(高负载区)
在C-D区间,随着系统用户数的增加,系统的处理能力减小。(崩溃区)
压力测试和负载测试的区别:
负载测试是在保持性能指标要求的前提下测试系统能够承受的最大负载。
压力测试则是测试系统性能达到极限的状态。
例如,软件系统要求的响应时间不超过2秒。进行负载测试时发现,当访问量达到1万时,系统响应时间不超过2秒,而当访问量超过1万时,系统响应时间则会超过2秒。
负载测试: 在满足系统响应时间指标的前提下,该系统能够承受的最大访问量是1万。
压力测试 :继续增加系统的访问量,并观察系统的性能变化。例如,当系统访问量增加到2万时,发现系统响应时间延迟到5秒,当访问量增加到3万时,系统崩溃,⽆法做出响应。由此可以确定系统能达到的极限访问量是3万
并发测试
并发测试用于评估被测系统的某些操作同时发生时的性能表现.。
例如,测试系统多个用户同时登录时的响应能力,或系统的某⼀功能被多个用户同时操作时的性能表现。
例如,通过模拟多个用户同时访问某⼀条件数据,或模拟多个用户同时更新数据,可能发现系统的数据库访问错误、写⼊错误等。
常见性能测试指标
响应时间
响应时间(Response Time),是指用户从客户端发起一个请求开始,到客户端接收到从服务器端返回的结果,整个过程所耗费的时间。不包括前端页面的处理和渲染时间。直观上看,这个指标与人对软件性能的主观感受是非常一致的,因为它完整地记录了整个计算机系统处理请求的时间。
并发数
并发数:某一时刻同时向服务器发送请求的用户数
吞吐量
吞吐量:指系统在单位时间内处理请求的数量。
从业务角度看:业务数/小时、业务数/天、页面访问量/天、访问人数/天
从网络角度看:字节数/天、字节数/小时
从技术角度看
吞吐量的表现形式有TPS和QPS:
QPS(Query per Second)每秒查询数:即服务器每秒处理的请求数量。
TPS(Transactions per Second)每秒事务数:服务器每秒处理的事务请求的数量。
事务:即业务,一次操作可能会产生多个请求,这一次操作称为一次事务。
页面上的一次支付操作会有三个请求,这一次操作称为事务。QPS=TPS*n个请求,此处为45
点击数和错误率
点击数:客户端向服务器发送请求时,所有的请求总数量。点击数不是指页面上的一次点击,包括页面资源元素(图片、链接、CSS、JS等)的请求总数量。
点击量:一般指用户点击数量
错误率:系统在负载情况下,失败业务的概率。错误率=(失败业务/总业务数)*100%
- 绝大多数系统要求错误率接近于0
- 错误率是性能测试的指标,是由于高负载导致的错误,而不是代码BUG导致的。
资源使用率
性能测试的流程
-
需求分析:熟悉系统的业务功能和技术架构。了解系统的用户需求和预期负载,明确性能测试的目标和内容。
-
制定测试计划:制定详细的测试计划,包括测试用例、测试数据和测试时间表。明确每个测试场景的输入、操作步骤和预期输出。关于测试计划的格式,可自行查阅资料
-
测试用例设计,关于测试用例的格式,可自行查阅资料
-
搭建测试环境:搭建与生产环境相似的测试环境,包括服务器、数据库、缓存等组件的设置和配置。确保测试环境能够支持预期的负载和数据量。
-
编写测试脚本、执行性能测试脚本
-
收集性能数据:收集性能测试期间产生的数据,包括日志、性能指标记录等,用于后续的分析和评估。
-
分析测试结果:根据收集到的性能数据,进行性能分析,找出性能瓶颈、潜在问题以及系统的弱点,并提出优化建议。
-
撰写测试报告:总结性能测试的结果和分析,撰写测试报告,包括测试过程、测试结果、性能问题和优化建议等内容。关于测试报告的格式,可自行查阅资料
-
优化和改进:根据测试报告中的性能问题和优化建议,对系统进行优化和改进,如代码优化、数据库调优、服务器配置调整等。
-
再次测试:在优化和改进后,再次进行性能测试,检验优化效果,确保系统在实际负载下的性能能够满足要求。
Jmeter模拟性能测试
Jmeter的基本操作请看另外一篇博客,或自行查阅自行、查看Jmeter自带文档。除另外一篇博客外,在此再介绍一些Jmeter组件用于性能测试。
Jmeter组件
事务控制器
作用:将多个请求汇总成一个事务,易于查看整个事务的性能指标。
位置:线程组->右键->添加->逻辑控制器->事务控制器
如果,电商网站整个下单业务包括登录、加入购物车、结算、下订单的操作,如果我们想收集整个业务的性能指标,就需要用到事务控制器。
聚合报告
作用:收集性能测试中, 系统的各项性能指标。如:响应时间、吞吐量、错误率等。
位置:测试计划->右键->添加->监听器->聚合报告
第三方插件PerfMon(仅作参考)
作用:监控系统的资源指标(CPU、内存、磁盘IO、网络)
操作步骤:
-
下载Jmeter插件管理工具jar包 jmeter-plugins.org
jmeter-plugins.org
-
将下载好的插件管理工具jar包 jmeter-plugins.org 放到Jmeter文件夹lib\ext目录下
-
重启Jmeter,在选项下面可以看到插件管理器
-
打开 Plugins Manager
-
选择Available Plugins
-
搜索 PerfMon插件 勾选
-
点击右下角安装按钮
PerfMon组件添加方法:线程组->监听器->jp@gc - PerfMon Metrics Collector
PerfMon组件工作原理:需要在服务器端安装资源监听服务程序,启动并收集资源指标,使用PerfMon汇总资源指标并展示。
随后,我们要对jp@gc - PerfMon Metrics Collector进行配置,才能接收到服务端的资源指标信息。
压力测试场景(仅供参考)
假设有一个电商网站的性能需求如下(具体性能指标仅作演示),峰值场景(高负载场景)相比于日常场景下的下订单业务,对TPS和响应时间要求不同,我们要对峰值场景(高负载场景)进行性能测试,该如何进行呢?
按照压力测试策略的设计方案,我们进行如下测试步骤。
Jmeter脚本大致设计
- 添加线程组
- 添加事务控制器
- 在事务控制器下添加HTTP请求-登录,我们要测试整个下单业务的性能指标,所以使用事务控制器
- 在事务控制器下添加HTTP请求-添加购物车
- 在事务控制器下添加HTTP请求-结算
- 在事务控制器下添加HTTP请求-下订单
- HTTP请求-下订单下添加常数吞吐量定时器,由于高负载场景下的吞吐量为50,在逐步增加负载的情况下,最后将吞吐量设为50。
- 添加聚合报告和jp@gc - PerfMon Metrics Collector
- 执行,通过聚合报告和PerfMon查看性能指标
并发测试场景
Jmeter脚本大致设计
- 添加线程组,线程数设为50
- 添加HTTP请求-下订单, 秒杀活动肯定是已经提前完成了登录、物品加入购物车等操作。
- 测试数据提前准备
- HTTP请求-下订单下添加同步定时器,用于模拟50个用户同时发送请求。
- 添加聚合报告和jp@gc - PerfMon Metrics Collector
- 执行,通过聚合报告和PerfMon查看性能指标
补充:Jmeter生成测试报告
性能分析和调优
服务器资源瓶颈
CPU
内存
磁盘IO
网络
数据库瓶颈
慢查询
数据库连接池
数据库锁
JVM内存瓶颈
使用jvisualvm监控JVM内存
jvisualvm本地监控与远程监控
压测机瓶颈
参考目录
https://www.bilibili.com/video/BV12Q4y1C7Wf
https://www.bilibili.com/video/BV19Q4y167Qo/
https://www.bilibili.com/video/BV12W4y197qU
https://blog.csdn.net/2201_76100073/article/details/138165025
https://blog.csdn.net/weixin_55807049/article/details/141757657
https://blog.csdn.net/cs888zsy/article/details/144588686