1、性能测试核心知识点
1.1、正确了解性能测试
性能测试:
属于软件测试范畴,旨在测试处于特定环境和配置下的系统在一定量的负荷下,系统的响应时间、吞吐量、成功率、稳定性、可恢复性等特性是否满足特定干系人需求的能力。
不符合需求情况下:
结合系统的业务模型、环境配置、设计、实现细节等识别出问题,并最终确保该问题得到妥善解决的过程。
1.2、性能测试的目的
基本目的:验证是否达到用户的性能指标;发现软件中存在的性能瓶颈并优化
评估系统的能力:测试中得到的负荷和响应时间数据,用于验证所计划的能力;帮助做出决策
识别体系中的弱点:受控的负荷可以被增加到一个极端的水平,并突破它修复体系的瓶颈或薄弱的地方
系统调优:重复测试,验证调整系统的活动是否得到了预期的结果,改进性能;如:长时间的测试执行可导致的内存泄漏
验证稳定性:在一定生成负荷下执行测试一定的时间评估系统稳定性和可靠性是否满足要求。
1.3、关于性能测试的常见误区
误区1:性能测试=性能测试工具的使用(目标不明确,缺乏计划)
误区2:性能测试=功能测试+并发量(测试所有场景)
误区3:性能测试=GUI界面性能测试(APP,web,小程序多管齐下)
误区4:性能测试=性能脚本的运行(缺乏数据收集,分析,调优过程)
误区5:实验室下性能指标=实际环境下性能指标(忽视环境的差异)
1.4、性能测试需要掌握的相关知识体系
1、系统业务(核心业务:并发量可能会高的业务)
2、系统架构(单数据库还是分布式的等)
3、负载工具
4、分析工具
5、监控工具
6、支撑系统
7、测试策略
8、测试方法
1.5、性能测试方法
1、验收性能测试(是性能测试里最容易的测试)
例子:xxx系统要求同时支持100并发量同时登陆,成功率为100%,平均响应时间小于2s,系统各项资源使用率(cpu、内存、带宽、磁盘空间)低于80%,裕兴持续时间12小时。
概率:模拟生产上线业务环境,测试是否满足性能要求。
特定:1、特定用户的环境 2、用户要求的性能指标 3、执行、分析结果 4、验收性质 5、一定要有客观性的结果
2、负载测试(没有性能要求的情况下,做出的系统评估)
如果没有验收标准,验收性能测试 演变成 系统性能评估测试 演变成 性能调试(负载测试->压力测试->极限测试)
理解层面:是性能测试里面的一个方法
概念:软件系统在一定负载下的性能表现
强调:一定负载------一般是客户需求的负载
负载测试与压力测试的区别:
负载测试:主要是考察软件系统在既定负载下的性能表现------关心的是用户规则和需求
压力测试:考察系统在极端条件下的表现,是否会漫延,影响到其他的功能---------关系的是系统本身,预期是系统出现问题,而我们要考察的是系统处理问题的方式。
3、压力测试
4、并发测试
5、配置测试
6、可靠性测试
7、恢复性测试
针对有冗余备份和负载均衡的系统设计的。用于检验如果系统局部发生故障,用户是否能够继续使用系统,以及如果这种情况发生,用户将受到多大程度的影响。测试系统能否快速地从错误状态中恢复到正常状态。
8、稳定性测试
目的:测试系统在一定负载下运行长时间后是否发生问题(TPS不变,时间变)
常见案例:这种问题一般是程序占用资源却不能及时释放而引起的。比如,内存泄漏问题就是经过一段时间积累才会慢慢变得显著,在运行初期却很难检测出来
9、基准测试
1、当软件系统中增加一个新的模块的时候,需要做基准测试,以判断新模块对整个软件的性能影响
2、按照基准测试的方法,需要打开/关闭新模块至少各做一次测试
3、关闭模块之前的系统各个性能指标标记下轮作为基准(Benchmark),然后与打开模块状态下的系统性能指标作比较,以判断模块对系统性能的影响
1.6、性能测试应用领域
性能测试应用领域 :
性能验收,性能评估,性能基准对比(缺陷发现、调优)
1、能力验证
概率:某系统能否在A条件下具备B能力
特点:1、要求在已确定的环境下运行 2、需要根据典型场景设计测试用例和方案
使用方法:1、负载测试 2、可靠性测试 3、压力测试 4、失效恢复测试
强调:当前能力
2、规划能力
3、性能调优
4、缺陷发现
5、性能基准比较
案例:
boss:小张,主干功能已经测试通过,你来做性能测试?
张工:性能测试应用领域:
验收:(有指标,有需求)发现问题,性能调优
A系统白天高峰期每秒钟要有1000个用户同时发请求,要求每个请求响应时间小于1s,成功率100%,CPU:小于82%,内存使用率低于90%,磁盘空间:使用率低于70%,网络带宽:5M
基于:dell服务器小型机24内核、96G内存,磁盘:16TB,带宽:5M
方法:负载测试法:TPS=1000,直接跑
评估(探索)发现问题,性能调优
2、性能测试方法
性能测试方法:负载测试,压力测试,极限测试,稳定性测试,可靠性测试
2.1、性能指标解析
2.1.1、并发用户数
并发用户数=并发用户量===》同时对系统发送的请求的量
2.1.1.1、并发用户数类型划分:
1、系统用户数----------软件系统注册是用户总数(跟磁盘空间有关系,用例设计:设计一个用例,测试系统容量,确保磁盘里可以插入足够的用户数据,为了如果实际情况以及到达此用户量,需要考虑扩容)
2、在线用户数----------某段视角内访问的用户数,这些用户只是在线,不一定同时做某一件事情。(包含游客和以及注册了并在线的人数,跟内存有关系,用例设计:用户不断上线,不下线。用来测试系统最多可以有多少个用户登录,是否会出现用户被踢出的情况)
3、并发用户数----------某一个视角同时向软件系统提交请求的用户数(比如:秒杀),场景不一定是同一个。(跟CPU有关系,即响应时间。用例设计:1、游客身份+注册用户:访问不同的页面或请求;2、游客身份+注册用户:访问相同的页面或请求,如秒杀,容易出现CPU100%或者出现系统没有响应或者响应时间长)
2.1.1.2、案例:
组长:小李,你测试下这个web系统的性能,看能支持多少个并发?
注意:在确定并发用户数之前,必须先对用户的业务进行分解,分析出其中的典型业务场景(用户最常用,最关注的的业务操作),然后基于场景获得其并发用户数。
常见场景:访问网站首页,登录功能,核心业务功能,个人中心。
2.1.1.3、并发用户数公式计算:(不同公司计算公式不一样,参考性不大)
实例:平均平法用户数的计算:C=nL/T
C-----是平均的并发用户数
n-----是平均每天访问用户数(login session)
L-----是一天内用户从登陆到退出的平均时间(login session的平均时间)
T-----是考察时间长度(一天内多长时间有用户使用系统)
并发用户数峰值计算:C^约等于C + 3*根号C
2.1.2、吞吐量
2.1.2.1、概念
吞吐量:是指软件系统在每个单位时间内能处理多少个事务/请求/单位数据等信息
从业务角度看:吞吐量可以用:请求数/秒、页面数/秒、人数/天或者处理业务数/小时等单位来衡量
从网络角度看:吞吐量可以用:字节/秒来衡量
对于交付试应用来说:吞吐量指标反映的是服务器的压力,他能够说明系统的负载能力
TPS:每秒事务数
2.1.2.2、评估
第一种情况为有过载保护,第二种为灾难蔓延
2.1.3、点击数
2.1.3.1、概念
点击数:点击数是衡量web server处理能力的一个很有用的指标
说明:点击数是客户端向服务器发起了多少次http请求计算的,一次鼠标可能触发多个http请求,这需要结合实际情况。
2.1.4、响应时间
2.1.4.1、概念
响应时间:用户感觉软件系统为其服务所耗费的时间,是用户感知软件性能的主要指标,一般响应时间为2/5/8s。
实例:
对于网站系统来说,响应时间就是从点击了一个页面计时开始,到这个页面完全在浏览器里展现计时结束的这一段时间间隔
响应时间包括:
1、用户客户端呈现时间
2、请求/响应数据网络传输时间
3、应用服务器处理时间
4、数据库系统处理时间
当有用户抱怨慢,不一定是系统的问题,需要问:是否就一个用户抱怨,查看其访问其他APP是否有问题,如果不是一个用户,需要分析是移动、联通还是电信网络,都是什么浏览器,都分布在什么位置。
2.1.5、资源使用率
2.1.5.1、概念
性能计数器:是描述服务器或操作系统性能的一些数据指标。
系统典型资源:
1、内存
2、CPU
3、磁盘
4、网络等资源使用率等
2.1.6、思考时间
2.1.6.1、概念
Think Time:从业务角度来看,这个时间指用户进行操作时每个请求之间的时间间隔
在做新功能测试时,为了模拟这样的时间间隔,引入了思考时间这个概念,来更加真实的模拟用户操作。
问题解答:
1、吞吐量包括请求+响应吗?还是单向的请求?
答案:吞吐量是一来一往的,算一个。
2、“思考时间,应用在什么场景”?
答案:应用在用户两个操作之间的需要思考的时间,一般为2到3秒
3、tomcat是什么?
答案:web服务器
4、中间件?
答案:Tomcat等
5、思考时间和tps之间的关系,项目中核心请求需要6s左右的思考时间?
答案:没关系,tps是每秒处理的访问量
6、事务数中的事务不是很清楚?事务和请求接口是不是存在一个事务是由几个请求接口完成?
答案:一个事务可能包括多个请求
7、我们公司要求接口时间在200毫秒没,合理不?
答案:合理,根据实际情况定
8、web服务器和应用服务器有啥区别?
答案:web服务器:Apache,nginx==》处理简单的HTML文本
应用服务器:Tomcat=》运行Java代码
9、jmeter ip 不变吗?
答案:可以使用虚拟ip
10、测试查询报表 几十万数据 响应时间多少?
答案:一般2/3/5/,按照性能看
3、性能测试应用场景