性能测试概念

SizeTheMoment

于 2024-10-08 20:54:04 发布

阅读量596

点赞数 13

文章标签：可用性测试

本文链接：https://blog.csdn.net/2301_79450337/article/details/142767697

版权

什么是性能测试？

性能测试和功能测试都是在系统测试阶段进⾏，那么这两者有什么区别呢？

案例1：五菱和法拉利都是汽⻋⼚商⽣产的汽⻋，从功能上说，它们都有四个轮⼦⼀个⽅向盘，能够坐在⾥⾯往前开，有挡⻛玻璃能够遮⻛挡⾬
从性能来说，五菱的座椅材质可能是⼈造⽪，法拉利是真⽪；速度从0-100km/h，五菱可能需要⼗⼏秒，⽽法拉利只需要⼏秒，这就是性能的区别
对于⼀个事情来说，能做是⼀回事，做的好不好⼜是另⼀回事情。就跟做饭⼀样，能不能吃是⼀回事，好不好吃⼜是另⼀回事

概念：为了发现系统性能问题或获取系统性能相关指标⽽进⾏的测试。

⼀般在真实环境、特定负载条件下，通过⼯具模拟实际软件系统的运⾏及其操作，同时监控性能各项指标，最后对测试结果进⾏分析来确定系统的性能情况

对于软件来说什么是性能问题：

常⻅的性能问题：

查询数据时间过⻓，⽹速很慢，服务器⽆响应，查询数据很⻓时间才显⽰列表。

常⻅性能测试指标

如何来评估系统性能的好坏？需要借助性能指标来统计和分析

并发数

并发⽤⼾数
从业务层⾯看，并发⽤⼾数指的是实际使⽤系统的⽤⼾总数
从后端服务器层⾯看，指的是web服务器在⼀段时间内处理浏览器请求⽽建⽴的http连接数或⽣成的处理线程数
案例：⼀个已经投⼊运⾏的web系统，有5000名员⼯使⽤，最多同时有2500⼈使⽤，⽤⼾分别进⾏浏览⻚⾯、填写订单、提交订单、查询订单的操作。那么这个系统的业务并发⽤⼾数是2500，实际并发⽤⼾数是提交订单和查询订单操作的⽤⼾

吞吐量

单位时间内处理的并发数，直接体现软件系统负载承受能⼒。吞吐量越⾼，系统承受的并发越多，性能越好
案例：有AB两种场景
A场景，有100个并发⽤⼾，每个⽤⼾每隔1秒发出⼀个请求
B场景，有1000个并发⽤⼾，每个⽤⼾每隔10秒发送⼀个请求
A和B场景的吞吐量相同都是每秒100个请求。但是A场景思考时间短，所以A场景占⽤的系统资源更多

响应时间

应⽤系统从请求发出开始，到客⼾端接收到最后⼀个字节数据所消耗的时间
对于web系统⽽⾔，系统响应时间包含前端展现时间和系统响应时间
前端展现时间：⻚⾯渲染时间系统响应时间：包含服务器、数据库、通讯⽹络等响应时间

并发⽤⼾、系统吞吐量、系统响应时间之间的关系

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

事务

⼀个接⼝可以是⼀个事务，多个接⼝也可以是事务，⼀个流程可以是事务，事务代表⼀个完整的功能

TPS和QPS

TPS：每秒处理事务数，⽤于衡量系统在⼀定时间内能够处理的事务数

计算公式：总的事务数 / 总的运⾏时间
举例1：某⼀系统1分钟处理1000个业务，那么TPS = 1000 / 60 = 16.7
举例2：2022年最⾼的⼀天⼜10万笔交易，预测2023年TPS需要多少合格？认为每笔交易就是⼀个事务，理论TPS = 100000 / 24*60*60 = 1.2（理想状态），然⽽实际上订单量会在某段时间内突然增加，并不是平均到每个时间段内，因此
没有更详细的数据：根据⼆⼋定律（80%的事务在20%的时间内完成）
TPS = 100000 * 0.8 / 24*60*60*0.2 = 4.6 2）
如果有详细的数据：5万笔交易在晚上的8~9点完成的
TPS = 50000 / 60*60 = 13.9（实际还要参考往年业务的增⻓，假设每年业务增⻓30%，则TPS = 50000 + 50000*0.3 / 60*60 = 18）

QPS：每秒查询率

若⼀个事务中只有⼀个接⼝且是查询接⼝，则QPS = TPS；
资源利⽤率
通过查看系统占⽤的情况分析资源瓶颈
服务器：CPU、内存、磁盘、⽹络等

性能测试关注点

不同的⻆⾊看待性能测试的侧重点不同。从从客⼾端发起⼀个请求到客⼾端收到请求的整个过程中，各阶段都可能存在性能问题。

