負載測試如何尋找"拐點"？使用哪種方法進行測試？

軟體效能測試中有一類很重要的測試——負載測試，包括併發測試和容量測試。負載測試的重要工作在於找到系統的效能拐點。

在併發測試中我們不斷地增加事物的使用者併發數，觀察系統所可以接受的併發數是否與設定的併發數保持一致，或者在增加併發數的時候觀察系統的響應時間是否在可接受的範圍之內（比如<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）。同樣我們拿上一個例子作為參考。

在這裡系統的拐點為7150（一般設定透過的事務數在可接受的範圍內，系統的拐點值回比其他方式高）。

容量測試找拐點也可利用這個方法，但是每次的遞增值一定要儘可能的大。大家可以看見利用這種方法是可以找到系統拐點的，但是有一個很致命的問題，即速度很慢，如果預設的起始值遠遠小於拐點值，且每次的遞增值有比較小的時候。那麼我們有什麼改進辦法呢？見圖二。

圖二：二分逼近法

在這裡，我們先預估兩個值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次就找到拐點的。

另外對於容量測試尋找拐點也可以使用如下方法，只是容量測試的間距注意取得大一些。最後還要有一處注意的，對於併發測試，拐點是不太明晰的，所以第一次找到拐點的時候最好做二到三次的確認，而容量測試的拐點是非常明確地，在拐點上下的效能有明顯的區別。