避开这12个压测误区保证有效压测

压测本质上其实就是经验的问题，至于技术我认为现在都是配套了，也有人配套的东西也搞不清，那还是经验的问题。提醒下，这篇对野路子玩压测的人蛮有用的。

一、压测的误区

首先讲压测误区，每个误区我会简单的总结下，对于需要拓展的，我会在第二部分如何有效压测中去具体描述。

误区1：性能测试就是从写脚本开始

最重要的是你能搞清楚为什么要压测，你这次的压测目的以及压测场景；写脚本只是你认为的第一步，因为你其他所谓性能的需求分析没有思路或者也不清楚。直接写脚本并不是最科学的一步。

误区2：性能测试必须在功能测试之后

这是瀑布思维，大家都在聊测试左移，为什么性能测试不能左移呢？

单元级的性能测试也是可以的，比如在方法层注入Benchmark（Benchmark 是一个支持功能标杆管理的库，类似于单元测试），一般公司没有时间做单元级的，在接口现先行的情况下，可以先完成接口的基准性能测试。

误区3：性能测试要像功能测试一样覆盖更多的场景

性能测试更看重用户访问模型去筛选，做到有的放矢，并不是像功能一样全覆盖。不过目前行业都在推业务稳定性测试，在时间和资源允许的情况下，多场景覆盖也是有很大的作用。还是建议两者区分，做到核心目的快速实现。

误区4：提升硬件就能提升系统性能

对于造成性能瓶颈的原因很多，硬件这是其中一项，不加判断说通过加硬件提升性能可以说是技术门外汉。提升硬件性能并不一定能提升系统性能，比如你死锁了，死循环了，加硬件没用。

误区5：不切实际的性能指标

往往业务动辄给出百万并发这些词，这些实际上是需要去转化可测的性能测试指标。有些同学不了解转化过程，直接拿业务说的并发数去对比压测工具中的线程数

误区6：线下压测没有意义

这个蛮典型的，一部分同学在线下压测的结果比较差，去找开发，往往被开发打回，你的压测环境根线上相比差异太大，结果没意义。这个话表面上看是成立的，但其实这是在偷换概念，线下压测的目的并不是去对比线上的实际值，而是通过线下压测去发现基本性能问题，如慢方法、索引问题、死锁等。所以要有自己的独立思考，不要被开发带偏。

误区7：脚本里存在大量的逻辑

核心逻辑完成即可。如if判断，通过逻辑插件很浪费性能，适得其反。

误区8：不参数化也能跑，就不用参数化

脚本能跑，但是场景不真实。能跑，返回200，只是你看的是皮子，皮子是一样的，里子不一样。压测数据不参数化，大量走缓存，和真实场景未必符合，这是里子。

误区9：脚本不加检查点或者过多检查点

脚本不加检查点可能会导致性能压测中业务偏离。检查点过度会导致性能浪费，尤其是不能一边压测一边连接数据库做查询验证。

误区10：脚本一定要加集合点吗？

搞清楚性能测试的访问模型，对于秒杀等场景可以添加集合点，验证超卖。对于一些预售类，查询类并不一定，要根据实际需求来。

误区11：瓶颈诊断先从服务端开始

排查压测瓶颈首先确定自身发压没有瓶颈，包括压力发起的环境。如：

你自己的笔记本？
你传递压力的带宽，办公室公用网络？

误区12 ：一定要做性能测试才能发现性能问题？

这是个经验问题，并不需要一定做性能测试才能发现性能问题，比如：接口单次调用过慢，可以trace；比如发现索引未添加，可以做执行计划。

二、如何有效压测？

充分的需求调研，需求调研的科学准确性决定是否能有效压测，核心的包括目标制定，业务梳理，测试数据梳理，系统部署结构以及监控等。

1、目标制定以及业务规则梳理

① 目标制定

衡量性能最重要的三个指标是TPS、响应时间、报错率。那如何制定性能测试的指标呢？你的依据是什么呢？我列举几个常见的误区答案：

我是根据二八原则，老板说我们百万日活，80% 的用户在 20% 的时间段里访问，响应时间是根据业内的 2-5-8 来制定；
我是根据竞品数据分析，他们产品的 PV 应该是百万级，所以我们的产品也是这么制定的；
这个指标是业务定的，他们和开发讨论过，应该没什么问题。

以上回答不仅从道理上讲有些牵强，而且也没有任何制定性能测试可以参考的有效信息。性能测试是一项非常严谨的工作，通过间接或者普适规则不可能满足具体特定的分析，所以对这个问题的理解基本可以判断一位同学是否真正做过性能测试。

