JMeter技巧集錦

領測軟件測試網

　　 

　　JMeter 是一個流行的用于負載測試的開源工具， 具有許多有用的功能元件，如線程組（thread group）， 定時器（timer）， 和HTTP 取樣 (sampler) 元件。 本文是對JMeter 用戶手冊的補充，而且提供了關于使用Jmeter的一些模擬元件開發質量測試腳本的指導。

　　本文同時也討論了一項重要的內容：在指定了精確的響應時間要求后，如何來校驗測試結果，特別是在采用了置信區間分析這種嚴格的統計方式的情況下應如何操作。請注意，我假定本文的讀者們了解關于Jmeter的基礎知識，本文的例子基于Jmeter2。0。3版。

　　確定一個線程組的ramp-up period （Determine）

　　Jmeter腳本的第一個要素是線程組（Thread Group），因此首先讓我們來回顧一下。 正如圖一所示，線程組需要設置以下參數：
　　·線程數量。
　　·ramp-up period。
　　·運行測試的次數。
　　·啟動時間:立即或者預定的時間，如果是后者，線程組所包含的元素也要指定這個起止時間。

　　圖 1。 JMeter 線程組（JMeter Thread Group）

　　每個線程均獨立運行測試計劃。因此， 線程組常用來模擬并發用戶訪問。如果客戶機沒有足夠的能力來模擬較重的負載，可以使用Jmeter的分布式測試功能來通過一個Jmeter控制臺來遠程控制多個Jmeter引擎完成測試。

　　參數 ramp-up period 用于告知JMeter 要在多長時間內建立全部的線程。默認值是0。如果未指定ramp-up period ，也就是說ramp-up period 為零， JMeter 將立即建立所有線程，假設ramp-up period 設置成T 秒， 全部線程數設置成N個， JMeter 將每隔T/N秒建立一個線程。

　　線程組的大部分參數是不言自明的，只有ramp-up period有些難以理解， 因為如何設置適當的值并不容易。 首先，如果要使用大量線程的話，ramp-up period 一般不要設置成零。 因為如果設置成零，Jmeter將會在測試的開始就建立全部線程并立即發送訪問請求， 這樣一來就很容易使服務器飽和，更重要的是會隱性地增加了負載，這就意味著服務器將可能過載，不是因為平均訪問率高而是因為所有線程的第一次并發訪問而引起的不正常的初始訪問峰值，可以通過Jmeter的聚合報告監聽器看到這種現象。
這種異常不是我們需要的，因此，確定一個合理的ramp-up period 的規則就是讓初始點擊率接近平均點擊率。當然，也許需要運行一些測試來確定合理訪問量。

　　基于同樣的原因，過大的ramp-up period 也是不恰當的，因為將會降低訪問峰值的負載，換句話說，在一些線程還未啟動時，初期啟動的部分線程可能已經結束了。

　　那么，如何檢驗ramp-up period I太小了或者太大了呢？首先，推測一下平均點擊率并用總線程除點擊率來計算初始的ramp-up period。 例如，假設線程數為100， 估計的點擊率為每秒10次， 那么估計的理想ramp-up period 就是 100/10 = 10 秒。 那么，應怎樣來提出一個合理的估算點擊率呢？沒有什么好辦法，必須通過運行一次測試腳本來獲得。

　　其次， 在測試計劃（test plan）中增加一個聚合報告監聽器，如圖2所示，其中包含了所有獨立的訪問請求（一個samplers）的平均點擊率。 第一次取樣的點擊率（如http請求）與ramp-up period 和線程數量密切相關。通過調整ramp-up period 可以使首次取樣的奠基率接近平均取樣的點擊率。

點擊查看大圖

　　圖2 JMeter 聚合報告

　　第三， 查驗一下Jmeter日志(文件位置：JMeter_Home_Directory/bin) 的最后一個線程開始時第一個線程是否真正結束了，二者的時間差是否正常。

