网站首页 > 开源技术 正文
考虑到文章篇幅过长,计划分两部分写完《利用Python Locust库基于Robot Framework实现接口性能测试》,包含设计策略、框架设计、核心源码的分享,本篇主要分享设计策略、框架设计及实际应用效果。核心源码部分将在第二部分中进行分享,文章链接如下:
由于公司内测试环境(Linux虚拟机)系统资源性能指标无法保证,使得业务性能受到影响,进而导致性能测试结果的可靠性较低,因此性能测试大多在实际生产环境上进行。
因此萌生一个想法——如何提高测试环境性能测试结果的可靠性并实现持续构建性能测试?
性能瓶颈的影响因素
性能瓶颈定位从维度上划分,性能指标主要分为两大类,分别是业务性能指标和系统资源性能指标。
业务性能指标可以直观地反映被测系统的实际性能状况,常用的指标项有:
- 并发用户数
- 事务吞吐率(TPS/RPS)
- 事务平均响应时间
- 事务成功率
系统资源性能指标,主要是反映整个系统环境的硬件资源使用情况,常用的指标包括:
- 服务器:CPU利用率、处理器队列长度、内存利用率、磁盘IO状态、网卡带宽使用情况等。
- 数据库:数据库连接数、数据库读写响应时长、数据库读写吞吐量等。
- 网络:网络吞吐量、网络带宽、网络缓冲池大小。
- 缓存(Redis):静态资源缓存命中率、动态数据缓存命中率、缓存吞吐量等。
- 测试设备(压力发生器):CPU利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘IO状态、网卡带宽使用情况等。
测试环境下测试结果可靠性的探讨
在测试环境系统资源性能指标不满足性能测试条件时,性能的测试结果是难以被认可的。这也是我们在测试环境(linux虚拟机)下,不做性能测试的原因,只有在生产环境进行实测时,会开展性能测试。
矛盾双方是可以互相转换的,假如测试环境的测试结果不是进行性能评估的,而是用来比对的呢?——与上一次该接口在该测试环境下的性能测试结果比较。实现接口的不同版本的横向比较。理论上,不同版本非重大改动的情况下的接口性能指标是相对稳定的(测试环境数据量等因素已考虑),因此我们利用这一点,进行同一接口在相同测试环境下的不同版本的性能指标比较结果是相对可靠的。
持续性的性能测试探讨
随着版本的迭代,每次迭代是否需要进行接口的性能测试,个人认为是需要的。但由于实际的测试环境、人力投入、测试周期等因素,难以做到持续性的性能测试,大多数在某一个版本或交付版本进行性能测试,再进一步就是线上生产环境的性能监控。
那么是否有必要构建持续性的性能测试呢,如何构建?是否可以像构建自动化用例那样,快速的构建接口的性能测试用例呢?使性能测试常态化,抱着这种期望,在前段时间,我使用Python的Locust库基于Robot Framework做了一次尝试,实践效果不错,随后也应用到了实际项目当中。
持续性的性能测试设计策略
核心理念
围绕产品进行持续性的业务性能指标比对,实现性能测试的常态化。
框架定位
该框架适应于对接口进行持续性的性能比对,如比对新旧版本接口的性能指标差异是否保持在合理的范围内,以便对新旧版本性能差异较大的接口进行更深层的性能测试。
框架构建
技术栈:Python、 Locust、Robot Framework、SqLite
如下图所示,整体架构目前分为压力生成关键字、负载控制(包含结果采集)关键字、结果分析器关键字、文件清除关键字四部分。
压力生成关键字
根据性能测试用例模版与接口请求类型、检查点、请求体等内容构建Locustfile文件(接口性能测试用例),当前只支持单接口的性能测试:
请求参数说明
- host:host地址
- url:请求url
- method:请求方式
- web_reg_find:检查点
- parameterization:参数,填写文本地址默认进行参数化处理。
- parameter_allocation_update: 参数分配和更新方式
- min_wait:最小等待时间,默认10ms
- max_wait:最大等待时间,默认20ms
响应返回说明
- filename :初始化性能测试脚本路径
负载控制(包含结果采集)关键字
运行接口性能测试用例,获取性能测试结果,并实现结果入DB数据库:
请求参数说明
- locustfile:locustfile脚本路径
- locust_command:locust命令
响应返回说明
- result:接口测试结果
结果分析关键字
获取性能测试结果根据阈值校验项,检测各项结果是否超过历史平均结果的阈值设定,如果异常则断言失败。
请求参数说明
- result:接口测试结果
- threshold_value:比对阈值,默认超过历史测试结果平均数的20%,则视为异常。
- search:阈值校验项,默认关注平均、最大、最小、中位响应时间、rps
- result:接口测试结果
- threshold_value:比对阀值,默认超过历史测试结果平均数的20%,则视为异常。
- search:关注点,默认关注平均、最大、最小、中位响应时间、rps
文件清除关键字
删除临时文件,包含Locustfile文件、执行结果文件:
请求参数说明
- filename:Locustfile路径
考虑到文章篇幅过长可能影响阅读体验,关于每个关键字的设计及核心源码分享我们将在后续文章中分享。
应用效果
场景一 单接口性能测试,无参数化。
我们可以看到通过几行简单的配置,就可完成接口的性能测试用例开发。
场景二 单接口性能测试,参数化。
参数化数据存放在parameterfile.txt中。
测试结果
一般情况,此次测试结果不超过历史均值的设定阀值,则视为通过,否则异常。
若对你有所帮助,欢迎大家评论、留言。
猜你喜欢
- 2024-10-03 Python Locust 基于Robot Framework实现关键字驱动接口性能测试
- 2024-06-23 黑色幽默 “败给你的黑色幽默”#翻唱
- 2024-06-23 运行Scrapy程序时出现No module named win32api的解决思路和方法
- 2024-06-23 「性能测试」Locust+boomer+prometheus的分布式性能测试方案
- 2024-06-23 利用Python Locust库基于Robot Framework实现接口性能测试(二)
- 2024-06-23 坦克连:全球坦克库 美国M22蝉式-Locust空降轻坦
- 2024-06-23 Locust压测框架实战:HTTP脚本编写
- 2024-06-23 locust压测框架实战案例2
- 2024-06-23 从实例讲解Locust、jmeter、Loadrunner三种工具的分布式压测
- 2024-06-23 快速构建本地locust帮助文档
你 发表评论:
欢迎- 03-19基于layui+springcloud的企业级微服务框架
- 03-19开箱即用的前端开发模板,扩展Layui原生UI样式,集成第三方组件
- 03-19SpringMVC +Spring +Mybatis + Layui通用后台管理系统OneManageV2.1
- 03-19SpringBoot+LayUI后台管理系统开发脚手架
- 03-19layui下拉菜单form.render局部刷新方法亲测有效
- 03-19Layui 遇到的坑(记录贴)(layui chm)
- 03-19基于ASP.NET MVC + Layui的通用后台开发框架
- 03-19LayUi自定义模块的定义与使用(layui自定义表格)
- 最近发表
-
- 基于layui+springcloud的企业级微服务框架
- 开箱即用的前端开发模板,扩展Layui原生UI样式,集成第三方组件
- SpringMVC +Spring +Mybatis + Layui通用后台管理系统OneManageV2.1
- SpringBoot+LayUI后台管理系统开发脚手架
- layui下拉菜单form.render局部刷新方法亲测有效
- Layui 遇到的坑(记录贴)(layui chm)
- 基于ASP.NET MVC + Layui的通用后台开发框架
- LayUi自定义模块的定义与使用(layui自定义表格)
- Layui 2.9.11正式发布(layui2.6)
- Layui 2.9.13正式发布(layui2.6)
- 标签列表
-
- jdk (81)
- putty (66)
- rufus (78)
- 内网穿透 (89)
- okhttp (70)
- powertoys (74)
- windowsterminal (81)
- netcat (65)
- ghostscript (65)
- veracrypt (65)
- asp.netcore (70)
- wrk (67)
- aspose.words (80)
- itk (80)
- ajaxfileupload.js (66)
- sqlhelper (67)
- express.js (67)
- phpmailer (67)
- xjar (70)
- redisclient (78)
- wakeonlan (66)
- tinygo (85)
- startbbs (72)
- webftp (82)
- vsvim (79)
本文暂时没有评论,来添加一个吧(●'◡'●)