你真的了解压测吗？实战讲述性能测试场景设计和实现

继《性能测试环境搭建》和《施压模式选择》两篇文章之后，今天就让我带大家通过实战了解性能测试场景设计和实现的常见思路和方法。文章主要分为理论和实践两个部分，大家可以根据不同的需要选择性的阅读，在进入正题之前，我们先回顾一下性能测试的概念。

前言

---

性能测试的常见分类

负载测试：

一种验证性测试，它的目的是验证预设负载条件下的性能表现是否达到性能目标（可用性、并发数/RPS、响应时间等），在达到性能目标之后不会继续增加负载。

稳定性测试：

负载测试的一个子集，侧重于发现、验证只有经过长时间的运行才会暴露的问题。比如内存泄漏、FGC 等。

压力测试：

一种破坏性测试，尝试探测应用或者基础设施的极限能力。因此压力测试过程中会一直增加负载直到部分性能指标不再符合性能预期。压力测试能发现仅在高负载条件下出现的同步问题、竞争条件、内存泄漏等。通过压力测试我们还可以确定应用服务在什么条件下会变得不可用，不可用的现象，以及可以通过哪些监控指标来监控即将发生的不可用，压测结果通常可以为限流等管控系统提供数据支撑。

容量测试：

往往与容量规划一起进行，是在保证用户体验不受影响（稳定性）的前提下，使有限的资源的利用率最大化（成本）。也可以用它来预估未来用户量增长到某个量级的情况下，需要多少资源（例如处理器、内存、磁盘、网络带宽）来支持。

应用性能场景的设计

---

在了解了相关背景之后，我们开始进入正题。性能场景的设计主要包括：业务场景建模、测试数据准备、监控指标确认三个关键步骤。下面我们用实战的方式说明每个步骤的常见做法。

业务场景建模

确定压测场景范围：

人类是不可预测的，在性能测试中模拟每个用户可能的操作场景基本上是不可能实现的。一般情况下我们必须要关注的性能场景包括但不限于：

• 高频使用的场景

• 关键的业务场景

• 最耗性能的场景

• 曾经出现过问题的场景

• ……

在测试具有大量新功能的业务时，往往需要与业务方一起确认预期内有哪些功能点可能会被高频使用，需要与研发人员确认哪些功能虽然使用频率不高，但是存在性能隐患、容易引起雪崩效应；在测试已经上线的功能时，还可以通过业务监控、系统日志来分析现有用户的行为模式，得到更加逼近真实用户行为的业务场景。

业务场景的操作路径：

业务场景的操作路径可以借助一些可视化的工具来描述，这部分工作相对比较简单，不再详细深入。我们详细说明一下比较常见的延时策略。

思考时间

  

思考时间模拟的是用户在等待响应、阅读页面内容、表单填写等延迟操作的场景。每个人的阅读速度、输入速度都存在非常大的差异，决定了每个人的思考时间也是不一样的，在性能测试配置中有常见的四种延时模型覆盖了绝大部分的延时场景：

• 固定时间：顾名思义，设置一个固定的思考时间。

• 均匀分布：均匀分布在范围的上限和下限之间的随机数。 

• 正态分布：根据中心极限定理，如果一个事物受到多种因素的影响，不管每个因素本身是什么分布，它们加总后，结果的平均值就是正态分布。

• 负指数分布：该模型将延迟时间的频率强烈地偏向该范围的一端。

• 双驼峰正态分布：双峰驼正态分布可以模拟第一次访问时把页面说明整个仔细的阅读一遍，但下次访问时直接扫过页面&#