背景原因：
做系统服务压测都是比较耗时耗人力的，特别是在生产环境上做压测，压测的时间都是在晚上 23 点后，甚至在凌晨 1-4 点，每次投入的人力成本较高（经常是晚上通宵加班压测，疲惫感十足），对于团队来说，每次大家都很辛苦，但是又不得不做，这是非常苦恼的烦心事。
为了缓解团队每次投入做压测的疲惫感，以及降低投入的人力成本，我们对现有的压测流程做进一步的改善。现有的压测模式：常态化压测（例行压测，摸底压测）、大促全链路压测，这两种压测模式的执行是根据现有业务发展而制定的，但都存在一定时效上的问题，且投入人力成本也不低。
为推进常态化压测更高效，更贴近业务进行压测，且分化所有业务流量的焦点集中在大促压测上，把一些常规压测操作前置到日常业务迭代需求项目上，根据中、大规模的需求项目试行迭代式压测，提供更细致、更小范围的压测方式，尝试解决在压测上的时效和人力问题。
0 1
压测流程改进分析
1.以往的压测模式，主要是常态化压测为主，全链路压测为辅，压测时间段也只有特定的几个时间段（618 大促，双 11 大促等）才会安排。
2.每次压测主要针对大促流量的性能指标上考虑，而各服务本身的每个环节存在的问题，等到全链路压测的时候才暴露出来，往往已经滞后了很多（线上压测存在的弊端）。
3.压测的投入，虽然每次的压测都能拿想要的结果，但是人力的成本和时效，并不是很理想。
4.服务间相互的调量大小，以及能承载多少请求，只有通过常态化压测/全链路压测才发现存在的问题，日常缺少沉淀，经常压测过程会有超时、限流、熔断等情况出现，导致压测的有效性降低。
0 2
迭代式压测流程
结合分析的方向，制定迭代式压测流程如下：
结合公司现有的压测流程，以及存在的不足问题综合分析考虑，把现有的压测流程做调整优化（降本增效），通过日常迭代项目上线后做压测，即可做到贴合业务，以可满足压测需要，主要有以下 5 个方向改进：
压测服务的稳定性
通过迭代项目上线后压测，可以提前了解到服务本身的稳定性，是否有存在隐藏的问题。日常迭代需求较多，关联依赖也多，上线后压测可以快速了解影响范围，及隐藏的性能问题，如有问题，可根据项目迭代，灵活安排优化版本上线。
压测环境的稳定性
以往生产环境压测，机器存在问题，经常是通过扩容/或更换机器的方式，临时解决，并不能提前知道原因是什么，处理结果相对是滞后的。通过日常迭代项目的压测，可以提前暴露出在日常条件下生产环境机器是否存在问题，为大促压测提前做规避措施。
压测时效
快进快出，项目上线后，最小单位安排压测任务，且主要以定时压测为主，灵活压测时间，第二天上班收集压测报告，快速得出压测结果。
压测人员
● 降低产研发团队 QA 的学习门槛，把压测流程和压测平台做到足够简单
● 不再局限于特定的几个人才能做压测，让业务团队每个 QA 都能有参与压测的机会。
贴合业务
日常迭代项目，参与项目的成员，根据业务的特性评估是否压测：
● 如不需要压测，后续则降低/不考虑该业务场景对大促活动的影响面。
● 需要压测，则评估影响面范围：
后端重构项目，影响主流程业务
业务需求新增/变更，涉及有核心接口场景
核心业务场景调整
依赖服务接口变更
……
以项目维度评估压测范围比较小，能快速明确压测的指标，以及压测场景。
● 增加业务 QA 人员对压测的参与度，同时让个人在过程可以学习到相关性能测试的知识技能，可作为常态的测试手段。
● 刚好项目测试完，熟悉度还比较热乎，花费最低成本去创建压测脚本和压测数据，定时压测完成后，得出结果进行分析的成本也比较低。
● 项目维度的压测结果沉淀，对后续大促压测场景规划，提供更明确压测范围，以及可以提前规避掉服务存在的瓶颈问题。
0 3
全流程压测模式演进
压测流程流向
以小聚多，把迭代式压测作为最小压测单位，最后汇总为例行压测（常态化压测）、全链路压测，保障各种链路维度覆盖业务不同颗粒度。参考：常态化压测 、全链路压测
服务流量流向
0 4
压测模式对比
0 5
迭代式压测反馈效果
业务价值
2 月份开始以来，已完成几个需求的压测，压测过程能明显暴露出 6 个服务隐藏的性能问题，为业务服务规避掉隐藏的性能风险。
结果反馈
0 6
总结
● 业务团队的 QA 人员需要具备一定的性能测试技能，学会识别项目需求中是否存在隐藏的性能风险；
● 以项目需求作为压测单位，可能不会覆盖到服务所有功能，但在日常迭代过程，迭代式压测相对会比较频繁，以点到面的切入条件，被压测的功能也会逐步积少成多；
● 稀释大促全链路压测和常态化压测准备及计划的压力，融入需求生命周期管理，轻量分布式的完成压测资产沉淀。
更多内容可以进入个人主页学习《测试工程师 Python 工具开发实战》书籍、《大话性能测试 JMeter 实战》书籍
