测试开发---性能测试概念篇

一、什么是性能测试

1.概念

为了发现系统性能问题或获取系统性能相关指标而进行的测试

2.性能指标

评价一个人好与不好一般都有指标,对于性能也是一样,我们要有指标来反映性能的好坏

3.常见的性能问题

查询数据时间过长,网速很慢,服务器无响应,查询数据很长时间才显示列表

二、常见的性能指标

1.并发数

①从业务层面来看,并发用户数指的是实际使用系统的用户总数

②从后端服务器层面看,指的是web服务器在一段时间内处理浏览器请求而建立的http连接数或生成的处理线程数

③最大并发数指的是一个系统最多能够承受多少个用户去访问

2.吞吐量

①单位时间内处理的并发数(每秒处理的并发数),直接体现软件系统负载承受能力。吞吐量越高,系统承受的并发越多,性能越好。

②案例

A场景:有100个并发用户,每个用户每隔一秒发出一个请求

B场景:有1000个并发用户,每个用户每隔10秒发送一个请求

A和B场景的吞吐量相同都是每秒100个请求,但是A场景思考时间短,所以A场景占用的系统资源更多。

③分类

按照请求数量分为:TPS(transaction per second)和QPS(query per second)

a. TPS:每秒处理的事务数,用于衡量系统在一定时间内能够处理的事务树

计算公式:总的请求成功的事务数/总的运行时间

举例:系统一分钟处理1000个业务,则TPS=1000/60

如果没有详细数据:根据二八定律(80%的事务是在20%的事件完成)

TPS=1000*0.8/24*60*60*0.2(一天完成1000个事务,其中的80%在一天的20%的时间内完 成)

如果有详细的数据:5万笔交易在晚上的8~9点完成的
TPS = 50000 / 60*60 = 13.9(实际还要参考往年业务的增⻓,假设每年业务增⻓30%,则TPS = 50000 + 50000*0.3 / 60*60 = 18)

b.QPS:每秒查询率

若一个事物中只有一个接口且是查询接口,则QPS=TPS
按照网络数据包划分:KB

3.响应时间

①验证系统处理速度快不快

②应用系统从请求发出开始,到客户端接收到最后一个字节数据所消耗的时间

③对于Web系统而言,系统响应时间包含前端展现时间和系统响应时间

④前端展现时间:页面渲染时间

⑤系统响应时间:包含服务器、数据库、通讯网络等响应时间

⑥并发用户、系统吞吐量、系统响应时间之间的关系

到达c点,并发开始增加,响应时间增加,吞吐量减低


⑦当并发⽤⼾较少,系统吞吐量低,系统响应时间较短,我们认为系统处于空闲区间。随着系统并发⽤ ⼾增加,系统吞吐量开始呈线性增⻓,系统性能进⼊了线性增⻓区间。
⑧吞吐量在某个点上达到了饱和点,也称之为拐点。在这之后⽤⼾请求不再被⽴即处理,响应时间随之变⻓,吞吐量也逐渐降低,系统性能进⼊了过饱和区间。
⑨系统性能的拐点通常是性能测试的主要⽬的。

4.资源利用率

①通过查看系统占用的情况分析资源瓶颈

②服务器:CPU、内存、磁盘、网络等

③运维比较关注

三、性能测试关注点

不同的角色看待性能测试的侧重点不同

从客户端发起一个请求到客户端收到请求的整个过程中,各个阶段都可能存在性能问题

开发人员和测试人员并不需要关注全流程的性能问题。通过分析不同角色的侧重点,从而促进性能测试更好的开展

1.终端用户

关注从提交请求到收到请求的响应时间,响应时间慢就是体验不好,不关心其他问题,不关心后端前端,什么也不关心

2.运维人员

运维人员出了关注单个请求的响应时间,更关注大用户并发访问时对系统的影响,以及更大负载情况下的系统的健康状态。

3.开发人员

关注算法设计、架构设计、性能最佳实践、数据库相关、软件性能的可测试等方面

4.测试人员

⼯作重点在于性能测试场景的设计、脚本的开发和执⾏,以及性能缺陷的排查和定位。
测试⼈员除了具有及其宽⼴的知识⾯,如系统架构,存储架构,⽹络架构等全局的知识,还要有⼤
量知识积累,⽐如数据库SQL语句的执⾏计划调优、JVM垃圾回收、多线程常⽤问题等。

四、性能测试分类

1.基准测试

①基准测试又称单用户测试,主要用于检测被测系统在较低压力下的运行状况并记录相关数据

