前言
在现阶段大促备战的压测不算是一件新鲜事，已经不存在什么技术瓶颈或者资源问题，每个团队都有很多人能够执行性能测试，在一些团队也已经落地了日常常态化，但压测也没有简单到只在压测平台上设置参数、运行脚本，然后去看压测报告中某个指标是否满足压测目标那么简单，我平时也跟一些同学一起做过性能测试，发现在压测过程中存在一些细节问题，有些同学做但不是很理解，压测方案对于性能测试来说是尤为重要一环，今天把对于压测方案方面的一些理解跟大家一起探讨一下；
性能测试的本质是模拟生产环境的用户，构造用户真实的行为请求，对尽量真实的压测系统施加压力，验证系统性能是否满足业务需要，是否存在性能瓶颈；
从里面可以看出核心的几个点：压测目标、压测场景、压测环境，今天主要从三大块来说
一、压测目标
我们在制定压测方案去说起压测目标的时候，很多同学都直接的考虑到 TPS、QPS、TP99 这些，
忽略了很重要的一项内容就是压测背景，就是因为什么原因我们要做这次压测，压测背景是我们压测的的方向，如果方向错了就会导致我们费时费力压测完成之后，压测的结论是没有意义的
那么压测背景和压测目标的关系是啥呢？
说一下我们现在常见的几种压测背景：
1、大促期间调用量对比平常明显有增长的业务
目标：是否能够支承大促预估峰值流量（业务预估 + 业务增长 + 大促增长）+ 单机房承载量 + 接口能支撑多大的调用量
结论：xxx 配置最优/最大吞吐量 xxx，能够支撑本次大促预估峰值调用量 xxxx，是否存在风险；
2、上次大促压测过，但是之后新增/修改过的内容
目标：接口性能是否有变化 + 是否能够支撑大促预估峰值流量 + 接口能支撑多大的调用量
3、新增的接口，没有压测过，有业务预估调用量
目标：接口是否能够满足业务预估调用量（极限）+ 正常
4、新增的接口，没有压测过，没有业务预估调用量
目标：接口性能评估，系统性能是否存在瓶颈？有无优化空间？
5、新增的接口替换老接口
目标：接口性能评估，是否能够满足老接口的业务调用量 + 新增业务调用量
6、老接口的性能优化
目标：对比优化前优化后的性能指标，是否有优化效果
7、大促期间峰值调用量相比日常调用量没有明显变化，但是高峰时间拉长的业务
目标：峰值流量稳定性压测
8、没有太大的调用量，但是用户对于用户体验要求比较高
目标：接口响应时间是否有感官上的延迟，关注 TP99，是否需要优化
9、不知道系统是否需要扩容
目标：极限压测，应用服务器和数据库资源使用情况是否合理
10、已知链路、接口性能比较慢，我需要知道瓶颈在那里
目标：找到链路、接口体系上的薄弱点（可优化内容）
二、压测场景
业务模型的调研和构建是我们压测前期工作中最为核心的一个环节，业务模型的创建要以实际生产环境系统业务操作模式为依据，只有模型符合实际的生产业务使用模式，性能测试的结果才能真实有效的反应上线后系统的性能情况，业务建模好坏直接决定性能测试执行的成功与否，也就是我们所说的压测模型
业务建模的过程中要分析清楚三件事情：
1、产生流量场景有哪些？如何选择需要压测的场景？
2、各场景和交易之间流量如何分配和设计？
3、要达成测试目标需要构造铺地数据需要多大的量，这些铺地数据该如何分配和部署；另外需要业务模型设计数据，数据要如何分配和构造
其实要做的就是在了解清楚业务并在其基础上完成：业务模型、流量模型及数据模型。
1、业务模型
一般从业务运营视角、技术运营视角、线上问题分析以及测试经验四个维度进行收集、整理和提炼：
业务运营：从实际业务应用的角度收集用户实际的使用情况和业务增长的趋势，比如我们有几个业务调用来源，平时用户使用最多的场景是那些，用户操作的高峰时段是什么时候？
技术运营：从技术运营角度去梳理我们接口实现逻辑的调用链路，比如说调度工作台线路展开查询，线路下任务低于 20 条的会去调异常接口，高于 20 条的不调异常接口；比如说查询接口实现的方式，走缓存还是走数据库；
线上问题：根据用户反馈和线上问题的收集，结合线上问题修复的方式；比如说一线反馈 xxx 操作会感知响应比较慢，研发在优化这个的时候会覆盖哪些用户操作场景
测试经验：根据测试经验来完善业务模型
2、流量模型
在业务场景确定后，就要思考各个场景和交易之间流量如何分配？。
生产环境的用户操作场景比较复杂的，请求报文的大小和请求路径也各不一样，使用单一的请求报文进行压测是不合理的，在流量模型分析的过程中有两种思考方式。即用户行为模型和系统业务模型。
用户行为模型：通过描述高峰时期用户行为特点，通过对用户行为调研分析，归纳总结出用户行为模型。比较常见的就是现在的流量录制，在业务高峰时间录制业务流量，然后进行流量回放，优点是实现起来比较简单，缺点是录制的流量用户行为较难统计分析。
系统业务模型：根据高峰时期系统业务特点，通过系统日志、数据埋点等方式获取高峰时段系统业务流量，获悉用户的主要流量行为，然后通过自己编写脚本和配置流量占比的方式来实现，优点是用户的流量占比比较清晰，缺点是要有数据的人工归类分析过程
3、数据模型
设计完成业务模型和流量模型，还要清楚需要多少基础数据（也叫铺地数据），铺底数据目的是测试时尽可能的与线上保持一致（至少数量分布一致），不管是哪类数据库，对于不同体量的数据，所走的查询器选择都是不一样的。几百行的数据走全表扫描肯定比走索引要好，但如果是几百万行呢？这方便需要我们具体地做评估。一般来说数据量要按照实际生产环境的数据量为多少为基础，在性能测试环境做等量代换。
总结：多少用户（WHO）在什么时间或者持续多长多久（When），在多大的数据量的基础上（How much），完成了什么业务（What），最终需要关注怎样的指标（How）。
举例：
单接口压测（调用方式不同）：
1、默认页面打开自动查询，查询每页默认 20 条记录，也是最大的用户形式
2、通过接口调用，接口每页最大返回条数是 1000 条
单接口缓存压测：
- 走缓存 10 分钟
- 不走缓存 10 分钟
- 部分命中缓存，部分未命中缓存，10 分钟经历 5 分钟缓存失效
单接口混合场景压测：
调度工作台 - 分页查询用户权限内线路，不同的用户行为
1、1 天 1 个区域查询量
2、1 天 7 个区域查询量
3、混合场景 (7 天 1 个区域 10%，1 天 7 个区域 20%，1 天 1 个区域 70%) 三种
单应用多接口混合压测：
根据调用量进行接口调用配比
单业务接口混合压测：
适用场景：
运营指标看板（链路大屏页面，常用用户大概在 150 人左右），在用户访问大屏的同时调用五个接口方法：
用户初始进入页面后，默认无查询条件调用 5 个接口
用户在此页面停留，每隔 30s 自动刷新页面内容调用 5 个接口
用户手动录入查询条件，点击查询自动执行查询操作调用 5 个接口
极限压测：
【618 备战压测 - 执行核心流程极限压测】测试方案
双实例线性增长验证
全链路压测：
【备战 618 性能测试 - 运输 ORC 接单】性能测试报告
系统稳定性压测
满足业务需求后，持续加压一段时间（4-6）验证系统稳定性
三、压测环境
1、优先考虑线上环境
2、压测环境与生产环境吞吐量差异，单实例压测和双实例压测怎么选择
3、压测环境与生产环境差异
4、铺底数据量压测环境与生产环境差异
作者：京东物流 朱飞
来源：京东云开发者社区 自猿其说 Tech 转载请注明来源