目录：导读
- 前言
- 一、Python编程入门到精通
- 二、接口自动化项目实战
- 三、Web自动化项目实战
- 四、App自动化项目实战
- 五、一线大厂简历
- 六、测试开发DevOps体系
- 七、常用自动化测试工具
- 八、JMeter性能测试
- 九、总结（尾部小惊喜）
前言
1、混合业务场景的TPS计算方式
TPS的计算：
单业务与混合业务业务的基准测试场景构建
单业务测试
混合业务测试：登录-资料录入-发短信认证-核保
页面渲染+业务处理时间+思考时间=单次业务时间
5分钟内完成2000笔资料录入+发短信认证 计算平均并发（单位时间内平均能同时处理完成的录入+认证业务）
平均并发=（单次时间*业务量）/业务总时间
平均并发（5s*2000）/300=33
峰值并发=平均并发数+3*根号平均并发 =33+17=50
例如：TPS（Transaction per Second）：系统每秒处理交易数，推导过程如下，
当前线上APP1.0试⽤系统主要为查询类交易，交易占⽐40%，系统⽣产交易量统计为1个⽉约20W笔，假设APP2.0系统上线后业务量激
增到每⽇查询类20W，则每⽇总交易量T达到：
T = 20W/40%=500000笔/⽇
系统处理能⼒TPS推导：APP2.0上线后交易量最⼤500000笔/⽇,系统晚间⼏乎⽆交易量，按2：8原则推算，则(500000*80%)/(8*20%*3600)=69.4笔/秒，取整为70笔/秒，每年按业务量增长50%计算，则⼀年后系统处理能⼒指标约等于70+70*50%=105笔/秒。
稳定性交易量推导：取系统处理能⼒的60%*时长=105笔/秒*60%*8*3600=1814400笔。
2、TPS上不去哪些原因导致的？
1）网络带宽
在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，就会造成网络资源竞争，导致服务端接收到的请求数达不到服务端的处理能力上限。
2）连接池
可用连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行），没有保持长连接，TCP 连接频繁中断
3）GC
如果堆内存分配的不合理，就会导致频繁的gc，gc会导致线程暂停。尤其是fullgc，会造成线程长时间暂停，代码故障，list 使用 contain 方法进行遍历去重，线程阻塞或者死锁
jvm 内存分配故障，fullgc 频繁，内存溢出
4）数据库配置
高并发情况下，如果请求数据需要写入数据库且需要写入多个表的时候，数据库的最大连接数不够，或者写入数据的SQL没有索引，或没有主从分离、读写分离，就会导致数据库事务处理过慢，还有数据库没加索引，db 缓存空间不足，也会影响到TPS。
5）硬件资源
包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）
6）压力机
单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，会影响TPS（这个时候就需要进行分布式压测来解决问题）
7）其他中间件
Nginx 负载均衡策略不当，压力分配不均
Redis 瓶颈。hash 未合并，缓存被击穿，单条命令耗时过长
8）硬件资源中CPU和内存
服务器资源不足，上下文切换过快，中断过高，swap 交换频繁
压力大的时候tps频繁抖动，导致总tps上不去。
查看是否有fullgc（tail -f gc_mSrv1.log | grep full）
pacing设置太小也会导致tps上不去，对抖动大的交易多增加点用户即可。
tps抖动，单压抖动大的交易，发现很平稳，这时怀疑是不是压力太大导致，所以发容量的时候把压力最大的那只交易分到其他压力机，然后发现tps不抖动了。
注意：多台压力机只影响tps抖动，不会影响服务器的cpu。看响应时间有没有超时，看用户数够不够。
完整版！企业级性能测试实战，速通Jmeter性能测试到分布式集群压测教程
| 下面是我整理的2025年最全的软件测试工程师学习知识架构体系图 |
一、Python编程入门到精通
二、接口自动化项目实战
三、Web自动化项目实战
四、App自动化项目实战
五、一线大厂简历
六、测试开发DevOps体系
七、常用自动化测试工具
八、JMeter性能测试
九、总结（尾部小惊喜）
人生最珍贵的不是终点站的掌声，而是追梦路上的每一个脚印。当你觉得疲惫时，请记住：钻石经过打磨才能璀璨，雄鹰经历断羽才能高飞。你的坚持，正在书写属于自己的传奇篇章！
别让任何人定义你的极限！你拥有的不是天花板，而是等待突破的起点。那些看似不可能的梦想，终将在你日复一日的坚持中变得触手可及。你，就是自己人生的造梦者！