②当性能测试环境确定以后,通常选取业务模型中的重要业务做基准测试,对北侧系统施加一定压力,从而获取被测系统在单用户运行情况下的各项性能指标,为多用户并发测试和混合场景测试提供参考依据

2.并发测试

并发测试(Concurrency Testing)⽤于评估被测系统的某些特定操作同时发⽣时的性能表现,例
如,被测系统被多个⽤⼾同时登录时的响应能⼒,或系统的某⼀功能被多个⽤⼾同时操作时的性
能表现。通过并发测试,不仅可以获得被测系统在多⽤⼾并发操作时的性能指标,还可以发现被
测系统在并发条件下可能发⽣的问题,如内存泄漏、线程锁、资源争⽤问题。例如,通过模拟多
个⽤⼾同时访问某⼀条件数据,或模拟多个⽤⼾同时更新数据,可能会发现被测系统的数据库访
问错误、写⼊错误等。⼏乎所有的性能测试都会涉及⼀些并发测试。但并发测试对并发时间要求
⽐较苛刻,通常需借助专⻔的性能测试⼯具,采⽤多线程或多进程的⽅式来模拟多个虚拟⽤⼾的
并发性操作。

3.负载测试

①负载测试就是找什么时候达到拐点
②通过逐步增加负载的方式来确定系统的处理能力
③负载测试类似于举重运动,通过不断给运动员增加重量,确定运动员在其身体状况保持正常的情况下所能举起的最大重量。通过负载测试可以获取系统能够达到的峰值指标
④例如,⼀个软件系统的响应时间要求不超过2秒,如果在这个前提下不断增加⽤⼾访问量,系统
的响应时间就会变⻓。假设当访问量超过1万⼈时系统的响应时间超过2秒,那么就可以确定在系
统响应时间不超过2秒的前提下,系统的最⼤负载量是1万⼈。负载测试可⽤于系统的性能验证、
性能诊断和性能调优等场景

4.压力测试

①压⼒测试(Stress Testing)⽤于评估被测系统在⾼于预期、⾼于指定容量负载需求或低于最少需求
资源的条件下的⾏为
②压力测试就是测试系统崩溃时访问量是多少
③与负载测试的区别

负载测试是在保持性能指标要求的前提下测试系统能够承受的最⼤负载,⽽压⼒测试则是测试系统性能达到极限的状态。例如,软件系统要求的响应时间为2秒。进⾏负载测试时发现,当访问量达到1万时,系统响应时间不超过2秒,⽽当访问量超过1万时,系统响应时间则会超过2秒,那么,在满⾜系统响应时间指标的前提下,该系统能够承受的最⼤访问量是1万。进⾏压⼒测试时,则可继续增加系统的访问量,并观察系统的性能变化。例如,当系统访问量增加到2万时,发现系统响应时间延迟到5秒,⽽当访问量增加到3万时,系统则崩溃,⽆法做出响应。由此可以确定系统能达到的极限访问量是3万

5.稳定性测试

在负载测试的基础上,执⾏较⻓时间的测试以检查系统的稳定性。通常较⻓时间指3*24⼩时以
上。

相关推荐
卓码软件测评21 小时前
CNAS软件测试机构:【Postman集合从接口组织到自动化测试套件的过程】
网络·测试工具·性能优化·测试用例·压力测试·postman
黛琳ghz21 小时前
极速云原生:openEuler之Redis与Nginx部署性能实战
redis·nginx·云原生·操作系统·压力测试·openeuler·服务器部署
十二测试录1 天前
用F12获取接口信息,并进行接口测试
经验分享·功能测试·测试工具·压力测试·职场发展·安全性测试
卓码软件测评2 天前
第三方软件测试评测机构:【基于Scala DSL的Gatling脚本开发:从零开始构建首个负载测试模型】
后端·测试工具·测试用例·scala·负载均衡·压力测试
天才测试猿2 天前
Jmeter压测实战:Jmeter二次开发之自定义函数
自动化测试·软件测试·python·测试工具·jmeter·职场和发展·压力测试
workflower2 天前
软件需求变更
嵌入式硬件·压力测试·团队开发·需求分析·规格说明书
汽车仪器仪表相关领域3 天前
MTX-AL:传统指针美学与现代数字科技的完美融合 - 模拟宽带空燃比计
大数据·人工智能·科技·单元测试·汽车·压力测试·可用性测试
卓码软件测评3 天前
【第三方CNAS软件测试机构:Gatling中的资源监控_实时收集服务器CPU、内存、磁盘I/O和网络指标】
后端·测试工具·测试用例·scala·压力测试
爱尔兰极光4 天前
软件测试--BUG篇
bug·压力测试·测试