　　總之，是否能確定一個適當的ramp-up time 取決于以下兩條規則:
　　·第一個取樣器的點擊率（hit rate）是否接近其他取樣器的平均值，從而能否避免ramp-up period 過小。
　　·在最后一個線程啟動時，第一個線程是否在真正結束了，最好二者的時間要盡可能的長，以避免ramp-up period過大。

　　有時，這兩條規則的結論會互相沖突。 這就意味著無法找到同時滿足兩條規則的合適的ramp-up period。 糟糕的測試計劃通常會導致這些問題，這是因為在這樣的測試計劃里，取樣器將不能充分地采集數據，可能因為測試計劃執行時間太短并且線程會很快的運行結束。



　　用戶思考時間（User think time），定時器，和代理服務器（proxy server）

　　在負載測試中需要考慮的的一個重要要素是思考時間（think time）， 也就是在兩次成功的訪問請求之間的暫停時間。 有多種情形揮發導致延遲的發生： 用戶需要時間閱讀文字內容，或者填表， 或者查找正確的鏈接等。未認真考慮思考時間經常會導致測試結果的失真。例如，估計數值不恰當，也就是被測系統可以支持的最多用戶量（并發用戶）看起來好像要少一些等。

　　Jmeter提供了一整套的計時器（timer）來模擬思考時間（think time）， 但是仍舊存在一個問題：: 如何確定適當的思考時間呢？幸運的是， JMeter 提供了一個不錯的答案：使用 JMeter HTTP 代理服務器（Proxy Server）元件。

　　代理服務器會記錄在使用一個普通的瀏覽器（如FireFox 或 Internet Explorer）瀏覽一個web應用時的操作。 另外， JMeter 在記錄操作的同時會建立一個測試計劃（test plan）。 這個功能能提供以下便利：

　　·不必手工建立HTTP 訪問請求， 尤其是當要設置一些令人乏味的參數時（然而，非英文的參數也許不能正常工作) 。JMeter 將會錄制包括隱含字段（hidden fields）在內的所有內容。

　　·在生成的測試計劃中，Jmeter會包含瀏覽器生成的所有的 HTTP 報頭，如User-Agent (e。g。， Mozilla/4。0)， 或AcceptLanguage (e。g。， zh-tw，en-us;q=0。7，zh-cn;q=0。3)等。

　　·JMeter 會根據設置在錄制操作的同時建立一些定時器，其延遲時間是完全根據真實的操作來設置的
現在讓我們來看一下如何配置Jmeter的錄制功能。 在JMeter 的控制臺上， 在工作臺（WorkBench）元件上單擊右鍵，然后選擇”add the HTTP Proxy Server “。 注意是在WorkBench 上單擊右鍵而不是在Test Plan上， 因為現在是要為記錄操作進行配置而不是要運行測試計劃。  HTTP Proxy Server 的實現原理就是通過配置瀏覽器的代理服務器而使所有的訪問請求通過JMeter發送（，因而被Jmeter把訪問過程錄制下來）。

　　如圖3所示， HTTP代理服務器（HTTP Proxy Server）元件的一些參數必須被配置:

　　·端口(port): 代理服務器的監聽端口

　　·目標控制器（Target Controller）: 是代理用于存儲生成的數據的控制器，默認情況下，， JMeter 將會在當前的測試計劃中找一個記錄用的控制器用于存儲，此外也可以在下拉菜單中選擇任意控制起來存儲，通常默認值就可以了。

　　·分組(Grouping): 確定在測試計劃中如何來為生成的元件分組。 有多個選項， 一般可以選擇“只存儲每個組的第一個樣本”，否則，將會原樣錄制URLs，包括包含圖像和JavaScripts腳本的頁面。當然 也可以嘗試一下默認值“不對樣本分組”（"Do not group samples"），來看一下JMeter 建立的原版的測試計劃。

