性能测试理论知识(一)

软件测试的分类:

1、功能测试

2、自动化测试:

UI自动化测试

API自动化测试(接口自动化测试又是接口测试)

3、性能测试

4、安全测试(渗透测试)

 

性能测试所学知识

1、性能测试的理论

2、性能测试的方法

3、性能测试的工具实战

4、代码级别的性能测

5、资源监控

 

性能对软件而言是一直指标,是衡量软件用户体验最核心的指标之一,给用户最直观的感受就是产品的响应时间。

衡量一个产品的性能指标有很多,但是主要是响应时间(反应快慢),以及吞吐量(同时多少个人可以访问这个系统,比如说一码通,同时是否支持100万人同时进行核酸检测)

 

怎么查看响应时间?

1、鼠标右键点击检查

 

 

2、找到Network

 

 

 

3、点击clear按钮

 

 

 

4、刷新一下找到下面的Load就显示出来他的响应时间

 

 

 

 

为什么大家的响应时间不一样?因为涉及到资源竞争,因为资源有限,但是竞争的程序有点多,那么这个时候有限抢到资源的,就可以有限执行。

 

用户立场: 在用户的角度而言,软件性能就是用户操作的响应时间。一般而言关于响应时间业界的说法具体如下:

1-3秒,属于优的表现

3-5秒,可以接受,属于中间的表现

5秒以上,无法接受

 

在实际的工作里面,如果测试的一个页面,响应时间大于5秒,那么一般情况下,需要反馈给程序员,也就是说需要提交一个优化的问题单

 

运维是干什么的?

维护服务器,管理服务器的,还有就是负责公司的网络环境。服务器主要是阿里云的服务器,IBM的小型服务器

 

运维除了关注响应时间外,也会关注更多底层的资源信息,这些资源信息具体可以汇总为如下:

系统资源(CPU和内存)

数据库资源(IOPS资源)

JVM内存是否够用 系统的最大容量

 

系统资源

CPU 和内存(memory)

数据库(database,db):数据库就是存储数据的,对于数据库而言读写的速度就显得非常重要,衡量读写速度的指标就是IOPS(固态硬盘)

 

JVM内存是否够用:

Java语言,特点是跨平台的,Java跨平台是通过JVM来实现的,就是Java编写的程序都有内存的大小设置,如果程序超过这个内存的大小设置,那么就出现了内存泄漏(out,of,memory,oom)

 

开发视角 开发的关注度会更加的全面,毕竟代码都是程序员来编写的,具体可以汇总为如下:

前后交互的响应时间

中间件的参数设置

内存释放泄露

连接数泄露

是否存在不合理的内存使用方式

是否存在不合理的线程同步方式

系统中是否存在不合理的资源竞争

系统架构&代码结构=

 

中间件的参数设置: 中间件(RabbitMQ,Kafka,Redis)

Redis缓存穿透 存到内存里面,这样的目的设计上是合理的,这样的目的是查询的时候读取速度很快

 

连接数泄露: 数据库(DB):程序员需要查询数据,前提是连接到数据库,但是了资源有限,如果之前的占用了没释放,那么导致后面的连接不上,然后就泄露了

 

架构模式

单体架构-垂直架构-SOA架构-微服务架构

单体架构:所有的代码整合到一起 垂直架构:按照模块来整合不同的代码 SOA架构:不同模块之间的数据同步 微服务架构:按照业务类型把每个业务写成一个服务

 

SAAS:Software As A Sevice 中文意思:软件即服务 PAAS: Platform As A Service 中文意思:平台即服务

 

测试视角 用户关注的视角属于全栈性的,需要考虑用户视角的产品体验,也要监控以及关注运维视角和开发视角,所以性能测试中测试的具体工作职责可以总结为:

设计合理的场景和测试用例来验证系统的资源数据

验证在高并发的情况下架构是否满足

给架构师以及开发人员提供中间件配置参数的合理值范围

使用技术手段监控系统,DB,中间件,全链路监控的方式来监控系统资源情况

 

WEB前端 所谓前端的性能目前也是性能测试中比较热门的技术之一,关注的点具体汇总为如下:

浏览器的资源加载(HTML解析,图片资源加载,CSS文件资源加载)

前端缓存技术的优化是否合理性

前端与后端的交互性耗时

 

 

 

客户端-<--》路由器(DNS)<---〉nginx中间件-<--->淘宝服务<--->淘宝数据库

响应时间=⽹络时间+应⽤程序的处理时间

并发用户数

性能测试的核心是验证当前系统能否支持现有用户的访问,也就是说系统可以承受在同一时间段多少用户来访问系统,比如王者荣耀的游戏,是否可以承受同时在线人数一个亿的人同时进行玩游戏?

 

并发用户数,可以说:不论从业务视角出发,还是服务端承受压力而言,描述的是同一时间同时向客户端发出请求的客户,某些时候也称为“并发测试”。这中间主要体现的是服务端承受的最大并发访问数。

 

吞吐量

主要⽤于数据传输⽅⾯,也就是被测试系统的执⾏效率。该术语⽤于描述数据传输速度(字节/秒或者⽐特/秒),在 某些情况下(如DB层⾯),吞吐量指的是操作的速度,也就是每秒操作数或者每秒业务数。或者也可以说单位时 间内客户端请求的数量,直接体现系统的性能承载能力。

 

