5个W【why what who where when】带你认识性能测试

一、概念和术语介绍:

1、并发数

系统用户数:就是该系统的注册用户数,注册了都算
在线用户数:登录系统的用户。你做饭时把 QQ挂着,这时并没对腾讯的服务器产生压力
并发用户数:是对服务器产生压力的用户

2、响应时间

响应时间=用户响应时间+前端响应时间+网络响应时间+服务器端响应时间+数据库响应时间(它是一个来回)
在这里插入图片描述

3、吞吐率

吞吐率是单位时间内的吞吐量,从它的单位(字节数/秒、业务数/秒、点击数/秒、请求数/秒)就可以看出来。吞吐量是服务器所能处理事物的能力

4、资源利用率

cpu、内存、硬盘、网络宽带这些都是我们可以使用的资源,
利用率=已利用的/总的资源

5、点击率

这里需要注意点击率并不是指用户对鼠标的点击次数,而是提交的http请求次数,因为你点一次鼠标可能会产生多个请求。

二、5个W详解

1、why为什么要进行性能测试

一个系统做出来有太多的未知性,是否能够很快的响应用户的要求?是否能处理预期的用户负载并有盈余能力?是否能处理业务所需要的事务数量?在预期和非预期的用户负载下,应用程序是否稳定?用户使用起来会不会不满意?这些我们都不确定,所以要进行测试

2、what性能测试的关注内容

并发用户数、吞吐量、平均响应时间、服务器资源占用情况、可靠性:下面的测试分类里面会有介绍、可扩展性、发现引起系统问题的原因、关注采用何种技术提高系统性能软、硬件配置是否合适(容量规划/硬件选型)(不同的角色关注的性能方面有差异的,who里面会详细讲)

3、who谁关注性能测试

开发人员:我们想开发人员开发的步骤就是架构分析数据库设计再到代码实现,所以他关注的就是系统架构和数据库设计是否合理?代码是否存在性能问题,像时间空间复杂度?系统中是否存在不合理的内存使用方式?设计和代码:系统中是否存在不合理的线程同步方式和不合理的资源竞争?
系统管理人员:他只是负责管理这个系统,所以他关注的都是与系统相关的,像资源利用率:应用服务器和数据库资源使用状况合理吗?系统容量:系统最多能支持多少用户的访问?系统最大的业务处理量是多少?系统稳定性:系统是否能支持7X24小时的业务访问?系统可扩展性:系统是否能够实现扩展?系统性能可能的瓶颈在哪里?更换哪些设备能够提高系统性能?
用户:我们就是好多软件的用户,用户只关心响应时间和系统稳定性,遵循358原则,只要使用过程中系统不崩溃反应速度快就行
3秒钟用户会觉得是一个很好的体验。
5秒钟用户可能会觉得差了一点,还行,比较好。
8秒钟是用户所能承受的最大极限
测试人员
以上所有层面都需要关注,是否能够发现系统中存在的瓶颈?是否真实有效的评估系统性能能力

4、where:性能测试的关注领域

①、能力验证
性能测试中最简单也是最常用的一个应用领域,主要关心的是“在给定的条件下,系统能否具有预期的表现”。
②、规划能力
规划能力领域与能力验证领域有些不同,其主要关心的是“应该如何才能使系统具有我们要求的性能能力”或 是“在某种可能发生的条件下,系统具有如何的性能能力
③、性能调优
主要应用于对系统性能进行调优。一般来说,性能调优活动会和其他领域的活动交杂在一起。是一种在开发
阶段和测试阶段都可能会涉及到的性能测试应用领域。
④、发现缺陷
主要该应用领域的主要目的是通过性能测试的手段来发现系统中存在的缺陷

扫描二维码关注公众号,回复: 11378103 查看本文章

5、when什么时候进行性能测试

功能测试中后期,因为有功能才谈性能

三、性能测试的分类:

1、并发测试

