1性能测试基础

性能测试的重要性

案例:  奥运会售票系统上线之后出现问题      12306网站之前一直会出现性能问题    支付宝天猫双十一   单车等等后果:项目上线之后如果不做性能测试或者性能测试做的不够完善,随着用户访问量的增加,会给服务器带来请求压力,造成服务器出现一些题。

影响:

开发、测试人员:加班,扣除绩效奖金,工资等,开除失业

开发商:经济损失,口碑变差,客户流失。

用户:用户体验变差,响应时间变慢,界面出现无响应,崩溃,闪退等问题。

结论:项目上线之前,性能测试还是很有必要的(项目上线用户的访问量会比较大--针对:电商类、金融类、保险类、政府类、军工类)

什么是性能测试

性能测试的概念

软件性能

软件性能其实指的是一些指标,具体的指的是被测软件系统或构件对需求及时性的符合情况,及时性体现在响应时间或者吞吐量等一些具体的指标上面的。

对性能感受可以从不同的角度来衡量,用户、系统管理员、开发人员、测试人员的角度。

用户:响应时间的快慢

响应时间分为直观的(实际的)客观的响应(用户感知的)时间,用户感受到的响应 时间是客观的响应时间,具体的项目具体的分析,结合业务场景来分析。

系统管理员:除了响应时间之外,还需要关注系统的一些资源消耗情况。

要关注系统的资源消耗:CPU的利用率,MEM的利用率,网络,磁盘等消耗情况,应用服务器(TOMCAT)的分配JVM内存够不够用了,数据库容量还剩多少,系统管理员要时刻关注系统的运行稳定性以及良好的可扩展性。对于系统资源的关注情况其实用户是感受不到的。

开发人员:除了需要关注响应时间以及系统资源消耗情况,还要关注更多的一些性能情况

如何通过调整系统参数以及优化或修改设计代码,来提升优化系统性能;以及如何修复系统性能出现的一些问题;也就是所谓的修复性能问题,优化性能;

测试人员:要全部关注所有的性能指标(用户、系统管理员、开发人员)

性能测试的概念:

就是对被测系统进行测试,对比实际性能结果跟预期性能指标,关注收集性能数据(响应时间,资源利用率等),分析性能瓶颈,进行性能优化分析,进行回归验证,最后进行项目总结,项目梳理,整个过程就是性能测试;

性能测试的类别

服务端的性能

协议级

代码级

客户端的性能

系统资源消耗

性能测试也是属于自动化测试的范畴,测试流程,测试手段,测试过程等都类似,但是会一些差别;

性能测试的基础原理

基于协议级的接口 --- 用到HTTP协议(get  post   delete  put)

基于多线程、多进程、协程--jmeter、loadrunner、locust

后面做性能测试是需要用到多台电脑协同工作(联机负载),单机并发能力有限,一台电脑大概能够模拟500-2000个用户并发;

模拟用户真实使用场景

页面资源 --  就是用户访问某一功能所需要加载的所有资源请求,在做性能测试的时候需要全部模拟。

请求数量 -- 就是将用户的完整的业务流程通过协议级接口去实现

请求大小 -- 就是充分的考虑请求参数大小的问题,尽量的模拟不同用户的额请求数量进行测试

思考时间 --  就是将用户请求之间的操作停顿时间通过脚本的思考时间来进行模拟

参数化 -- 在做性能测试时要考虑不同用户数据的差异,一般在脚本中使用参数化来实现。

带宽 --  模拟真实的用户带宽

缓存 -- 模拟真实用户的本地缓存

并发用户数 --  在做性能测试的额时候要通过不同的并发用户想服务器发送请求,评估服务器的性能测试指标

数据库容量 --  在做性能测试之前实现需要向服务器中预埋一些测试数据(尽量的模拟真实环境下面用户的数据)

通过调用注册接口通过工具或脚本直接构建

可以直接使用真实环境的数据(直接获取生产环境下面的数据---脱敏)

测试环境 -- 在做性能测试的时候要尽量的模拟真实生产环境的下的服务器

在生产环境下面直接去做性能

实现准备备份的服务器数据库-

事先要对数据库的数据进行备份--昨晚性能测试要还原线上数据

不在线上的数据库里面测,使用本地数据库来测。应用服务器环境还是线上环境的

测试时间 -- 在凌晨12:00以后,不要再用户高峰期去测性能,会将用户访问的域名切换到咱们临时的服务器上去。(偷梁换柱法)

指标换算法

在现有的环境下面去部署性能测试环境进行测试,根据测试结果以及测试环境跟生产环境的差异进行等比换算

一般都是通过二元一次性能方程找出规律进行推算(数据不太准确--可以做一个参考)

云服务器租赁法

花钱租一台跟生产环境类似的或相同的服务器环境

偷梁换柱法