对于每一个接口都会有访问计数，这是目前业内比较常见的，也是衡量接口访问能力最准确的指标之一。一般大公司会自己开发相应的监控工具，发展中的公司也会使用一些开源或者商业工具进行监控。比如从ELK就可以提取这些数据，通过实际访问的频次去指定目标Tps。

② 业务规则的调研

对于性能测试而言，业务规则的了解也是不可或缺的。一些公司的性能测试组在进行压测时，业务线的测试也需要协助支持压测的进行，由此可以体现业务的重要性。

对业务的充分了解不仅可以帮助你提高写脚本的效率，也可以帮助你构造更为真实的性能测试场景。举个简单的例子，你模拟下单的时候是否考虑商品属性会员属性等，比如是单一商品还是套餐商品，下单的时候购物车里有几件商品，通过不同条件的组合，这些都会影响性能测试的结果。这一部分很重要，比如你测试过促销，有可能功能的组合会产生上千条case，活动会触发很多规则，如果你只走一个简单的流程，逻辑复杂度根本不是一回事，性能差异会跟真实的逻辑差别很大，而交易又作为最核心的链路，如果出了问题，这锅挺大的，这一块需要好好思考。

2、部署架构调研

被测的业务部署架构是什么意思呢，简单来说就是 被测服务涉及哪些组件，每个组件部署在哪些服务器上，服务器的配置是怎样的？你需要画一个部署架构示意图，有了这张图，才能知道如何做到全貌监控，以及遇到问题从哪些服务入手。

我用一个自己画的架构示意图来说明这个问题，如下图所示，这是一个经典的链路：从客户端发起到服务端，服务端从代理层到应用层，最后到数据层。需要注意的是，你需要明确被测的环境里的各个服务有多少节点，比如客户层的压测机节点有几台，分别在哪个网段。同理我们可以去调研服务层和数据层的节点。

而且现在都是云服务，会做到弹性扩容，不同的时间节点会有不同的实例节点，这些都应当做好记录。

3、对测试数据进行调研

关于测试数据调研，包含了非常多的内容，对于业务测试来说数据调研就是获取必要的参数来满足既定的场景可以跑通。那对于性能测试来说，需要做哪些方面的数据调研呢，我带你一一解读。

① 数据库基础数据量分析

数据库的基础数据量就是目前线上数据库实际的数据量，为什么要统计基础数据量呢？很多公司往往有独立的性能测试环境，但是数据库的数据量与线上相比差距较大，可能出现一条 SQL 在性能测试环境执行很快，但上了生产却会很慢的问题。这就导致测试觉得该测的都测了，但上了生产还是会有问题出现。

这种问题可能会因为索引缺失以及性能环境数据量较少而不能将问题暴露出来，所以在 性能测试环境下的数据量一定要和生产上一致。为了达到这个目的，有的公司可以将生产数据脱敏后备份，有的则需要你自己写脚本来根据业务规则批量造数据。

② 压测增量数据分析

除了数据库的基础数据量，我们也需要考虑一轮性能测试下来会增加多少数据量。往往增加的数据量最终落到数据库，可能会经过各种中间件如 Redis、Mq 等，所以涉及的链路可能存在数据量的激增，所以这方面需要根据增加情况制定相应的兜底方案（即最差情况下的临时解决办法）。

③ 冷热数据的分析

以我的从业经历来讲，能够在方案阶段考虑到冷热数据分布的公司并不多，往往都是从性能测试结果的一些异常点或者实际产线出现的问题去追溯。接下来我就带你了解下什么是冷热数据，以及如果不对其进行分析可能会带来什么影响。

冷数据，是指没有经常被访问的数据，通常情况下将其存放到数据库中，读写效率相对较低。
热数据，是经常被用户访问的数据，一般会放在缓存中。

在性能测试的过程中，被频繁访问的冷数据会转变为热数据。如果参数化数据量比较少，持续压测会让 TPS 越来越高。而在实际大促情况下，往往有千万级的用户直接访问，但大多都是冷数据，会存在处理能力还没达到压测结果的指标，系统就出现问题的情况。所以在需求调研时，你也需要考虑：数据会不会被缓存，缓存时间多久的问题？

4、测试监控

为什么监控很重要，它是发现问题的眼睛，而且一旦在过程中没有及时监控和发现，还原现场是有难度的。不仅需要罗列清楚你所需要的监控工具和访问方式，同时也需要层次分明地传递你监控的内容。对我来说做监第一个关键词：全。

怎么去理解“全”呢？先举一个典型的例子，有时候做一个新的项目，询问支持的同学有没有部署监控，他们说已经部署了，但等你真正使用的时候发现只监控了一台应用服务器的 CPU。这个例子我相信大多数人都似曾相识，所以我说的全，至少包含两个方面：