软件性能测试中有一类很重要的测试——负载测试，包括并发测试和容量测试。负载测试的重要工作在于找到系统的性能拐点。

在并发测试中我们不断地增加事物的用户并发数，观察系统所可以接受的并发数是否与设置的并发数保持一致，或者在增加并发数的时候观察系统的响应时间是否在可接受的范围之内（比如<3秒》）。当并发数少的时候，实际并发数与设置并发数是一致的，当系统并发数达到一定的数量后，实际并发数保持恒定，不会受到设置并发数的增加而增加了。或者系统的响应时间会超过设定的目标值。如图一所示，A即为我们找到的并发测试的拐点。

图一：负载测试的拐点

同样，在容量测试中，我们不断地往数据库中灌入数据，在开始数据量比较少的时候，系统的响应时间是在一定的可接受范围之内，但是当数据量达到一定的规模之后，系统响应的响应时间会远远高于设置的可接受范围之内。

如何去寻找性能负载测试中的拐点呢？我发现在许多公司采用的是逐步逼近法，即先设定一个预估值进行测试，观察系统的响应情况，然后增加一定的数量，观察系统的变化，直到系统超出我们所预估的值。

比如，在并发测试的时候，我们先预估设置并发用户为2000，然后以200的速度递增，检查系统的响应时间是否小与3秒，从而找出并发测试的系统拐点，数据如下：

当系统设置并发数为5000的时候，系统响应时间为3.14秒，超出了可接受范围，我们就不继续增加了，在5000到4800中寻找一个中间值4900进行测试，测试结果为2.94秒，仍旧在可接受的范围之内，所以我们断定拐点一定在4900到5000之间，于是我们寻找4900与5000中的中间点4950进行测试，得到2.99这个结果，由于非常接近3了，且两次测量值的间隔在50之内（4950-5900=50）。

在实际工作中，当我们对系统响应时间没有或者无法预估的时候，我们也往往采取系统通过率是否在可接受范围之内来评测。一般系统通过率可接受范围 = 通过的事务数（Pass）/全体事务数（All） = 通过的事务数（Pass）/(通过的事务数（Pass）+错误事务数（Error）+失败事务数（Fail）)*100%，是否在95%以上（含95）。

同样我们拿上一个例子。

测试找拐点也可利用这个方法，但是每次的递增值一定要尽可能的大。大家可以看见利用这种方法是可以找到系统拐点的，但是有一个很致命的问题，即速度很慢，如果预设的起始值远远小于拐点值，且每次的递增值有比较小的时候。那么我们有什么改进办法呢？

见图二。

图二：二分逼近法

在这里，我们先预估两个值m和n，其中m<n，取值公式为一个二元函数? (m,n)。

1.我们先用m来进行测试，如果测试不通过，我们可以确定，拐点值小于m，也可以说在0到m之间，所以我们1/2为a来作为最小值，重新递归二元函数? (m/2,n)即?（a,n）。

2.当m通过测试了，我们就用n值来进行测试，如果n值测试不通过，我们可以确定拐点在m与n之间，于是取（m+n）/2作为k值，重新递归二元函数? ((m+n)/2,n)即?（k,n）。

3.如果n值测试通过了，我们拐点比n大，找一个比n大的数字x，重新递归二元函数? (n,x)。

4.当最大值与最小值在500内，认为找到拐点

在这里我们用这个方法来检查系统的响应时间是否小与3秒，从而找出并发测试的系统拐点。我们取初始的m为1000，n为5000，即? (1000, 5000)

认为拐点值为4969，与第一次方法获得的值4950应该比较接近。在第一种方法中我们测试了18步，而采用这种方法仅仅用了8步。

我们在用这种方法来试一下通过“通过的事务数”小与95%来寻找系统性能拐点的方法进行，我们仍旧取初始的m为1000，n为5000，即? (1000, 5000)。

这里得到的拐点值为7148， 同样与上一个方法得到的7150也是比较接近的，但是上一次一共测试了28次，而这次测试了9次就找到拐点的。

另外对于容量测试寻找拐点也可以使用如下方法，只是容量测试的间距注意取得大一些。最后还要有一处注意的，对于并发测试，拐点是不太明晰的，所以第一次找到拐点的时候最好做二到三次的确认，而容量测试的拐点是非常明确地，在拐点上下的性能有明显的区别。

版权声明：本文出自51Testing原创，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。