名词解释
QPS：Query Per Seconds，每秒处理的请求数量；
TPS：Transaction Per Second，每秒处理的事务数量，事务根据场景定义，如：用户进入活动首页，请求的所有后端接口放在一起，作为一个事务；
并发：同一时间内处理多个任务或者请求的能力；
一、场景分析
分析业务场景，确定参与压测的业务域：
·一级页面加载涉及的接口，可以通过抓包方式获取接口列表；
·秒杀场景，如：大额抢券、促销活动等；
·重点二级页面接口，如：奖励列表；
·业务流程比较长的重要接口，如：下单；
梳理待压测接口的业务逻辑和上下游服务，这里需要开发协助确认，性能环境压测时上下游服务根据情况可能需要进行mock，生产环境压测需要提前周知上下游关联方
二、流量预估
性能测试需要有明确的目标，需要测试同产品、运营、开发一起协作评估：
·根据历史同类型活动的峰值流量预估：
通过网关获取历史同类型活动的峰值调用量，适当放大3至5倍进行预估
·根据运营预估的UV、PV数据进行流量预估：
针对日常运营的活动场景，可以根据运营的目标UV、PV数据，按照一九原则（90%的请求在10%的时间范围内）计算TPS；
如果存在秒杀场景，实际情况可能更加极端，可以按照99%的请求集中在1%的时间范围内，并配合压测结果做好限流配置；
三、压测环境
·生产环境压测
生产环境的压测结果可以准确的反映线上服务的真是容量，但是压测的局限性比较大，一般只能对查询类的业务场景进行线上压测
压测需要提前通知到关联方，压测时配合做好线上监控，避免影响线上用户
·性能环境压测
对于需要更新数据的场景，如果线上无法进行压测，建议部署性能环境进行压测：独立部署压测的服务，关联方采用Mock桩形式，数据库、缓存、中间件部署独立的性能环境
配置上建议各节点采用线上同配置（CPU、内存）进行单节点部署
压测环境需要注意：
1、数据库中相关数据表需要模拟线上真实的容量，提前进行数据预埋；
2、关联方mock时需考虑关联方的真实性能指标；
3、压测时的apollo配置、日志级别配置与线上保持一致；
最后，性能环境的压测结果无法预估线上的真实TPS，但性能环境压测可以实现两个目标：
1、验证是否存在明显的性能问题，如：内存泄漏、数据库索引问题、代码逻辑导致的性能问题等；
2、性能环境的压测结果高于流量预估所需的TPS，可证明线上服务可承载预期的流量；
四、输出压测方案、完成方案评审
以上三步明确后，可以进行压测方案编写，压测方案通常包括：压测目标、压测场景、压测环境、工具选择、相关人员（测试、开发、运维、关联方跟进人）、时间安排等。
方案完成后，需要拉通测试、开发、架构、运维进行方案评审，补充和完善测试方案
五、数据准备、脚本设计
·数据准备：一方面根据梳理的业务场景，准备压测所需的数据，另一方面，查询场景，需要在数据库中预置有意义的业务数据；
·脚本设计：做好参数化处理，同时为了便于重复执行压测，可以准备数据初始化方案；
·压测工具：根据个人技术栈，选择适合的工具即可；
数据和脚本准备完成后，需要进行场景演练，确保被测服务可以正常访问，压测可以正常进行
六、压测执行与监控
线上压测，需要提前邮件通知压测时间，确认收到关联方的回复消息，压测时间选择在业务流量低峰期，一般是凌晨，压测开始前需要相关开发、运维、关联方现场或在线支持
压测执行时做好以下数据的监控：
·测试监控：QPS、TPS、平均时延、成功率；
·开发监控：服务器CPU、内存、JVM运行情况、异常日志、关联方接口的响应状况；
·运维监控：数据库的QPS、CPU、IO，Redis的QPS、CPU等；
压测过程中，应当逐步提升并发压力，观察TPS开始出现降低，或者响应时延逐渐超过预期值时，即为达到该场景的性能瓶颈
线上压测完成后，需要检查相关服务的压力是否回归正常，验证线上的业务是否正常
七、结果分析
整理压测结果，初步分析各场景是否达标，拉上相关开发、架构、运维等，进行复盘，逐一分析压测结果
对于性能不达标的场景，明确开发负责人以及优化计划，排期优化
八、性能优化、复测
配合开发进行功能、性能的回归，避免优化性能影响了功能，优化上线后，重复之前的压测动作，验证优化结果，直到性能指标达到预期
九、压测报告
收集整个过程所有有效的测试数据和执行结果，在压测方案的基础上编写性能测试报告：
·压测结论：将最终的压测结果与目标对比，判断是否通过；
·压测明细与分析：压测过程中各场景的并发、TPS、时延、成功率、关键服务的资源占用情况、瓶颈点、压测平台报告详情；
·问题清单及跟进：问题现象、解决情况、优化方案等
