性能测试方法汇总+性能响应很慢排查方法（详全）

前言

1、性能测试包含哪些内容？

1）负载测试

负载测试是指在特定条件下，对软件产品的性能进行测试和评估。测试人员可以通过模拟不同的用户数量、并发请求、访问频率等条件，来评估软件产品在不同条件下的性能表现。

2）强度测试

强度测试是指在资源有限的情况下，对软件产品的性能进行测试和评估。测试人员可以通过模拟资源紧张的情况，例如限制CPU使用率、内存容量等，来评估软件产品在资源受限条件下的性能表现。

3）数据库容量测试

数据库容量测试是指通过插入一定数量的数据，来评估软件产品在处理大量数据时的性能表现。测试人员可以通过模拟大量数据的插入操作，来观察软件产品的性能表现。

4）并发测试

并发测试是指在多个用户同时访问软件产品时，对软件产品的性能进行测试和评估。测试人员可以通过模拟多个用户同时访问软件产品，来观察软件产品在并发访问条件下的性能表现。

5）容量测试

容量测试是指在一定的软、硬件条件下，通过构造不同数量级的记录数量，来评估软件产品在给定虚拟用户数量下的性能表现。

测试人员可以通过模拟不同数量级别的用户数量，来观察软件产品在不同负载下的性能表现。

6）稳定性测试

稳定性测试是指在软件产品运行过程中，对其性能和稳定性进行测试和评估。测试人员可以通过模拟实际场景，如网络故障、负载峰值等，来评估软件产品在面临异常情况时的性能表现和稳定性。

7）配置测试

配置测试是指在软件产品发布前，对其配置信息进行验证和确认的测试。测试人员可以通过检查和验证软件产品的配置信息是否正确无误，来确保软件产品能够在发布后正常运行。

8）网络测试

网络测试是指对软件产品在网络环境下的性能进行测试和评估。测试人员可以通过模拟不同的网络环境，如稳定的局域网环境和繁忙的广域网环境，来评估软件产品在不同网络环境下的性能表现。

9）安全测试

安全测试是指在保障软件产品的数据安全和用户隐私的前提下，对其进行测试和评估。

在进行性能测试时，还可以通过对软件产品进行压力测试来评估其在不同条件下的性能表现。

压力测试是通过模拟大量用户同时访问软件产品或系统，来测试其在高负载情况下的性能表现。通过对软件产品进行压力测试，可以发现软件产品在高负载下的性能瓶颈，并对其进行优化。

2、性能测试响应很慢怎么排查？

大多数的性能测试工作人员分为以下三个阶段：

1）出了问题看资源，资源占用如果很高，报以窃喜的心态，恩，发现了，原理是资源瓶颈。

2）资源没有出现瓶颈，通过一些技术手段分析，发现是组件的配置文件有问题，例如：server的并发策略有问题，带宽有问题，找到了线路短板性能中的短板，到了这个阶段在我看来是比较牛的测试。

3）以上均无问题的情况下，考虑数据结构和算法我个人接触到的来说，现在大多数的人员都是在仰望第二阶段，摸索第三阶段。

希望从代码级发现出性能的问题，进行问题的发现和解决，也符合我们的bug越早发现修复的成本越低的理论。同时，也是一名性能测试工程师高薪的象征。

性能测试调优哪些方面入手，如下几点：

TPS波动较大：

原因解析：出现TPS波动较大问题的原因一般有网络波动、其他服务资源竞争以及垃圾回收问题这三种。

性能测试环境一般都是在内网或者压测机和服务在同一网段，可通过监控网络的出入流量来排查；

其他服务资源竞争也可能造成这一问题，可以通过Top命令或服务梳理方式来排查在压测时是否有其他服务运行导致资源竞争；

调优方案：
网络波动问题，可以让运维同事协助解决（比如切换网段或选择内网压测），或者等到网络较为稳定时候进行压测验证；

资源竞争问题：通过命令监控和服务梳理，找出压测时正在运行的其他服务，通过沟通协调停止该服务（或者换个没资源竞争的服务节点重新压测也可以）；

垃圾回收问题：通过GC文件分析，如果发现有频繁的FGC，可以通过修改JVM的堆内存参数Xmx，然后再次压测验证（Xmx最大值不要超过服务节点内存的50%！）

高并发下大量报错：

原因解析：常见的原因有短连接导致的端口被完全占用以及线程池最大线程数配置较小及超时时间较短导致。

调优方案：
短连接问题：修改服务节点的tcp_tw_reuse参数为1，释放TIME_WAIT scoket用于新的连接；

线程池问题：修改服务节点中容器的server.xml文件中的配置参数。

集群类系统，各服务节点负载不均衡：

原因解析：出现这类问题的原因一般是SLB服务设置了会话保持，会导致请求只分发到其中一个节点。

调优方案：
可通过修改SLB服务（F5/HA/Nginx）的会话保持参数为None，然后再次压测验证；

并发数不断增加，TPS上不去，CPU使用率较低：

原因解析：SQL没有创建索引/SQL语句筛选条件不明确、代码中设有同步锁，高并发时出现锁等待；

调优方案：
SQL问题：没有索引就创建索引，SQL语句筛选条件不明确就优化SQL和业务逻辑；

同步锁问题：是否去掉同步锁，有时候不仅仅是技术问题，还涉及到业务逻辑的各种判断，是否去掉同步锁，建议和开发产品同事沟通确认；

压测过程中TPS不断下降，CPU使用率不断降低：

原因解析：出现这种问题的原因可能是因为线程block导致，当然不排除其他可能；

调优方案：
如果是线程阻塞问题，修改线程策略，然后重新验证即可；

性能测试调优应该注意的要点：

要点 1：在应用系统的设计开发过程中，应始终把性能放在考虑的范围内。
要点 2：确定清晰明确的性能调优目标是关键。
要点 3：必须保证性能调优后的程序运行正确。
要点 4：系统的性能更大程度上取决于良好的设计，调优技巧只是一个辅助手段。
要点 5：性能调优过程是迭代渐进的过程，每一次调优的结果都要反馈到后续的代码开发中去。
要点 6：性能调优不能以牺牲代码的可读性和可维护性为代码。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

​

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！