六、性能测试流程(如何做性能测试?)
根据学习全栈测试博主的课程做的笔记
1、前期准备–
项目初期就开始,业务需求评审时尽量参与,对业务更深刻的认识(确定哪些是核心业务、哪些可能存在并发请求、确定什么地方会出现瓶颈,方便后续性能需求评审时给出建设性建议)
2、性能需求分析、评审(确定性能测试的范围、性能测试的目标是多少)
2.1、确定范围:哪些业务接口
使用多的、核心业务功能
2.2、目标:tps、rt、成功率、资源利用率等
2.3、补充
2.3.1关于需求来源(项目组一起定性能目标)
2.3.1.1迭代项目
1)范围
新增、修改、受影响的功能也是需要放在压测范围内
2)目标
不能低于之前版本的性能
还需要进行容量评估,根据历史数据的请求数据进行统计月增长率是多少
比如现在要做一个容量预估:可以根据增长率(业务、用户增长的情况)预估tps达到多少未来才能满足业务需求,就可以做容量预估
3)业务比例:类似ELK的日志平台来统计
从生产上统计接口的业务比例(其实就是单接口的比例)
这只是统计出接口的比例,但是需要转换成业务比例,评审时就需要将业务比例获取到,最后在jmeter设计场景时要用到。
2.3.2新项目
1)范围:核心业务功能
2)目标值:参考竞品、经验值(产品经理)
若是迭代项目可以和之前的版本性能做对比,也可以通过生产环境的统计日志获得容量tps,新项目就是参考竞品和产品经理的经验。
3)补充:①业务比例(项目组谈论、项目运行后统计)②要测出最大容量Tps,为上线后限流提供参考
迭代项目的业务比例是可以通过类似ELK日志平台拉取数据,看一下压测时间范围内各个接口请求的压测业务比例历史数据统计,新项目没有历史数据,怎么解决?
这种新项目的业务比例只能是项目组进行讨论(不好定的情况,最简单的就是1:1或者就是项目试运行后数据统计比例,少量用户和大量用户使用的tps有差异,业务比例的1偏差不是太大。
对于新项目,一定需要测出最大容量tps,为上线后限流进行提供参考。
3、制定性能测试方案(为后续工作进行指导)
方案很重要(设计相关的、数据的设计、场景的设计、监控的设计等)
3.1、项目背景
描述项目做什么、核心业务什么、出现什么问题,系统架构(用到什么技术栈)
1)背景描述
2)系统架构
了解系统架构、用到什么技术栈、接口的的数据流向、经过了哪些技术栈,才能为后续设计监控提供参考(才知道去监控哪些服务)
3)压测目的
解决当前什么性能问题、还需要测试出系统的最大容量tps(为上线后续的保证服务不挂、限流等)
3.2、术语说明(主要为了避免理解偏差)
1)tps
2)rt
3)并发
4)业务比例
5)单场景
6)容量场景(混合场景)
7)稳定性场景
3.3、测试范围、目标
1)要压测的接口清单以及业务比例
2)各个场景的目标:tps、rt、成功率等
3.4、测试资源
1)人力资源(组织架构)
项目经理(协调压测需要的资源)
性能测试工程师(编写性能测试方案、性能测试脚本、设计压测场景、执行压测、收集监控数据、编写测试报告等)
开发工程师(开发需要配合性能测试进行打对应的压测分支、做性能分析、做性能优化)
运维工程师(配合性能测试部署压测测试环境、协助性能部署测试监控)
2)压测工具(主要是压力端的工具)
jmeter还是loadrunner
压力机(window、linux)
如果对性能要求不高,用window压力机即可,一般用的是linux
3)压测环境:
硬件、软件、部署描述清楚
3.5、压测设计(最重要)
1)数据设计
①参数化数据—数据量–根据业务来
唯一性:tps500,压测时间600s,至少需要30000数据量乘以20%,
非唯一性:tps500,也是时间600s,至少覆盖线上时间被使用到的
如:注册要用不同的用户名,系统要求用户名是唯一,就需要准备不同用户名。
模拟不同的真实用户,发送请求。
参数化数据设计多少?得根据业务来,对数据有唯一性。
若要求tps=500,压测时间10分钟,600s,至少需要30000数据量,但是压力端在发送请求时,不是轮流发请求,假设起了200个线程,jmeter线程关系之间也是有竞争关系,也是要去争夺cpu的执行权限。如果获得cpu的执行权限,就将请求发送出去,可能有的线程获得cpu执行权限多一点,发的请求数也会多,jmeter数据量把,一部分数据分成线程1,线程2,线程3,获得cpu的执行权限不一样,为了避免发的请求更多数据量不够,再算出的数据量再乘以20%或者更多
对数据若没有唯一性。如查询商品,a\bc都可以查询到电脑,商品表有10万个商品,数据量应该设置多少?假设tps=500,压测时间10分钟,600s,至少需要30000数据量,商品表里有10万数据,可以直接用,也可以直接统计线上某一段时间内哪些商品被搜索,再进行参数化,需要与线上覆盖到(实际被使用到的数据)
参数化唯一性数据需要自己造
非唯一性数据在库里存在,若想所有数据都需要参数化数据导出,若想拿某一些热点数据进行参数化,就需要统计线上日志。
②数据库存量
数据库里各个表都存有数据,测时的数据库量级与生产一致,方便复现线上回归压测复现问题,变量太多,尽量保持与生产一致(数据量级、环境差异、软硬配置)
数据库的表和生产量的数据库表的尽量保持一致
2)场景设计(单场景、容量场景、稳定性场景等)
①单场景
单个业务接口进行压测
生产环境有很多的业务功能,一般说系统的tps都是混合容量的tps,为什么还需要对单场景进行压测?单个接口,链路简单,可以发现明显的性能Bug,可以为后续混合场景tps参考(代码逻辑性能Bug、软件配置bug如数据库连接配置,应用代码线程池里的配置)
②容量场景(混合场景)
容量场景一定需要集合业务比例模拟线上真实业务场景,在性能需求评审时不仅要给到目标tps,还需要给到业务比例,因为线上环境,每个接口调用次数不一样。
涉及到有用户登录、查询商品、添加购物差、创建订单接口:若对这些业务做单场景测试,这四个接口就属于压测范围。
单场景就是针对每一个业务(单独的接口)去进行单独指定目标、设计到加压方式、表的数据量,脚本涉及到关键点,以及重点关注相关指标
根据图中的单场景的目标tps是300、500、500、200,一般性能测试中给出的tps都是混合容量的tps。
混合容量tps=800,接口业务占比,可以根据业务比例算出在混合容量场景各个接口的tps。创建订单 业务比例10%,总的tps是800,则创建订单接口的tps为800*10%=80
其他接口也是同样算法:根据混合容量总的tps算出各接口在混合容量场景下的tps
单场景若没有指定目标tps,接口的目标tps至少是需要比混合容量场景中各接口的tps高(有的项目组会告诉单场景的tps,有的项目组则不会告诉单场景的tps,不指定的话根据总混合容量场景tps和业务比例是可以进行算出每个单接口的tps需要达到多少)
图中的业务比例是日志平台统计业务峰值容量tps,分解出来各个接口的比例,在jmeter中设置的时候还需要进行转换(吞吐量控制器)
业务占比用户登录15%,查询商品40%,添加购物车35%,创建订单10%,根据日志平台线上系统进行统计(有并发请求的业务的一个量,后面再根据jmeter的吞吐量控制器进行业务比例转换)
③稳定性场景(防止系统在高峰值时挂)
压测时需要设置一个持续时间,jmter中,循环次数勾选永远,会设置一个持续时间
稳定性压测时间设置多少合理?jmeter中,tps=总请求数/并发时间
并发时间=总请求数/tps
5000万/800=62500s–建议,时间乘以120%
50000万/1000=50000s,建议:时间乘以120%(防止跑到后面后,性能下降后,没有达到5000万的业务量)
稳定性场景的tps用的是混合容量场景测试出来的最大tps1000,用更大的tps跑出更少的时间。
④加压方式
秒杀、抢购----瞬间产生压力
非秒杀、抢购-----逐步阶梯加压
3)监控设计
根据压测接口的链路涉及的技术栈、选择合适的监控工具
比如:链路监控工具是微服务的标配(服务很多,排查问题难)
java项目:通过链路监控工具,进行时间拆分,发现是应用耗时多(对应用接口的调用的方法,通过arthas之类工具看哪个是方法耗时多或者可能是jg在耗时,通过jdk自带的相关命令进行查看,jstack)
系统架构、数据流向、技术栈需要清楚
3.6、测试计划
流程的一个里程碑计划、产出物什么、时间节点、负责人是谁?
3.7、风险评估
根据当前情况罗列出可能的风险(如涉及到外围系统,外围系统也属于外围风险、人力资源缺少、环境差异)
3.8、参考资料
4 、性能测试方案评审
写好后项目组进行评审、性能测试计划、性能测试场景怎么设计的.
根据评审会议的建议进行修改
评审会议通过后需要发送给各项目组的成员
5、申请性能测试环境
简单架构(nginx+2 tomcat +mysql),nginx做反向代理,tomcat容器有两个+mysql,看哪一个服务是影响大的,资源不足的话,对对应的服务等比例缩放进行两次压测,看损耗率。
初步判断,瓶颈在应用层,第一次是一个tomcat,tps是100,两个tomcat的tps是180,此处有20的tps的损耗。换算成损耗率,生产是3个tomcat,预估可以达到多少tps,现在简单架构较少,一般都是复杂架构,复杂架构链路长,涉及的服务多,每一个服务的影响因子性能大小不一样,很难换算。建议项目组进行评估,做好线上的保护,如限流。
大公司一般压测环境不足,一般是直接线上全链路,充分利用线上的资源。
补充:新项目可以直接在线上环境压测
6、性能测试用例编写及评审
性能测试用例设计:一般是对性能测试场景进行设计
对单场景、混合容量场景、长时间稳定性的设计,重点就是各场景里的数值
单场景(目标tps、加压方式、数据量、脚本设计等)混合容量场景(业务比例、目标tps等)
长时间稳定性(总的压测时间、总的目标业务量等)
7、搭建测试环境
参考测试资源压测环境的部署
除了部署应用,还需要部署监控
8 、准备测试脚本、测试数据
8.1、脚本
推荐:开发提供压测环境调通的postman或者jmeter脚本
或者根据接口文档写(swagger)
8.2、场景设计
8.3、准备数据
1)参数化数据
方式,代码生成,从数据库导出
2)数据库存量数据
方式:
复杂表,jmeter跑业务接口
单表:代码,存储过程
9、环境确认测试
9.1、静态测试
确认环境配置(软件、硬件),尽量和生产保持一致
软件(jdbc的配置、线程池的配置等是否和生产保持一致)
9.2、非静态测试
确认环境是否可用(压测的接口是否通、发送请求是否有响应响应结果是否正确等)
10、执行压测并监控
先单场景测试发现明显的性能bug,为容量场景做准备
混合容量场景:模拟真实线上的真实场景
再执行稳定性场景
执行压测监控时,不要一次性打开所有监控,监控也是需要耗费监控资源。先通过jmeter非gui模式下持续阶梯加压跑一下,看一下结果,如不达标后,若是微服务(用skywalking)是哪一个节点耗时多,就着重监控不达标的节点(如果是mysql服务,则将mysql的服务打开),通过mysql监控看是什么问题,若有慢sql,后续就需要出现问题的接口执行的sql,拿出来用explain单独分析sql执行情况
每一步需要哪个监控就开哪个监控
11、分析定位
11.1方法
1)简单架构
查看资源消耗,通过监控发现应用服务器的CPU高,java项目可以进行打栈,看一下线程在做什么,下一步就是代码逻辑。
2)复杂架构
通过分解时间方式(微服务skywalking)
举例:
场景比对:加节点怀疑是服务资源不足,可以进行加节点,
性能提升后就是服务资源不足导致的,服务为什么消耗资源,代码逻辑是否合理。
隔离:这个功能会调另一个功能,先将一个功能去掉后再进行压测。