---

前言

什么是性能测试？？

用工具模拟实际并发场景，发现系统问题，使系统上线后在接近的用户场景下不死。

具体解释？？

工程解释：
性能测试是针对系统的性能指标，建⽴性能测试模型，制定性能测试⽅案，制定监控策略，在场景条件之下执⾏性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满⾜既定值。

你在工作中经常做得三件事？？也叫性能测试的价值

分类：
性能验证：针对给定的指标，只做性能验证
性能测试：针对给定的系统做全面的性能测试，可以得到系
统的最大容量，但不涉及到调优 –-旧系统保证系统不衰减
性能测试+性能调优：针对给定的系统做全面的性能测试，

同时将系统调整到“最优”状态

意义：
验证系统上线之后是否可以稳定运行 第一层的含义
给出开发和运维人员提出线上的配置建议 第二层的含义
在满足业务要求的前提下，可以节省资源 第三层的含义
让你压几百，你就压，压了500个没有崩溃这种方法叫性能验证 一般性能都这么测试

10000 并发正常,40000万开始增加，50000并发满了 ，最大6万就崩了 一般的性能测试
一边压测，一边调整，各方面配置都很优秀，这就是性能调优的过程
一般在公司你就做，第一步第二步

常用性能测试的性能指标？

RT 响应时间 最重要指标（点一下页面按钮，到页面完成出来这就叫响应时间，包含前端点击，点击之后给接口发一个请求，页面返回的内容渲染在页面）

如果只看发到服务器的服务器的处理时间也叫rt根据具体事件定义

HPS 每秒点击数 ，f12加载好多页面，点击一次请求一次没啥价值

tps 每秒处理事务处（什么是事务？刚才的请求返回叫事务？可以，站在服务器角度收到给响应当一个事务？可行,数据库接到一个查询发出去？事务?也可以 ）

qps MySQL ，每秒收到的请求，把你的tps定义到数据库中就是qbs ，你调用接口只发一个数据库查询？可能不是1可能是10，当你把数据库查询当tps就是，你单测试数据库那就是tps，或者以数据库收到查询为主也等于tps

cps 请求页面返回的

pv 用户访问量 一天访问10000次 最大 都是1s 10000 最小 10000/24均分 跟性能没关系帮助你算并发

有时间，时间段访问高。按公司来，比如十分钟二百次，200/10*60 这个接近最大峰值 ，提供的数据越详细我的设计就越细

uv 独立访问者

注意：pv,uv这两个是用来帮助你算tps的 只给你每天的用户访问10000 每秒的tps=10000/246060=0.115 想要接近真实就要有更详细的数据

找到每个时间端访问的最大值 比如今年某个十分钟二百次最多访问，200/10*60 这个接近最大峰值 ，提供的数据越详细我的设计就越细

吞吐量 每秒处理的数目，吞吐量在jmeter就是tps JMETer报告会带上 吞吐量就等于tps 在Jmeter

出错率 error

对应的资源使用率

总结性能测试只关注四个重要点：响应时间（rt） ,tps每秒处理事务处,错误率，对应的资源使用率，也叫资源使用范围

登录和下单的测试 ，为什么分别测试要组合一起测试？

贴近真实用户场景
登录接口 测试 单交易压测
下单接口 测试
登录-下单 测试 混合场景

性能测试先做单交易在测试混合场景 ，首先清除单独业务的响应时间和大体的情况

测试前期要在服务器内网压测！！也
就是说你的服务器是11，你要在这个网络内找一台机器去压他

举例子几个性能测试指标 第一 指标怎么定的？？？要具体算出来

第二设计场景

验证被测场景是否满足目标tps
验证被测场景最大支持的tps，找到拐点

第一个tps 1s83个 就是开83个线程 持续时间一小时 看tps是否符合

第二个就是如果第一个不够的话，就加服务器，开发该配置，然后够的话就继续压，看tps最大到多少下降找到拐点，同事还要考虑tps的响应时间是否在范围内

比如：抢火车票，一个人测试没问题，多个人用的时候会引发问题？为什么多个人用会有问题？

代码的问题，有的代码写的死循环？一个人写了慢了点，多个人使用产生很大cpu，死循环占cpu

功能测试就是一个人装一个假肢能装上就行，性能测试看看他使用的效果是不是好用

性能测试是通过自动化的测试工具模拟多种正常 -解析通过工具去模拟

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

负载测试和压力测试都属于性能测试，两者可以结合进行 这句话不太科学

通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。 负载不断的增加压力

压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。找最大容量

进程和线程，线程是通过cpu去调度的，每个线程就是一个用户

响应时间不是你可以控制的

性能指标设计的方法！！

第一种 老系统无历史数据/日志监控/用户分析参考
拍脑袋，压500 压1000 做了也没有意义，其实也有就是性能验证了
根据竞品，参考老系统，你的新系统根据老系统参考测试拿到tps

第二种有上游

有pv 用户访问量 和uv用户量
根据2.8原则来，80%的任务产生 在20%的时间内 ，每个公司业务不一样，有的是1，9，4，6原则

第二—根据业务来 如果你拿到一天一万业务量 最好拿到分钟和小时的，一天的交易总量，就找每小时，看不到就用2.8

1万除以24*3600 这样算出来的是100%
二八算法 8000除以 24*3600*0.2 这样比上面强 没有办法情况下二八原则
也就是说你每天80%的业务量除以20%的业务量，均分到每s ，算出tps

假定一天是10000访问量
不算二百，百分之百业务发生在100%时间 tps很小
二八算法 1000080% /24606020% 这样算出来的tps肯定比按天算大

第三：那没给你找个业务一天的uv活跃用户在线数目？？？？？？？
uv活跃用户数，能拿到小时最好，拿不到就乘以3%-5%算出来tps 在根据响应时间算出虚拟用户线程

模拟用户一千个用户如何模拟，根据并法度百分之3%-5%，一千个用户就是30到五十个在线

总结：获取以下场景的 交易数以及各个业务比例分配

场景一：交易峰值日（10-28）交易峰值小时
场景二：交易峰值日（10-28）每个核心业务的峰值小时
场景三：登录业务峰值日(10-25) 核心业务峰值小时
场景四：产品查询业务峰值日(10-26) 核心业务峰值小时
场景五：优惠码兑换业务峰值日(10-27) 核心业务峰值小时
场景六：普通交易日(10-31) 交易峰值小时

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

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

别让“我不行”成为你的口头禅，你的潜力远未被发掘。每一次尝试都在拓展能力的边界，每一次突破都在重塑自信的高度。相信自己，你能行！

种一棵树最好的时间是十年前，其次是现在。别让“太晚了”成为借口，今天就是你余生中最年轻的一天。行动起来，让梦想在当下生根发芽！