《如何做好性能压测》系列专题分享的第四期，该专题将从性能压测的设计、实现、执行、监控、问题定位和分析、应用场景等多个纬度对性能压测的全过程进行拆解，以帮助大家构建完整的性能压测的理论体系，并提供有例可依的实战。
该系列专题分享由阿里巴巴 PTS 团队出品，欢迎在文末处加入性能压测交流群，参与该系列的线上分享。
第一期：《压测环境的设计和搭建》，点击这里。
第二期：《性能压测工具选型对比》，点击这里。
第三期：《阿里巴巴在开源压测工具 JMeter 上的实践和优化》，点击这里。
第四期：《并发模式与 RPS 模式之争，性能压测领域的星球大战》
性能测试的常见分类
负载测试：
一种验证性测试，它的目的是验证预设负载条件下的性能表现是否达到性能目标（可用性、并发数/RPS、响应时间等），在达到性能目标之后不会继续增加负载。
稳定性测试：
负载测试的一个子集，侧重于发现、验证只有经过长时间的运行才会暴露的问题。比如内存泄漏、FGC 等。
压力测试：
一种破坏性测试，尝试探测应用或者基础设施的极限能力。因此压力测试过程中会一直增加负载直到部分性能指标不再符合性能预期。压力测试能发现仅在高负载条件下出现的同步问题、竞争条件、内存泄漏等。通过压力测试我们还可以确定应用服务在什么条件下会变得不可用，不可用的现象，以及可以通过哪些监控指标来监控即将发生的不可用，压测结果通常可以为限流等管控系统提供数据支撑。
容量测试：
往往与容量规划一起进行，是在保证用户体验不受影响（稳定性）的前提下，使有限的资源的利用率最大化（成本）。也可以用它来预估未来用户量增长到某个量级的情况下，需要多少资源（例如处理器、内存、磁盘、网络带宽）来支持。
业务场景建模
一般情况下，在性能测试中模拟每个用户可能的操作场景基本上是不可能实现的，我们必须要关注的性能场景包括但不限于：
- 高频使用的场景
- 关键的业务场景
- 最耗性能的场景
- 曾经出现过问题的场景
- ...............
在测试具有大量新功能的业务时，往往需要与业务方一起确认预期内有哪些功能点可能会被高频使用，需要与研发人员确认哪些功能虽然使用频率不高，但是存在性能隐患、容易引起雪崩效应；在测试已经上线的功能时，还可以通过业务监控、系统日志来分析现有用户的行为模式，得到更加逼近真实用户行为的业务场景。
业务场景的操作路径：
业务场景的操作路径可以借助一些可视化的工具来描述，这部分工作相对比较简单，不再详细深入。我们详细说明一下比较常见的延时策略。
思考时间：思考时间模拟的是用户在等待响应、阅读页面内容、表单填写等延迟操作的场景。每个人的阅读速度、输入速度都存在非常大的差异，决定了每个人的思考时间也是不一样的，在性能测试配置中有常见的四种延时模型覆盖了绝大部分的延时场景：
- 固定时间：顾名思义，设置一个固定的思考时间。
- 均匀分布：均匀分布在范围的上限和下限之间的随机数。
- 正态分布：根据中心极限定理，如果一个事物受到多种因素的影响，不管每个因素本身是什么分布，它们加总后，结果的平均值就是正态分布。
- 负指数分布：该模型将延迟时间的频率强烈地偏向该范围的一端。
- 双驼峰正态分布：双峰驼正态分布可以模拟第一次访问时把页面说明整个仔细的阅读一遍，但下次访问时直接扫过页面，点击页面深处的操作链接。
我们通常可以通过以下方式对思考时间进行建模：
- 如果是已上线系统，可以从线上日志统计分析出来平均值以及标准方差
- 没有线上日志，可以从内部人员的使用模式中收集响应的数据
- 可以计算自己和同事访问的时候，在不同页面停留的时间
- 如果没有更好的来源，也可以从第三方统计数据获取延时数据
确认监控指标
在性能测试执行过程中，往往需要实时观察各项指标是否正常，包括客户端指标、应用服务器、数据库、中间件、网络入口等各方面的指标。更重要的是，监控的过程是发现系统瓶颈的过程，监控数据是性能基线管理、容量规划甚至是高可用架构的重要基础。我们通常需要关注的监控指标包括：
- 业务接口指标，响应时间、RPS、成功率等；
- 网络指标，数据吞吐量、数据错误率等；
- 服务器指标，连接数、CPU、内存、I/O、磁盘等；
- ……
最理想的状态是，这些监控指标能够与性能测试工具集成，在一个操作界面上展示各个维度的监控数据，并能够基于策略来智能化、自动化识别指标异常。这对快速、准确的定位压测过程中可能出现的各种问题是至关重要的。