并发测试是通过模拟用户的并发访问,测试多用户并发访问同一个应用,同一个模块或者数据记录时是否存在死锁或者其他性能问题。目的是确定系统能承载的最大用户数,最大有效用户数以及不同用户数下的系统响应时间以及服务器的资源利用率

2、压力测试

压力测试是测试系统在一定饱和状态下,例如cpu、内存等在饱和使用状态下,系统能够处理的会话能力,以及系统能否会出现错误。压力测试与负载测试有些类似,经常把负载测试描述成压力测试的一种场景-例如增加用户数对系统进行压力测试。压力测试的目的是为了揭露高负载下的问题,例如资源竞争、同步问题、内存泄漏等

3、可靠性测试(疲劳测试)

指在一定的软硬件及网络环境下,模拟大量的虚拟用户向服务器产生负载,使服务器的资源在70%到90%的利用率下长时间运行,看它能否连续稳定的正常工作。

4、配置测试

配置测试方法是通过被测系统的软/硬件环境的调整,了解各种不同环境对系统性能影响的程度,从而找到各项资源的最优分配原则,例如在测试执行时更换、扩充硬件设备,调整网络环境、调整应用服务器和数据库服务器的参数设置,比较每次测
试结果,从而确定各个因素对系统性能的影响,选择最佳的设备及参数配置

5、数据库测试

包括数据库完整性测试(测试数据是否完整,防止数据库被意外破坏)和数据库容量测试(数据库所能存储的容量极限,确定在给定时间内能够处理的最大负载)

四、性能测试模型

1、曲线拐点模型

在这里插入图片描述
注:x轴代表用户数,y轴代表资源利用率、吞吐量、响应时间,用户数分为轻压、重压和拐点区

2、地铁模型

跟理发师模型师是异曲同工
假设:某地铁站进站只有3个刷卡机,每个人进站需要1s。人特别少时,每位乘客很快就可以刷卡进站,人多时,如果等待超过30min,乘客就会暴躁不安
1、场景一:只有1名乘客时,用1s和一台机器就能完成进站,剩余2台等待
2、场景二:只有2名乘客时,2名乘客仍都可以在1s的时间内完成进站,且利用了2台刷卡机,剩余1台等待
3、场景三:只有3名乘客时,3名乘客还能在1s的时间内完成进站,且利用了3台刷卡机,资源得到充分利用。
4、场景四:A、B、C、D、E、F6名乘客进站,A、B、C先到,所以D、E、F需要排队。那么,A、B、C乘客进站时间为1s,而D、E、F乘客必须等待1s,所以DEF进站的时间是2s。
5、场景五:假设这次进站一次来了9名乘客,有3名的“响应时间”为1s,有3名的“响应时间”为2s(等待1s+进站1s),还有3名的“响应时间”为3s(等待2s+进站1s)。
6、场景六:如果地铁正好在火车站,每名乘客都拿着大小不同的包,包太大导致卡在刷卡机堵塞,每名乘客的进站时
间就会又不一样。刷卡机有加宽的和正常宽度的两种类型,那么拿大包的乘客可以通过加宽的刷卡机快速进站(增加带宽)。
7、场景七:进站的乘客越来越多,3台刷卡机已经无法满足需求,为了减少人流的积压,需要再多开几个刷卡机,增加进站的人流与速度(提升TPS、增大连接数)。
8、场景八:上班高峰时间乘客数量上升太快,现有的进站措施已经无法满足,单单增加刷卡机已经不行了,此时的乘客就相当于“请求”,乘客不是在地铁进站排队,就是在站台排队等车,已经造成严重的“堵塞”,那么增加发车频率(加快应用服务器、数据库的处理速度)、增加车厢数量(增加内存、增大吞吐量)、增加线路(增加服务的线程)、限流、分流等多种措施便应需而生。

猜你喜欢

转载自blog.csdn.net/chris__x/article/details/106966435