测试工具对结果影响及解决对策
我经常遇到一些开发团队，他们收到诸如“客户端将每小时处理20个客户”此类的性能需求。团队就试图把该需求转化为某种测试。执行这种测试的常见方法就是以死循环的形式对服务器进行反复请求，然后静观其效。通常事情进行得不是很顺利，这就是为什么随后我会作为一个性能专业化方面的顾问“遇见他们”的原因。通常我问的第一个问题是：“您是如何进行测试的？”一般来说，答案会是：“我们将请求置于循环中，然后计算服务器可以处理的请求的数目。”正是这种回答使我明白首先要做的就是调整测试工具本身。
然而,我们首先要明白的是，虽然测试通常都是从客户端活动的角度定义的，但是它们必须从以服务器为中心的视角来看待。以服务器为视角将只看到客户端访问的频率和处理每个请求所花费的时间。让我们考虑一个典型例子，即银行的出纳员。出纳员通常不知道您是什么时候到的，也不知道您是从哪里来的。他们所知道的只是您在这里，而且您要让他们为您做一些事情。现在，队列中有多少人将取决于人们到达的速度，以及满足他们的要求所花的时间。
比队列中有多少人更重要的是，随着后来的人不断补进队列，房间中的人数是在减少、保持不变还是在增加？与之相随的另一个问题是，人们进入队列的速度与离开的速度相比，是快一些、相同还是慢一些？如果离开的速度要比到达的速度快，那么处理请求的速度要比递交请求的速度快。第二种情况说明刚刚处理完一个客户，下一个就到达了。最后一种情况则说明人们到达的速度要比处理的速度快。用数学术语来说，第一种系统是收敛的，第二种处于稳定状态，第三种则是发散的。这三种情况中房间中的人数都是由利托氏定理(Little's Law)决定的。
对于每种情况，利托氏定理都描述了系统是如何处理工作负载的。虽然状态可能会发生瞬时的迸发和间歇，总体的趋势还将由平均的状况决定。例如，在收敛系统中，可能会由于许多人同时进入队列而产生瞬时的暴涨，但是队列仍将会腾空，因为收敛系统的倾向就是趋向空闲。但是，第三种场景是发散的，其中的请求数将会无限增长。它会吗？这个问题的答案与如何定义发出请求的全域有关。
在某个随机的时间点，全域中的用户将发出一个请求。这肯定是从以服务器为中心的视角来看全域了。大多数系统都基于一个假设，即在任一个给定的时间点，全域中只有一部分会发出请求。经验告诉我们，在许多因特网应用程序中，全域中有10％在任意时间点都是活动的。我们需要知道这种信息，如果我们要定义实际的压力测试的话。例如，如果全域中有1000个用户，我们会预料有100个每时每刻都在使用系统。由于我们估计会有10％的并发使用，用户库又有1000个用户，所有我们的测试应该模拟100个用户重复执行一些请求系列。用这种方法定义测试的危害是它反映的是客户端的视角。
当我们从以服务器为中心的视角转向以客户端为中心的视角后，就看不到向服务器发送请求的速度了。如果我们限制或固定为执行用户请求所分配的用户（线程）数目，那么就看得更模糊了。在这种情况下进行测试，我们将看到服务器正在处理稳定的请求流，而处理请求的时间似乎越来越长。
正如前面所提到的，在发散系统中，每个后继用户的响应时间都要比前一个所经历的时间长。这意味着平均响应时间将不断地增长而没有限制。尽管如此，但是我们人为地限制了客户端的数目，因此平均响应时间将稳定在一个点上，该点取决于客户端数目与处理单个请求所花费时间的乘积。这里所说的这种系统中的响应时间包括花在队列中的时间，而且因为花在队列中的时间比预料的要少，所以我们又人为扩大了测量值。最终结果是您的测试限制了您确定系统的可伸缩性的能力。
要解决这个问题，需要知道用户/线程发出请求的速度。所有用户的速度之和就转化为服务器接受请求的速度。一旦确定了这个值，就可以对工具发出请求的速度进行调整。
文章来源于领测软件测试网 https://www.ltesting.net/