后端处理请求的性能问题
服务器硬件资源（CPU、内存、磁盘）
中间件、⽹络、数据库、架构设计等是否存在瓶颈。开发⼈员和测试⼈员并不需要关注全流程的性能问题。通过分析不同⻆⾊的侧重点，从⽽促进性能测试更好的开展。和软件系统性能相关的⻆⾊主要有四种

终端⽤⼾

对于终端⽤⼾来说，表现为⽤⼾进⾏业务操作时的主观响应时间。⽤⼾重点关注从你提交请求到收到响应的时间，包括系统响应时间和前端展现时间

系统运维⼈员

系统运维⼈员除了关注单个请求的响应时间，更关注⼤量⽤⼾并发访问时对系统的影响，以及更⼤负载情况下的系统健康状态。从⽽执⾏系统的整体的策略

关注全局利益最⼤化，对最⼤并发⽤⼾数和系统响应时间进⾏权衡取舍
系统并发处理时间、系统容量、数据库调优，以及⻓时间运⾏稳定性和可扩展性。

例如：当有以下两种⽅案时

A⽅案：100万并发访问⽤⼾，登陆响应时间3秒

B⽅案：500万并发访问⽤⼾，登陆响应时间8秒

这种情况下运维⼈员往往更更倾向于第⼆种

软件设计开发⼈员

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

例如：对于算法，要保证⾼效，⽆内存泄漏；对于架构，要保证系统容量和性能可扩展

性能测试⼈员⼯作重点在于性能测试场景的设计、脚本的开发和执⾏，以及性能缺陷的排查和定位

测试⼈员除了具有及其宽⼴的知识⾯，如系统架构，存储架构，⽹络架构等全局的知识，还要有⼤量知识积累，⽐如数据库SQL语句的执⾏计划调优、JVM垃圾回收、多线程常⽤问题等

可⻅性能测试的范围太⼤了，不同的⻆⾊对于性能有不同的处理⽅式

性能测试分类

基准测试

基准测试(Benchmark Testing)⼜称单⽤⼾测试，主要⽤于监测被测系统在较低压⼒下的运⾏状况并记录相关数据。当性能测试环境确定以后，通常选取业务模型中的重要业务做基准测试，对被测系统施加⼀定压⼒，从⽽获取被测系统在单⽤⼾运⾏情况下的各项性能指标，为多⽤⼾并发测试和混合场景测试等提供参考依据

并发测试

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

负载测试

负载测试(Load Testing)是性能测试的⼀种测试类型，⽤于评估被测系统在预期的不同负载下的⾏为。负载测试关注系统处理不同负载的能⼒，这些负载可通过控制并发⽤⼾或者进程的数量来实现。进⾏负载测试时，通过对系统不断增加并发访问负载，监测系统性能的变化，直到系统的某项或多项性能指标达到安全临界值，最终确定在满⾜该安全临界值的性能指标下，系统所能承受的最⼤负载量。简⽽⾔之，负载测试是通过逐步加载的⽅式来确定系统的处理能⼒。负载测试类似于举重运动，通过不断给运动员增加重量，确定运动员在其⾝体状况保持正常的情况下所能举起的最⼤重量。通过负载测试可以获取系统能够达到的峰值指标。

例如，⼀个软件系统的响应时间要求不超过2秒，如果在这个前提下不断增加⽤⼾访问量，系统的响应时间就会变⻓。假设当访问量超过1万⼈时系统的响应时间超过2秒，那么就可以确定在系统响应时间不超过2秒的前提下，系统的最⼤负载量是1万⼈。负载测试可⽤于系统的性能验证、性能诊断和性能调优等场景

压⼒测试

压⼒测试(Stress Testing)⽤于评估被测系统在⾼于预期、⾼于指定容量负载需求或低于最少需求资源的条件下的⾏为。压⼒测试关注被测系统处理超出预期或特定峰值负载的能⼒，也可以⽤于评估系统在资源匮乏时的处理能⼒，⽐如在可⽤的计算能⼒、带宽和内存资源不⾜的条件下系统的表现。进⾏压⼒测试时通常采⽤逐步增加系统负载的⽅式，使系统某些资源达到饱和甚⾄失效，从⽽发现那些只有在⾼负载条件下才会出现的缺陷，如同步问题、内存泄漏等。通过对被测系统进⾏压⼒测试，也能找出被测系统的性能拐点，获得系统所能提供的最⼤服务级别（系统所能承受的最⼤压⼒），评估系统在峰值负载或超出最⼤负载情况下的处理能⼒。压⼒测试主要⽤于性能诊断、性能调优和容量规划等场景。

压⼒测试和负载测试的区别?

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