为什么要在性能测试中设置考虑时间(Thinking Time)(转自taobao SQA)

考虑时间Thinking Time指的是在性能测试脚本中，事务与事务之间，会有一些短暂的停顿，就好像真实用户在操作时，两次操作之间需要考虑一下。比如用户注册的时候，在打开注册页面到提交注册页面之间，是有一段考虑时间的（用户在填写个人信息）。

下面就讨论一下在性能测试实战中，为什么要设置考虑时间。

先说一个概念：吞吐量，这指的是服务器系统（包括软件和硬件）单位时间内处理业务的数量。我们现在做一个小试验，写一个小程序，执行一个简单的业务，并且在程序中进行计时，计算每分钟能执行多少次。然后当我们运行1路这个程序的时候，每分钟能完成约6万次。好，现在问一个问题，如果我们起2路，是不是每一路都能达到 6万/分钟 的吞吐量？

试验发现，当运行2路的时候，两个程序的数值都降了下来，但是它们的总和仍然是6万次。而且不管我们起多少路，这些程序的性能总和都接近于6万。

这就好像一个人1分钟最快能吃1个馒头，你让他一个一个吃，他两分钟能吃2个，如果你让他一手拿一个，同时吃，他两分钟吃不了4个，还是只能吃两个。

我们不是在说“考虑时间”么，哈哈，别急，因为上面的问题必须要先说清楚。

如果我们需要进行性能测试的业务是一个单纯的业务，就好像上面举的那个例子一样，那么测试脚本中就不需要设置“考虑时间”，因为不管你用什么方法测试，一个服务系统处理单一业务的吞吐量总是一个定值。

但是在实际环境里面，往往一个系统都是要处理多种业务，并且这些业务之间是有逻辑关系的。举例说明，比如一个论坛系统，每天最常处理的业务有两个：A打开帖子、B回复帖子。那么每天系统处理AB业务的总数是不是一样的呢，答案很明显，看帖子多，回复的少一些。假设A:B=2:1。

好，如果我们不设置考虑时间，起2路A的脚本，1路B的脚本进行性能测试，我们会得到什么结果呢？我们会得到这两个业务的吞吐量，并且能算出每个小时系统完成A、B业务的总数，吞吐量 × 时间 ＝ 总数。

这时我们发现，同样时间，AB业务的处理总数却不是2:1的关系，这是为什么呢？原因是这样的，我们在跑AB脚本的时候，这两组脚本都在尽全力争夺服务器的资源，他们的并发路数虽然是2:1，但是给服务器的压力却不一定是2:1，可能会出现偏差，测试结果就是最好的证据。A查看帖子由于响应时间短，因此跑的次数更多，最后的比例可能是4:1。

那么这样的结果有什么问题呢。总结为一句话：测试环境的业务和真实环境不符，这样测出的数据没有价值。即使测试通过，也不能证明真实环境是ok的；或者即使测试不通过，也不能说明真实环境不ok，呵呵。

比如上面的例子，如果我们测出的结果是B回复帖子的吞吐量不够，响应时间太长，那可能是因为A业务抢走了过多的，本不属于A的资源，而引起了B的性能降低。

说到这里，大家应该明白了，我们设置考虑时间，是为了保证测试复合业务的时候，各个业务之间的比例关系符合我们的真实生产环境。

在上一篇《为什么要在性能测试中设置考虑时间》中，我们讲了设置考虑时间是为了保证测试环境和生产环境尽量一致，今天我们讲一下考虑时间的计算方法，以及考虑时间是如何让测试环境更符合生产环境。

我们还是引用上次那个例子：测试一个论坛系统的两个业务，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秒。随着考虑时间的调整，响应时间也会跟着变，呵呵，需要耐心。

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