网站内搜索功能怎么做,网页设计实训报告总结万能模板,网站排行首页怎么做,微信小程序用什么开发工具接口性能测试是用于验证应用程序中的接口是否可以满足系统的性能要求的一种测试方法。确定应用程序在各种负载条件下的性能指标#xff0c;例如响应时间、吞吐量、并发性能等#xff0c;以便提高系统的性能和可靠性。本文主要讲述接口性能测试从前期准备、方案设计到环境搭建…
接口性能测试是用于验证应用程序中的接口是否可以满足系统的性能要求的一种测试方法。确定应用程序在各种负载条件下的性能指标例如响应时间、吞吐量、并发性能等以便提高系统的性能和可靠性。本文主要讲述接口性能测试从前期准备、方案设计到环境搭建执行及数据收集整理的完整流程。
本文主要根据自身经历介绍如何进行接口的性能摸底测试进行摸底测试前需要进行哪些准备如何执行执行后结果分析与测试报告输出。
1 确定测试目标
明确性能摸底测试的目标确定要测试的接口和预估性能指标例如评估接口的响应时间、吞吐量、并发性能等性能指标服务稳定性、资源消耗情况评估。可以从如下方面了解性能需求
1、项目立项时定义的性能指标
2、产品或运营人员站在用户角度提测的性能需求
3、项目技术负责人从技术角度直接提测的性能需求
2 收集业务需求
2.1 系统未上线或新上线用户数据量少
与产品、项目侧沟通确认预计试用推广后正常使用该系统的用户量、活跃用户比例、系统工作时长单业务每人每天平均调用次数和预估目标TPS可参考下表。 2.2 系统已上线有稳定用户量
1、若系统已经投入使用且有一定的用户数据量则与运维人员沟通拉取现网真实业务请求数据详细要求可参考如下表格 2、业务选取原则如下
1)系统选取占总业务量80%的业务做为基础业务模型
2)据业务量大小选取典型业务一般通过统计现网系统业务量排序TOP10、TOP20确定
3)选取现网系统中消耗资源最多或者耗时最长的业务
4)选取现网系统中业务路径最长的业务
5)选取现网系统容易发生故障的业务
6)为满足其他特殊测试目标需要选取的业务。
现在我也找了很多测试的朋友做了一个分享技术的交流群共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源没人解答问题坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化性能安全测试开发等等方面有一定建树的技术大牛
分享他们的经验还会分享很多直播讲座和技术沙龙
可以免费学习划重点开源的
qq群号110685036【暗号csdn999】 2.3 环境调研
1、系统架构调研 2、服务器配置调研 3、数据库配置调研 2.4 铺底数据调研 2.4.1 铺底数据量调研 1、对于已上线且成熟的系统数据库表的数据量可由现网获取 2、对于未上线或刚上线的新系统数据库中数据量相对较少系统整体响应时间很快。随着业务的持续开展数据量会成倍地增加业务系统的相关操作响应时间会因为数据的快速增长等原因变长。因此在性能测试时需要加入相当规模的铺底数据来模拟未来几年业务增长条件下系统相关操作的性能表现。可与产品、研发和业务方共同评估系统上线后2年后数据库的数据量可根据业务正常推广后面向客户群数量估算估算方法可参考面向客户群数量为M,每个用户产生数据量N条,该表的数据量为M*N 。 2.4.2 铺底数据检查注意事项 1、数据量是否合理数据量需要预估一下未来几年的数据量来进行数据构造
2、数据构造尽可能贴合实际使用情况
3、数据分布是否合理
1有的是数据库集群数据的分片需要检查一下构造的数据分布是否均匀每台服务器上分布的数据量是否差异很大
2查看是否有数据集中的问题比如有一个查询交易这个数据分为a、b两种类型。 3.1 测试场景设计 根据需要压测的业务和性能期望分别进行基准场景、单业务压测场景、混合测试场景和稳定性场景设计详细的测试方法。 3.1.1 基准测试场景
获取单个业务在无压力的情况下的基准响应时间及验证测试数据正确性作为其他场景的参考依据。一般情况下建议一个脚本(线程)只包含一个完整的业务不要把多个业务放到一个脚本中。因为不同的业务其响应时间会不同响应时间较长的业务会成为“瓶颈”。
3.1.2 单业务测试场景
单业务负载的场景是为了找到单个业务的最优TPS检测单业务在并发情况下是否存在性能瓶颈。
单业务最优的衡量标准通常以应用或数据库等系统的CPU使用率不大于70%为标准。一般在生产上运行的应用如果CPU使用率长期处于高水平那是非常严重的问题应用的节点随时都可能挂掉。单业务设计压测场景可以从10个并发用户开始执行几分钟后再增加10个用户直到应用CPU使用率超过70%为止找到TPS增长的拐点确定最优TPS。 3.1.3混合测试场景
按照测试模型中的业务比例及目标TPS对每个业务分配不同的并发用户数量设置不同的延时同时进行加压通过多个子场景的不断尝试最终测试出应用能够达到的最优TPS。
3.1.4稳定性测试场景
给应用一个恒定的压力使场景运行较长的时间用于测试应用在长时间运行下的表现TPS是否有较大波动、是否有错误和异常、是否存在内存溢出等。
根据业务类型不同一般会运行不同的时长对于5*8这样的应用稳定性运行8小时即可7*24这样的应用最好能够运行12小时以上恒定的压力大概选择最优压力的80%为目标压力。 3.2 测试脚本准备 确认好测试工具和场景后就可以编写测试脚本这里以jmeter脚本为例
1、基准压测启动jmeter添加线程组编写脚本设置好基准测试时间和线程数就可执行 2、设置阶梯加压 启动jmeter添加线程组——jpgc - Stepping Thread Group设置阶梯加压方法编写脚本后即可执行 3、混合测试吞吐量设置启动jmeter添加线程组设置执行时间添加吞吐量控制器—Throughput Controller按一定的比例或数量分配设置每个接口的线程数设置好后执行脚本即可 4.1 测试环境要求 1、硬件配置尽量和生产环境保持一致
2、选用与被测软件相一致的操作系统和软件平台 3、营造相对独立的测试环境 4、系统架构和生产环境一致。
5、和生成环境在同一局域网
4.2 数据准备
测试时需要模拟数据量尽量跟前期调研的数据量保持一致可以从生产库导数据或通过Loadrunner、Jmeter、DataFactory等方法生产数据。
5.1 脚本执行
当测试方案设计评审通过后即可开始执行在压测机上面执行脚本的同时观察是否有报错及时查看日志寻找报错原因可找研发协助解决。以下举例几种比较常见的错误。
1、不要在本地进行压测要选取合适的压测机进行测试。本地端口有限压测线程起来就容易占满后续的就连接不上了会导致接口大量报错需要修改端口回收时间。 2、压测前先检查下服务磁盘空间避免因服务磁盘空间不足导致压测中断下图就是在压测过程中磁盘空间满了的错误和查看磁盘空间方法。 3、压测过程中并发增大过快等待时间过长导致的超时或接口不稳定概率性报错此时需要查看日志找出报错的具体原因可找研发协助排查分析 5.2 性能监控
在脚本执行过程中及时监控CPU使用率、内存溢出、是否有慢sql等情况
如果业务有集成监控可直接观察如Grafana平台没有集成监控可使用服务器资源监控工具nmon、mysql性能分析工具MONyog等监控工具。 5.3 慢sql监控 除了监控工具外还可以通过数据库配置的慢sql时间和log路径查看到慢sql情况可以让运维人员帮忙导出日志信息。 5.4 结果记录
测试完成后记录过程数据便于分析统计。可以通过jmeter查看tps和响应时间趋势。查看tps选择监听器jpgc - Transactions per Second查看响应时间选择监听器jpgc - Response Times Over Time需要安装jar包将JmeterPlugins-Standard.jar和JmeterPlugins-Extras.jar放到jmeter安装路径/lib/ext中 将测试的数据收集后进行整理分析与预期结果进行对比判断性能指标是否达到期望并提出改进意见。
- 本文详细描述了接口性能摸底测试的完整链路以及测试过程中可能遇到的问题和解决方法希望对想要学习或需要进行接口性能测试的业务侧人员提供设计思路和指导。
END今天的分享就到此结束了点赞关注不迷路~
