性能测试 | 认识性能测试的概念以及应用
性能测试
- 认识性能测试
- 性能测试策略
- 1. 基准测试
- 2. 负载测试
- 3. 稳定性测试
- 4. 压力测试
- 5. 并发测试
- 性能测试指标
- 1. 响应时间
- 2. 并发数
- 3. 吞吐量
- 1. 吞吐量----QPS
- 2. 吞吐量----TPS
- 4. 点击数
- 5. 错误率
- 6. 资源shiyonglv
- 性能测试流程
- 1. 性能测试需求分析
- 2. 性能测试计划和方案
- 3. 性能测试用例
- 4. 性能测试执行
- 5. 性能测试分析和调优
- 6. 性能测试报告
- 性能测试工具
- 一、开源性能测试工具(成本低,灵活性高)
- 1. Apache JMeter(最常用开源工具) ⭐
- 2. Gatling(高并发场景首选)
- 3. Locust(代码化脚本,轻量灵活)
- 4. k6(DevOps友好,API测试首选)
- 二、商业性能测试工具(功能强,成本高)
- 1. Micro Focus LoadRunner(老牌商业工具)
- 2. NeoLoad(云原生友好,新兴商业工具)
- 三、专项性能测试工具(针对特定场景)
- 工具选择建议
基础色:red(红色)、blue(蓝色)、green(绿色)、black(黑色)、white(白色)
特殊色:pink(粉色)、purple(紫色)、orange(橙色)、gray(灰色)
#ff0000(红色)、#0000ff(蓝色)、#ffff00(黄色)、#333333(深灰色)
性能测试:满足真实的业务场景(活动场景)、支持大量的用户,满足商用要求
认识性能测试
什么是性能?
-
性能:就是软件质量属性中的"效率特性。 关注时间和资源
- 时间:系统处理用户请求的响应时间 - 资源:系统运行过程中,系统资源的消耗情况
什么是性能测试?
- 性能测试概念:使用
自动化工具
,模拟不同的场景,对软件各项性能指标
进行测试和评估的过程
- 性能测试的目的
- 评估当前系统能力
- 例如:验收第三方提供的软件
- 例如:验收第三方提供的软件
- 寻找性能瓶颈 优化性能
- 评估软件是否能够满足未来的需要
- 性能测试与功能测试
性能测试只针对于正向功能测试
一般是先进行功能测试,后进行性能测试
性能测试策略
1. 基准测试
基准测试是性能测试的核心基础类型之一,本质是在 “稳定、可控的特定环境” 下,对系统施加 “标准、可重复的负载”,采集并记录系统关键性能指标,最终建立一套可用于后续对比的 “性能基准值”。它不追求 “突破系统极限”,而是聚焦 “建立参考标准”,为后续性能优化、版本迭代、环境变更的效果验证提供 “参照物”。
- 狭义概念
狭义上讲:就是单用户测试。测试环境确定后,对业务模型中的重要业务做单独的测试,获取单用户运行时的各项性能指标。
- 广义概念
广义上讲:是一种测量和评估软件性能指标的活动。你可以在某个时刻通过基准测试建立一个已知的性能基准线,当系统的软硬件环境发生变化之后再进行一次基准测试以确定变化对性能的影响。
- 小节
基准测试不会单独存在,为多用户并发测试和综合场景测试等提供参考依据
在这个图中,定义了三条曲线、三个区域、两个点以及三个状态描述。三条曲线:吞吐量的曲线(紫色)、利用率(绿色)、响应时间曲线(深蓝色)。
三个区域:轻负载区(Light Load)、重负载区(Heavy Load)、塌陷区(Buckle Zone)。
两个点:最优并发用户数(The Optimum Number of Concurrent Users)、最大并发用户数(The Maximum Number of Concurrent Users)。
三个状态描述:资源饱和(Resource Saturated)、吞吐下降(Throughput Falling)、用户受影响(End Users Effected)。
2. 负载测试
电商系统平时可以正常运行,双11时能保证也可以正常运行吗?
通过逐步增加系统负载,确定在满忌系统的性能指标(如响应时间等)情况下,找出系统所能够承受的最大负载量的测试。系统最大负载量达到用户要求时,系统才能正式上线使用。
3. 稳定性测试
电商系统能抗住双11时的考验能保证长时间运行不出问题吗?
在服务器稳定运行(用户正常的业务负载下)的情况下进行长时间测试(1天-1周等),并最终保证服务器能满足线上业务需求。
系统在用户要求的业务负载下运行达到规定的时间时,系统才能正式上线使用。
- 性能测试负载测试稳定性测试
(1)在(A-B)范围内,增加系统的在线用户数,系统的处理能力(负载量)会增大(轻压力区)
(2)在(B-C)范围内,增加系统的在线用户数,系统的处理能力(负载量)不变(重压力区)
(3)在(C-D)范围内,增加系统的在线用户(1)在(A-B)范围内,增加系统的在线用户数,系统的处理能力(负载量)会增大(轻压力区)
(2)在(B-C)范围内,增加系统的在线用户数,系统的处理能力(负载量)不变(重压力区)
(3)在(C-D)范围内,增加系统的在线用户数,系统的处理能力(负载量)会减小(崩溃区)
(4)系统能处理的最大负载用户数量为(接近B),极限负载用户数量为(接近C)
(5)系统长时间稳定运行时的推荐用户数量为(A-B)
(6)需求要求:系统在正常使用(长时间使用)时的用户量为(B-C)区间,考虑是否有性能问题
4. 压力测试
- 为什么要进行压力测试?
- 软件实际使用时,用户量超过预期(系统最大负载量),该如何反应?
- 软件由于意外情况出现问题,多久能恢复?
在强负载下的测试,查看系统在峰值情况下是否功能隐患、系统是否具有良好的容错能力和可恢复能力。
5. 并发测试
秒杀的情况下
并发测试(绝对并发):是指在极短的时间内,发送多个请求,来验证服务器对并发的处理能力。
负载测试可以理解为相对并发
性能测试指标
1. 响应时间
响应时间:指用户从客户端发起一个请求开始,到客户端接收到从服务器端返回的结果,整个过程所耗费的时间。
注意:
- 通过HTTP接口请求消息来测试
- 不包括发消息时前端页面的处理时间和收到消息后前端页面的渲染显示时间
2. 并发数
并发(用户)数:某一时刻同时向服务器发送请求的用户数。
3. 吞吐量
吞吐量(Throughput):指的是单位时间内处理的客户端请求数量直接体现软件系统的性能承载能力。
1. 吞吐量----QPS
QPS(Query Per Second)每秒查询数:即控制服务器每秒处理的指定请求的数量
2. 吞吐量----TPS
TPS(Transactions Per Second)每秒事务数:即控制服务器每秒处理的事务请求的数量
- (3)QPs和TPs有什么关系?
事务,即业务。一个事务可以对应一个请求/多个请求
- 一个事务对应一个请求时:TPS=QPS
- 一个事务对应n个请求时:QPS=n*TPS
4. 点击数
点击数:指客户端向服务端发送请求时,所有的页面资源元素(如:图片、链接、框架css、js等)的请求总数量。
5. 错误率
错误率:指系统在负载情况下,失败业务的概率。错误率=(失败业务数/业务总数)*100%。
注意:
- 大多系统都会要求错误率无限接近于0
- 不是功能上的随机bug
6. 资源shiyonglv
同资源管理器的使用
资源使用率:是指系统各种资源的使用情况,一般用"资源的使用量/总的资源可用量×100%”形成资源利用率的数据。。
性能测试流程
1. 性能测试需求分析
2. 性能测试计划和方案
01测什么项目背景测试目的测试范围
02谁来测进度与分工交付清单
03怎么测测试策略
3. 性能测试用例
4. 性能测试执行
5. 性能测试分析和调优
说明:性能测试分析人员经过对结果的分析以后,如果不符合性能需求,则会提出性能Bug,然后由开发人员进行后续的调优。
6. 性能测试报告
测试报告是对性能测试工作的总结,为软件后续验收和交付打下基础。
测试报告的主要内容:
- 测试工作的经过回顾
- 缺陷分析和调优
- 风险评估
- 性能测试结果
- 测试工作总结与改进
性能测试工具
性能测试工具是用于模拟用户负载、采集系统性能指标(如响应时间、吞吐量、资源使用率等)、分析系统瓶颈的工具,按功能、开源/商业属性可分为多种类型。以下是主流性能测试工具的核心特点、适用场景及优缺点:
一、开源性能测试工具(成本低,灵活性高)
1. Apache JMeter(最常用开源工具) ⭐
-
核心特点:
基于Java开发,支持多协议(HTTP/HTTPS、FTP、数据库JDBC、SOAP、WebSocket等),可模拟多种场景(接口测试、Web应用、移动端、数据库性能等)。
提供可视化界面,支持通过“线程组、采样器、断言、监听器”等组件配置测试流程,无需代码基础即可上手。
支持分布式测试(多机联合施压),可模拟数万并发用户。 -
适用场景:
中小型Web/APP性能测试、接口性能验证、数据库压力测试,尤其适合测试团队中“非开发背景”人员使用。 -
优缺点:
✅ 优点:功能全面、社区活跃(问题易解决)、支持二次开发(Java扩展)。
❌ 缺点:高并发下(如10万+用户)资源消耗大(内存/CPU占用高),脚本复杂时维护成本高。
2. Gatling(高并发场景首选)
-
核心特点:
基于Scala语言开发,采用异步非阻塞架构,性能远高于JMeter,单机能轻松模拟10万+并发用户,资源消耗极低。
脚本通过代码(Scala/Java/Kotlin)编写,支持版本控制,适合开发团队协作;提供实时可视化报告(HTML格式),包含响应时间分布、吞吐量趋势等。 -
适用场景:
高并发场景(如电商秒杀、直播平台峰值测试)、需要精准控制请求逻辑的复杂场景,适合“开发+测试”协同的团队。 -
优缺点:
✅ 优点:高性能(低资源消耗)、脚本可维护性强、报告直观。
❌ 缺点:需掌握基础编程(Scala等),学习曲线较陡;可视化界面较弱(主要依赖代码配置)。
3. Locust(代码化脚本,轻量灵活)
-
核心特点:
基于Python开发,完全通过代码(Python)定义测试场景(无图形界面),脚本简洁易读,支持复杂业务逻辑(如用户登录→浏览→下单的流程)。
采用分布式架构,支持多机协同施压;提供Web监控界面(实时查看并发数、响应时间等)。 -
适用场景:
开发人员主导的性能测试、需要快速编写复杂场景脚本的场景(如用户行为链测试),尤其适合Python技术栈团队。 -
优缺点:
✅ 优点:脚本灵活(Python生态支持丰富)、分布式部署简单、轻量级(安装即用)。
❌ 缺点:协议支持较少(主要依赖Python库扩展),高并发下性能略逊于Gatling。
4. k6(DevOps友好,API测试首选)
-
核心特点:
基于Go语言开发,轻量级命令行工具,脚本用JavaScript编写,专注于API(REST、GraphQL、WebSocket)性能测试。
原生支持CI/CD集成(如Jenkins、GitLab CI),可在开发阶段嵌入自动化性能测试;提供简洁的指标输出(通过命令行或JSON/HTML报告)。 -
适用场景:
API性能自动化测试(如接口发布前验证性能)、DevOps流程中的性能门禁(如性能不达标则阻断部署)。 -
优缺点:
✅ 优点:轻量快速、CI/CD集成友好、API测试体验佳。
❌ 缺点:功能较单一(主要针对API),不适合复杂UI场景。
二、商业性能测试工具(功能强,成本高)
1. Micro Focus LoadRunner(老牌商业工具)
-
核心特点:
行业标杆工具,支持几乎所有主流协议(Web、移动端、大数据、云服务等),可模拟百万级并发用户。
提供“VuGen(脚本生成)、Controller(场景控制)、Analysis(结果分析)”三大模块,支持复杂场景设计(如混合业务比例、阶梯式加压)和深度瓶颈分析(结合服务器监控数据)。
采用C语言编写
-
适用场景:
大型企业级应用(如银行核心系统、ERP系统)的全链路性能测试,需要精准定位瓶颈(从前端到数据库、中间件)的场景。 -
优缺点:
✅ 优点:功能全面、协议支持最广、分析能力强,IP欺骗功能。
❌ 缺点:成本极高(按并发数/许可证收费)、学习复杂(需专业培训)、资源消耗大。
2. NeoLoad(云原生友好,新兴商业工具)
-
核心特点:
较新的商业工具,支持云原生应用(K8s、微服务)、移动应用、API等场景,脚本可通过“录制+可视化编辑”生成,也支持代码扩展。
内置AI辅助功能(如自动识别性能瓶颈、推荐优化方案),支持与云平台(AWS、Azure)集成,适合分布式云环境测试。 -
适用场景:
云原生应用性能测试、企业级Web/APP混合场景,需要快速定位瓶颈并生成优化建议的团队。 -
优缺点:
✅ 优点:云原生支持好、AI辅助分析、易用性强。
❌ 缺点:成本较高(低于LoadRunner)、在超大规模场景下的稳定性略逊于LoadRunner。
三、专项性能测试工具(针对特定场景)
- 数据库性能:pt-query-digest(分析MySQL慢查询)、Oracle AWR(Oracle性能报告)、SQL Server Profiler(SQL Server查询监控)。
- 前端性能:Lighthouse(Chrome插件,分析前端加载速度、资源优化)、WebPageTest(多地点前端性能对比)。
- 服务器/中间件监控:Prometheus + Grafana(监控服务器CPU/内存、Redis/Kafka等中间件指标)、Nagios(系统资源告警)。
工具选择建议
- 团队技术栈:Python团队优先选Locust,Java/Scala团队优先选Gatling,非开发团队优先选JMeter。
- 测试场景:高并发选Gatling,API自动化选k6,企业级全链路测试选LoadRunner/NeoLoad。
- 成本预算:开源工具(JMeter/Locust)适合低成本需求,商业工具适合大型企业复杂场景。
实际测试中,常结合“施压工具(如JMeter)+ 监控工具(如Prometheus)”使用,既模拟负载,又全面采集系统资源指标,更精准定位瓶颈。