软件测试最新一次实战压测流程及问题梳理！(1)，软件测试开发视频教程

本文链接：https://blog.csdn.net/2401_84715732/article/details/138801267

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

接下来就是压测执行阶段了，我们除了对圈选的业务模块进行压测外，也对熔断、降级方案进行了验证。

压测过程中，除了服务本身的问题外（【记一次业务压测过程中发现的问题】），我们在压力评估及肉鸡配置上踩了不少坑。

压力评估

过往我们仅仅是通过CPU及内存使用率来判断容器压力，但是这是非常不准确的，一定要结合Load Average来看。

Load Average，描述系统处于RUNNABLE或UNINTERRUPTIBLE状态的进程，包含正在执行、等待执行以及不可中断状态的进程，当其大于CPU核数数，此时的CPU负载很可能就是有压力的。

关于UNINTERRUPTIBLE状态的进程？表名进程阻塞在磁盘IO或一些锁上，因此Load Average也能侧面反应出磁盘IO负载，这种情况可以通过off-cpu火焰图进行分析。

一般我们通过top可以看到最近1分钟、5分钟及15分钟的负载，但是实际上这三个值并不是准确的Load Average，它计算是基于指数衰减的移动加权累加得到的，变化的速度会慢于真实的负载。

图中为跑1个Thread时的负载，可以看到要到5分钟后Load Average才跑到接近1左右。因此，想要观察真正的负载需要保持一段时间的压力，我们压测时是按保持5分钟压力后的结果来定的。

容器内的Load Average

top命令中的Load Average是读取/proc/loadavg中的值，而在容器中，该目录是挂载宿主机的/proc，因此top看到的是宿主机的负载，无法真正区分容器中的值。

这里推荐大佬张师傅基于topic修改的ctop来进行观察。
（ github.com/arthur-zhan… ）

肉鸡配置及数量的评估

在压测的发起端，底层是通过JMeter实现的，为了能够保持一段时间的服务压力，我们是通过控制并发数而非请求总数来进行肉鸡配置的，可以简单的理解为1并发数就是一个线程持续的发起请求。

那么，如何将压测目标QPS转化为并发数配置呢？一个线程持续的发起请求，那么QPS是未知的，要怎么找到最合适的并发数配置呢？

这里可以拆解两步来分析：

单场景/接口压测，找到单场景目标QPS达成所需要的并发数。

这里有一个容易踩的坑，并发数的配置一定要在肉鸡、服务实例均无压力的情况下进行评估，评估方法可以结合前面提到的Load Average及99线。如果肉鸡压力大，CPU资源紧张，线程等不到CPU资源分片，导致QPS上不去，99线也会高出很多。

全场景压测，评估单台肉鸡的并发数配置及肉鸡数。

由于单台肉鸡的配置有限，所能支撑的并发数也会太高，所以我们需要估算出单台肉鸡的并发数配置。

这里可能有一个误区，并发数并不是要小于等于CPU核数。实际能支撑的并发数和接口的响应时间有关系，请求发出并等待返回的这段时间内，线程阻塞等待结果，此时是不占用CPU的。占用CPU的只有组装和发送请求、解析和判断返回的阶段，中间的等待阶段可以调度处理不同线程的任务。

这里的肉鸡并发数配置也有两种方式：

（1）按照单个场景/接口，单独下发脚本和并发数。这样做意味着不同的肉鸡在执行不同的压测脚本，能更好的控制并发数和目标QPS，但是需要能比较好的单独控制脚本下发和并发数配置；

举个栗子，

肉鸡A，4C8GB，下发场景1和场景3脚本，按并发数9、14进行多线程执行；肉鸡B，8C16GB，下发场景2脚本，按并发数112进行多线程执行。

这样不同的肉鸡配置各不相同，各自执行特定的场景脚本，优点是压测中各场景的目标QPS比较准确，符合预期，但是无论是自动化或手动配置都比较繁琐，无法快速批量扩大压测规模。

（2）按各场景不同的的并发数比例，计算单肉鸡的并发配置，再按目标并发数计算肉鸡数量，批量下发脚本及并发数配置。

该方式下，每台肉鸡都会收到全部场景的脚本和并发数配置，只需批量下发即可，最终通过控制肉鸡数量来达到全场景目标QPS值，优点是可以快速扩大压测规模，缺点是最终各场景的QPS比例可能偏差较大。

比如图中的场景3，4并发*3肉鸡=12并发，小于目标并发数，此时无论增加单肉鸡并发数还是肉鸡数量，也都会导致实际并发数与目标不一致。

其他

持续性压测更多观关注GC、有效吞吐占比及99线尖刺。

故障演练核心验证熔断是否能按预期生效，限流降级方案演练及有效性验证，如果有应急处理流程的话也可以进行全流程的演练。

5 - 压测总结及资源回收

这个阶段没什么好说的，总结过程、描述问题及解决方案、后续的优化策略以及压测流程、平台的后续建设方向等都可以一起讨论总结、沉淀为团队知识。

最后，最最重要的，不要忘了回收压测资源，因为很贵。

3、总结

本文更多是对压测流程上的一些经验总结，帮助找到合适的流程及方法来进行压测，后续也能基于流程不断迭代更新。从过程上看，我们在压测流程以及基础设施的建设上还比较原始，依赖人工调整、评估，也能对未来的压测平台建设提供方向。

行动吧，在路上总比一直观望的要好，未来的你肯定会感谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入群： 786229024，里面有各种测试开发资料和技术可以一起交流哦。

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取**【保证100%免费】** 在这里插入图片描述
软件测试面试文档
我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。在这里插入图片描述