这篇来讲压测，压测本质上其实就是经验的问题，至于技术我认为现在都是配套了，也有人配套的东西也搞不清，那还是经验的问题；提醒下，这篇对野路子玩压测的人蛮有用的。
一.误区首先讲误区，每个误区我会简单的总结下，对于需要拓展的，我会在第二部分如何有效压测中去具体描述。
误区1：性能测试就是从写脚本开始。
- 最重要的是你能搞清楚为什么要压测，你这次的压测目的以及压测场景；
- 写脚本只是你认为的干活的第一步，因为你其他所谓性能的需求分析没有思路或者也不清楚。
- 直接写脚本并不是最科学的一步。
误区2：性能测试必须在功能测试之后。
- 这是瀑布思维，大家都在聊测试左移，为什么性能测试不能左移呢？
- 单元级的性能测试也是可以的，比如在方法层注入Benchmark，一般公司没有时间做单元级的，在接口现先行的情况下，可以先完成接口的基准性能测试。
误区3：性能测试要像功能测试一样覆盖更多的场景。
- 性能测试更看重用户访问模型去筛选，做到有的放矢，并不是像功能一样全覆盖。
- 不过目前行业都在推业务稳定性测试，在时间和资源允许的情况下，多场景覆盖也是有很大的作用。
- 还是建议两者区分，做到核心目的快速实现。
误区4：提升硬件就能提升系统性能。
- 对于造成性能瓶颈的原因很多，硬件这是其中一项，不加判断说通过加硬件提升性能可以说是技术门外汉。
- 提升硬件性能并不一定能提升系统性能，比如你死锁了，死循环了，加硬件没用。
误区5：不切实际的性能指标。
- 往往业务动辄给出百万并发这些词，这些实际上是需要去转化可测的性能测试指标。
- 有些同学不了解转化过程，直接拿业务说的并发数去对比压测工具中的线程数，感觉不对但又不知道错在哪里。
误区6：线下压测没有意义
- 这个蛮典型的，一部分同学在线下压测的结果比较差，去找开发，往往被开发打回，你的压测环境根线上相比差异太大，结果没意义。
- 这个话表面上看是成立的，但其实这是在偷换概念，线下压测的目的并不是去对比线上的实际值，而是通过线下压测去发现基本性能问题，如慢方法，索引问题。死锁等。
- 所以要有自己的独立思考，不要被开发带偏。
误区7：脚本里存在大量的逻辑
- 核心逻辑完成即可。
- 如if判断，通过逻辑插件很浪费性能，适得其反。
误区8：不参数化也能跑，就不用参数化。
- 脚本能跑，但是场景不真实。
- 能跑，返回200，只是你看的是皮子，皮子是一样的，里子不一样。
- 压测数据不参数化，大量走缓存，和真实场景未必符合，这是里子。
误区9：脚本不加检查点或者过多检查点
- 脚本不加检查点可能会导致性能压测中业务偏离。
- 检查点过度会导致性能浪费，尤其是不能一边压测一边连接数据库做查询验证。
误区10：脚本一定要加集合点吗？
- 搞清楚性能测试的访问模型，对于秒杀等场景可以添加集合点，验证超卖。
- 对于一些预售类，查询类并不一定，要根据实际需求来。
误区11：瓶颈诊断先从服务端开始
- 排查压测瓶颈首先确定自身发压没有瓶颈，包括压力发起的环境。
- 你自己的笔记本？（这是胡搞）。
- 你传递压力的带宽，办公室公用网络？（也是业余）。
误区12 ：一定要做性能测试才能发现性能问题？
- 这是个经验问题，并不需要一定做性能测试才能发现性能问题
- 比如接口单次调用过慢，可以trace
- 比如发现索引未添加，可以做执行计划
