目录
一、性能测试基本介绍
什么是性能测试?什么时候开展性能测试?
性能测试一般可以理解为在功能实现正确后,通过一定量的并发用户,重点考察服务器端在一定并发压力下的性能指标所开展的测试活动。性能测试是为了验证软件系统是否能够达到预期的性能指标,同时发现软件系统中存在的性能瓶颈,从而实现优化系统的目的。
二、性能测试类型以及方法
根据不同的测试目的,性能测试可以分为多种类型,常见的有如下几类:
- 基准测试(Standard Testing):
- 负载测试(Load Testing)
- 压力测试(Stress Testing)
- 疲劳强度测试
首先说下基准测试。基准测试指的是模拟单个用户执行业务场景时,考察系统的性能指标。严格意义上来讲,基准测试并不能算作性能测试范畴,它跟功能测试并没有太大区别。差异在于,基准测试的目的更多地是关注业务功能的正确性,或者说验证测试脚本的正确性,然后,将基准测试时采集得到的系统性能指标,作为基准测试结果,为后续并发压力测试的性能分析提供参考依据。
负载测试,主要指的是模拟系统在正常负载压力场景下,考察系统的性能指标。这里说的正常负载,主要是指用户对系统能承受的最大业务负载量的期望值,即预计系统最大应该支持多大用户的并发量。通过负载测试,目的是验证系统是否能满足预期的业务压力场景。
和负载测试的概念比较接近的是压力测试。通俗地讲,压力测试是为了发现在多大并发压力下系统的性能会变得不可接受,或者出现性能拐点(崩溃)的情况。在加压策略上,压力测试会对被测系统逐步加压,在加压的过程中考察系统性能指标的走势情况,最终找出系统在出现性能拐点时的并发用户数,也就是系统支持的最大并发用户数。
最后再说下疲劳强度测试。其实疲劳强度测试的加压策略跟负载测试也很接近,都是对系统模拟出系统能承受的最大业务负载量,差异在于,疲劳强度测试更关注系统在长时间运行情况下系统性能指标的变化情况,例如,系统在运行一段时间后,是否会出现事务处理失败、响应时间增长、业务吞吐量降低、CPU/内存资源增长等问题。
通过对比可以发现,不同的性能测试类型,其本质的差异还是在加压策略上,而采用何种加压策略,就取决于我们实际的测试目的,即期望通过性能测试发现什么问题。明白了这一点,性能测试类型的差异也就不再容易混淆了。
结论要点1:性能测试手段的重点在于加压的方式和策略。
三、性能瓶颈定位的核心
从维度上划分,性能指标主要分为两大类,分别是业务性能指标和系统资源性能指标。
业务性能指标可以直观地反映被测系统的实际性能状况,常用的指标项有:
- 并发用户数
- 事务吞吐率(TPS/RPS)
- 事务平均响应时间
- 事务成功率
而系统资源性能指标,主要是反映整个系统环境的硬件资源使用情况,常用的指标包括:
- 服务器:CPU利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘IO状态、网卡带宽使用情况等;
- 数据库:数据库连接数、数据库读写响应时长、数据库读写吞吐量等;
- 网络:网络吞吐量、网络带宽、网络缓冲池大小;
- 缓存(Redis):静态资源缓存命中率、动态数据缓存命中率、缓存吞吐量等;
- 测试设备(压力发生器):CPU利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘IO状态、网卡带宽使用情况等。
有些指标在不同的操作系统中的名称有些差异,但是基本都会有对应的指标,其代表的意义也是相通的。例如,处理器队列长度这个指标,在Windows中的指标名称是
System\Processor Queue Length
,而在Linux系统中则需要看load averages
。
可能对于最后一项(测试设备)有些人不大理解,监控被测系统环境的相关硬件资源使用情况不就好了么,为什么还要关注测试设备本身呢?这是因为测试设备在模拟高并发请求的过程中,设备本身也会存在较高的资源消耗,例如CPU、内存、网卡带宽吃满,磁盘IO读写频繁,处理器排队严重等;当出现这类情况后,测试设备本身就会出现瓶颈,无法产生预期的并发压力,从而我们测试得到的数据也就不具有可参考性了。
需要说明的是,性能指标之间通常都是有密切关联的,单纯地看某个指标往往很难定位出性能瓶颈,这需要我们对各项性能指标的含义了然于胸,然后才能在实际测试的过程中对系统性能状况综合进行分析,找出整个系统真正的瓶颈。举个简单的例子,压力测试时发现服务器端CPU利用率非常高,那这个能说明什么问题呢?是服务端应用程序的算法问题,还是服务器硬件资源配置跟不上呢?光看这一个指标并不能定位出产生问题的真正原因,而如果仅因为这一点,就决定直接去优化程序算法或者升级服务器配置,最后也很难真正地解决问题。
结论要点2:性能瓶颈定位的重点在于性能指标的监控和分析。