阿里巴巴在应用性能测试场景设计和实现上的实践

本文是《Performance Test Together》（简称PTT）系列专题分享的第5期，该专题将从性能压测的设计、实现、执行、监控、问题定位和分析、应用场景等多个纬度对性能压测的全过程进行拆解，以帮助大家构建完整的性能压测的理论体系，并提供有例可依的实战。

该系列专题分享由阿里巴巴 PTS 团队出品，欢迎在文末处加入性能压测交流群，参与该系列的线上分享。

第1期：《压测环境的设计和搭建》

第2期：《性能压测工具选型对比》

第3期：《阿里巴巴在开源压测工具 JMeter 上的实践和优化》

第4期：《并发模式与 RPS 模式之争，性能压测领域的星球大战》

本文将介绍应用性能测试场景的设计和实现，旨在借助阿里巴巴在这方面的沉淀帮助您更准确的找到性能瓶颈，文章将围绕以下：

• 性能测试的常见分类
• 应用性能测试场景的设计
• 应用性能测试场景的设计实践
• 应用性能测试场景的实现

性能测试的常见分类

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

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

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

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

应用性能测试场景的设计

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

业务场景建模

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

• 高频使用的场景
• 关键的业务场景
• 最耗性能的场景
• 曾经出现过问题的场景
• ……

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