鲁达 继《性能测试环境搭建》和《施压模式选择》两篇文章之后，今天就让我带大家通过实战了解性能测试场景设计和实现的常见思路和方法。文章主要分为理论和实践两个部分，大家可以根据不同的需要选择性的阅读，在进入正题之前，我们先回顾一下性能测试的概念。
前言
性能测试的常见分类
负载测试：
一种验证性测试，它的目的是验证预设负载条件下的性能表现是否达到性能目标（可用性、并发数/RPS、响应时间等），在达到性能目标之后不会继续增加负载。
稳定性测试：
负载测试的一个子集，侧重于发现、验证只有经过长时间的运行才会暴露的问题。比如内存泄漏、FGC 等。
压力测试：
一种破坏性测试，尝试探测应用或者基础设施的极限能力。因此压力测试过程中会一直增加负载直到部分性能指标不再符合性能预期。压力测试能发现仅在高负载条件下出现的同步问题、竞争条件、内存泄漏等。通过压力测试我们还可以确定应用服务在什么条件下会变得不可用，不可用的现象，以及可以通过哪些监控指标来监控即将发生的不可用，压测结果通常可以为限流等管控系统提供数据支撑。
容量测试：
往往与容量规划一起进行，是在保证用户体验不受影响（稳定性）的前提下，使有限的资源的利用率最大化（成本）。也可以用它来预估未来用户量增长到某个量级的情况下，需要多少资源（例如处理器、内存、磁盘、网络带宽）来支持。
应用性能场景的设计
在了解了相关背景之后，我们开始进入正题。性能场景的设计主要包括：业务场景建模、测试数据准备、监控指标确认三个关键步骤。下面我们用实战的方式说明每个步骤的常见做法。
业务场景建模
确定压测场景范围：
人类是不可预测的，在性能测试中模拟每个用户可能的操作场景基本上是不可能实现的。一般情况下我们必须要关注的性能场景包括但不限于：
高频使用的场景
关键的业务场景
最耗性能的场景
曾经出现过问题的场景
……
在测试具有大量新功能的业务时，往往需要与业务方一起确认预期内有哪些功能点可能会被高频使用，需要与研发人员确认哪些功能虽然使用频率不高，但是存在性能隐患、容易引起雪崩效应；在测试已经上线的功能时，还可以通过业务监控、系统日志来分析现有用户的行为模式，得到更加逼近真实用户行为的业务场景。
业务场景的操作路径：
业务场景的操作路径可以借助一些可视化的工具来描述，这部分工作相对比较简单，不再详细深入。我们详细说明一下比较常见的延时策略。
思考时间
思考时间模拟的是用户在等待响应、阅读页面内容、表单填写等延迟操作的场景。每个人的阅读速度、输入速度都存在非常大的差异，决定了每个人的思考时间也是不一样的，在性能测试配置中有常见的四种延时模型覆盖了绝大部分的延时场景：
固定时间：顾名思义，设置一个固定的思考时间。
均匀分布：均匀分布在范围的上限和下限之间的随机数。
正态分布：根据中心极限定理，如果一个事物受到多种因素的影响，不管每个因素本身是什么分布，它们加总后，结果的平均值就是正态分布。
负指数分布：该模型将延迟时间的频率强烈地偏向该范围的一端。
双驼峰正态分布：双峰驼正态分布可以模拟第一次访问时把页面说明整个仔细的阅读一遍，但下次访问时直接扫过页面，点击页面深处的操作链接。
我们通常可以通过以下方式对思考时间进行建模：
如果是已上线系统，可以从线上日志统计分析出来平均值以及标准方差
没有线上日志，可以从内部人员的使用模式中收集响应的数据
可以计算自己和同事访问的时候，在不同页面停留的时间
如果没有更好的来源，也可以从第三方统计数据获取延时数据
集合点
集合点模拟的是大量的用户在同一时刻一起做同样的操作（加购、付款等），集合的方式通常包括按时间集合和按量集合。一般只有具备秒杀特性的业务才会使用到。虽然直接在压测工具中设置巨大的起步量级看似也能模拟秒杀的行为，但是压测工具一般都存在一个不太稳定的预热的过程，因此不推荐超高的起步量级模拟秒杀。
确定场景的施压参数
施压模式：
常见的施压模式有以下两种，并发模式与 RPS 模式没有优劣，各自有各自适用的场景。
1、并发模式（虚拟用户模式）
并发是指虚拟并发用户数，从业务角度，也可以理解为同时在线的用户数。如果需要从客户端的角度出发，摸底业务系统各节点能同时承载的在线用户数，可以使用该模式设置目标并发。
2、RPS 模式（吞吐量模式）
RPS（Requests Per Second）是指每秒请求数。RPS 模式即“吞吐量模式”，通过设置每秒发出的请求数，从服务端的角度出发，直接衡量系统的吞吐能力，免去并发到 RPS 的繁琐转化，一步到位。
目标量级：
目标量级往往来自于对项目计划、目标，业务方要求，或者是技术文档的量化。
场景的负载占比：
已上线应用，尽量使用线上的日志、埋点数据结合业务运营的预期目标确保分配比例尽可能的符合实际情况；新上线的应用一般依靠事前预期分配虚拟用户，在测试的执行过程中可以逐步的调整。
测试数据准备
高质量的测试数据应当能真实的反映用户的使用场景。我们一般会选择以线上真实数据作为数据源，经过采样、过滤、脱敏，作为性能测试的测试数据。低质量的测试数据也许能够测试出一些问题，但是更大的可能性是无效的测试结果。压测数据至少包括基础数据和运行时数据两种。
基础数据，主要是应用系统存储的元数据，比如用户信息、产品信息、商品信息等；基础数据的数据量、数据分布应当与线上运行的数据量相当，否则容易引起无效测试。
运行时数据，主要是虚拟用户操作过程中需要使用的表单数据，比如虚拟用户的用户名、密码、搜索关键词等；运行数据的逼真度也是至关重要的。
确认监控指标
在性能测试执行过程中，往往需要实时观察各项指标是否正常，包括客户端指标、应用服务器、数据库、中间件、网络入口等各方面的指标。更重要的是，监控的过程是发现系统瓶颈的过程，监控数据是性能基线管理、容量规划甚至是高可用架构的重要基础。我们通常需要关注的监控指标包括：
业务接口指标，响应时间、RPS、成功率等；
网络指标，数据吞吐量、数据错误率等；
服务器指标，连接数、CPU、内存、I/O、磁盘等；
……
最理想的状态是，这些监控指标能够与性能测试工具集成，在一个操作界面上展示各个维度的监控数据，并能够基于策略来智能化、自动化识别指标异常。这对快速、准确的定位压测过程中可能出现的各种问题是至关重要的。
应用场景设计实践
JPetStore 是一个开源的简单的Java语言开发的在线宠物商店，可以从 GitHub 获取到源码。为了方便演示，我们用阿里云 EDAS 部署了一套 JPetStore 宠物购物网站。
业务场景建模
在这次的实战演示中，我们通过实际操作体验的方式来获取所有的业务场景、操作路径、思考时间。我们先用文字的方式来描述场景和操作路径。
用户登录，访问首页->进登录页->登录操作
购买流程1，访问首页->选择产品大类->进入产品列表->进入型号列表->查看型号详情->加购物车->思考(3s-5s)->提交订单->确认订单
购买流程2，访问首页->搜索产品->进入产品列表->进入型号列表->查看型号详情>加购物车->思考(3s-5s)->提交订单->确认订单
购买流程3，访问首页->搜索商品->进入产品列表->进入型号列表->加购物车->思考(3s-5s)->提交订单->确认订单
我们的目的是做压力测试。我们选择 RPS 模式，梯度递增，漏斗模型；
与并发模式相比，RPS 模式可以实现更加精准的流量控制；常见的限流设施都是基于TPS设置阈值的；因此我们首选 RPS 模式。
我们使用手动递增的方式，逐步的逼近系统极限。
在真实的业务中，用户会由于各种原因（网络、库存、不喜欢、付款失败等）而放弃购买，在此我们构造一个漏斗模型，我们假定100个人查看详情之后有30个人加入了购物车，15个人提交订单，最终10个人确认订单，购买成功；在真实的场景中我们可以从线上用户行为中采集到这些信息。
假定用户登录容量足够，不是这次压力测试的重点业务。我们基于线上日志和产品运营分析得出以下结论：
使用购买流程1的用户占比10%
使用购买流程2的用户占比60%
使用购买流程3的用户占比为30%
最终，我们得到的业务模型如下图所示：
测试数据准备
因为该应用专为测试而生，不用考虑数据污染，我们免去采样、过滤、脱敏步骤，直接使用线上的基础数据作为压测的基础数据。基础数据的结构如下图所示，当然真实系统的基础数据，比这个复杂的多：
常见的压测工具都支持 CSV 格式（可以简单理解为逗号分隔值，但是实际上更加复杂）的数据源。我们构造的用户登录的运行时数据格式如下图所示：
确认监控指标
依据我们的应用部署架构图，本次压测过程中需要关注 SLB、ECS、RDS 的基础指标（云监控）和压测引擎提供的 RPS、RT、成功率等接口指标。各项监控指标均有平台可以支撑，在此不做赘述。
应用性能场景的实现
性能场景的实现主要包括：压测工具选型、性能场景配置、施压参数配置三个关键步骤，某些压测工具还提供了监控集成、SLA 等功能，我们稍后也会做一些介绍。
压测工具选型
工欲善其事必先利其器，选择一款高效的压测工具往往能达到事半功倍的效果。然而压测工具选型已经是一个老生常谈的话题了，今天我们换个角度，从场景实现的角度再对比一下，希望对大家做选型有所帮助，如果有哪些方面不太完善的地方，请在文末留言讨论。对比详情，点击这里。
下面我们演示怎么在阿里云 PTS 上配置我们设计的压力测试场景，由于操作都比较简单，仅截取关键配置用于演示，大家如果有不明白的地方可以留言讨论或者进入我们的钉钉群中讨论。
下面我们演示怎么在阿里云 PTS 上配置我们设计的压力测试场景，由于操作都比较简单，仅截取关键配置用于演示，大家如果有不明白的地方可以留言讨论或者进入我们的钉钉群中讨论。
压测场景配置
1、高仿真场景编排,完美再现用户行为
压测接口录入：
录入接口信息是一件非常繁琐的事情，接口多，参数多经常容易出错。今天我们用PTS提供的云端录制器来演示怎么快速的梳理和录入所有涉及到的接口。云端录制器的原理是在本地电脑或者手机设备配置网络代理，云端录制器就能获取到所有网络请求的信息。具体的录制步骤如下：
配置网络代理。请参考 PTS 录制器操作文档即可，这里不再赘述。
在浏览器或者 App 中执行业务操作。强烈建议使用域名过滤功能，可以避免录制到干扰请求；每次执行业务操作前先创建一个步骤并备注上业务名称，而不要在所有操作录制完成之后在梳理分类（想象一下从几百个请求中捞出来哪些是登陆相关的请求吧）。
选择录制到的接口信息，导入一个新场景。仍然请参考 PTS 录制器操作文档即可，这里不再赘述。
表单数据的参数化处理
这个步骤实际上是做场景与压测数据的分离。PTS 支持常见的 CSV 格式文件、包含一个 CSV 文件的 ZIP 文件作为场景的数据源。这里演示一下如何使用用户名和密码进行虚拟用户的登录，其他参数的设置与此类似，不在赘述。
第一步，将我们准备的测试数据上传到 PTS，并且给每一列设置变量名。
第二步，编辑登录接口，将 username 变量的值和 password 变量的值设置为文件参数列表中的变量名。
接口间的参数关联处理
这个步骤的主要作用是从前置接口的返回内容中提取出后续接口需要的变量，传递给后续接口使用。在场景编排过程中经常会碰到很复杂的关联方式，比如加密、字符串截取等，可以使用系统函数、数据指令进行加工处理，详见 PTS 操作文档。我们演示一下怎么实现从产品列表中随机选择一个产品进行购买。
第一步，使用正则表达式从产品列表接口的响应中随机提取一个产品 ID ，作为该接口的出参。
第二步，在型号列表接口中，修改参数 productId 的值为上一步导出的变量
第三步，将 itemId 也用类似的方式配置参数关联，就实现了虚拟用户随机购买商品的需求。操作过程类似，不在赘述了。
检查接口调用是否成功
检查点的作用是保证接口调用是成功的，配置了检查点的接口有业务成功率的监控指标，是发现服务端问题的重要渠道之一。PTS 支持多种复杂的检查点，具体配置请参考 PTS 操作文档。下面演示怎么给产品列表接口添加检查点，检查返回的产品ID 是否存在。
2、灵活的施压配置,想怎么压就怎么压
施压参数配置
施压参数主要包括压力来源、压测模式、加压方式、虚拟用户分配等，根据之前设计的场景模型，我们直接配置上去即可。
第一步，配置目标量级、压力来源、压测时长、IP 扩展等信息
第二步，配置各个业务目标量级的分配占比，这也是漏斗模型的关键
流量来源定制
PTS 支持 IP 数量定制、国内公网流量的运营商和地域定制，如果有更加复杂的流量定制需求，还可以申请独占资源池，全球流量定制都不是问题。
3、完整实时监控,瓶颈无所遁形
监控集成&SLA监控
PTS 支持添加云监控，用于查看各项指标，更好地保证测试前提，记录相关数据，输出最终结果。如果您使用了阿里云基础服务（ECS、RDS、SLB），均可通过添加监控的方式，在压测及报告中便捷地查看相应的监控数据。若未使用阿里云基础服务，亦可以使用PTS进行施压。
结合我们之前的架构图，我们给 ECS、SLB、RDS 配置云监控集成，利用PTS的监控大盘，方便的监控所有监控指标。
服务等级定义 SLA（Service Level Agreement）是判定服务是否异常的重要依据。压测过程中，通过监控核心服务状态的 SLA 指标数据，可以更直观地了解被压测业务的状态。PTS 支持定义常见的的、关键的 SLA：
业务质量相关指标，RT、RPS、成功率；
ECS基础监控指标，CPU利用率、内存利用率、load5；
RDS基础监控指标，CPU利用率、连接利用率；
SLB基础监控指标，丢弃连接数、后端异常ECS数；
我们给提交订单、确认订单、商品详情、加购物车接口配置SLA监控，以及时的发现问题。
总结
本文介绍了性能压测场景设计和实现的常用方法和流程，针对目前几款受众相对较多的性能压测工具给出了场景实现相关的功能对比。与实际需求匹配的方法和工具才是最佳实践，大家可以针对不同需求选取最合适的性能压测工具来实施性能测试。
<EOF>
顺便介绍一个技术活动，对 Dubbo 感兴趣的同学请留意，下周在上海举行 Dubbo 社区开发者日，有兴趣的同学可以报名参加。