性能测试痛点
过去性能测试通常是开发自测、或以项目需求驱动的方式实施，也就是根据需求在测试环境验证相应的性能目标，出具性能验收报告后就算结束。但随着业务系统的迭代速度不断加快，这种做法也会存在诸多不足：
首先，测试环境得出的测试结果，可以验证程序级问题，但因环境和数据的差异，无法验证或获得业务系统在生产环境的性能指标。
其次，随着业务需求变更的频率不断加快，发布周期随之缩短，很多紧急项目直接跳过性能测试就上生产。也造就了一个行业误区：功能一定要测，性能可以不测。举个例子，比如说变更数据库连接数则是一个反例。
第三，据了解过的大多企业，为了生产系统的安全，日常水位很低，比如CPU利用率不到10%，高峰时期可能达到20%。之所以资源利用率低，也是因为对生产容量的不确定性所造成。
另外，以项目需求驱动测试的做法，测试结果将会是数据孤岛，很难做到可持续的性能基线跟踪和风险识别，容易引发累积雪崩性问题。
性能测试成熟阶段
前业内并没有针对性能评测的成熟度的评估模型，根据过往的行业实践经验，大致可将其定位为五个阶段。
第一阶段，以开发自测为主，初创型企业在该阶段居多，没有独立的性能测试团队，系统开发完成后，开发人员自行用开源工具针对核心接口进行压测，缺乏专业的测试方法。
第二阶段，以项目需求驱动为主，测试团队基于项目需求设计测试场景对被测系统进行相应评测，测试需求与测试目标大多依赖人工评审。
第三阶段，以瀑布模式为主，拥有独立的性能测试团队，并制定统一的的性能准入/准出标准和规范，通过组织形式推广整个IT部门，实施规范化的性能测试验收过程。
第四阶段，化被动为主动，用平台化方式对关键业务变更形成一套完整的性能回归体系，打通持续集成，依托迭代性能评测数据建立可持续的性能基线跟踪机制，识别频繁迭代变更带来的性能隐患。
第五阶段，测试左右赋能，向左赋能于研发，提前识别潜在性能风险，向右赋能于运维，为生产容量、稳定性提供有效保障手段。
压测误区
值得特别提出的是：有了生产压测，并不代表测试环境压测就可以不做了
