原创 软件测试常见性能问题案例分析

在用户场景不确定的情况下，我们为了保障软件的正常运行就必须对软件的性能进行测试。下面我们一起来看看在软件测试中常见的性能问题，希望大家可以通过这七个比较典型的案例分析，充分掌握各种性能问题的解决方法。

案例一：某次压力测试，系统CPU等指标较正常，但偶发间断时间请求耗时特别高

|[Full GC (Ergonomics) [PSYoungGen: 944K-> 890K(2048K)]

[ParOldGen: 7129K-> 7129K(7168K)18074K->8019K(9216K),

[Metaspace: 3357K-> 3357K(1056768K0], 0.1213761 secs| [Times:

user=2 sys=0.00, real=2 secs]

JVMGC问题:

Full GC Stop the world

减少FullGC时间，老年代降低

案例二：某次压力测试，php 程序, php-fpm内存增长，OOM导致服务挂掉。

排查原因，使用了某第三方so插件做JSON解析，但第三方so插件有内存泄漏问题。

Max-request, fast-cgi 固定请求数后重启。

案例三：某次压力测试，同样并发TPS,但前期性能良好，后期数据库CPU飙升

压测会产生大量级的数据，数据增长会带来性能的损耗

压测数据不合理，导致统一设备 关联多个用户，服务端不做限制的in查询

不合理分页，未做页数limit,导致将数据库新增数据全部查询

案例四：某次稳定性测试，如果HTTP入口流量仅百QPS，但下游RPC服务打挂。

商户列表，For 循环调用下游解决，导致请求数百倍扩大。

使用Batch接口减轻压力，Batch 接口可能带来的功能隐患。

案例五：某次稳定性测试，大并发TPS，前期性能良好，分片缓存，在模拟缓存单点失效后大量数据库穿透。

缓存不合理的分片策略，使用除模方式。导致大量缓存统-一时间失效。

不合理的负载均衡算法也会有类似问题。

一致性Hash解决缓存问题。

案例六：某次压力测试，服务端CPU飙升打满。CPU计算型

Top -H -P pid

Pstack pid

Trace -p pid

代码逻辑问题：

同步解析接口，使用正则方式匹配返回内容，但由于返回内容过大，导致CPU飙升。正则，大数据的JSON序列化反序列化。

另外死锁问题也可以通过类似方式调优CPU不高，但服务响应耗时高，请求堆积。

案例七：某次压力测试，CPU/内存/网络 等指标表现良好，但响应耗时非常久。

监控查看磁盘I0异常，追查发现日志级别设置为Debug，大量日志打印拖累性能。

同步日志，可能是潜在的性能杀手。

以上就是软件测试常见性能问题的案例分析，大家都能够解决了吗？如果对于软件测试还有深入学习的兴趣，不妨上博学谷官网，体验一下软件测试就业班的免费课程！