一码通而言:场景早上6点至7点学生上班族都开始做核酸检测,那么并发用户数指的是这个时间段服务端能够承受的最大用户数,吞吐量指的是这个时间段,每秒能够同时多少人进行核酸检测

 

性能计数器

指的是性能测试过程中,需要收集哪些数据,并且收集的这些数据对性能测试有帮助 系统:cpu memory db:iops 被测系统:响应时间,并发用户数,吞吐量

 

性能测试什么时候开始合适? 性能测试最好建议是在功能测试的基础上,也就是说系统测试的没什么问题了,再做性能测试

 

使用率 对于服务所请求的资源,使⽤率描述的是所给定的时间区间内资源的繁忙程度。对于存储资源来说,使⽤率指的就 是所消耗的存储容量。如⼀个业务中,会使⽤⼤量的内存资源,总的内存资源是4G,在⼀定数据量的情况下执⾏该 业务形态,内存使⽤率从100M⼀直占⽤到3G,然后随着业务形态内存资源得到释放呈下降的趋势,那么可以说内 存使⽤率最⾼为75%,可能会存在OOM的错误信息,也可能会存在内存泄露的情况。所以使⽤率分两个维度,⼀ 个是系统资源的使⽤率,另外⼀个是系统内部署服务对系统资源的使⽤率。

 

当系统的资源使用率(cpu和内存)达到60%以上,那么可能系统就会存在很卡的情况。

 

思考时间

思考时间英文名称是Think Time,也称为休眠时间,在业务视角,思考时间指的是用户在进行操作时,每个请求之间的间隔时间。

 

两个维度:

1、针对磁盘

2、针对数据库的读写

 

IOPS 该术语主要是针对数据库的,也就是每秒发⽣的输⼊/输出操作的次数,是数据传输的⼀个度量⽅法。⽤于磁盘的 读写,IOPS值的是每秒读和写的次数。

 

事务

一系列操作动作的组合,如登录,输入账户,输入密码,点击登录按钮,可以说是登录的事务

 

TPS

统计的是每秒处理的事务数,即系统每秒能够处理的事务的数量 100/s

QPS

指的是 每秒查询率 100/s

 

资源调度

系统的资源是有限的,假设所有的程序都启动,很明显资源不够,那么这个时候谁先执行,谁后执行。谁先抢到资源,谁先执行,这个过程中资源会不停的切换。

 

在操作系统的级别上,进程是操作系统最小的运行单位。什么是进程,进程是每个程序运行后,都是一个独立的进程。现在的软件都是可以同时干很多的事,比如抖音,可以同时看视频的同时也可以发私信,也可以聊天,这个过程中,发私信,聊天,看视频,都是由线程来支撑执行的,所以了,现在的软件可以说是多线程的模式。

 

在进程角度,多线程内部都是共享数据的(如你拿你的抖音看视频,聊天,发私信,其实是同一个人)。

 

调度策略:在资源有限的情况下,所有的任务都可以执行,但是如果资源在不够的情况下,那么就会有排队的机制。

 

排队的机制: 队列(数据结构),先进先出。Queue,有这么几个方法: put():进队 get():出队 empty():队伍是否为空

 

CPU密集型:应⽤程序执⾏繁重的计算,通常运⾏时间⽐较⻓,会占⽤⼤量的CPU

CPU:存在大量的计算任务,占用大量的CPU,而占用少量的内存

 

IO密集型:应⽤程序执⾏I/O,计算不多,会占⽤⼤量的内存资源 系统的最⼩粒度是线程,也就是说系统调度中粒度最细的就是对线程的调度。

 

等待队列 在程序中,都会涉及到等待队列的,不管是同步交互还是异步的交互中,都会涉及它的最⼤队列,这样设计的核⼼ 思想是防⽌在客户端⾼并发的情况下服务端在没有队列的情况下出现雪崩以及最终导致服务端出现瘫痪,

 

服务端的稳定性测试怎么保障? 客户端在持续的高并发的情况下发送请求给服务端,服务端处理能力有限,导致资源出现瓶颈的同时排队的任务越来越多,最后服务端就出现了瘫痪。为了服务端不出现崩溃,服务端一般会使用队列的机制,具体的说就是服务最多可以处理任务是30个,那么如果过来的任务是少于30个,那么全部同时处理,如果过来的任务是100个,那么70个任务是排队的。

 

1、队列设置的值是多少?最⼤可以运⾏的任务是多少?

2、需要测试到排队的策略机制,也就是说模拟⼤批量的程序进⾏排队,然后⼀个任务执⾏结束后,队列位置释放 ⼀个,等待中的可以⽴刻进⼊然后执⾏,这中间就设计到先进先出还是先进后出,以及线程优先级的设计策略

3、线程在排队的过程中,设置最⼤的等待时间是多少,也就是说⼀个线程不可能永远处于等待中,那么等待多 久,还是没到执⾏的阶段,这个时候服务针对排队等待的线程处理的机制是?这个时间专业术语就是:访问等待时 间

4、那么⼀个线程完整的时间是由三部分组成的,响应时间:客户端发起请求的时间+访问等待时间+逻辑执⾏时间 +返回给客户端的时间。⼀般在测试中,可以把每个线程名称设置为uuid,这样它都是独⽴的,可以依据这个 uuid,让开发同学配合输出每个阶段的时间输出,然后就可以得到每个阶段的具体时间了,根据时间再来判断时间 是否优化。

posted @ 2022-05-18 16:13  朝阳群众老马  阅读(159)  评论(0编辑  收藏  举报