性能测试过程中，首先应该设计测试场景，模拟真实业务发生的情境，然后是针对场景设计脚本。为了真实的反映被测对象可能存在的性能问题，需要尽可能模拟被测对象可能发生瓶颈的业务场景。测试需求分析过程中已经确定了需要测试的业务类型，在此，则需要设计针对每种或综合业务的测试场景。
一、应用性能测试场景的设计
在了解了相关背景之后，我们开始进入正题。性能场景的设计主要包括：业务场景建模、测试数据准备、监控指标确认三个关键步骤。下面我们用实战的方式说明每个步骤的常见做法。
1.1.业务场景建模
确定压测场景范围：
人的行为是不可预测的，在性能测试中模拟每个用户可能的操作场景基本上是不可能实现的。一般情况下我们必须要关注的性能场景包括但不限于：
- 高频使用的场景
- 关键的业务场景
- 最耗性能的场景
- 曾经出现过问题的场景
- ……
在测试具有大量新功能的业务时，往往需要与业务方一起确认预期内有哪些功能点可能会被高频使用，需要与研发人员确认哪些功能虽然使用频率不高，但是存在性能隐患、容易引起雪崩效应；在测试已经上线的功能时，还可以通过业务监控、系统日志来分析现有用户的行为模式，得到更加逼近真实用户行为的业务场景。
业务场景的操作路径：
业务场景的操作路径可以借助一些可视化的工具来描述，这部分工作相对比较简单，不再详细深入。我们详细说明一下比较常见的延时策略。
思考时间：
思考时间模拟的是用户在等待响应、阅读页面内容、表单填写等延迟操作的场景。每个人的阅读速度、输入速度都存在非常大的差异，决定了每个人的思考时间也是不一样的，在性能测试配置中有常见的四种延时模型覆盖了绝大部分的延时场景：
- 固定时间：顾名思义，设置一个固定的思考时间。
- 均匀分布：均匀分布在范围的上限和下限之间的随机数。
- 正态分布：根据中心极限定理，如果一个事物受到多种因素的影响，不管每个因素本身是什么分布，它们加总后，结果的平均值就是正态分布。
- 负指数分布：该模型将延迟时间的频率强烈地偏向该范围的一端。
- 双驼峰正态分布：双峰驼正态分布可以模拟第一次访问时把页面说明整个仔细的阅读一遍，但下次访问时直接扫过页面，点击页面深处的操作链接。
我们通常可以通过以下方式对思考时间进行建模：
- 如果是已上线系统，可以从线上日志统计分析出来平均值以及标准方差
- 没有线上日志，可以从内部人员的使用模式中收集响应的数据
- 可以计算自己和同事访问的时候，在不同页面停留的时间
- 如果没有更好的来源，也可以从第三方统计数据获取延时数据
集合点
集合点模拟的是大量的用户在同一时刻一起做同样的操作（加购、付款等），集合的方式通常包括按时间集合和按量集合。一般只有具备秒杀特性的业务才会使用到。虽然直接在压测工具中设置巨大的起步量级看似也能模拟秒杀的行为，但是压测工具一般都存在一个不太稳定的预热的过程，因此不推荐超高的起步量级模拟秒杀。
确定场景的施压参数
施压模式：
常见的施压模式有以下两种， 并发模式与 RPS 模式没有优劣，各自有各自适用的场景。
1、并发模式（虚拟用户模式）
并发是指虚拟并发用户数，从业务角度，也可以理解为同时在线的用户数。如果需要从客户端的角度出发，摸底业务系统各节点能同时承载的在线用户数，可以使用该模式设置目标并发。
2、RPS 模式（吞吐量模式）
RPS（Requests Per Second）是指每秒请求数。RPS 模式即“吞吐量模式”，通过设置每秒发出的请求数，从服务端的角度出发，直接衡量系统的吞吐能力，免去并发到 RPS 的繁琐转化，一步到位。
目标量级：
目标量级往往来自于对项目计划、目标，业务方要求，或者是技术文档的量化。
场景的负载占比：
已上线应用，尽量使用线上的日志、埋点数据结合业务运营的预期目标确保分配比例尽可能的符合实际情况；新上线的应用一般依靠事前预期分配虚拟用户，在测试的执行过程中可以逐步的调整。
1.2.测试数据准备
高质量的测试数据应当能真实的反映用户的使用场景。我们一般会选择以线上真实数据作为数据源，经过采样、过滤、脱敏，作为性能测试的测试数据。低质量的测试数据也许能够测试出一些问题，但是更大的可能性是无效的测试结果。压测数据至少包括基础数据和运行时数据两种。
基础数据，主要是应用系统存储的元数据，比如用户信息、产品信息、商品信息等；基础数据的数据量、数据分布应当与线上运行的数据量相当，否则容易引起无效测试。
运行时数据，主要是虚拟用户操作过程中需要使用的表单数据，比如虚拟用户的用户名、密码、搜索关键词等；运行数据的逼真度也是至关重要的。
1.3.确认监控指标
在性能测试执行过程中，往往需要实时观察各项指标是否正常，包括客户端指标、应用服务器、数据库、中间件、网络入口等各方面的指标。更重要的是，监控的过程是发现系统瓶颈的过程，监控数据是性能基线管理、容量规划甚至是高可用架构的重要基础。我们通常需要关注的监控指标包括：
- 业务接口指标，响应时间、RPS、成功率等；
- 网络指标，数据吞吐量、数据错误率等；
- 服务器指标，连接数、CPU、内存、I/O、磁盘等；
- ……
最理想的状态是，这些监控指标能够与性能测试工具集成，在一个操作界面上展示各个维度的监控数据，并能够基于策略来智能化、自动化识别指标异常。这对快速、准确的定位压测过程中可能出现的各种问题是至关重要的。
二、应用性能测试场景设计的实践
DISCUZ 是一个使用PHP语言开发的论坛网站
业务场景建模
在这次的实战演示中，我们通过实际操作体验的方式来获取所有的业务场景、操作路径、思考时间。我们先用文字的方式来描述场景和操作路径。
- 用户登录，访问首页->登录操作
- 发帖流程1，访问首页->用户登录->进入版块->编写帖子->思考(3s-5s)->提交帖子->用户退出->退出后页面
- 发帖流程2，访问首页->进入版块->用户登录->发表帖子->思考(3s-5s)->提交帖子->用户登录->登录后首页
- 发表帖子3，访问首页->进入注册主页->提交注册>思考(3s-5s)->自动登录->跳转到主页->进入版块->发表帖子->思考(3s-5s)->提交帖子->用户登录->登录后首页
我们的目的是做压力测试。我们选择 RPS 模式，梯度递增，漏斗模型；
- 与并发模式相比，RPS 模式可以实现更加精准的流量控制；常见的限流设施都是基于TPS设置阈值的；因此我们首选 RPS 模式。
- 我们使用手动递增的方式，逐步的逼近系统极限。
- 在真实的业务中，用户会由于各种原因（网络、不想发帖、发帖失败等）而放弃发帖，在此我们构造一个漏斗模型，我们假定100个人查看详情之后有30个人加入登录，最终10个人发帖成功；在真实的场景中我们可以从线上用户行为中采集到这些信息。
假定用户登录容量足够，不是这次压力测试的重点业务。我们基于线上日志和产品运营分析得出以下结论：
- 使用发帖流程1的用户占比10%
- 使用发帖流程2的用户占比60%
- 使用发帖流程3的用户占比为30%
