吐血整理，性能测试-正确定义性能瓶颈分析，一篇通透...

前言

性能测试和功能测试在本质上没有区别，大体的流程也没差，无非是分析需求，准备用例、执行用例、确认BUG、跟进修复验证，最终出具测试结果/报告。

两者的不同点在于，侧重不一样：功能测试侧重需求的正确实现，性能测试更注重系统的处理能力是否能支撑真实的用户访问。

在功能测试开展前，我们会分析需求，确认需求要实现的功能最终是什么表现形式，以便于设计测试用例和预期结果，性能测试同样如此。

在性能测试开展之前，依然要分析需求，确认预期的性能指标，即当系统达到什么指标的情况下，可以支撑线上业务的用户访问，而性能瓶颈，对应的则是未达到预期性能指标。

网上充斥着太多的水文，讲了太多错误的性能测试方法，荼毒了不少人。
比如用高并发把服务器资源使用率压上去，直到服务挂了，这个时候的性能测试结果就是所谓的性能瓶颈；再比如当RT明显上升和出现请求报错时，就到性能瓶颈了。诸如此类，误人子弟。

什么是性能瓶颈？

一句话概括：在给定条件下未达到预期性能指标，就是性能瓶颈。

需求：创建订单场景，服务器配置4C8G，预期性能指标是单机在CPU使用率40%以下时，TPS>200&99RT<200ms。这个时候的预期性能指标是什么？

答案：单机CPU%<40%+TPS>200+99RT<200ms，这就是预期性能指标。

其中的给定条件，业务场景是创建订单，服务器配置是4C8G，环境配置是单机服务器。

分析完需求后，接着该做什么呢？

按要求搭建压测环境，根据创建订单的业务场景准备对应的测试数据，然后找个压测工具编写脚本，同时部署好监控，以便压测时可以实时观察性能指标的变化。

如果在给定条件下，性能表现符合预期指标，那就是不存在性能瓶颈。如果性能表现未达到预期指标，就出现其他问题，比如请求超时、报错率较高、内存资源耗尽，则判断存在性能瓶颈。

然后就是根据具体的问题具体分析，逐一排查，修复后再次进行压测验证，直至达到预期结果。

很多刚学习性能测试的同学都对性能测试有个误解，那就是我一定要把服务器资源压满，或者一定要让它出现RT拐点才表明到了性能瓶颈，其实并不是这样。

无论是功能测试还是性能测试，工作开展的前提一定是需求说明。通过需求分析确认测试场景，预期结果，然后针对性的设计测试用例，执行用例进行验证。至于你是手动点点点还是利用工具自动执行，本质上对测试结果没有影响。

当然，对于刚开始入门学习性能测试的同学来说，确实很容易犯一些基础的常识性错误，如果有一定的项目实践经验，就会知道性能测试比我们想象的要复杂得多。

除了对技术的广度和深度有一定要求之外，对业务的熟悉程度，对需求和场景的分析理解能力，甚至在压测实施过程中的沟通和协调能力，也有较高的要求。

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

每个努力的瞬间，都在为你铺设通往梦想的道路。不要害怕前方的挑战，它们只会让你更加坚定和强大。相信自己，你的坚持将创造奇迹。

成功没有捷径，只有不懈的努力和坚定的信念。不要因为一时的困难而放弃，记住，每一步都在离目标更近。坚持走下去，终将看到光明的未来。