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

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

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

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

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

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

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％用戶響應時間來作為度量標準，它們并不沖突。實際上，在定義某些系統的性能需求時，一定范圍內的請求失敗也是可以被接受的；

7.      上面提到的這些內容其實是與工具無關的，只要你可以得到原始的響應時間記錄，無論是使用LoadRunner還是JMeter或者OpenSTA，你都可以用這些方法和思路來評估你的系統的性能。

事實上，在性能測試領域中還有更多的東西是目前的商業測試工具或者開源測試工具都沒有專門講述的——換句話說，性能測試僅僅有工具是不夠的。我們還需要更多其他領域的知識，例如數學和統計學，來幫助我們更好的分析性能數據，找到隱藏在那些數據之下的真相

原文轉自：http://www.anti-gravitydesign.com