跳转至

性能测试

主要参考了极客时间高楼老师讲的性能测试系列专栏

针对系统的性能指标,建立性能测试模型,制定性能测试方案,制定监控策略,在场景条件之下执行性能场景,分析判断性能瓶颈并调优,最终得出性能结果来评估系统的性能指标是否满足既定值。

给运维做系统容量规划提供依据,最小化成本,给开发提供应用调优参考,满足用户使用需求。

建议不要使用像性能测试、负载测试、容量测试这样的词来概括性能执行策略,这些定义只能片面的表示性能测试的一个点或面,不能完整的表达出来性能测试,并且定义之间的界限非常模糊,对实施过程没有什么指导价值。

20211125161809

项目分类

  • 新系统性能测试类:这样的项目一般都会要求测试出系统的最大容量,不然上线心里没底。
  • 旧系统新版本性能测试类:这样的项目一般都是和旧版本对比,只要性能不下降就可以根据历史数据推算容量,对调优要求一般都不大。
  • 新系统性能测试优化类:这类的系统不仅要测试出最大容量,还要求调优到最好。

职责定位

  • 性能验证:针对给定的指标,只做性能验证。第三方测试机构基本上都是这样做的。
  • 性能测试:针对给定的系统,做全面的性能测试,可以得到系统最大容量,但不涉及到调优。
  • 性能测试 + 分析调优:针对给定的系统,做全面的性能测试,同时将系统调优到最优状态。

指标

技术指标

  • 时间指标:接口响应时间、业务响应时间
  • 容量指标:接口容量、业务容量
  • 资源利用率指标:操作系统(CPU、IO、Memory、Disk、Network、System)、JVM(GC、Classes)

技术指标不能脱离业务指标,比如:1000万在线用户

20211125164557

最关键的指标当属TPS,它可以反应出一个系统的处理能力

TPS在不同的行业不同业务中定义的粒度都是不同的,所以用TPS的前提是所有相关的人都要知道你的事务(Transactions)是如何定义的。

模型

一些金融业务线上交易不容出错,需要在测试环境中用业务模型来模拟出生产的流量,或者从生产流量中导过来

监控

监控要有分层、分段的能力,要有全局监控、定向监控的能力

监控是为了取证,分析是为了调优

场景/用例

在既定的环境(包括动态扩展等策略)、既定的数据(包括场景执行中的数据变化)、既定的执行策略、既定的监控之下,执行性能脚本,同时观察系统各层级的性能状态参数变化,并实时判断分析场景是否符合预期。

  • 基准性能场景:这里要做的是单交易的容量,为混合容量做准备。
  • 容量性能场景:这一环节必然是最核心的性能执行部分。根据业务模型复杂度的不同,这部分的场景会设计出很多个。
  • 稳定性性能场景:在稳定性测试中,显然最核心的元素是时间,而时间的设置应该来自于运维周期,而不是来自于老板、产品和架构等这些人的心理安全感。
  • 异常性能场景:要做异常性能场景,前提就是要有压力。在压力流量之下,模拟异常。

20220808163611

示意图

比较符合实际的一张图

  • 蓝色:TPS
  • 黄色:RT

20220808153704

与实际不太相符的经典示意图

20211125165501

三条曲线

  • 利用率(Utilization 绿)
  • 吞吐量(Throughput 紫)
  • 响应时间(Response Time 蓝)

三个区域

  • 轻负载区(Light Load),有人将其对应为性能测试
  • 重负载区(Heavy Load),有人将其对应为负载测试
  • 塌陷区(Buckle Zone),有人将其对应为压力测试

两个点

  • 最优并发用户数(The Optimum Number of Concurrent Users)
  • 最大并发用户数(The Maximum Number of Concurrent Users)

三个状态描述

  • 资源饱和(Resource Saturated)
  • 吞吐下降(Throughput Falling)
  • 用户受影响(End Users Effected)

报告

至少要有调优前后的TPS、响应时间以及资源对比图

工具

推荐:JMeter

20211125164448


最后更新: 2022-08-09