性能测试收尾
Locust概述
是基于Python语言的性能测试工具,它是基于协程的思想来进行设计的。Python语言是没有办法利用多核的优势,所以了Python为了解决这个问题,设计了协程,作为协程的任务,遇到IO堵塞就立刻切换。 什么是协程,协程可以简单的来说就是微线程。
locust主要做负载测试和稳定性测试,也可以做压力测试。
安装locust
pip3 install locust
WEB模式
下⾯具体通过⼀个案例的代码来演示Locust的使⽤,我们通过编写的代码来模拟对⽬标服务进⾏⽤户⾏为的HTTP 的请求,通过控制台的命令⾏以及WEB平台来查看它收集到的性能测试数据。涉及到的代码如下:
`import time from locust`
`import HttpUser,task,between`
`class QuickStartUser(HttpUser):`
`wait_time = between(1,2.5)`
`@task`
`def index(self):`
`r=self.client.get('/login')`
`assert r.status_code==200`
下⾯针对这部分代码来进⾏解释,在@task⾥⾯,我们使⽤装饰器定义了微线程的⽤户请求,也就是模拟⽤户请求 路由地址为/login的接⼝信息。wait_time是模拟每个⽤户耗时是在1⾄2.5秒之间。下⾯在控制台⾥⾯执⾏如下命 令,就会启动locust的程序,命令为:
locust -f locustfile.py

