性能测试是软件测试中的重要一环,今天给大家介绍性能测试及如何使用RunnerGo完成性能测试任务。
性能测试是什么?
一句话概括:不断地通过不同场景的系统表现去探究系统设计与资源消耗之间的平衡,为开发人员提供消除瓶颈所需的诊断信息。
测试类型:
性能测试中常用的性能有:负载测试、压力测试两种。
负载测试(Load Testing)主要是通过逐渐增加系统负载,如并发用户数、数据量等,来测试系统的性能变化。测试的目的是确定在满足性能指标的情况下,系统所能承受的最大负载量。负载测试通常从较小的负载开始,逐渐增加并发数和数据量,观察并记录不同负载下系统的各项指标,直至系统无法承受而崩溃或服务不可用。
压力测试(Stress Testing)则更侧重于测试系统的限制和故障恢复能力,通常是在超强的、近乎会导致系统崩溃的负荷(如大数据量、大量并发用户等)下进行。这种测试方法旨在观察系统在极限负荷下的性能变化,如CPU利用率、内存使用率、磁盘I/O吞吐率、网络吞吐量等,以及系统是否会出现内存泄漏、功能性故障等问题。压力测试包括稳定性压力测试和破坏性压力测试。稳定性压力测试是在选定的压力值下长时间持续运行,以考察各项性能指标是否在指定范围内;而破坏性压力测试则是通过继续加压的手段,使系统迅速崩溃,以暴露潜在的问题。
不同的测试类型需要配置不同的测试脚本,如我们常用的阶梯压测、高并发的压力测试等等。通过RunnerGo内置的六种压测模式可以满足多种性能测试类型。
性能测试指标:
常见的测试指标:
吞吐量:系统在指定时间内处理多少个信息单元。
响应时间:从用户输入的请求到系统开始响应该请求之间经过的时间量。
带宽:每秒可以在工作负载之间移动的数据量,通常是指通过网络。
每秒 CPU 中断次数:取的是平均值。指处理器每秒接收和处理的硬件中断数。
内存使用:计算机上进程可用的物理内存量。
磁盘使用:磁盘忙于执行读取或写入请求的时间量
确定测试指标:
实际我们在测试时,只要不报错我们关注吞吐量、响应时间就可以了。测试指标需要根据以下两点进行确定:
根据系统在线用户数,来计算生产环境的用户 TPS,通过基准环境的测试,来验证真实的 TPS 是否满足生产环境的 TPS 需求,以及我们的运维架构和资源使用是否合理。
保证在 CPU 利用率小于80%,内存小于80%,并且没有错误的 Http 请求。
并发压力测试tps计算:
在开始计算前需要了解三个概念:
用户数:数据库中的总用户数
在线用户数:登录状态的用户数,挂在系统上,但是不会对系统产生压力=
并发用户数:真正产生操作的用户,产生压力之源
TPS计算公式为:tps=持续时长/总请求数
秒杀活动压测数据计算
假如平台总注册用户数有100w,有10w用户约定好同时对某一接口进行访问,比如1分钟,陆续来访10w用户,那么我们系统并发用户是比实际的10w要小的
那一个秒杀活动开始时,10w用户在10秒内重复请求多次,平均3次每个人,那么tps=100000/10=10000tps,表明我们目标的tps应达到10000才能抗住100000用户的同时请求
领券活动压测
平台注册用户数100w,用10w用户准备抢券,即10w人同时在10秒内访问抢券接口,在过程中每个用户可能会多次点击抢券,估算每个用户点击3次抢券接口,那么
tps=100000*3/10=30000tps,系统的目标tps需达到30000才抗住10w用户的并发访问压力
使用RunnerGo做性能测试:
RunnerGo支持单接口压测和场景压测。并且使用RunnerGo做性能时只需简单几个操作:
单接口压测:
每个接口在测试完成后可以在一键压测处进行单接口压测,同样支持测试模式选择:
场景压测:
RunnerGo可以创建测试场景,在场景的基础上进行场景性能测试,在右侧任务配置栏,根据需求配置控制模式、压测模式并配置并发数即可开始测试。
开始测试:
这里我们使用RunnerGo对单个商品评论接口进行一次阶梯模式的压力测试:
配置如下图:(配置完成后会显示加压梯度图)
测试完成后 RunnerGo会提供可视化图形测试报告,测试人员根据预定的测试指标进行多次调节从而得到 API 请求的实际 TPS 和 RT再与理想中TPS和RT做对比,来确定当前API性能情况。
还可查看debug日志和压力机情况对测试结果进行分析:
除此之外,RunnerGo在进行性能测试时还支持分布式服务器部署、接口权重、服务器权重配置,更好地满足性能测试需求。
感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取