专栏文章 性能测试连载 (20)-教科书式的性能测试场景设计

飞天小子的性能课堂 · 2019年11月11日 · 最后由 王_test 回复于 2021年01月12日 · 4273 次阅读

性能答疑 QQ 群:697244251

概述

如何设计测试场景是性能测试中比较关键的内容。在性能测试领域有几个教科书一样的场景设计方法,放之四海而皆准

单业务基准测试

目的
单业务基准测试是在服务器没有压力的情况下,获取单笔业务的处理时间,为后续调优提供数据依托。

策略
jmeter 中设置为单个线程迭代 n 次(如 100),取平均响应时间。一般情况下我们不需要监控硬件资源和数据库。但是,如果系统出现了 TPS=1 与 TPS=100 消耗的 CPU 资源差不多的情况,那可能就是性能出了问题。

单业务负载测试

目的
获取系统单笔业务的最大处理能力,以及性能指标之间的关联关系和变化趋势,例如:响应时间随 TPS 的变化趋势,TPS 和响应时间随并发用户数变化的趋势、CPU 利用率随 TPS 的变化趋势。注意:关注的是最大业务处理能力,而不是系统并发数

策略
单业务负载测试一般以逐渐加压的方式执行 30 分钟(无步调、无 ThinkTime),观察性能拐点。同时需要监控服务器资源、数据库处理能力。jmeter 中可以用 rps 定时器或阶梯加压线程组去实现


拐点判断方式

1) 通过 Tps/Hps 走势图观察拐点。吞吐量会随压力的增大呈抛物线状,抛物线的最高点处,即为当前测试环境下该交易的单支最大处理能力。吞吐量的拐点往往也就是响应时间的拐点。

通过资源消耗判断拐点。比如测试中 Tps 仍呈上升趋势,但 CPU 资源使用率已高达 90%,就以此时 Tps 值为当前测试环境下该业务的单笔最大处理能力。

单业务负载测试可考察系统结构是否存在性能隐患。

混合业务负载测试

目的
考察各业务按比例分配逐渐加压的情况下,系统随着负载变化处理能力趋势,如响应时间、Tps、资源消耗。

执行策略
按比例分配,通过逐渐加压的方式执行 1~2 小时,需监控服务器资源消耗、数据库处理能力等。混合业务负载测试也需要判断拐点,判断方式与单业务负载测试相同



稳定性测试

目的
系统长时间处于极限负载下的处理能力,是否随着测试时间的增长,有响应时间变长、内存泄露、磁盘空间不足、等隐藏问题。

执行策略
通过逐渐加压的方式执行 8 小时(也可以是 4、6、12、24、24*7 等,根据实际情况),监控服务器资源消耗(特别是核心进程的内存消耗)、数据库处理能力等。稳定性测试负载压力可以采用系统最大处理能力的 70% 或 80%,或混合场景中某个压力值。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 1 条回复 时间 点赞

为什么忽高忽低的啊

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册