压测本质上其实就是经验的问题，至于技术我认为现在都是配套了，也有人配套的东西也搞不清，那还是经验的问题。提醒下，这篇对野路子玩压测的人蛮有用的。
一、压测的误区
首先讲压测误区，每个误区我会简单的总结下，对于需要拓展的，我会在第二部分如何有效压测中去具体描述。
误区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、部署架构调研