目录
【写在前面】
读书笔记,做记录,供自学,如侵,请告知,会删。
1. 性能测试基础
1.1 什么是性能测试
(1)性能测试,是指通过自动化的测试工具,模拟多种正常的,峰值的,以及异常的负载条件来对系统的各项性能指标进行测试。
本质是更精细的规划我们的架构和更优质的代码质量,充分有效的利用资源。
(2)最典型的是负载测试和压力测试。
负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时系统各项性能指标的变化情况。
压力测试,通诺确定一个系统的瓶颈或者不能接受的性能点,来获得系统能提供的最大服务级别的测试。
(3)性能测试的目的
验证软件系统是否能够达到用户指出的性能指标,同时发现软件系统中存在的性能瓶颈,优化软件,最后达到优化系统的目的。包括:
评估系统的能力。
识别体系中的弱点。
系统调优。
验证稳定性resilicence和可靠性reliability。
1.2 理论模型
(图源网络)
解析:
(1)横坐标:用户数增加。
(2)纵坐标:
Utilization:系统资源利用率。Light Load区域的边界,这个值一般为70%左右,剩余资源作为缓冲区。Heavy Load区域时,系统资源消耗殆尽。
Throughput:吞吐量。在Heavy Load区域的中间时刻达到最高(注意这里是否达到了网卡的最大流量,这里的最高点表示未达到网卡的最大流量),这时系统的资源也消耗得差不多了,此时,用户数继续增加,吞吐量反而开始下降(系统资源消耗过多,单位时间内处理的数据量会减少,导致流量减少)。Buckle Zone区域,系统死机,无法处理更多请求,吞吐量急剧下降。
Response Time:响应时间。Buckle Zone区域,系统死机,响应时间急剧上升。
(3)Light Load:轻负载区域。
(4)Heavy Load:重负载区域,各项性能指标已接近最大值。
(5)Buckle Zone:毁灭区域,系统已崩溃。
1.3 常见术语
(参考该文第三点: 性能测试:概念,性能指标,监控指标........)
(1) 虚拟用户数 VUser
Virtual User,模拟真实业务逻辑步骤的虚拟用户,虚拟用户模拟的操作步骤都被记录在虚拟用户脚本里。 Vuser脚本用于描述Vuser在场景中执行的操作。
(2)事务 Transaction
事务是性能测试脚本的一个重要特性。需要定义事务。每个事务包含事务开始和事务结束标记。事务用来衡量脚本中一行代码或多行代码的执行所耗费的时间。可以将事务开始放置在脚本中某行或多行代码的前面,将事务结束放置在该行或多行代码的后面。在该脚本的虚拟用户运行时,这个事务将衡量这些代码的执行花费了多长时间。
(3)每秒事务数 TPS
Transaction Per Second,每秒中系统能够处理的交易或事务的数量。是衡量系统处理能力的重要指标。
(4)Page View PV
Page View,用户通过浏览器访问的页面,对应用服务器产生的每一次请求,记为一个PV。性能测试环境下,将这个概念做了延伸,系统真实处理的一个请求,称为一个PV。也适用于接口。
(5)高峰PV (Peak PV)
PV峰值,一天中PV数达到的最高峰。
(6)并发 Concurrency
狭义的并发,是指所有的用户在同一时刻做同一件事情或操作,这种操作一般针对同一类型的业务,或者所有用户进行完全一样的操作,目的是测试数据库和程序对并发操作的处理。
广义的并发,即多个用户对系统发出了请求或者进行了操作,这些请求或操作可以不同,对整个系统来说,还是相当于有很多个用户同时进行操作。
(7)场景 Scenario
为了模拟真实用户的业务处理过程,构建的基于事务,脚本,虚拟用户,运行设置,运行计划,监控,分析等的一些动作的集合,称为性能测试场景。场景包含了待执行脚本,脚本组,并发用户数,负载生成器,测试目标,测试执行时的配置条件等。
(8)响应时间 Response Time
是指从客户端发出一个请求开始计时,到客户端接收到从服务器返回的响应结果结束所经历的时间。响应时间由 请求发送时间+网络传输时间+服务器处理时间 组成。
重点关注:事务的响应时间。分为事务最小响应时间+事务平均响应时间+事务最大响应时间
(9)思考时间 Think Time
模拟正式用户在实际操作时的停顿间隔时间。
从业务角度来讲,思考时间是指用户在进行操作时,每个请求之间的间隔时间。
在测试脚本中,思考时间体现为脚本中两个请求语句之间的时间间隔。
(10)CPU资源
是指性能测试场景运行的时间段内,应用服务系统的CPU资源占用率。
是判断系统处理能力以及应用运行是否稳定的重要参数。
应用服务系统可以包括应用服务器,web服务器,数据库服务器。
(11)负载 Load
系统平均负载,是指在特定时间间隔内,运行队列中的平均进程数。在运行队列中的进程需要满足:它没有在等待I/O操作的结果。它没有主动进入等待状态。没有被停止。
(12)标准差 Std.Deviation
根据数理统计的概念而来。标准差越小,说明波动越小,系统越稳定。反之同理。
包括: 响应时间标准差,TPS标准差,Running Vuser标准差,Load标准差,CPU资源利用率标准差,Web Resources 标准差等。
1.4 场景和类型
(参考该文第四点: 性能测试:概念,性能指标,监控指标........)
这里说得更清楚一些。
性能测试从狭义的角度,分成4中类型和2种场景,如下:
(1)基准测试
参考上图,Light Load区域前期的测试。
利用少量的用户,进行一次性能测试,得到一个基准值,方便其他测试后有个对比的依据。
(2)负载测试
以性能预期目标为前提,对系统不断施加压力,验证系统在资源可接受范围内是否能达到性能预期。
每个项目都需要做负载测试。
(3)压力测试
指超过安全负载的情况下,对系统不断施加压力。
通过确定系统的瓶颈或不能接收用户请求的性能点,来获得系统能提供的最大服务级别的测试。
(4)稳定性测试
指被测试系统在特定硬件,软件,网络环境条件下,给系统加载一个业务押利率,使系统运行一段较长的时间,以此检测系统是否稳定。
一般稳定性测试的时间为12*n小时。
(5)单场景测试
针对单个性能测试点,构建一个性能测试场景,而进行的性能测试。
单场景适用于性能测试,负载测试,压力测试,稳定性测试。
(6)混合场景测试
为了尽量模拟生产线上运行的业务压力或用户使用场景,测试系统的整体性能是否满足性能需求,把经过一定规则筛选的性能测试点,按合乎实际逻辑的虚拟用户请求并发,组合成一个混合场景。
混合场景的特征,通常包含两个或者两个以上的脚本组,执行时间较长。
混合场景在稳定性测试,负载测试中使用。
2. 性能测试如何设计
(1)性能需求点分析
(2)确定测试目标
(3)测试服务对象确认
(4)关键场景定义
(5)关键路径获取及全面覆盖