　　·包含模式(Patterns to Include) 和 排除模式(Patterns to Exclude) :幫助過濾一些不需要的訪問請求。

　　圖 3。 JMeter 代理服務器(Proxy Server)。

　　當你點擊開始（Start）按鈕時，代理服務器就會開始記錄所接受的HTTP 訪問請求。 當然，在開始記錄前，要首先設置好瀏覽器的代理服務器設置。在代理服務器元件中可以增加一個定時器子元件（配置元件），用于告知Jmeter來在其生成的HTTP請求中自動的增加一個定時器。Jmeter會自動把實際的延遲時間存儲為一個被命名為T的Jmeter變量，因此，如果在代理服務器元件里使用了高斯隨機定時器，就應該在其中的固定延遲偏移（Constant Delay Offset）設置項里添上${T}（用于自動引用紀錄的延遲時間），如圖4所示。這是另一個節省時間的便利特性。

點擊查看大圖

　　圖 4。 在代理服務器組建中增加一個高斯隨機定時器


　　定時器將會使相應的的取樣器被延遲。 延時的規則是，在上一個訪問請求被響應并延時了指定的時間后，下一個被定時器影響的取樣訪問請求才會被發送出去。 因此， 你必須手工刪除第一個取樣器中自動生成的定時器，因為第一個取樣器不需要定時器。

　　在啟動HTTP代理服務器以前，要在測試計劃中增加一個線程組（thread group），在線程組中增加一個錄制控制器（recording controller）用于存儲生成的結果。 否則， 生成的元件將會被直接添加到工作臺里。另外， 在錄制控制器里增加一個HTTP請求默認值元件HTTP Request Defaults 元件 (是一個配置元件) 也很重要，這樣Jmeter就不填寫使用了默認值的字段。

　　錄制完成后， 停止HTTP 代理服務器; 在錄制控制器元件上單擊右鍵將記錄的元件保存為一個文件用于以后重用，另外，不要忘了恢復瀏覽器的代理服務器設置。

　　指定響應時間需求并校驗結果

    　盡管本節內容與Jmeter不是直接相關，但是Jmeter仍舊是指定響應時間需求和校驗測試結果這兩個負載測試評價任務互相聯系的紐帶。

　　在web應用的環境里，響應時間指的是從提交訪問請求到等到HTML結果所耗費的時間。從技術的角度看，響應時間也應包括瀏覽器重繪HTML頁面的時間，但是瀏覽器一般是一塊接著一塊地顯示而不是直接顯示完整的整個頁面，讓人感覺響應時間要少一些。 另外，典型的情況是，負載測試工具不會考慮瀏覽器的重繪時間。 因此， 在實際的性能測試中，我們將考慮以上描述的情形， 如果不能確信，可以在正常的響應時間上加一個固定值，如0.5秒。

　　以下是一套眾所周知的確定相應時間的標準:
　　·用戶將不會注意到少于0.1秒的延遲
　　·少于1秒的延遲不會中斷用戶的正常思維， 但是一些延遲會被用戶注意到
　　·延遲時間少于10秒，用戶會繼續等待響應
　　·延遲時間超過10秒后，用戶將會放棄并開始其他操作

　　這些閥值很有名并且一般不會改變，因為是關乎人類的感知特性的。 所以要根據這些規則來設置響應時間需求， 也需要適當調整以適應實際應用。例如，亞馬遜公司(Amazon.com) 的主頁也遵循了以上規則，但是由于更偏重于風格上的一致，所以在響應時間上有一點損失。

　　乍一看，好像有兩種不同的方式來確定相應時間需求：
　　·平均響應時間(Average response time )
　　·絕對響應時間（Absolute response time）;即， 所有的響應時間必須低于某一閥值

　　指定平均響應時間比較簡單一些（straightforward），但是由于數據變化的干擾，這個需求往往難以實現。為什么取樣中的20%的響應時間要比平均值高3倍以上呢？請注意，JMeter 計算平均響應時間與圖形結果監視器中的標準偏差是一致的。

