一、引言

很多做性能测试的同学都问过我这样一个问题：鱼哥(Carl_奕然)，你说性能测试的重点是什么?

我的回答很简单：瓶颈分析与问题定位。

在性能项目的整个周期，不管是脚本设计，脚本编写还是脚本执行，都还算简单。

难点在于如何定位瓶颈，分析瓶颈，解决瓶颈。

如果你不会性能分析，脚本设计的再好，脚本编写的再完美，分析不出问题所在，那都是白白浪费时间。

所以，这一讲，我们来学习：如何进行性能分析，学会了性能分析的思路，才能定位问题，分析问题，从而解决问题。

在性能项目中，我总结的性能分析思路，分5个模块，即性能分析5部曲，如下：

1、判断性能瓶颈；

2、线程递增策略；

3、性能衰减过程；

4、拆分响应时间；

5、构建分析决策tree；

接下来，我就对这5部曲进行一一解释。

二、判断性能瓶颈

在整个性能测试阶段，让性能测试工程师最艰难的，就是如何定位性能瓶颈。

如果无法定位到性能瓶颈，那么对开发同学的支持也就有了限制，这无疑即增加了解决问题的时间，又增加了开发工程师的工作量。

这时候，你会说，开发工程师的职责不就是解决性能瓶颈吗，

那要是这样说， 测试工程师的职责，可不仅仅是发现性能瓶颈，还需要定位性能瓶颈，换句话说，也就是协助开发工程师快速定位并解决性能问题。

为什么说在整个性能项目中，最难得就是分析性能瓶颈。

这里，我先上一张图，为了更形象的表现接下来要描述的内容，我把图片做了一点处理：

通过这张图，我们很直观的知道：这是一个阶梯式增加的压测场景。

但是，根据这个图，你能判断出拐点在哪里吗？

如果无法判断哪里是拐点，那我再上一张ResponseTime(后面简称为RT)图：

同样，为了让你更直观的查看RT图，， 我同样也对RT图做了优化处理。

结合RT图与TSP图，我们能不能判断拐点在哪里呢？

如果你觉得在3.3s的位置是拐点。我不能否认你说的完全错误，但是，我也不会认同你的观点， 为什么呢？

因为，根据多年的经验，判断的标准是：随着TPS的不断增加，找到那个清晰可见的弧度。

这一点很重要，需要你记住。

我举个例子：如果按照你刚刚的说法，只根据一个拐点来进行判断，想象一下，

假如网络出现突然的抖动，按照你刚刚的判断依据(只根据一个拐点)，是不是就不准确了。。

所以，一定是找到那个 清晰可见的 弧度。

我们在回来说上面的TPS图与RT图，根据这两个图，你能得出哪些结论呢？

是不是可以得出这个系统有瓶颈，系统的瓶颈与压力有关系，并且随着压力的增加，涨幅在逐渐减少。

到这里， 需要请你在思考一个问题：瓶颈点是否跟压力的大小有关？

答案：肯定不是跟压力大小有关。

既然不是跟压力大小有关，那么，根据什么有关呢？

其实结合上面的图， 我们可以知道：

①引起系统瓶颈的问题是有规律的；

②TPS是周期性的降低，并且最大的TPS也都差不多是一致的；

所以，即使压力降低，最多只是降低最大的TPS水位，这种情况只是让问题出现的更晚一点，但不会不出现的。

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

---

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

---

一、Python编程入门到精通

二、接口自动化项目实战 

三、Web自动化项目实战

四、App自动化项目实战 

五、一线大厂简历

六、测试开发DevOps体系 

七、常用自动化测试工具

八、JMeter性能测试 

九、总结（尾部小惊喜）

生命不息，奋斗不止。每一份努力都不会被辜负，只要坚持不懈，终究会有回报。珍惜时间，追求梦想。不忘初心，砥砺前行。你的未来，由你掌握！

生命短暂，时间宝贵，我们无法预知未来会发生什么，但我们可以掌握当下。珍惜每一天，努力奋斗，让自己变得更加强大和优秀。坚定信念，执着追求，成功终将属于你！

只有不断地挑战自己，才能不断地超越自己。坚持追求梦想，勇敢前行，你就会发现奋斗的过程是如此美好而值得。相信自己，你一定可以做到！