Number of total users to simulate:设置模拟的⽤户总数
Spawn rate (users spawned/second):每秒启动的⽤户虚拟数
Host (e.g. http://www.example.com):被测的⽬标服务器的地址信息
下⾯具体看这些信息展示的含义,具体总结如下:

Type:请求类型(也就是请求具体是那个=⽅法)
Name:请求的路径地址信息
Requests:当前已完成的请求数量
Fails:当前失败的数量
Mediam(ms): 响应时间的中位数
90%ile (ms):90%的请求响应时间
Average (ms):平均响应时间 Min (ms):
最⼩响应时间 Max (ms):最⼤响应时间
Average size (bytes):平均请求的数据量
Current RPS:每秒中处理请求的数量,也就是RPS
菜单栏具体为:
New test:点击该按钮可对模拟的总虚拟⽤户数和每秒启动的虚拟⽤户数进⾏编辑;
Statistics:聚合报告 Charts:测试结果变化趋势的曲线展示图,分别为每秒完成的请求数(RPS)、响应时间、不同时间的虚拟⽤户数;

Download Data:测试数据下载模块, 提供三种类型的CSV格式的下载,分别是:Statistics、responsetime、 exceptions;
负载模式
Locust⽐较优秀的地⽅在于它可以在单机模式的情况下,可以实现对服务端⾼负载的压⼒测试,这样对服务端的压 ⼒会造成很⼤的负载,我们可以测试在加载完的模拟的⽤户后,继续对服务端发送请求,修改后的代码具体为:
import time
from locust import HttpUser,task,between
class QuickStartUser(HttpUser):
host = 'http://127.0.0.1:5000'
min_wait = 3000
max_wait = 6000
@task
def index(self):
r=self.client.get('/login')
assert r.status_code==200
性能测试项目实战
背景
公司之前的测试团队做API的⾃动化测试都是使⽤JMeter等⼯具来进⾏,这样的话测试效率⽽⾔不是那么很⾼,⽽ 且在扩展性⽅⾯不是很有竞争⼒的。所以开发了新的测试平台,但是考虑到公司的测试⼈员有1000⼈,那么就需要 验证1000⼈同时使⽤测试平台,是否会出现平台⽆响应以及崩溃(雪崩)的情况。
工作内容 | 负责人 | 时间 | 备注 | |
---|---|---|---|---|
1 | 测试场景梳理 | 小陈 | 2022.18-2022.18 | |
2 | 资源采购(阿⾥云服务器) | 李四 | 2022.18-2022.18 | 与⽣产保持⼀致 |
3 | ⽬标输出 | 小陈 | 2022.18-2022.18 | |
4 | 测试数据的准备 | 小A | 2022.18-2022.18 | 需要10万数据 |
5 | ⼈员不够 | 测试经理协调 | 2022.18-2022.18 |
测试前期准备(前置工作)
基于梳理的业务场景,和服务底层稳定性体系的保障,性能测试⼯具的选择具体如下:
工具 | 选择理由 | 备注 | |
---|---|---|---|
1 | JMeter | 开源,可以做常规以及并发测试 | |
2 | Locust | 开源,基于协程,来测试服务稳定性这部分 | 验证服务是否出现崩溃 |
3 | JVM监控⼯具 | 检测服务是否出现OOM | |
4 | Grafana&InfluxDB | 数据可视化报表展示 |
测试计划
背景
公司之前的测试团队做API的⾃动化测试都是使⽤JMeter等⼯具来进⾏,这样的话测试效率⽽⾔不是那么很⾼,⽽ 且在扩展性⽅⾯不是很有竞争⼒的。所以开发了新的测试平台,但是考虑到公司的测试⼈员有1000⼈,那么就需要 验证1000⼈同时使⽤测试平台,是否会出现平台⽆响应以及崩溃(雪崩)的情况。
前置工作
人员配备
序号 | 工作内容 | 负责人 | 时间 | 备注 |
---|---|---|---|---|
1 | 测试场景梳理 | 小陈 | 2022.18-2022.18 | |
2 | 资源采购(阿⾥云服务器) | 李四 | 2022.18-2022.18 | 与⽣产保持⼀致 |
3 | ⽬标输出 | 小陈 | 2022.18-2022.18 | |
4 | 测试数据的准备 | 小A | 2022.18-2022.18 | 需要10万数据 |
5 | ⼈员不够 | 测试经理协调 | 2022.18-2022.18 | |
工具 | 选择理由 | 备注 | |
---|---|---|---|
1 | JMeter | 开源,可以做常规以及并发测试 | |
2 | Locust | 开源,基于协程,来测试服务稳定性这部分 | 验证服务是否出现崩溃 |
3 | JVM监控⼯具 | 检测服务是否出现OOM | |
4 | Grafana&InfluxDB | 数据可视化报表展示 |
场景 | 目标 | 负责人 | 时间 | 是否完成 | 备注 | |
---|---|---|---|---|---|---|
1 | 测试并发登录 | 满⾜100⼈同时登录 | ⼩A | |||
2 | 产品列表加载 | 同时满⾜50个⼈加载,响应时间⼩ 于5秒 | ⼩A | |||
3 | 产品搜索 | 同时满⾜50个⼈加载,响应时间⼩ 于5秒 | ⼩E | |||
4 | 同时⽀持执⾏API测试 ⽤例 | 响应时间⼩于5秒,最⼤并发100 | ⼩B | |||
5 | 上传⽂件最⼤⽀持2G | 不能出现OOM | ⼩C | |||
6 | ⽀持持续的发送API请 求 | 验证服务的稳定性 |
测试风险
⽬前⽆⻛险 基于客观事实,有没有依赖项
测试设计与开发
JMeter⼯具
测试并发登录
产品列表加载
测试最简单的⽅式: 多个人访问产品列表,响应时间,是否成功访问
同时⽀持执⾏API测试⽤例
上传⽂件最⼤⽀持2G
测试⽅式是:一个人上传2.1G会不会泄露,2.2G,2.3G会不会,如果两个人都是1.1G是否会发生内存泄露,如果更多的人同时上传是否发生泄漏
locust开发
支持持续的发送API请求
import time
from locust import HttpUser,task,between
class QuickStartUser(HttpUser):
host = 'http://47.95.142.233:8000'
min_wait = 3000
max_wait = 6000
def login(self):
r=self.client.post(
url='/login/auth/',
json={"username":"13484545195","password":"asd888"})
return r.json()['token']
@task
def api(self):
r=self.client.post(
url='/interface/run/api/32',
headers={'Authorization':'JWT {token}'.format(token=self.login())})
assert r.status_code==200
测试执行与管理
登陆场景
测试报告(分析)
参与人员
测试人员 | 版本 | 备注 |
---|---|---|
⼩A,⼩B,⼩C,⼩D,⼩E | V3.1.0 |
报告汇总
测试并发登录
测试结论:结果结果不符合预期,在100⽤户并发登录的情况下,响应时间最⼤是31.88s。
过程数据
错误汇总
错误类型 | 错误日志 | |
---|---|---|
1 | Java.lang.OutOfMemoryError | 详细的错误⽇志信息 |
2 | TimeOutExpection |
测试风险
序号 | 风险描述 | 备注 |
---|---|---|
1 | 并发⽤户数载100的时候是满⾜要求,但是在110的时候,响应时间不满⾜,可能会给⽤户的 体验很差劲。 | |
2 | 在20次的测试中,存在1次的上传⽂件失败,概率是5% | |
测试结论
依据上述的各个结果,整体测试结论具体汇总如下:
序号 | 并发登录 | 是否通过 | 备注 |
---|---|---|---|
1 | 登录并发测试 | 不通过 | |
2 | |||
3 |
性能测试关注指标
测试执行过程中,需要收集数据
1、时间
2、CPU与内存的变化趋势
指标:
1、系统资源:CPU与内存
2、响应时间:最小,最大,平均,中位数,90%,95%,99%
3、吞吐量
4、IOPS,连接数
5、JVM的资源变化趋势关注
100万 90万 150万
1、系统资源:CPU与内存
2、响应时间:最小,最大,平均,中位数,90%,95%,99%
3、吞吐量
4、IOPS,连接数
文件上传: 过程数据: 测试结论: 2.2 g 1G
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· Manus的开源复刻OpenManus初探
· AI 智能体引爆开源社区「GitHub 热点速览」
· C#/.NET/.NET Core技术前沿周刊 | 第 29 期(2025年3.1-3.9)
· 从HTTP原因短语缺失研究HTTP/2和HTTP/3的设计差异