性能测试的理解误区

最近找我咨询性能测试问题的同学挺多，见识了不少案例，发现很多同学对性能测试依然存在很多理解的误区，即使是一些在测试岗位工作多年的资深工程师，依然存在这种情况。

市场上关于性能测试的专业书籍不少，专业的课程和免费的学习资料以及技术文章也有不少干货，但部分同学依然是从来不主动学习，遇到问题才想起来临时抱佛脚，这样其实对技术提升不怎么友好。

性能测试，说简单也简单，因为实施性能测试的方法和流程和正常的功能测试没太多区别。说难也难，因为要想正确的开展性能测试并达到目标，对技术广度和深度都有一定的要求。

这篇文章，我会列举一些常见的理解误区，并对此做出解释，希望能对测试同学们有所帮助。

误区一、性能测试就是工具+高并发

这是很多初学者最容易犯的一个错误，认为性能测试就是找个工具模拟高并发，不断加压然后看监控统计结果，其实不然。

举一个在技术交流群看到的例子：单接口调用没问题，用JMeter调试系统返回code:500。遇到这个问题该如何处理呢？

一般来说，当请求响应返回的状态码为500时，可以判断请求是通的，只是返回的响应体不是我们预期的结果。这个时候可以从这两点出发来分析问题：

1、查看被测服务日志，看详细的请求和响应信息，以及报错的堆栈信息。

2、对比单接口调试的请求内容和用JMeter组装的请求内容，是否存在差异。

为什么要对比JMeter的请求内容呢？因为它模拟请求的原理，是自己定义请求头和请求的body主体，和postman等测试工具还是存在一定差异的，很多时候就是因为些许差异导致请求失败。

对于性能测试的初学者，我建议在学习压测工具之前，先对网络协议如HTTP/TCP协议有一定的了解，否则只是学习压测工具的使用方法，很容易被卡在性能测试的门槛之外。

误区二、性能瓶颈一定要压到资源耗尽

即使是对性能测试有一定实践经验的测试同学来说，这个误区依然是错误高发区。

前几天有同学告诉我，他每次压测都要压到服务器资源耗尽才认为到了瓶颈，但有时候会发现资源使用率不高但已经压不上去，RT不断增高的现象，很困惑。原因就是走入了如副标题所述的误区。

所谓的性能瓶颈，是没有定量标准的，是否存在性能瓶颈，取决于性能目标如何定义。比如某个业务，希望能支撑200并发，并且响应时间不能超过50ms，这个时候如何判断是否存在性能瓶颈呢？

从需求的角度来看，通过压测并监控观测，是否能达到预期的指标。从技术的角度来看，还要考虑系统稳定性以及系统性能的冗余能力，那就加上成功率99.99%和CPU%<40%。

合并一下，性能指标就是：TPS>200，99RT<50ms，请求成功率>99.99%，CPU使用率<40%。只要压测监控到的性能表现满足这些要求，就可以认为满足性能预期，不存在性能瓶颈，否则就要针对性分析定位和优化。

所谓性能瓶颈，是没达到性能预期指标，而压测监控到的诸如TPS之类的技术指标，只是反映了系统当前的性能表现，这是现象，不是瓶颈。

除了上述两个测试同学的理解误区之外，性能测试对技术的广度和深度都有一定要求。

首先，你要对被测系统和请求链路很熟悉，这就要求你熟知被测系统的系统架构和请求调用关系；其次，要对业务有很深入的理解，并且和业务以及研发团队有良好的沟通，这样才能得到比较明确的性能指标。

最后，还要对常见的各种中间件如Redis/MQ比较了解，且对网络协议和操作系统有基本的了解，否则请求报错查看日志都搞不定，就很难将性能测试工作开展下去。

再扩展来说，性能测试是很吃经验的，很多所谓的性能瓶颈其实并不难定位，但经验的价值就在于可以让你快速筛选出大概率存在问题的部分，并且快速验证和优化。

对新手来说，打好技术基础，熟练掌握工具使用，深入理解业务，再找到好的性能测试资料深读，就能快速掌握性能测试并应对大多数日常的性能测试工作。