软件测试软件测试漫谈测试

捋一捋让你困惑的性能测试指标(一)

2019-02-26  本文已影响5人  dono45

做测试的朋友都觉得性能测试是比较高端的东西,工作或者平常的时间都会想着往这方面靠,或者下载个性能测试工具,录录脚本,再压测一下,成就感满满的.一切都挺好的,但是不管你是正打算做性能测试,还是已经搞了一段时间的性能测试,掌握好性能测试基本的几个指标是很有必要的,否则测试的再多,你也不知道得出的测试结果意义在哪.

因为工作需要和个人爱好,我也给公司的产品做过一些性能测试的工作,搭建测试环境,制造测试数据,编写脚本,测试过程自动化,探索不同测试工具的优劣等,可做的东西很多.走着走着,会发现其实对一些基本的测试指标并没想象中了解,严重影响测试的进度.而且有些指标,如TPS/QPS,我一直也没搞的太清楚两者的区别,网上的答案大部分都模糊不清.

性能测试指标分两类,业务指标(客户端统计)和资源指标(服务器端统计).

我们先来捋一捋常见的性能测试业务指标,看看这个问题是否同样困惑着你.

业务指标

吞吐量

单位时间内网络传输的数据量的总和,一般有TPS和QPS两种表达方式.

TPS(Transaction per second,每秒事务数),如访问一个网页,该网页由5个接口的数据组成,则可以该网页为一个事务,每秒钟能请求10个网页的数据,则TPS为10.

QPS(Query per second,每秒查询数/请求数),接TPS的例子,一个接口看做一个请求,上面例子的QPS将统计为10*5=50.

两者意思差不多,均能反映服务器处理请求的速度,根据实际的测试工具或需求进行统计使用即可.

响应时间

客户端发出请求-网络传输到服务器-服务器处理请求-网络响应返回到客户端,请求的一个流程所消耗的时间就是响应时间.一般性能测试通过内网测试,网络传输速度稳定且快速,传输的时间可忽略不急,故响应时间的快慢反映的是服务器处理请求速度的快慢.

在服务器达到性能瓶颈之前,响应时间与吞吐量呈线性变化,服务器达到瓶颈后,吞吐量不会继续增加,甚至可能出现下降,而响应时间则继续增大.

并发数

并发数有两种理解,一个是同时并发的连接数,一个是同时并发的请求数.

连接数和请求数不是一样的?当然,连接数是指客户端和服务器端建立的一个连接通道(端口对端口),一个连接可以并发多个请求.如jemter在设置并发数时,设置的就是并发连接数,同时并发的连接需保持ESTABLISHED状态.

为了更直接观察并发连接数,可在服务器端通过命令查询活跃连接数,如查询80端口:

sudo netstat -lanp | grep :80 | grep ESTABLISHED

每秒并发的请求数可以在jmeter测试结束后,通过监听器聚合报告的Throughput项找到,单位是请求数/s,计算方式是请求总数/平均响应时间.

并发数中还有个概念--线程.jmeter的Number of Threads设置项也是指并发数,threads就是线程,照我的理解,在这里线程和连接数有同样的意思,只是说法不一样.

评价服务器的性能,并发连接数其实意义不大,真正有意义的是每秒并发的请求数,这才是服务器真实处理的请求.


不知以上的描述是否让你对性能测试的指标更加了解?如果之前粗略明白,现在更困惑了,那可能是天气问题.

相对于服务器端的性能指标,业务指标更直接更快速对测试结果进行反馈,在一些场景下,甚至可以只观察业务指标即可对服务器的性能做大致的判断.至于资源指标,更多是用来定位性能问题,以便更进一步对系统进行分析.

上一篇下一篇

猜你喜欢

热点阅读