　　另一方面， 對絕對響應時間需求過于苛求是不實際的。 如果只有0。5%的取樣不能通過測試該怎么辦？如果再測一次，又會有很大的變化。 幸運的是， 使用置信區間（confidence interva）分析這種正規的統計方法可以顧及到取樣變化的影響。
在繼續進行前，讓我們首先回顧一些基本的統計學知識。

　　中心極限定理（The central limit theorem）
 
　　中心極限定理表明如果總體的分布有一個平均值μ和標準偏差σ，那么對于一個十分大的n(>30)，其取樣平均值的分布將接近于正態分布，其平均值μmean = μ ，標準偏差σmean = σ/√n。
注意取樣平均值的分布是正態的，而取樣自身的分布不必是正態的。也就是說如果多次運行測試腳本則測試結果的平均響應時間將會是正態的。

　　圖 5 和圖 6 分別展示了兩個正態分布。 在這里橫坐標是采樣響應時間的均值， 總體的均值被調整到坐標的原點（shifted so the population mean is at the origin）。 圖5 表明90%的時間里，采樣均值位于±Zσ的區間里（percent of the time， the sampling means are within the interval ±Zσ，），這里的Z=1.645 和 σ 是標準偏差。 圖 6 表明了99%的情況下的情形這時的Z=2.576。 在給定的概率下，如90%， 我們可以看到相應的Z呈現正態曲線，反之亦然。

　　Figure 5。 Z value for 90 percent
  

　　Figure 6。 Z value for 99 percent

　　在相關資料中所列的是可提供正態曲線計算的一些網站。在這些網站，我們可以計算隨意的相對區間內的概率(如，-1.5 < X < 1.5)或者在一個聚集的區域（cumulated area）內 ，(如， X < 1.5)。 也可以從下面的表中得到近似值。

　　表 1。 對應于給定的置信區間（confidence interval）的標準偏差范圍（Standard deviation range）

　　表 2。 對應于給定的標準偏差范圍（Standard deviation）的置信區間（confidence interval）

　　置信區間（Confidence interval）
 
　　置信區間（confidence interval）的定義是[取樣平均值- Z*σ/√n， 取樣平均值+ Z*σ/√n]。 例如， 如果置信區間（概率）是90%， 經查找可知Z 值是1。645， 于是置信區間就是 [取樣平均值- 1。645*σ/√n， 取樣平均值+ 1。645*σ/√n]， 這意味著在90%的時間里， 總體平均值（population mean）(是未知的) 會落入這個置信區間內。 也就是說， 我們的測試結果是十分接近的。 如果 σ（標準偏差） 更大一些， 置信區間也會更大，這就意味著置信區間的上限就會更可能會越過可以接受的范圍，即σ 越大，結果越不可信。

　　響應時間需求（Response-time requirements ）
    
　　現在我們把所有的信息都歸結到響應時間需求上來。首先。必須要定義性能需求，如: %95概率的置信區間的平均響應時間的上限必須小于5秒。 當然，最好有相應的需求或場景。

　　在性能測試結束后，假設進分析得出結論是平均響應時間是4.5秒，標準偏差時4.9秒，樣本數量是120個，然后就可以計算%95概率的置信區間了。 通過查表1，找到Z值是 1。95996。 于是置信區間就是 [4.5 – 1.95996*4.9/√120， 4.5 + 1.95996*4.9/√120]， 也就是 [3.62， 5.38]。 盡管看起來這個響應時間看起來很不錯，但這個結果（因為超出了需求的要求，因而）是不可接受的。 實際上， 可以檢驗的是即使是對于80%概率的可信區間，這個測試結果也是不能接受的。正如你所看到的，使用了置信區間分析后，會得到一個十分精確的方法來估算測試質量。

