目录：导读
- 前言
- 一、Python编程入门到精通
- 二、接口自动化项目实战
- 三、Web自动化项目实战
- 四、App自动化项目实战
- 五、一线大厂简历
- 六、测试开发DevOps体系
- 七、常用自动化测试工具
- 八、JMeter性能测试
- 九、总结（尾部小惊喜）
前言
开始性能测试前需要了解的内容：
①项目具体需求。
②指标：响应时间在多少以内，并发数多少，tps多少，总tps多少，稳定性交易总量多少，事务成功率，交易波动范围，稳定运行时长，资源利用率，测哪些交易，哪些接口,测试哪些场景。
③环境：生产环境服务器数量，测试环境服务器数量，按照资源配比得出测试指标。
④协议：系统用什么协议进行通讯。
⑤压力机数量：如果并发用户数太多，需要把压力发到不同的压力机，不然可能会存在压力机瓶颈问题，导致tps和响应时间抖动。
⑥交易占比：分析线上日志得出tps占比。
⑦系统架构：请求流经过哪些环节，压测时监控这些环节。
测试：
①基准：一个用户迭代100次，关注响应时间，事务成功率100%。
②负载：10个用户跑10分钟，关注响应时间，事务成功率100%。
③容量：估算一个总tps，根据公式计算出每个交易的pacing和vu，获取系统最大处理能力（最优容量），再令外测出三个梯度作为对比（两组小于最优容量，一组大于最优容量），四组容量VU等差，tps等差。
对比每组容量实际占比和测试占比（越接近越能模拟真实场景），关注响应时间，总tps，tps，事务成功率，AP cpu利用率，DB cpu利用率，线程死锁，数据库死锁。
其中响应时间应小于负载测试时间，总tps应约等于预估总tps（相差不超过10是正常的），每个交易的tps应接近预估总tps*占比，事务成功率100%，AP cpu小于60%，DB cpu小于80%。dump线程栈检测是否有线程死锁，查看数据库日志看是否有数据库死锁。
④稳定性：采取最优容量的80%作为压力持续运行24小时，观察系统长时间运行的性能表现，关注响应时间，tps，总tps，事务成功率，交易总数。
观察是否有内存溢出（堆溢出，栈溢出，持久代溢出），cpu利用率是否达标，mem是否不持续增长，是否能正常触发fullgc，gc时间，gc频率， fullgc时间，fullgc频率（重点关注，JVM调优就是为了减少fullgc频率）。
监控：
容量测试和稳定性测试时启动nmon监控。
压测中遇到的性能问题及解决办法：
1、容量测试过程中cpu过高
①用vmstat实时监控cpu使用情况。很小的压力AP cpu却到了80%多，指标是不能超过60%。
②分析是use cpu过高还是sys cpu过高，常见的是use cpu使用过高。
③如果是sys cpu使用过高，先把消耗cpu最多的进程找出来（top命令），再找到该线程下消耗cpu过高的是哪几个线程，再把该线程转换成16进制，再用jstack命令来dump线程栈，看这个线程栈在调用什么东西导致use cpu过高。
2、内存溢出（堆溢出、栈溢出、持久代溢出）
1）堆内存溢出
①稳定性压测一段时间后，LR报错，日志报java.lang.OutOfMemoryError.Java heap space。
②用jmap -histo pid命令dump堆内存使用情况，查看堆内存排名前20个对象，看是否有自己应用程序的方法，从最高的查起，如果有则检查该方法是什么原因造成堆内存溢出。
③如果前20里没有自己的方法，则用jmap -dump来dump堆内存，在用MAT分析dump下来的堆内存，分析导出内存溢出的方法。
④如果应用程序的方法没有问题，则需要修改JVM参数，修改xms，xmx，调整堆内存参数，一般是增加堆内存。
2）栈内存溢出
①稳定性压测一段时间后，LR报错，日志报Java.Lang.StackOverflowError。
②修改jvm参数，将xss参数改大，增加栈内存。
③栈溢出一定是做批量操作引起的，减少批处理数据量。
3）持久代溢出
①稳定性压测一定时间后，日志报Java.Lang.OutOfMenoryError.PermGen Space。
②这种原因是由于类、方法描述、字段描述、常量池、访问修饰符等一些静态变量太多，将持久代占满导致持久代溢出。
③修改jvm配置，将XX:MaxPermSize=256参数调大。尽量减少静态变量。
3、线程死锁
①容量测试压测一段时间后，LR报连接超时。
②造成这种现象的原因很多，比如带宽不够，中间件线程池不够用，数据库连接池不够，连接数占满等都会造成连接不上而报超时错误。
③jstack命令dump线程栈，搜索线程栈里有没有block，如果有的话就是线程死锁，找到死锁的线程，分析对应的代码。
4、数据库死锁
①容量测试压测一段时间后，LR报连接超时。
②造成这种现象的原因很多，比如带宽不够，中间件线程池不够用，数据库连接池不够，连接数占满等都会造成连接不上而报超时错误。
③数据库日志中搜索block，能搜到block的话就是存在数据库死锁，找到日志，查看对应的sql，优化造成死锁的sql。
5、数据库连接池不释放
①容量测试压测一段时间后，LR报连接超时。
②造成这种现象的原因很多，比如带宽不够，中间件线程池不够用，数据库连接池不够，连接数占满等都会造成连接不上而报超时错误。
③去数据库查看应用程序到数据库的连接有多少个（ show full processlist），假如应用程序里面配置的数据库连接为30，在数据库查看应用程序到数据库的连接也是30，则表示连接池占满了。
将配置改成90试试，去数据库看如果连接到了90，则可以确定是数据库连接池不释放导致的。查看代码，数据库连接部分是不是有创建连接但是没有关闭连接的情况。基本就是这种情况导致的，修改代码即可。
6、TPS上不去
①压力大的时候tps频繁抖动，导致总tps上不去。查看是否有fullgc（tail -f gc_mSrv1.log | grep full）。
②pacing设置太小也会导致tps上不去，对抖动大的交易多增加点用户即可。
③tps抖动，单压抖动大的交易，发现很平稳，这时怀疑是不是压力太大导致，所以发容量的时候把压力最大的那只交易分到其他压力机，然后发现tps不抖动了。注意：多台压力机只影响tps抖动，不会影响服务器的cpu。
④看响应时间有没有超时，看用户数够不够。
7、服务器压力不均衡（相差1%-2%是正常的）
①跑最优容量的时候，四台AP只有一台cpu超过60%，其他三台都在60%以下。
②查看服务器是否有定时任务。
③查看是否存在压力机瓶颈。
④是否存在带宽瓶颈（局域网不存在此问题）。
⑤查看部署的版本，配置是否一样。
⑥可能别人也在用这些AP，因为同一台物理机上有很多虚拟机，因为别人先用，资源被别人先占了。
8、fullgc时间太长
①跑容量和稳定性的时候，出现LR报请求超时错误，查看后台日志是fullgc了，看LR几点报的错和日志里fullgc的时间是否对应，fullgc会暂停整个应用程序，导致LR前端没响应，所以报错，这时可以减少old代内存，从而减少fullgc时间，减少fullgc时间LR就不会报错，让用户几乎感觉不到应用程序暂停。
②四台AP轮流着full gc（部分server fullgc，其他server也会fullgc），这时可以制定策略让不同的server不同时fullgc，或者等夜间交易量少时写定时任务重启服务。
注意：
服务器日志为error下测试。
服务启动后几分钟内发压压力会很大，最好是服务启动两三分钟后再开始跑压力。
| 下面是我整理的2023年最全的软件测试工程师学习知识架构体系图 |
一、Python编程入门到精通
二、接口自动化项目实战
三、Web自动化项目实战
四、App自动化项目实战
五、一线大厂简历
六、测试开发DevOps体系
七、常用自动化测试工具
八、JMeter性能测试
九、总结（尾部小惊喜）
只有拼尽全力，才能争取到更好的未来；成功需要不懈的努力，坚持不懈才是胜利的关键；勇敢面对挑战，超越自我不断进步；只要心怀梦想，努力不息，就会收获美好的人生。
只有不断向前迈进，才能让自己更加优秀；只有勇敢地面对挑战，才能创造属于自己的辉煌。无论遇到什么困难和挫折，都要坚持不懈，不放弃，用自己的努力去实现梦想！
每一天都是一个全新的开始，无论过去发生了什么，都不要忘记你的目标和梦想。坚持努力，不断前行，成功就在不远处等待着你的到来。相信自己，勇往直前，成就辉煌人生！
