一.场景的意义
性能测试场景的重要程度类似于业务测试的case，如果没有好的case业务测试很难做好，性能测试也是同样的道理，性能测试不仅仅依赖于场景的设计，执行的质量也是关键，下面我先描述三大基本场景，基准性能测试场景，负载和综合，这是性能测试场景中的基石，后续再补充一些场景；最近看一些文章，一些大咖说不建议给场景取这些名字，容易混淆且区分度不大，我持保留意见，任何事情的发展都是有循序渐进的规律，也是认知发展的过程，就好像敏捷说的工作的软件高于文档，响应变化高于工作计划，这不代表没有文档，没有计划，我经历过小作坊团队完全没有文档，随着项目进行，出现了一锅粥局面，效率完全没有提升，所以我认为下面的概念理解还是比较重要的，需要知道核心目的，然后再去挖掘你认为的一些不合理的地方，当你成为大咖的时候可以在行业内提出改进的修改建议。
二.基准测试场景
基准性能测试是指在一定的软件、硬件以及网络环境下，模拟少量的虚拟用户对一种或多种业务的测试对象的某项性能指标进行定量的和可对比的测试。将测试结果作为基准数据，在系统调优或者评测的过程中，通过运行相同的业务场景比较测试结果，为系统的选择提供决策数据。
基准性能测试所有达到的目的:
1.验证测试脚本及测试参数的正确性。
2.获取系统处理少量并发用户的性能数据，作为对比参考基准。
3.根据测试结果，初步评价可能成为系统瓶颈的场景，并后续进行针对性测试。
三.单接口负载测试
通过模拟虚拟用户，模拟节奏建议梯度翻倍，如(5,10,20,50,100vuser…)进行，每个虚拟用户级别建议做单独场景(利于分析)，并持续循环运行一定时间(15min)，获取事务响应时间，tps，报错率监测测试系统的各服务器资源使用情况（各服务器的CPU、内存、磁盘、网络等资源的使用状况）。每一个虚拟用户级别会对应tps，直到找到tps的拐点，说到拐点可能大家能够想到像山峰一样的高斯曲线，但其实这是一个极其理想的情况，大部分情况下是增涨到一定的阈值就不再增加。
四. 实际过程中常见的误区
1.在我们初学者人群当中。在使用工具做性能测试的时候，可能动辄就是上千甚至上万的虚拟用户，虚拟用户不代表真实的用户，工具的用户和真实用户行为操作是不一样的，在我说的负载测试中不具备直接对比的意义.
2.为什么我建议每个虚拟用户级别做单独的场景呢，绝大多数人看到网上的教程，可能是在一个场景中做了很多梯度，然后我们看tps的变化曲线，这样只会看上去简单方便一些，其实很不利于分析和诊断，并不是每一个量级性能表现都是类似的，在一个场景里先固定虚拟用户可以将自己的精力聚焦在诊断上，而且一个场景多梯度出来的报表也可能没你想象中的清晰明了，甚至会出现找不到拐点的情况，因为随着时间的推移，一些图形化处理会失真。
五. 综合性能测试场景
综合性能测试场景是场景中的关键，也是为了模拟用户最真实的操作，会将多支接口按照实际大促时候的比例进行性能测试，这个比例就是综合场景的关键了，我会用一个专题来阐述此问题，加虚拟用户和场景基本策略可以参考负载测试，综合场景执行除了要观察总的tps，还有一个非常关键的因素就是接口之间的调用比例，比例不能偏离，京东当时是控制在5%以内。
再谈场景
刚刚说的可以说是基石场景，每一个做性能测试的都不应该省去上述的场景步骤，每家公司可能场景的叫法不是很一样，这个我们不纠结，我们聚焦到场景的测试目的即可，我再叙述下其他的场景情况；
六.容量测试场景
说到容量测试，一百个人有一百个说法，我不去说明这样一个定义，我把我经历过的公司的容量测试的做法给大家唠唠。
1. 基于数据库容量的测试，会在数据中预埋不同等级的数据量，在不同等级的数据量下进行性能对比测试，得到数据量归档的依据；
2. 基于应用节点数的增加，现在很多都是微服务框架，我当时所在项目的做法基于同一台服务器先扩容，当服务器资源相对饱和的时候再开辟第二台，目前市场上来看基本都是云服务器了，开辟或销毁一台服务器非常容易，所以如何扩容根据项目来决定就可以。
3. 也有一些公司把上述的综合场景测试归结为容量测试，能看支持多少人同时在全站访问，不过我认为提到容量测试应该需要考虑扩容缩容的影响。
七.浪涌测试
浪涌测试是确定系统从高负载到低负载、甚至空闲，然后再攀升到高负载、再降低的能力。
浪涌测试一般在混合业务场景，通过脚本设置，形成高强度和普通强度的交叉压力测试，持续进行一段时间，以验证系统在正常情况下以及峰值情况下系统的稳定性，找出增加或减少负载的过程中由于突然的占用或者释放系统资源而引起的问题，浪涌测试也是性能测试场景的常见手段之一。
八.异常性能测试
性能测试也是存在异常测试的，主要表现在高可用方面，例如有两台数据库服务，其中一台宕机了，能不能及时切换到另外一台上，且切换的时延是多少，处理能力能不能达到预期标准。
九.稳定性性能测试
稳定性测试是通过给系统加载一定压力的情况下，运行较长一段时间，验证系统是否稳定。
比如我们稳定性测试采用典型混合场景，应用系统运行72小时，查看系统运行指数是否平稳。
稳定性测试的注意点
稳定性测试在性能测试中是一个相对严苛的场景，因为在72h小时中可以发生的事情太多了，不仅仅是业务承载的问题，还包括你准备的数据，客户端稳定性，甚至硬件设备断网断电等等，任何一项意外的发生，都会造成场景的失败，在稳定性测试的监控级别应当是你们公司的最高级别，一旦有问题，立即钉钉或者电话通知，所以稳定性之前需要有充足的预案和监控报警。
常常被问的一个问题:
综合场景我选取哪个梯度的访问量进行测试？
这是很多人问的一个问题，一些同学喜欢选用峰值去做，这是一个很严格的要求，性能本身没有统一标准，今年的某宝电商双11实时下单量峰值达到54w/s,有可能这个值也未必就能平稳跑72h，但作为业务量前一分钟已经足够用了，我们常常说的一句话是今年的峰值是明年的正常流量，所以对于大流量电商公司或者网红公司可以用峰值去跑稳定性，其他公司放宽要求也未尝不可。
