---

前言

1、TPS上不去的原因

1）网络带宽

在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。

2）连接池

可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。

3）垃圾回收机制

从常见的应用服务器来说，比如Tomcat，因为java的的堆栈内存是动态分配，具体的回收机制是基于算法，如果新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收较频繁，那么对TPS也是有一定影响的，因为垃圾回收其本身就会占用一定的资源。

4）数据库配置

高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等，就会导致数据库事务处理过慢，影响到TPS。

5）通信连接机制

串行、并行、长连接、管道连接等，不同的连接情况，也间接的会对TPS造成影响。

6）硬件资源

包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。

7）压力机

比如jmeter，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决其单机负载的问题）。

8）压测脚本

还是以jemter举个例子，之前工作中同事遇到的，进行阶梯式加压测试，最大的模拟请求数超过了设置的线程数，导致线程不足。

提到这个原因，想表达意思是：有时候测试脚本参数配置等原因，也会影响测试结果。

9）业务逻辑

业务解耦度较低，较为复杂，整个事务处理线被拉长导致的问题。

10）系统架构

比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过期等，都会影响到测试结果。

PS：性能瓶颈分析不能单从局部分析，要综合起来，多维度分析问题原因。上面列出的几点，可能有描述不当或者遗漏的，仅供参考。

2、性能测试四大流程

1）需求阶段

①提出需求

性能测试一定是先有需求，才可以决定要不要继续执行。而性能需求的提出方，可以是开发（觉得某个接口慢）、可以是运维（对某个系统的服务能力进行容量评估）；

也可以是测试人员（从需求评审中分析出某个需求需要进行性能测试来规避风险）、更可以是产品（线上问题直接表现&用户反馈）。

而上图中项目负责人的角色不一定必须是岗位title意义上的PM角色，而是需要这么一个角色来做好居中沟通、资源协调的工作。

②需求评审

不经过评审的需求往往有很多坑！！！只有多方相关人员参与评审，从各自的角度给出意见，沟通达成一致，才能决定后续的要不要做？怎么做？以及谁来做什么事情！

③需求调研

需求调研阶段主要是对后续性能测试实施的一些必要信息进行更细致的沟通和确认，以及在职责、工时、排期、交付时间这几点上寻求平衡的可接受的点。

2）准备阶段

①环境准备

无论是功能测试还是自动化或者性能测试，总是需要一个合适的环境来进行。

对性能测试来说，无论是环境选择（生产or性能测试环境）还是申请对应的资源（虚拟机&云服务器&docker），一般都需要运维工程师来进行搭建配置。

②应用部署

性能测试的被测应用必须是稳定的，没有P2及以上缺陷或通过回归测试的版本包，根据每个公司的职责定位不同，应用部署一般是开发进行部署，或开发提供对应的代码路径，运维进行拉取部署。

③数据准备

性能测试对数据的要求是很高的，无论是数据量级、精准度抑或是数据的多样性。一般分为如下几种数据类型：

铺底数据：最常见的准备方式为从生产拖库最新的最完整的基础数据来作为性能测试所用；

测试数据：比如性能测试场景需要读写大量的数据，而为了保证测试结果的准确性，一般通过从生产拉取同等量级或者至少未来一年的增长量级的脱敏数据；

参数化数据：不同类型的数据处理逻辑有差异时，需要通过测试数据的多样化来提高性能测试代码的覆盖率，而参数化是最常见的方式；

④脚本开发

性能测试脚本需要针对业务模型转化后的测试模型以及采用的测试策略进行针对性的开发调试试运行。

3）实施阶段

完成准备阶段的工作，就开始开展性能压测了（有时候需要进行压测预热），这也是很多对性能测试不太了解的同学对性能测试的认知（录制脚本→无脑高并发）。

①压测执行

性能测试执行阶段，是需要执行很多轮次，且测试脚本也需要不断地调整修改，根据测试结果不断改进的，这样才能得到更为准确的测试结果。

②服务监控

这个阶段称之为APM（Application Performance Management：对应用程序性能和可用性的监控管理）更合适。

狭义上的APM单指应用程序的监控，如应用的各接口性能和错误监控，分布式调用链路跟踪，以及其他各类用于诊断(内存，线程等)的监控信息等。

广义上的APM, 除了应用层的监控意外，还包括App端监控、页面端监控、容器、服务器监控，以及其他平台组件如中间件容器、数据库等层面的监控。

③瓶颈定位

进行性能测试的目的，就是为了探测系统是否存在影响提供正常服务的性能瓶颈以及为上线提供容量评估。

如果系统性能表现未到达预期指标，则需要对日志、监控数据进行分析，定位其性能瓶颈并针对性的进行优化才可以。

④优化验证

发现性能瓶颈并修改优化后，需要再次执行压测，以验证问题是否得到解决以及性能的提升能力，衡量的标准是需求评审和调研阶段确定的业务性能指标。

4）结束阶段

性能测试结束的标志，一般包括如下如下几点：

涉及的测试场景均已测试完毕、测试过程中发现的问题已全部修复验证、测试结果达到了预期的性能指标、满足上线要求。

①测试报告

在满足上面4个条件后，最好是出具一份简洁但是明确的测试报告，说明本次性能测试的目的、范围、环境信息、测试结果、问题，并给出测试结论。

测试报告的方式可以是文档、邮件、一个HTML页面等方式，但这个环节一定不能省略！！

②报告评审

最好是让参与本次性能测试各环节工作的各个角色都参与进行评审，大家对结果无异议，即可视为本次性能测试结束。

下面是我整理的2025年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

你体内沉睡着改变世界的力量。每个清晨都是改写命运的新机会，每次挫折都是精心包装的礼物。当别人选择放弃时，你的坚持就是胜利的宣言。向前走，属于你的时代正在到来！

生命最美的风景不在终点，而在攀登的路上。那些让你流泪的磨练，正在雕刻更璀璨的未来。别问还要多久，专注脚下的每一步。你的坚持，终将让平凡焕发奇迹！