如何编写性能测试计划?一篇文章教你设计符合项目的性能测试计划

上篇文章,我们讲过性能测试计划,接下来我们就来讲讲如何设计符合项目的性能测试计划。

到上篇为止,我们了解了性能测试计划中包含的内容,但是,这个颗粒度,我觉得作为一名测试经验不够丰富的性能工程师来说,还是有些迷茫,只知道理论还不够,如何把性能测试计划落地,才是我们这次的目标。

所以,接下来,我会结合实际的项目案例,来落地性能测试计划。当然,针对一看就懂的内容,我就不过多唠叨,毕竟,大部分人的想法都是:时间很珍贵,干货要满满。

设计符合项目的性能测试计划

背景

根据你的实际项目来描述即可, 此处省略……

性能目标

根据商品在系统中的下发主流程,来测试系统的单接口最大容量;

根据业务比例设计容量场景,充分利用当前资源,找到当前系统的性能瓶颈,并优化,以达到系统的最佳运行状态;

根据稳定性场景,判断当前系统可支持的系统最大累加容量;

根据异常场景,判断当前系统中的异常对性能产生的影响。

压测范围

计算接口;

同步接口;

在这里,强调一下:需要测试的接口,是业务主流程的主要接口,并不是所有的接口都需要测试。

我在面试过程中,问求职者这个问题, 大部分都会说所有的接口都会测试一遍,这没必要。

启停准则

启动准则:环境准备完毕,架构服务部署完毕,测试计划、测试方案评审完毕、所有功能测试完毕、所有相关人员(PM、架构师、开发工程师、性能测试工程师、运维)已到位;

结束准则:达到项目需求的性能指标,性能瓶颈已解决,测试报告和调优报告都已完成;

暂停准则:系统环境出现问题导致无法继续测试,比如网络不同、压力机损坏、服务宕机等;

在启动准则:上述问题都已解决,可以继续进行测试。

性能指标

这里的TPS,可以通过运维提供的数据,进行预估。

根据多年的测试经验,这里的TPS标准方差不会超过5%,如果超过,那……能为你"点赞"。

系统架构图

系统逻辑架构图 和系统部署架构图,你可以与设计沟通或者运维沟通,都可以得到。得到这两个图,需要你去梳理架构逻辑,为你进行性能瓶颈分析做准备。

压测前准备

主要是硬件服务的配置信息,这里的资源配置,在评审阶段就可以得到。

工具准备

压测工具:Jmeter+InfluxDB。

监控工具:Promethues、Grafana、Kafka、Logstash、Spring Boot Admin等。

数据准备

测试脚本数据的准备,由于我的项目需要读取文件的方式往数据库里面写数据,所以,txt文件里面的数据,我也是写脚本自动生成的。

性能设计

①性能测试策略,一定是要满足:连续、递增的策略。

如果你的性能测试策略不满足这两点,那我可以断定,你的性能测试最后的结果,一定不是准确地,或者说一定不会符合实际的生产环境的业务场景。

②业务场景,一定要满足 基准场景、容量场景、稳定性场景 和异常场景,否则,最后的结果,一定是跟上面说的一样。

监控设计

①全局监控设计:一定是从整体出发,监控全局系统;如何快速定位问题, 取决于你的全局监控部署的是否完整。

②定向监控设计:对具体的应用、数据库等进行监控分析,如 jstack、mysqlreport等。

全局监控发现问题, 定向监控分析问题,这就是监控布局的整体意义所在,定向监控是分析问题最快最直接最便捷的。

如果你没有定向监控,即使你的经验在丰富, 分析性能瓶颈也不是最快最准确的。

项目组织架构

把你的项目组织架构图画出来, 这样便于发现问题后知道第一时间找谁去处理。

例如:

PM:项目负责人;

架构师:项目架构负责人;

开发工程师:参与项目编发人员,解决性能问题;

性能工程师:负责编写性能测试脚本 和负责分析性能瓶颈 , 这两个职位可以是同一个人;

运维:部署服务,环境构建。

成果输出

性能测试报告、性能调优报告、性能测试脚本、性能缺陷列表,在大部分性能测试工程师认为,成果输出中,并不包含性能调优报告,我也调查过很多人,最后我得到的结果,让我很吃惊:

不知道性能成果还 性能调优报告;

性能调优报告是什么;

过程性内容,没必要提供;

性能调优是开发参与,我一个性能测试工程师,何必管那么多。

看到这里, 你是不是也很吃惊, 或者刷新了"三观认知"。所以,避免你说出同样的话,建议你在成果输出中包含 性能调优报告。

项目风险分析

关于项目分析分析, 你可能会说,项目风险是测试报告中体现的, 为何要在 性能测试计划中体现?

其实不然, 项目风险分析,是你性能测试开始前期进行分析和评估的。

例如:

你的测试环境无法满足与生产环境一样的配置;

你的业务模型可能因为某些原因,导致与生产环境某一节点不相符;

由于涉及多团队协作,可能在性能测试过程中,某些人员无法准确到位……

总结

看到这里,你是不是已经对如何编写性能测试计划有了重新的认识?我用了大篇幅的内容,从性能测试计划包含哪些内容,到如何落地性能测试计划,就是为了让你在性能测试更专业。

一份详细的性能测试计划,是整个性能测试工程的关键所在。而在这份性能测试计划中, 更核心的内容,就是:性能指标,系统架构图、性能场景、监控设计。

所以, 在整个性能测试计划中,你需要把更多的精力,放在更核心的内容上。只有编写详细的性能测试计划, 设定明确的性能指标, 理解系统架构图,设计完整的性能测试场景,部署完整的监控,你的性能测试才算完整。

最后:

可以到我的个人号:atstudy-js,可以免费领取一份10G软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享!其中包括了有基础知识、Linux必备、Mysql数据库、抓包工具、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试等。

这些测试资料,对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
电池管理系统(BMS)是一种用于电池管理的技术,其作用是实时监测和管理电池的状态,以确保电池的安全和性能。在这篇文章中,我将提出针对电池管理系统的测试计划。 首先,我们需要制定一份详细的测试计划,其中应包含测试的目的、范围、方法、标准和结果分析。测试的目的是验证电池管理系统的可靠性、稳定性和安全性。测试范围应该明确涵盖BMS的整个功能组件,如传感器、计算机算法、电源等。测试方法应包括静态测试和动态测试,其中静态测试主要涵盖系统的电气特性和物理特性测试,动态测试则涵盖系统的性能和功能测试。测试标准应该符合国际标准和行业标准。结果分析应包括评估测试结果,拟定改进方案。 其次,测试人员应该熟悉测试流程和测试要求,并根据测试计划制定测试方案。在测试前需要将系统置于稳定状态,准备测试环境。在测试中,需要进行多种测试方案,如传感器测试、模块测试、电池充电和放电测试等。测试过程中应记录测试数据和异常情况,并及时处理。 最后,针对测试结果进行评估和分析,并准备出一份详细的测试报告。测试报告中应包含测试结果的详细分析、问题修复情况、测试结论和建议,以及未来改进计划。 总之,BMS测试计划应该具备全面性、系统性和可重复性,确保BMS的正常运行和长期稳定性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值