在真实环境下面进行测试,在半夜凌晨去测试,将用户的服务器进行切换,测试完之后在切换回来。

性能测试分类

基准测试 -- 在一定的软硬件测试环境下面,选用少量的并发用户数(1个,10个)去向服务器发送请求,用以检测服务器在少量的并发用户的情况下的一个基本的性能情况。

目的:类似于系统测试的冒烟测试,用于对后续的正式的性能测试提供一个基准的性能参考。

负载测试 --  在一定的软硬件测试环境下面,通过逐渐递增负载的方式去向服务器构建不同并发用户的请求,用以检测服务器在不同的额负载的情况下的一个性能情况。

目的:找出服务器的性能瓶颈

负载模型图

压力测试--  在一定的软硬件测试环境下面,通过模拟大量的并发用户数(最大用户数)同时向服务器发送请求,用以检测服务器在大量的并发用户访问的情况下的稳定性,可靠性。

目的:测试服务器的运行稳定性

满足条件:

足够的并发用户

足够长的测试时间(7×24小时)

并发测试 --  在一定的软硬件环境下面,通过模拟大量的并发用户数(最大用户数)同时去访问系统中的某一个功能或接口或单一系统,用以检测服务器会不会出现性能缺陷等问题。

目的:检测服务器是否会出现性能缺陷,资源占用或内存泄漏等异常情况;

容量测试 -- 在一定的软硬件环境下面,通过向服务器的硬盘或数据库去构建不同容量的数据,再向服务器发送一定并发用户的请求,用以检测服务器在不同容量情况下的性能指标。

目的:找出系统的最大容量

配置测试 --  在一定的用户并发的情况下,用以检测不同的服务器或客户端的配置对应的性能情况是否满足预期的性能需求;

目的:测试服务器或客户端对应性能情况下的配置情况

极限测试 --  在一定的软硬件环境下,通过模拟大量的并发用户数(最大并发用户数),长时间(几个星期或几个月不等)的向服务器去发送请求,用以检测服务器在这种极限状态下会不会随时崩溃;

目的:为了验证一些上线之后就需要长时间的在线运营,不间断的收益的一些项目(12306之类的一些政府类项目,天猫双十一)

性能测试常见指标

RT(response time)   -- 响应时间

怎么判断响应时间是快是慢 (有没有性能需求,性能需求规定,参照需求来分析,没有需求,需求不明确,参照业界标准或同行竞品,针对一些电子商务类系统     公司内部系统等等   258原则

2秒以内:用户体验是最好的

2-5秒之间:用户体验是一般的

5-8秒之间:用户体验较差,还能容忍。

8秒以上:用户体检太差,不能容忍。)

吞吐量 (throughput)

就是系统在单位时间内处理业务的能力

TI:  Throughput In – 进入服务器的量 (请求)

TO: Throughput Out – 从服务器返回的量 (响应)

业务:业务/小时    事务/秒     请求数/秒        页面数/分

网络:字节数/秒

吞吐量一般会随着用户数的增加而增加,在用户数达到一定的量级的时候吞吐量会慢慢趋于平缓,在用户数继续递增的时候吐吞量会逐渐下降。

TPS(transaction per second)

每秒钟处理的业务数

请求数/秒       业务数/秒       页面数/秒

事务成功率

99.4%    90%

事务的失败率不能大于0.6%,一般情况下只要不大于10%就可以了。

资源利用率

CPU   <  75%

MEM  <  70%

NETWORK   <  70%

DISK   <   70%

数据库性能指标

资源利用率

SQL耗时  --  SQL语句的时间,一般情况SQL耗时都是微妙级的,SQL耗时越短越好。---  慢查询

SQL命中率 --  系统执行SQL操作的时候SQL语句的命中率的情况,命中率越高越好,命中率越高越会降低从数据库硬盘读取数据的时间。

QPS (query  per second) 每秒钟查询 -- 反应的是数据的查询效率

性能测试专业术语

最佳用户数

就是在一定的并发用户情况下,该系统的资源利用情况都处于最活跃的状态,在这个状态下对应的用户数就是最佳用户数。

最大用户数

就是在一定的并发用户情况下,该系统的资源利用情况都处于饱和极限状态,系统还能支撑运行,但可能随时会崩溃,在这种状态下对应的用户数就是最大用户数。

在线用户数

就是出于会话保持状态的用户叫做在线用户

系统用户数

就是一个理论值,就是系统设计的时候系统容量,做测试就是为了验证系统用户的合理性的。

并发用户数

就是在同一时间段同时向服务器发送请求的用户数

RT

响应时间(response time)·

TPS

每秒处理的业务数(transaction per second)

RPS

每秒钟处理的请求数(request per second)

QPS

每秒钟处理的查询数(query per second)

HPS

每秒发送的点击数(hits   per  second)

PV

page view    每秒钟处理的页面数

UV

unique view   每一用户访问量

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值