Jmeter 在测试工作中,是一款(同postman)常用的接口测试工具,在测试工作任务中除了做简单的接口测试之外,时常也会同Loadrunner一样被选择用来做性能压力测试测试,
Jmeter做性能压力测试,在测试工作中,有几个层面可以来做压力, 一种是直接从业务层面,
直接用接口来做压力,看业务功能所能承受的压力 以及 性能; 另一种直接通过页面操作录制脚本,
整理优化脚本然后做压力测试。这两种方式都可以,工作中会灵活性的选择
那么我们在做压力测试的时候,我们会有那些考虑点,也是我们如何来设计自己的性能压力测试
那么我们在做压力测试的时候,我们会有那些考虑点,也是我们如何来设计自己的性能压力测试,考虑下测试环境有多少个服务器负载机,产品的使用群体的用户量预估有多少,性能指标大概在什么范围可以接受(如事物响应时间);用户量的并发改如何设置(200、500、800、1000这样梯度试的增长),根据业务我们在设置场景的时候可以考虑适当加入一些集合点,如果在单台电脑上运行压力测试不够,可以在多台同事电脑同时运行jmeter ,同步实施压测
那么OK,压测OK后,,我们如何判断这个功能模块是否有性能问题,我们的参考点在那?
参考点:
通过jmeter 工具在压测完毕后输出的结果分析报告,如:聚合报告(Aggregate Graph) 、概要报告(Summary Report),事物响应时间图(Response Time Graph)等;那么通过这些报告里的数据,我们能够清晰的了解到,事物响应时间的曲线图是否正常(是否会出现波动性跳跃),事物请求事物响应时间是否过长,吞吐量多少根据这些可以做一个综合性的判断
同时在压测的过程,我们还可以通过,监控服务器系统资源的使用情况,这个我们可以通过不同的命令,比如服务器是Linux系统,我们有很多命令 vmstat 、 uptime、top等,也可以用比如运维常用的系统资源监控可视化工具 grafana 或者 tomcat+probe这样的工具监控系统资源的使用情况。
结合之前讲的:
Jmeter(一)-使用http proxy代理录制脚本
https://blog.csdn.net/qq_21422005/article/details/84070584
Jmeter(二)变量参数化:
https://blog.csdn.net/qq_21422005/article/details/84070584
我们开始实际操作下,性能压力测试
1:脚本已录制完毕
2:脚本已初步整理(改删除的图片、js、css 加载请求都已删除)
3:性能压力测试,如登入模块,不希望用一个用户来做压测,所以可以做好
参数化变量(参数化变量已完毕)
有些模块功能如果需要大批量数据提供支撑,可在数据库写存储,调用存储
场景设置:
步骤1:
设置模拟用户并发数
步骤2:
参数化变量,给模拟的用户有数据循环选择
步骤3:
这个可根据需要灵活设置,可设置也可不设置 (上面设置10用户做一个集合)
步骤4:添加设置–事物响应时间图(Response Time Graph)、添加Summary Report 概要报告
步骤5:设置添加 聚合报告
场景设置基本完毕(根据需要可自己添加其他的一些设置)
1:打开自电脑的任务管理器
其实基本可以不打开,自己做性能压力测试的时候,运行的程序应该不会开很多,配置应该够用,保证工具能正常运行(所以这个基本可以略)
2:负载机,环境的服务器,性能压测的过程,监控负载机的系统资源使用情况
方法很多:
vmstat
top
还有其他命令
同时可以使用工具辅助查看
步骤6:运行性能压测
运行的过程查看下负载机的系统资源情况(某个时间点出现 内存、cup 、load使用很大的时候要做好标准分析,看是否有问题),可结合后面的jmeter运行报告一起分析
重要点,查看分析报告
1:概要报告 (Summary Report)
2:聚合报告
3:事物响应时间 (Response Time Graph)
波动性很大,事物响应时间瞬间拉高,而且前面可以看到,错误率也很大,重点分析这几个时间点的事物请求
a,结合工具反馈的负载机资源 这几个时间点的情况
b.日志信息查看,看是否有报错日志和具体情况
c.从结果树看写信息,如
看返回的错误信息
以上可以看出,性能有问题!
基本上就这样,后面就是对问题的处理,性能调优要整个部门的协同合作处理!
PS:其他知识点
数据库连接池查看:
命令:SHOW PROCESSLIST;
调优的东西还涉及很多,这里就不一 一列举
文章为做简单的个人理解和记录,不足之处,还恳请大家多多指出与指导~!!!