天天看點

描述性統計與性能結果分析——《LoadRunner 沒有告訴你的》

為什麼要有90%使用者響應時間?因為在評估一次測試的結果時,僅僅有平均事務響應時間是不夠的。為什麼這麼說?你可以試着想想,是否平均事務響應時間滿足了性能需求就表示系統的性能已經滿足了絕大多數使用者的要求?

假如有兩組測試結果,響應時間分别是{1,3,5,10,16}和{5,6,7,8,9},它們的平均值都是7,你認為哪次測試的結果更理想?

假如有一次測試,總共有100個請求被響應,其中最小響應時間為0.02秒,最大響應時間為110秒,平均事務響應時間為4.7秒,你會不會想到最小和最大響應時間如此大的偏差是否會導緻平均值本身并不可信?

為了解答上面的疑問,我們先來看一張表:

描述性統計與性能結果分析——《LoadRunner 沒有告訴你的》

在上面這個表中包含了幾個不同的列,其含義如下:

cmdid  測試時被請求的頁面

num     響應成功的請求數量

mean   所有成功的請求的響應時間的平均值

std dev     标準差(這個值的作用将在下一篇文章中重點介紹)

min             響應時間的最小值

50 th(60/70/80/90/95 th)        如果把響應時間從小到大順序排序,那麼50%的請求的響應時間在這個範圍之内。後面的60/70/80/90/95 th也是同樣的含義

max     響應時間的最大值

我想看完了上面的這個表和各列的解釋,不用多說大家也可以明白我的意思了。我把結論性的東西整理一下:

1.     90%使用者響應時間在loadrunner中是可以設定的,你可以改為80%或95%;

2.     對于這個表,loadrunner中是沒有直接提供的,你可以把lr中的原始資料導出到excel中,并使用excel中的percentile函數很簡單的算出不同百分比使用者請求的響應時間分布情況;

3.     從上面的表中來看,對于home page來說,平均事務響應時間(mean)隻同70%使用者響應時間相一緻。也就是說假如我們确定home page的響應時間應該在5秒内,那麼從平均事務響應時間來看是滿足的,但是實際上有10-20%的使用者請求的響應時間是大于這個值的;對于page 1也是一樣,假如我們确定對于page 1的請求應該在3秒内得到響應,雖然平均事務響應時間是滿足要求的,但是實際上有20-30%的使用者請求的響應時間是超過了我們的要求的;

4.     你可以在95 th之後繼續添加96/ 97/ 98/ 99/ 99.9/ 99.99 th,并利用excel的圖表功能畫一條曲線,來更加清晰表現出系統響應時間的分布情況。這時候你也許會發現,那個最大值的出現幾率隻不過是千分之一甚至萬分之一,而且99%的使用者請求的響應時間都是在性能需求所定義的範圍之内的;

5.     如果你想使用這種方法來評估系統的性能,一個推薦的做法是盡可能讓你的測試場景運作的時間長一些,因為當你獲得的測試資料越多,這個響應時間的分布曲線就越接近真實情況;

6.     在确定性能需求時,你可以用平均事務響應時間來衡量系統的性能,也可以用90%或95%使用者響應時間來作為度量标準,它們并不沖突。實際上,在定義某些系統的性能需求時,一定範圍内的請求失敗也是可以被接受的;

^_^

描述性統計與性能結果分析——《LoadRunner 沒有告訴你的》

在這張圖中,我們繼續使用了上一篇文章——《描述性統計與結果分析》一文中的方法,對響應時間的分布情況來進行分析。上面這張圖所使用的資料是通過對

google.com首頁進行測試得來的,在測試中分别使用10/25/50/75/100幾個不同級别的并發使用者數量。通過這張圖表,我們可以通過橫向比較和縱向比較,更清晰的了解到被測應用在不同級别的負載下的響應能力。

描述性統計與性能結果分析——《LoadRunner 沒有告訴你的》

這張圖所使用的資料與第一張圖一樣,但是我們使用了另外一個視角來對資料進行展示。表中最左側的2000/5000/10000/50000的機關是毫秒,分别表示了在整個測試過程中,響應時間在0-2000毫秒範圍内的事務數量占成功的事務總數的百分比,響應時間在2001-5000毫秒範圍内的事務數量占成功的事務總數的百分比,響應時間在5001-10000毫秒範圍内的事務數量占成功的事務總數的百分比,以及響應時間在10001-50000毫秒範圍内的事務數量占成功的事務總數的百分比。

這幾個時間範圍的确定是參考了業内比較通行的“2-5-10原則”——當然你也可以為自己的測試制定其他标準,隻要得到企業内的承認就可以。所謂的“2-5-10原則”,簡單說,就是當使用者能夠在2秒以内得到響應時,會感覺系統的響應很快;當使用者在2-5秒之間得到響應時,會感覺系統的響應速度還可以;當使用者在5-10秒以内得到響應時,會感覺系統的響應速度很慢,但是還可以接受;而當使用者在超過10秒後仍然無法得到響應時,會感覺系統糟透了,或者認為系統已經失去響應,而選擇離開這個web站點,或者發起第二次請求。

那麼從上面的圖表中可以看到,當并發使用者數量為10時,超過95%的使用者都可以在5秒内得到響應;當并發使用者數量達到25時,已經有80%的事務的響應時間處在危險的臨界值,而且有相當數量的事務的響應時間超過了使用者可以容忍的限度;随着并發使用者數量的進一步增加,超過使用者容忍限度的事務越來越多,當并發使用者數到達75時,系統幾乎已經無法為任何使用者提供響應了。

這張圖表也同樣可以用于對不同負載下事務的成功、失敗比例的比較分析。

note:上面兩個圖表中的資料,主要通過excel中提供的frequency,average,max,min和percentile幾個統計函數獲得,具體的使用方法請參考excel幫助手冊。

====================================分割線================================

最新内容請見作者的github頁:http://qaseven.github.io/

繼續閱讀