我们聊聊性能测试的理解误区

有同学私信我，说想付费让我教他学习性能测试，问我能不能三个月内把性能测试包括全链路压测都熟练掌握，老实说，这要求把我难住了。和他聊了聊关于性能测试的一些话题，发现他对性能测试的理解走入了一些误区。,在一些技术交流群，同样遇到过很多同学由于对性能测试理解上的误区导致的各种问题，比如：,当然，这些都是比较基础的问题，刚入门的同学可能会犯这种错。如果有一定的项目实践经验，就会了解性能测试比我们想象的要复杂得多。除了对技术的广度和深度有一定要求之外，对业务的熟悉程度，对需求和场景的分析理解能力，甚至在压测实施过程中的沟通和协调能力，也有一定要的要求。,这篇文章，聊聊和性能测试相关的话题，它的实施目的、在不同场景下的侧重点以及一些被大家忽视的点。,首先要认识到一点，抛开性能测试涉及到的技术栈，其实性能测试的本质和功能测试没什么区别。同样需要需求分析、场景设计、准备测试用例和测试数据。功能测试是手动执行用例，观察结果，性能测试则大多是借助工具或者脚本来执行测试用例观察结果。,功能测试的目的是验证产品设计的功能正确性，找到功能上和设计不符的bug；性能测试则是找到应用服务处理能力存在的瓶颈，然后针对性的优化，为线上的容量规划和服务稳定性提供支撑。那么问题来了：如何定义所谓的处理能力瓶颈？这就需要锚定业务价值了。,性能测试的需求基本来自业务，比如用户反馈APP响应太慢、财务或成本部门反映IT的硬件成本太高，或者运营活动由于系统挂了导致业务目标未达成。这些问题归类来说，都是用户和业务的痛点诉求：,总结一下就是：降低成本、提升用户体验、保障业务目标达成，这就是所谓的业务价值！,性能测试的最终目的和功能测试本质上没区别，就是为用户提供正确稳定的服务和良好的用户体验，保障业务目标达成。为了满足用户和业务的诉求而采用的一系列技术方案，都是为了达成这个目的的手段而已。,聊完了性能测试的目的，接着回到具体的项目实践中。日常工作中最常见的项目类型，大概可以分为如下几种：,版本迭代算是软件工程师的工作日常了，这种类型的项目中，性能测试主要的侧重点聚焦在系统的处理能力方面。即验证系统是否由于需求迭代&新的代码引入而导致了系统处理能力下降，主要关注的指标是TPS&99RT&请求成功率等方面。从体系建设的角度来说，可以通过建立性能基线来评估系统长期的性能质量。,我们都知道很多的线上故障是变更引起的，但其实很多时候性能的变化，可能就是一个小小的参数变更导致的。细分的话性能测试场景中有一项叫做配置测试，就是为了验证由于系统各项参数或者服务配置的变化而带来的性能变化。常见的有下面两种：,这种配置变更带来的性能变化，更关注的是中间件和基础服务层面，因为这种变更往往容易被忽略，但这种变更又会对线上服务的性能和稳定性带来很大的影响。,在日常的版本迭代之外，还比较常见的是新服务上线这种项目。比如技术改造、服务拆分、引入新的服务供应商等，一般都需要进行性能测试来验证是否会对已有系统造成影响。,新服务上线进行性能测试的主要目的是验证系统的健壮性，即发现一些较为明显的性能问题，比如：内存泄漏、业务超卖、死锁、慢SQL等情况。,大部分的性能测试都是在线下环境开展的，但性能测试的结果一定要对线上的容量规划和稳定性保障提供支撑，否则性能测试没有太多价值。,虽然已经2023年了，生产全链路压测提出到现在也快11年了，但截至目前大多数公司还是不具备在生产环境进行性能测试的能力，其中原因很多。比如生产环境开展压测成本高风险大，比如大部分公司并没有很高的并发访问量，比如技术建设和储备不够深，究其根本原因，其实就是投入和产出的平衡问题。,当然，技术如何创造业务价值是一个很复杂的问题，但有一个关于全链路压测的误区，也是很多人忽视的。,生产全链路压测只适合某一部分具有特定业务需求的公司，能否实施取决于是否有合适的组织管理能力和对应的技术架构。生产全链路压测并不是银弹，也不单单只是一种测试的技术手段，如果将生产全链路压测看作一种促进生产服务稳定性的技术实践，那它有很多可以挖掘的价值点。但在实际落地过程中，只能说对技术的理解和对业务价值的认知，大家都好像走入了误区。,经常有同学问：我能不能一个用户的数据拿来重复压测，反正也是并发请求的。,在功能测试中，我们会根据要测试的场景和测试用例，准备对应的符合场景的测试数据，为什么性能测试的时候反而忽视了呢？这其实也是一个认知误区：性能测试就是模拟高并发给系统发请求。,正确的做法是和功能测试类似的，建立业务模型&流量模型&数据模型之间的映射关系，准备对应的符合测试场景的测试数据，并且要保证数据量足够测试使用。