背景
不知道各位大佬有没遇到上面的情况,性能这个东西到底是什么,还是以前的358原则吗?明显并不是适用于现在了。多次想踏入性能测试门槛都以失败告终,这次就以系列的方式来督促自己真正踏进性能测试的门槛。
什么是性能测试
通过一定的手段(工具、代码等在并发情况下获取系统的各项性能指标,验证被测系统在高并发下的处理能力、稳定性等是否可以满足我们对系统的预期。
什么样的系统才需要做性能测试
毕竟我也没真做过,在网上搜集了一下,总结如下:
-
用户量大,日活很高的系统
-
系统核心模块/核心接口
-
业务逻辑复杂的模块
-
新的技术选型
-
电商类项目促销和活动
-
性能容量评估及规划
-
日常性能回归
性能测试重要指标TPS
「什么是TPS?」
❝其实就是每秒服务器能处理的事务数。自然是单位时间内处理的越多越好。
❞
「那事务又是什么呢?(曾经一次面试就被问过,当时一脸懵逼)」
❝事务可以是一个业务操作,也可以是多个业务操作的集合,这取决于你想怎么定义。
❞
❝这里举一个曾经在组里说过的例子,就用吃饭来说吧。吃饭这个动作可以是一个事务。从办公室走出去,再到食堂、打饭、坐下、拿筷子、吃饭,这一连串的动作也可以认为是一个事务。每一个动作都可以当成是系统的一个接口,组合在一起就是一个大的事务。
❞
时间
性能测试中时间肯定就是金钱啊,这个时候就需要你越快越好了。这里常用的指标有响应时间、平均响应时间和top时间。在解释这些时间前,我们先看一下系统的流程是什么样的。
「响应时间」就是 网络传输的时间 + 各个环节业务处理时间
「平均响应时间」 就是整个过程中所有请求消耗时间的平均值
「top时间」分为90% 95% 99%,这些可以在聚合报告中看到。
那这三个时间就是响应时间*90%吗?并不是的。实际的意义是90%的请求耗时都低于的一个时间,一般用的最多的就是95%。
「为什么不采用平均时间,而要再弄个95%响应时间呢?」
因为平均响应时间在性能测试中并不完全可靠,如果有10个请求,最快的一个耗时100ms,最慢的一个耗时500ms,其他8个都在300ms左右,那么平均响应时间为300ms左右,你会觉得有什么大问题吗?如果只看平均响应时间,这个500ms耗时的接口你就会无法关注到,也就错失了性能测试发现的问题。
其他的一些指标
并发数:简单理解就是工具中设置的线程或者进程数量。
PV:页面访问量,即页面浏览量或点击量,用户每次刷新即被计算一次。可以统计服务一天的访问日志得到。
UV: 独立访客,也可以称之为日活,统计1天内访问某站点的用户数。可以统计服务一天的访问日志并根据用户的唯一标识去重得到。
成功率及失败率:就是整个测试过程中接口请求成功的数量/失败的数量 除以 总请求数
「吞吐量」:吞吐量是指系统在单位时间内处理请求的数量,TPS是吞吐量的常用量化指标。TPS越高,吞吐量越大。
对于并发数、TPS、响应时间的关系,我决定自绘一幅灵魂画作。
「由图可以得知」:在系统到达瓶颈前,并发数和TPS是成正比关系,吞吐量也随着TPS的增大,越来越大。
TPS = 并发数 / 响应时间(s) 「该公式在任何情况都可以计算TPS,面试可能会问」
看完这个是不是还是不明白,不明白就对了。
举个例子来说吧。假设要测试的是一个工厂,原本有10个工人,现在我们增加产线工人(也就是并发数),刚开始一段时间,每条生产线的产量都是越来越高。但是当工人达到一定数量时(瓶颈),一条产线就能挤得下那么多人,给你10000个人也只能在那排队等干货,所以产量不会再继续增大了。图上的这个曲线拐点就是我们想要寻找的结果。
TPS(工厂的每秒生产数量) = 并发数(工人数) / 响应时间(工人生产一件商品的时间)
这样看起来是不是就好理解多了。TPS和响应时间是反比的关系,工人数不变,工人生产的效率高了,时间短了,TPS就越高。
总结
其实上面这些百度都能找到,但是性能这些概念太多太杂,真的要好好过滤一下才行。下一篇水一下性能测试的流程吧。
绵薄之力【资源分享】
最后感谢每一个认真阅读我文章的人,看着粉丝一路的上涨和关注,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码,朋友们如果需要可以自行免费领取 【保证100%免费】
这些资料,对于想进阶【自动化测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!凡事要趁早,特别是技术行业,一定要提升技术功底。希望对大家有所帮助……基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等配套学习资源免费分享~