性能测试——监控指标 & 性能测试模型 & 性能测试分类 & 性能测试的实施

本文介绍了性能测试的概念,包括系统性能的定义和性能测试的目的。重点阐述了性能测试的关键监控指标,如并发数、响应时间和吞吐量等。探讨了两种性能测试模型——曲线拐点模型和地铁模型,以及它们在性能调优中的应用。此外,文章还详细讲解了性能测试的分类,如基准测试、负载测试和压力测试等,并概述了性能测试的实施步骤,包括测试前期准备、脚本设计到测试分析与调优。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1 性能测试的概念
(1)什么是系统的性能?
系统性能是一个很大的概念,对一个软件系统而言包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等等。
(2)什么是性能测试?
性能测试是通过自动化的测试工具,模拟多种正常、峰值以及负载条件对系统各项性能指标进行测试。

2 性能测试的监控指标
(1)并发数:在同一时间,进行同一操作的用户数;
(2)响应时间:也叫作请求相应时间,是对请求做出响应的时间;
(3)事务响应时间:事务是一组密切相关的操作集合,事务响应时间是对这一组操作集合响应的时间;
(4)每秒事务通过数TPS:指每秒系统能够处理的事务的数量;
(5)点击率:每点击一次相当于向WEB服务器发送一次HTTP请求,点击率越大,服务器的压力也就越大;
(6)吞吐量:单位时间内,系统处理用户请求的数量,直接体现软件的承载能力(吞吐量的单位没有固定的);
(7)思考时间:真实的模拟用户的操作,思考时间是指每个请求或者操作时间的间隔时间;
(8)资源利用率:不同系统资源的使用情况。

3 性能测试模型
(1)理发店模型(曲线拐点模型)
A. 随着并发用户数的增加,在轻压力区的相应时间变化不大,比较平缓,进入重压力区后呈现增长趋势,进入拐点区后倾斜率增大,响应时间急剧增加;
B. 随着并发用户数的增加,吞吐量也在不断增加,进入重压力区之后逐渐平缓,到达拐点区时说明系统已将到达处理的极限,急剧下降;
C. 随着并发用户数的增加,资源利用率也在不断增加,进入重压力区后逐渐平缓,至拐点区时已经达到饱和状态。
(具体介绍可参考:

<think>嗯,用户这次想深入了解性能测试指标的制定方法和依据,看来是对系统性能评估有专业需求。之前我提到过基准值设定和业务需求挂钩,但用户现在更聚焦在“方法论”层面,需要结构化展开。从用户提供的引用看,关键线索不少:引用[1]强调预期指标需综合系统/商业/技术需求,引用[2]提到业务需求决定响应时间目标值,引用[3]展示TPS如何通过业务数据推算,引用[4]则列举数据库指标层级——这些正好构成指标定义的完整逻辑链。用户可能是个测试工程师或技术经理,正在搭建性能测试体系。ta特意强调“依据”,说明需要权威参考,不能只讲操作步骤。深层需求或许是希望说服团队采用科学化的指标制定流程。专业上需要分四层拆解:指标类型(用户感知层/系统资源层/中间件层)→数据来源(业务规模推导/技术限制/用户协议/SLA)→计算方法(峰值系数法/百分位法)→验证原则(可测量/可追踪)。特别要突出引用[3]的TPS公式案例,把数学推导具象化。最后用数据库指标案例落地(呼应引用[4]),再抛几个进阶问题:关于容器化指标适配、AI预测趋势、混沌工程中的指标变异——既能衔接用户专业深度,又预留扩展空间。</think> 性能测试指标的制定需综合业务目标、技术约束和用户体验,以下是系统化的定义方法及依据: ### 一、核心指标定义方法论 1. **业务需求驱动** - **交易量推导法**(引用[3]案例) $$TPS = \frac{\text{日交易量} \times \text{峰值占比}}{\text{时间窗口} \times \text{时间占比}}$$ 示例:日交易117.5万笔,取80%交易集中在20%时间(12小时),则: $$TPS = \frac{1,175,000 \times 0.8}{12 \times 0.2 \times 3600} \approx 109 \text{笔/秒}$$ - **依据**:业务增长预测、历史峰值数据、市场扩张计划 2. **用户体验基准**(引用[2]) | 操作类型 | 可接受响应时间 | 依据 | |----------------|----------------|--------------------------| | 简单查询 | ≤1秒 | 用户感知瞬时响应 | | 复杂事务 | ≤3秒 | 认知容忍阈值研究 | | 批量处理 | ≤10秒 | 进度条心理模型 | 3. **系统能力指标**(引用[4]) ```mermaid graph LR A[数据库指标] --> B[SQL耗时] A --> C[吞吐量-QPS] A --> D[缓存命中率] D --> E[索引缓冲区命中率] D --> F[InnoDB缓冲命中率] ``` ### 二、关键指标制定依据 1. **响应时间** - **业务依据**:用户满意度的黄金标准(如电商结账<2秒流失率降低37%) - **技术依据**:95百分位值(P95)确保绝大多数用户体验 2. **吞吐量(TPS/QPS)** - **计算公式**(引用[3]): $$\text{峰值TPS} = \frac{\text{预期交易量} \times \text{集中系数}}{\text{时间因子}}$$ - **容量规划**:需预留30%冗余应对突发流量 3. **资源利用率 | 资源类型 | 警戒阈值 | 依据 | |------------|----------|--------------------------| | CPU | ≤75% | 保留处理突发流量余量 | | 内存 | ≤70% | 避免频繁GC导致延迟波动 | | 磁盘IO | ≤60% | 规避I/O等待队列堆积 | ### 三、实施框架 ```python # 指标定义伪代码 def define_metrics(): business_require = get_business_data() # 获取117.5万笔/天等数据 user_experience = { # 引用[2] 'search': {'max': 1.0, 'p99': 0.8}, 'checkout': {'max': 3.0, 'p99': 2.5} } tech_limits = load_sla_config() # 硬件/中间件约束 # 计算TPS目标值(引用[3]方法) peak_tps = calculate_peak_throughput(business_require) return PerformanceTarget( response_time = user_experience, throughput = peak_tps, db_metrics = DB_METRICS # 引用[4]指标) ``` ### 四、验证原则 1. **可测量性**:所有指标需具备监控采集路径 2. **场景关联性**:登录场景侧重并发用户数,报表场景侧重内存泄漏 3. **基线迭代**:每季度依据业务量变化调整基准值(引用[1]) > **典型案例**:银行系统转账业务指标制定 > - 依据日均200万笔交易 + 促销期300%流量增长 > - 结合金融行业监管要求(<500ms响应) > - 通过SQL执行计划优化确保InnoDB缓冲命中率>98%(引用[4])
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值