UML软件工程组织

 

 

性能测试中考虑时间Thinking Time的计算

2008-05-07 来源:网络

 

我们讲了设置考虑时间是为了保证测试环境和生产环境尽量一致,今天我们讲一下考虑时间的计算方法,以及考虑时间是如何让测试环境更符合生产环境。

我们还是引用上次那个例子:测试一个论坛系统的两个业务,A查看帖子、B回复帖子,假设每天会员查看帖子的总数(PV)是回复帖子的2倍,也就是A:B=2:1,因此我们的性能测试也要符合这一比例,如果我们测出的结果是5:1,那么测试结果就没有意义了。

这里我们要先讲一个容易混淆的概念。是不是性能测试中的考虑时间等于用户实际使用中的“考虑的时间”呢。答案是不。我们不能根据用户实际的考虑时间来设置性能测试的考虑时间,而要经过计算才能得到正确的考虑时间。

一般我们会先录制编写A、B的测试脚本,这时要把脚本中的考虑时间全部删除,因为录制时产生的考虑时间不能直接作为正式性能测试的考虑时间。脚本制作好以后我们开始进行计算,(当然也可以先计算再做脚本)。

刚才我们的要求是A:B=2:1,我们还要确定具体的数字,比如我们经过分析发现,论坛系统A业务每小时的(PV)数量大约是10k,B业务是5k,而且对用户来说,页面的响应时间最多不能超过5秒。好,这就是我们测试的一个基准。注意,这些数据在计算前就需要确定下来,我们可以从类似的系统中采集数据,也可以根据用户的数量进行估算,这些工作可以和产品经理讨论沟通,达成一致。

确定了这些数据基准以后,我们开始计算。这里先讲一个公式:

并发数 / (响应时间+考虑时间) = 总业务数 / 总时间

先看等式右边,这在上一篇曾经出现过:总业务数 / 总时间 = 系统吞吐量。

比如A业务每小时是10k,那么系统处理A的吞吐量就是:10k / 3600s = 2.78次/s。也就是说系统每秒钟会处理2.78次A业务,同理,系统会处理1.39次B业务,注意,系统是在一秒内同时完成了2.78次A业务和1.39次B业务,因此我们测试时不能把A和B分开来测。

再看一下等式的左边,并发数指的是性能测试时,同时运行某一脚本的个数。我们先来算A业务的,由于用户对响应时间要求的上限是5秒,我们就确定(响应时间+考虑时间) =5秒,这样把5秒带入公式:

并发数 = 2.78 × 5 = 13.89

因此我们需要按照A脚本14路,B脚本7路这样的压力来测试。可是,考虑时间不是还没有算出来么?

讲到这里,就需要明确一个定义了:我们要设置考虑时间,最终的目的是要保证:(响应时间+考虑时间) 是一个定值!

如果(响应时间+考虑时间)会不停的变化,那么这个等式就无法成立,这样就会出现测试结果的偏差。这里最主要的问题是,响应时间是不受我们控制的,响应时间如果变小,那么测出的吞吐量就会变大,从而影响到其他的业务。

那我们怎么做才能保证(响应+考虑)是一个定值呢?最完美的方法是在测试脚本中设置,首先在脚本开始的时候定义一个计时器,等脚本执行完后,统计一下经过的时间,如果不到5秒,就sleep一直到5秒,然后再结束当前脚本。如果超过5秒,就说明系统已经不合格了。

最简单的方法,是人为的指定一个考虑时间,来让(响应+考虑)=5秒。这样的测试结果就没那么精确了,而且可能需要执行很多次脚本,才能实现这个要求。比如我们先设考虑时间为2秒,执行发现响应时间是1秒,加起来是3秒,于是我们调整考虑时间为4秒。随着考虑时间的调整,响应时间也会跟着变,呵呵,需要耐心。

到此为止,对于考虑时间的说明已经讲完了。只要我们能保证(响应+考虑)是一个定值,就能有效的控制各个业务的测试比例,从而使我们的测试环境更符合要求。最后要说一下,这种算法是针对于评估系统的吞吐量,并不适用于压力测试或者是强度测试。

 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号