考虑时间（Thinking Time）的计算方法

在上一篇《为什么要在性能测试中设置考虑时间》中，我们讲了设置考虑时间是为了保证测试环境和生产环境尽量一致，今天我们讲一下考虑时间的计算方法，以及考虑时间是如何让测试环境更符合生产环境。   我们还是引用上次那个例子：测试一个论坛系统的两个业务，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秒。随着考虑时间的调整，响应时间也会跟着变，呵呵，需要耐心。   到此为止，对于考虑时间的说明已经讲完了。只要我们能保证（响应+考虑）是一个定值，就能有效的控制各个业务的测试比例，从而使我们的测试环境更符合要求。最后要说一下，这种算法是针对于评估系统的吞吐量，并不适用于压力测试或者是强度测试。

原文转自：http://www.ltesting.net