前言

1、新上线项目

1)指标以目的为导向

容量验证——某软硬件条件下系统最大处理能力,为运维提供容量模型/预估
稳定性验证
有特定的预期指标(1~3年未来规划)

注:基准性能需提前把控(重点关注在无压力情况下的响应耗时)

2)业务模型

参考历史项目或其他同行业项目
业务产品综合评估

注:待系统上线后可观察一段时间,按照较为标准的业务模型在验

3)已上线系统

根据历史数据分析获取方式
请运维同学协助查看;通过现有监控平台等途径获取;
版本迭代(按照原预期)

性能需求指标

序号 指标类型 指标名称 指标要求 说明
1 系统指标 90%基准响应时间 ≤200ms 指无压力情况下从客户端发起业务请求到得到响应的整个过程所经历的时间
1 系统指标 90%负载响应时间 ≤1s 指在TPS满足预期指标负载下从客户端发起业务请求到得到响应的整个过程所经历的时间
2 系统指标 并发/在线用户数 XXX 在同一时刻与服务器进行交互(指向服务器发出请求)的在线用户数
3 系统指标 系统处理能力(TPS) XX笔/秒 每秒处理事务数(处理客户的请求数)
4 系统指标 查询类交易成功率 ≥99.9% 指交易成功的数量占发出的总交易量的百分比
4 系统指标 支付类交易成功率 ≥99.99% 指交易成功的数量占发出的总交易量的百分比
5 服务资源指标 CPU ≤90% CPU负载不得超过90%,生产正常超过60%会提示预警
6 服务资源指标 内存 / 内存无泄漏,GC正常
7 服务资源指标 磁盘I/O / 读写正常,无等待排队
8 服务资源指标 网络I/O / 数据传输上下行无阻塞异常
9 服务资源指标 无慢查询 <100ms 数据库SQL查询耗时

TPS折算方式:

常用的二八原则(80%的交易在20%时间内完成);
根据并发用户数:TPS=并发用户数/响应时间 ——不是特别推荐,也没有特别正确的推理,因为并发用户数本身是一个比较争议的点

响应时间定义方式:

基准200ms,负载1s(在满足TPS指标的情况下所涉接口需≤1s/3s)
业界定义:1357原则,1s优秀,3s良好,5s及格,7s不合格。随着用户对“快”的要求越来越高,一般的请求超过3s就不能接受。

用户数折算方式——不推荐

并发用户:同时对服务产生请求的用户总数
在线用户:所有正在访问系统用户(不一定作操作)
系统用户:系统额定的用户数量或者注册用户数
对于并发用户数的概念,很多时候都是模糊的,所谓官方推理或经验都不是很准确,这跟系统本身的属性有很大关系,以下几种折算方式仅供参考

在线人数:并发用户数峰值计算C^=C+3*根号C
1)平均并发用户数为 C = nL/T
2)并发用户数峰值 C‘ = C + 3*根号C

C是平均并发用户数,C’是并发用户数峰值,n是login session的数量,L是login session的平均长度,T是值考察的时间长度。

按照TPS进行计算:公式为 C = (Think time + 1)*TPS
并发用户数=TPS*响应时间

二八原则:(用户总量/统计时间)*影响因子(一般为3)来进行估算并发量。

比如,以乘坐地铁为例子,每天乘坐人数为5万人次,每天早高峰是7到9点,晚高峰是6到7点,根据8/2原则,80%的乘客会在高峰期间乘坐地铁,则每秒到达地铁检票口的人数为50000*80%/(3*60*60)=3.7,约4人/S,考虑到安检,入口关闭等因素,实际堆积在检票口的人数肯定比这个要大,假定每个人需要3秒才能进站,那实际并发应为4人/s*3s=12,当然影响因子可以根据实际情况增大!

据系统用户数计算:
并发用户数 = 系统最大在线用户数的5%到12%

2、并发压力测试TPS计算

三个概念:
用户数:数据库中的总用户数。
在线用户数:登录状态的用户数,挂在系统上,但是不会对系统产生压力。
并发用户数:真正产生操作的用户,产生压力之源。

①秒杀活动压测数据计算假如平台总注册用户数有100w,有10w用户约定好同时对某一接口进行访问。

比如1分钟,陆续来访10w用户,那么我们系统并发用户是比实际的10w要小的。

那一个秒杀活动开始时,10w用户在10秒内重复请求多次,平均3次每个人,那么tps=100000/10=10000tps。表明我们目标的tps应达到10000才能抗住100000用户的同时请求。

②领券活动压测平台注册用户数100w,用10w用户准备抢券,10w人同时在10秒内访问抢券接口。
在过程中每个用户可能会多次点击抢券,估算每个用户点击3次抢券接口。

那么,tps=100000*3/10=30000tps,系统的目标tps需达到30000才抗住10w用户的并发访问压力。

完整版!企业级性能测试实战,速通Jmeter性能测试到分布式集群压测教程

下面是我整理的2026年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

请添加图片描述

二、接口自动化项目实战

请添加图片描述

三、Web自动化项目实战

请添加图片描述

四、App自动化项目实战

请添加图片描述

五、一线大厂简历

请添加图片描述

六、测试开发DevOps体系

请添加图片描述

七、常用自动化测试工具

请添加图片描述

八、JMeter性能测试

请添加图片描述

九、总结(尾部小惊喜)

人生最动人的风景,往往藏在最险峻的山巅。当你觉得力竭时,请记住:每一次坚持都在重塑更强大的自己。别问路有多远,只管迈步向前;别怕山有多高,向上攀登就是答案!

你体内沉睡着改变世界的力量!每个清晨都是改写命运的新机会,每次挫折都是精心包装的礼物。当全世界都在说“不可能”时,正是你证明“可能”的最好时机!

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