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

LoadRunner中的90％響應時間是什麼意思？這個值在進行效能分析時有什麼作用？本文爭取用最簡潔的文字來解答這個問題，並引申出“描述性統計”方法在效能測試結果分析中的應用。

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

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

假如有一次測試，總共有100

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

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

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％；

（

LoadRunner Analysis-〉Tools-〉Options-〉General-〉Summary Report下修改Transaction Percentile

）

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，你都可以用這些方法和思路來評估你的系統的效能。

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

描述性統計與效能結果分析（續） ——《LoadRunner 沒有告訴你的》之二

資料統計分析的思路與分析結果的展示方式是同樣重要的，有了好的分析思路，但是卻不懂得如何更好的展示分析結果和資料來印證自己的分析，就像一個人滿腹經綸卻不知該如何一展雄才

一圖勝千言，所以這次我會用兩張圖表來說明“描述性統計”在效能測試結果分析中的其他應用。

在這張圖中，我們繼續使用了上一篇文章——《描述性統計與結果分析》一文中的方法，對響應時間的分佈情況來進行分析。上面這張圖所使用的資料是通過對Google.com 首頁進行測試得來的，在測試中分別使用10/25/50/75/100 幾個不同級別的併發使用者數量。通過這張圖表，我們可以通過橫向比較和縱向比較，更清晰的瞭解到被測應用在不同級別的負載下的響應能力。

這張圖所使用的資料與第一張圖一樣，但是我們使用了另外一個視角來對資料進行展示。表中最左側的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幫助手冊。