一、引言
很多做性能测试的同学都问过我这样一个问题：鱼哥(Carl_奕然)，你说性能测试的重点是什么?
我的回答很简单：瓶颈分析与问题定位。
在性能项目的整个周期，不管是脚本设计，脚本编写还是脚本执行，都还算简单。
难点在于如何定位瓶颈，分析瓶颈，解决瓶颈。
如果你不会性能分析，脚本设计的再好，脚本编写的再完美，分析不出问题所在，那都是白白浪费时间。
所以，这一讲，我们来学习：如何进行性能分析，学会了性能分析的思路，才能定位问题，分析问题，从而解决问题。
在性能项目中，我总结的性能分析思路，分5个模块，即性能分析5部曲，如下：
1、判断性能瓶颈；
2、线程递增策略；
3、性能衰减过程；
4、拆分响应时间；
5、构建分析决策tree；
接下来，我就对这5部曲进行一一解释。
二、判断性能瓶颈
在整个性能测试阶段，让性能测试工程师最艰难的，就是如何定位性能瓶颈。
如果无法定位到性能瓶颈，那么对开发同学的支持也就有了限制，这无疑即增加了解决问题的时间，又增加了开发工程师的工作量。
这时候，你会说，开发工程师的职责不就是解决性能瓶颈吗，
那要是这样说， 测试工程师的职责，可不仅仅是发现性能瓶颈，还需要定位性能瓶颈，换句话说，也就是协助开发工程师快速定位并解决性能问题。
为什么说在整个性能项目中，最难得就是分析性能瓶颈。
这里，我先上一张图，为了更形象的表现接下来要描述的内容，我把图片做了一点处理：
通过这张图，我们很直观的知道：这是一个阶梯式增加的压测场景。
但是，根据这个图，你能判断出拐点在哪里吗？
如果无法判断哪里是拐点，那我再上一张ResponseTime(后面简称为RT)图：
同样，为了让你更直观的查看RT图，， 我同样也对RT图做了优化处理。
结合RT图与TSP图，我们能不能判断拐点在哪里呢？
如果你觉得在3.3s的位置是拐点。我不能否认你说的完全错误，但是，我也不会认同你的观点， 为什么呢？
因为，根据多年的经验，判断的标准是：随着TPS的不断增加，找到那个清晰可见的弧度。
这一点很重要，需要你记住。
我举个例子：如果按照你刚刚的说法，只根据一个拐点来进行判断，想象一下，
假如网络出现突然的抖动，按照你刚刚的判断依据(只根据一个拐点)，是不是就不准确了。。
所以，一定是找到那个 清晰可见的 弧度。
我们在回来说上面的TPS图与RT图，根据这两个图，你能得出哪些结论呢？
是不是可以得出这个系统有瓶颈，系统的瓶颈与压力有关系，并且随着压力的增加，涨幅在逐渐减少。
到这里， 需要请你在思考一个问题：瓶颈点是否跟压力的大小有关？
答案：肯定不是跟压力大小有关。
既然不是跟压力大小有关，那么，根据什么有关呢？
其实结合上面的图， 我们可以知道：
①引起系统瓶颈的问题是有规律的；
②TPS是周期性的降低，并且最大的TPS也都差不多是一致的；
所以，即使压力降低，最多只是降低最大的TPS水位，这种情况只是让问题出现的更晚一点，但不会不出现的。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
