性能测试的时机

本文涉及的产品
可观测可视化 Grafana 版,10个用户账号 1个月
可观测监控 Prometheus 版,每月50GB免费额度
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 性能测试的时机

最近接触了一个团队。在查看APM的时候发现团队交付的服务响应时间超长,随即去性能平台找性能测试执行留痕的过程中发现已经很久没有做性能测试了,就这个问题和团队开发负责人、团队测试负责人进行深度讨论,发现两人对性能测试的必要性提出了质疑,理由也很简单APM都能发现问题,为什么还要做性能,APM发现慢了,就安排迭代改进就好了,没有必要再投入精力做性能测试了。

性能的闻道先后

测试其实是一种有效保障交付变更质量的保证方法,那么反过来看不保证交付质量可以吗?答案其实是可以,这样就会导致不良质量成本的出现。举一个非IT的例子,一个生产电风扇的厂商如果不做质量保证,流水线生产出来的电风扇就直接上市销售。我们假设流水线生产的电风扇的良品率是90%,一台电风扇生产成本是售价的50%。一台电风扇从生产完成到售卖到用户手中包含了包装、运输、营销等一系列的过程,这个过程总费用是一台电风扇售价的50%。那么如果这个电风扇生产厂商1个月生产10万台电风扇,每一台售价100元,那么要是没有质量保证,这一个月不良质量造成的成本就是10万台*90%*100元,结果就是900万的不良质量成本的损失。如果一切都不改变,仅仅是在流水线生产完成后加上质量保证环节,那么至少可以可以不让质量问题的产品流入市场,因此不良质量成本就减少了450万。

那么我们再回到我们软件的系统变更过程,测试在制品过程中越早的投入,就可以越早的发现质量问题从而减少不良质量成本。在功能测试活动中我相信所有人都能理解,所以缺陷逃逸率几乎是现在每一个团队都要度量的指标。为什么到性能测试就会有人本末倒置呢,当生产发现服务相应慢的时候,就是性能缺陷的逃逸,也是制品团队交付了不良质量的变更。也就是说性能测试在前,APM监控在后,不做性能测试使得一些性能缺陷逃逸,虽然APM发现了问题,但是也是事后的手段,同样对用户的使用造成了影响,这也造成了不良质量成本。


性能测试的开展时机

随着现在技术的发展,DevOps包含饿了越来越多的内容,DevSecOps、DevPerfOps等等Dev{}Ops就变成了每一个角色讲故事的通用范式了。那么无论叫什么,性能是任何产品交付过程中无法逾越的特性,也是八大软件质量特性中的一个,保证产品的性能效率质量特性的方法性能测试就是必不可少的一个环节。

在10年前每次有性能测试的需求测试小伙伴都会认为是一个大任务,需要很多天很多投入去验证,也相对应的让性能测试变成了一个很难做的任务。那个时候很多大规模公司都有专属的性能测试团队,性能测试团队在这个那个测试团队中的地位还是相对较高的,话语权非常重,尤其是在银行类系统的交付团队里。随着容器化的不断普及,被测环境和测试工具的部署可以在分钟级交付,性能测试已经降低了很大的门槛,节省了很多成本,这也是为什么很多互联网大厂能够实现的性能测试常态化的基础,那么性能测试的开展时机就是任何时机,只要有需求就可执行、可验证、可度量、可优化。

在测试领域,互联网远远领先于其他行业,那么在全部测试团队推行常态化的性能测试常态化估计还需要很长的一段路要走。既然不能马上进入高速路,性能测试的开展时机仍就是一个需要多方面考虑的问题,当然也是按需的进行,也不能随心所欲的投入。那么什么时候就应该是需要性能测试开展的时机呢?如下几点出现任意一种情况,都应该开展对应业务流程的性能测试,除非该业务并不关注性能表现:

  • 有并发业务访问模式,并且第一次在系统中交付
  • 单接口测试响应时间超过1秒钟
  • 3个月没有对系统关键业务流程或者并发业务流程做性能评估
  • 被测系统业务数据增长1个月内超过预期增长速度1倍以上
  • 其他明显会影响性能的变更或者基础数据的变化

当如上情况出现的时候,我们就应该立即按照预期的数据规模、访问规模、并发规模完成性能测试,给出优化建议。如何做性能测试https://blog.csdn.net/crisschan/article/details/114777321有详细的内容,就不再做重复说明了。


总结


《史记·鹖冠子》记载,魏文王问扁鹊:“子昆弟三人其孰最善为医?”扁鹊曰:“长兄最善,中兄次之,扁鹊最为下。”魏文王曰:“可得闻邪?”扁鹊曰: “长兄于病视神,未有形而除之,故名不出于家。中兄治病,其在毫毛,故名不出于闾。若扁鹊者,镵(chán)血脉,投毒药,副肌肤,闲而名出闻于诸侯。”

所以,APM是事后,性能测试是事前。性能测试是“治未病”,否则APM发现问题也是性能缺陷的逃逸,也会造成不良质量成本。

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
目录
相关文章
|
7月前
|
监控 测试技术 Apache
性能测试工作如何开展?
性能测试工作如何开展?
|
7月前
|
测试技术
性能测试和负载测试的区别
性能测试和负载测试的区别
|
7月前
|
监控 测试技术 数据处理
如何做性能测试?
如何做性能测试?
|
负载均衡 测试技术 应用服务中间件
性能测试常见瓶颈分析及调优方法总结
性能测试常见瓶颈分析及调优方法总结
358 0
|
5月前
|
监控 数据可视化 测试技术
性能测试:性能测试流程与方法
**性能测试流程与方法概述:** 本文介绍了性能测试的关键步骤,包括现状分析、指标获取、用户场景定义、验收标准设定、测试计划编写、压力环境准备、执行压测、监控、结果分析、报告编写及改进建议。测试方法涉及并发模式(虚拟用户)和RPS模式(吞吐量),确保系统在不同负载下的稳定性和效率。
|
5月前
|
测试技术 Apache Scala
性能测试方法与工具比较
性能测试方法与工具比较
|
SQL 运维 监控
性能测试常见瓶颈分析及调优方法
事务成功率在某些时候也可以视为请求成功率,在断言判断时以code/status等内容来作为请求是否成功的衡量依据;
性能测试常见瓶颈分析及调优方法
|
测试技术
性能测试(19)——定时器
loadrunner称为集合点,SyncTimer的目的是阻塞线程,直到阻塞了n个线程,然后立即释放它们。 同步定时器相当于一个储蓄池,累积一定的请求,当在规定的时间内达到一定的线程数量,这些线程会在同一个时间点一起并发,所以可以用来做大数据量的并发请求。 添加方式:测试计划 --> 线程组--> HTTP请求 --> (右键添加) 定时器 --> Synchronizing Timer
353 0
|
数据采集 测试技术
性能测试(2)——性能策略
压力测试是在强负载(大数据量、大量并发用户等)下的测试,查看应用系统在峰值使用情况下操作行为,从而 有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间(如24小时以上)的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。 通俗理解:压力是逐步增加的,直到系统不能接受用户请求的性能点,去发现系统在什么情况下,应用程序的性能会变得不可接受。
158 0
|
监控 Java 测试技术
深聊性能测试,从入门到放弃之:性能测试基准与阶段
深聊性能测试,从入门到放弃之:性能测试基准与阶段
230 0
深聊性能测试,从入门到放弃之:性能测试基准与阶段