提到性能测试，常会提到压力测试、负载测试、稳定性测试、配置测试等等，但说到其各自的定义，实在是晦涩难懂。但若将性能测试，看作是在不同的场景下执行系统，获取系统的性能指标，再对数据进行监控分析的过程，就比较好理解了。
性能测试场景可以分为四类。
- 基准性能场景
- 容量性能场景
- 稳定性性能场景
- 异常性能场景
下面说下每种场景的定义、场景设计以及一些补充。
基准性能场景
对单个业务进行加压，以获取其的最大容量
设计步骤
- 确定要测试的业务比例、业务目标TPS、响应时间指标
这里要测试两个接口，目标响应时间都是100ms
| 业务名 | 业务比例 | 业务目标TPS |
|---|---|---|
| 业务A | 70% | 160 |
| 业务B | 30% | 100 |
-
对业务接口进行梯度加压，得到测试结果
以每3秒一个用户的速度向上递增，直到加到50个用户
TPS
A-TPS.png
RT
A-RT.png
线程
A-T.png
- 获取最大TPS，以及此时的响应时间
从上面的图可以得到以下判断：
- 压力线程到14时，TPS达到上限180左右
- 此时的响应时间是75左右
4.重复以上步骤测试每一个业务，得到结果表格
| 业务 | 最大TPS | RT |
|---|---|---|
| 业务A | 180 | 75 |
| 业务B | 155 | 70 |
Q&A
Q：业务目标TPS和响应时间怎么定？
A：方法一：找同行业对比数据。方法二：到生产环境看用户使用情况并统计信息
Q：怎么得到业务比例？
A：根据生产环境的请求统计信息
Q：测试时为什么要逐步增压？
A：保证在测试过程中资源分配的合理性，可以看到整体的变化过程，例如递增过程中会不会出现系统动荡，便于分析性能瓶颈。
容量性能场景
模拟生产环境的业务场景，比如峰值场景进行的测试，判断在混合业务场景下，系统的指标是否符合预期
设计步骤
- 场景不断
-
控制比例
业务A、B按照7:3的比例，不断增加压力，得到以下结果：
混合容量.png
| 业务 | 最大TPS | 响应时间 | 业务比例 | 目标TPS | 容量测试结果TPS | 容量测试结果对应的响应时间 |
|---|---|---|---|---|---|---|
| 业务A | 180 | 75 | 70% | 160 | 115 | 116 |
| 业务B | 155 | 70 | 30% | 100 | 53 | 107 |
| 合计 | 168 |
混合场景下，业务的TPS并没有达到预期，此处应进行分析调优。
稳定性性能场景
系统能在一定时间内稳定运行
设计步骤
确定场景的运行时间长度的加压数
运行时长取决于系统上线后的运维周期。例如指标是稳定运行一周，支持100万业务量。之前容量TPS能达到168，所以时长应该是10000000/168=6250秒=1.8小时。
Q&A
Q：为什么用最大容量TPS跑稳定性？
A：有的观点是用最大TPS的80%去跑稳定性。跑稳定性的目的就是看系统会不会因为长时间处理业务而引发潜在瓶颈。只要系统正常处理，资源没有出问题也没有报错，就可以用最大TPS去跑。
异常性能场景
根据系统架构模拟异常情况，如宕主机、宕数据库等等，看系统性能下降是否符合预期并且能否在一定时间内恢复
网友评论