　　在web應用中，為了測定某一場景的響應時間，我們一般要通過測試工具來發送多個訪問請求，例如：
　　4. 登陸
　　5. 顯示表單
　　6. 提交表單

　　假設我們對請求3更感興趣。為進行置信區間分析，我們需要的僅是請求3的所有樣本的響應時間均值和標準偏差，而不是全部被統計的樣本的。

　　在Jmeter的圖表結果監聽器中計算的卻是全部請求的響應時間均值和標準偏差。 而Jmeter的聚合報告監聽器計算的是獨立的采樣器的響應時間均值，可惜沒有計算標準偏差。
總之， 僅僅指定響應時間均值是危險的， 因為不能反映出數據的變化。 即使響應時間均值是可以接受的，但是置信區間僅有75％，這個結果也不能令人信服。但是，使用置信區間分析還是會帶來更多的確定性。

　　結論

　　本文討論了以下內容:
　　·詳細講解了Jmeter 線程組在加載負載時的特別設置

　　·使用Jmeter代理服務器(Proxy Server)元件自動建立測試腳本的指導方針，其重點在于模擬用戶思考時間（user think time ）。

　　·置信區間分析（Confidence interval analysis）， 一種我們可以用來更好地滿足響應時間需求的統計分析方法

　　通過使用本文提及的技術可以改善測試腳本的質量，更廣泛地說，本文所討論的內容屬于是性能測試的一個工作流程的一部分， 是其中的一個較困難的部分。性能測試包括并不僅限于以下內容：

　　·編寫性能測試需求
　　·選擇測試情景
　　·準備測試環境
　　·編寫測試腳本
　　·執行測試
　　·回顧測試腳本和測試結果
　　·指出性能瓶頸
　　·書寫測試報告

　　此外， 性能測試結果，包括確定下來的瓶頸， 都需要反饋給開發團隊或者架構師進行優化設計。 在這個過程中，并寫測試腳本和回顧測試腳本是其中很重要的部分，要精心籌劃和管理實施。憑借測試腳本指導和一個好的性能測試流程，你將會有更多的機會來在較重負載下優化軟件性能。


　　關于作者

　　Chi-Chang Kung 是臺灣Sun 公司的java系統架構師，也是IEEE 和ACM的成員。

　　相關資源

　　·JMeter: http://jakarta.apache.org/jmeter/index.html
　　·《中心極限理論以及經典推論》（"Central Limit Theorem and Classical Inference" ）Scott M。 Lynch (2005年2月): http://www.princeton.edu/~slynch/clt_inference.pdf

　　·置信區間（Confidence intervals）: http://people.hofstra.edu/faculty/Stefan_Waner/RealWorld/finitetopic1/confint.html

　　·《java網站的性能分析》（Performance Analysis for Java Websites）， Stacy Joines et al. (Addison-Wesley， 2002年9月; ISBN: 0201844540): http://www.amazon.com/exec/obidos/ASIN/0201844540/javaworld

·《響應時間：三個重要的限制條件》("Response Times: The Three Important Limits") 引自《實用工程學》( Usability Engineering)， Jakob Nielsen (Morgan Kaufmann， 1994; ISBN 0125184069): http://www.useit.com/papers/responsetime.html

　　·一些提供了正態曲線計算功能的網站(Websites for normal curve calculation):
　　o        http://www.psychstat.smsu.edu/introbook/normal.htm
　　o        http://www.ecositebr.bio.br/curva_normal.htm
　　o        http://statistik.wu-wien.ac.at/mathstat/hatz/vo/applets/probCalc/normal_z_p.html

　　·更多關于測試的文章，請參照JavaWorld's 標題索引的Testing 部分: http://www.javaworld.com/channel_content/jw-testing-index.shtml

　　·關于JAVA開發工具，參見JavaWorld's 標題索引的Development Tools 部分: http://www.javaworld.com/channel_content/jw-tools-index.shtml

文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/