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) :幫助過濾一些不需要的訪問請求。