JMeter 問題

1.  JMeter 測試計劃

測試計劃

使用 JMeter 進行測試的起點，是其它 JMeter 測試元件的容器。

線程組

表明必定數量的併發用戶，它能夠用來模擬併發用戶發送請求。實際的請求內容在Sampler中定義，它被線程組包含。能夠在「測試計劃->添加->線程組」來創建它，而後在線程組面板裏有幾個輸入欄：線程數、Ramp-Up Period(in seconds)、循環次數，其中Ramp-Up Period(in seconds)表示在這時間內建立完全部的線程。若有8個線程，Ramp-Up = 200秒，那麼線程的啓動時間間隔爲200/8=25秒，這樣的好處是：一開始不會對服務器有太大的負載。線程組是爲模擬併發負載而設計。

取樣器（Sampler）

模擬各類請求。全部實際的測試任務都由取樣器承擔，存在不少種請求。如：HTTP 、ftp請求等等。
監聽器

負責收集測試結果，同時也被告知告終果顯示的方式。功能是對取樣器的請求結果顯示、統計一些數據（吞吐量、KB/S……）等。
斷言

用於來判斷請求響應的結果是否如用戶所指望，是否正確。它能夠用來隔離問題域，即在確保功能正確的前提下執行壓力測試。這個限制對於有效的測試是很是有用的。

定時器

負責定義請求（線程）之間的延遲間隔，模擬對服務器的連續請求。

邏輯控制器

容許自定義JMeter發送請求的行爲邏輯，它與Sampler結合使用能夠模擬複雜的請求序列。
配置元件

維護Sampler須要的配置信息，並根據實際的須要會修改請求的內容。
前置處理器和後置處理器

負責在生成請求以前和以後完成工做。前置處理器經常用來修改請求的設置，後置處理器則經常用來處理響應的數據。

 

2.  聚合報告

聚合報告（Aggregate Report） 是 JMeter 經常使用的一個 監聽器。對聚合報告各項數據欄的理解以下：

Label

每一個 JMeter 的 element（例如 HTTP Request）都有一個 Name 屬性，這裏顯示的就是 Name 屬性的值
#Samples

表示你此次測試中一共發出了多少個請求，若是模擬10個用戶，每一個用戶迭代10次，那麼這裏顯示100
Average

平均響應時間——默認狀況下是單個 Request 的平均響應時間，當使用了 Transaction Controller 時，也能夠以Transaction 爲單位顯示平均響應時間
Median

中位數，也就是 50％ 用戶的響應時間
90% Line

90％ 用戶的響應時間

----------------------------------------------------------另外一種說法

90% Line - 90% of the samples took no more than this time. The remaining samples at least as long as this.

 

「 90% 的樣品沒有超過這個時間，剩餘的樣品至少只要這個。」（拿google翻譯的）

沒太理解是什麼意思，因而，點擊詳細解釋。

90% Line (90 th Percentile) is the value below which 90% of the samples fall. The remaining samples too at least as long as the value. This is a standard statistical measure. See, for example: Percentile entry at Wikipedia. 

英語太差，仍是沒理解到底啥意思，不過最後提示我，用維基百科查一下什麼是百分位數。

 

百分位數：統計學術語，若是將一組數據從大到小排序，並計算相應的累計百分位，則某一百分位所對應數據的值就稱爲這一百分位的百分位數。可表示爲：一組n個觀測值按數值大小排列如，處於p%位置的值稱第p百分位數。

 

假如：

有10個數：

一、二、三、四、五、六、七、八、九、10    按由大到小將其排列。

求它的第90%百分位，也就是第9個數恰好是9 ，那麼他的90%Line 就是9 。

另外一組數:

二、2.一、2.五、三、3.四、3.四、四、四、四、四、五、五、五、5.九、5.9一、6.八、八、十二、2四、24.1   按由大到小將其排列。

求它的第90%百分位，第18個數是12 麼，他的90%Line 就是12。 

 

再來解釋90%Line 

一組數由小到大進行排列，找到他的第90%個數（假如是12），那麼這個數組中有90%的數將小於等於12 。

用在性能測試的響應時間也將很是有意義，也就是90%請求響應時間不會超過12 秒。

原創地址:http://www.cnblogs.com/fnng/archive/2013/02/26/2934317.html

----------------------------------------------------------另外一種說法-----end

Note

關於 50％ 和 90％ 併發用戶數的含義，請參考下文
http://www.cnblogs.com/jackei/archive/2006/11/11/557972.html
Min

最小響應時間
Max

最大響應時間
Error%

本次測試中出現錯誤的請求的數量/請求的總數
Throughput（吞吐量）

默認狀況下表示每秒完成的請求數（Request per Second），當使用了 Transaction Controller 時，也能夠表示相似 LoadRunner 的 Transaction per Second 數

KB/Sec

每秒從服務器端接收到的數據量，至關於LoadRunner中的Throughput/Sec

 

3.  圖形結果分析參數解析

樣本數目

總共發送到服務器的請求數。

最新樣本

表明時間的數字,是服務器響應最後一個請求的時間。

吞吐量

服務器每分鐘處理的請求數。

平均值

總運行時間除以發送到服務器的請求數。

中間值

表明時間的數字，有一半的服務器響應時間低於該值而另外一半高於該值。

偏離

服務器響應時間變化、離散程度測量值的大小，或者，換句話說，就是數據的分佈。

 

4.  Http請求的配置參數

名稱

本屬性用於標識一個取樣器，建議使用一個有意義的名稱。

註釋

對於測試沒有任何做用，僅用戶記錄用戶可讀的註釋信息。

服務器名稱或IP 

HTTP請求發送的目標服務器名稱或IP地址。

端口號

目標服務器的端口號，默認值爲80 。

協議

向目標服務器發送HTTP請求時的協議，能夠是http或者是https ，默認值爲http 。

方法

發送HTTP請求的方法，可用方法包括GET、POST、HEAD、PUT、OPTIONS、TRACE、DELETE等。

Content encoding 

內容的編碼方式，默認值爲iso8859

路徑

目標URL路徑（不包括服務器地址和端口）

自動重定向

若是選中該選項，當發送HTTP請求後獲得的響應是302/301時，JMeter 自動重定向到新的頁面。

Use keep Alive 

當該選項被選中時，jmeter 和目標服務器之間使用 Keep-Alive方式進行HTTP通訊，默認選中。

Use multipart/from-data for HTTP POST 

當發送HTTP POST 請求時，使用Use multipart/from-data方法發送，默認不選中。

同請求一塊兒發送參數 

在請求中發送URL參數，對於帶參數的URL ，jmeter提供了一個簡單的對參數化的方法。用戶能夠將URL中全部參數設置在本表中，表中的每一行是一個參數值對（對應RUL中的 名稱1=值1）。

同請求一塊兒發送文件

在請求中發送文件，一般，HTTP文件上傳行爲能夠經過這種方式模擬。

從HTML文件獲取全部有內含的資源

當該選項被選中時，jmeter在發出HTTP請求並得到響應的HTML文件內容後，還對該HTML進行Parse 並獲取HTML中包含的全部資源（圖片、flash等），默認不選中，若是用戶只但願獲取頁面中的特定資源，能夠在下方的Embedded URLs must match 文本框中填入須要下載的特定資源表達式，這樣，只有能匹配指定正則表達式的URL指向資源會被下載。

用做監視器

此取樣器被當成監視器，在Monitor Results Listener 中能夠直接看到基於該取樣器的圖形化統計信息。默認爲不選中。

Save response as MD5 hash 

選中該項，在執行時僅記錄服務端響應數據的MD5值，而不記錄完整的響應數據。在須要進行數據量很是大的測試時，建議選中該項以減小取樣器記錄響應數據的開銷。

 

5.  Constant Throughput Timer 的主要屬性

名稱 

定時器的名稱

Target throughput（in samples per minute）

目標吞吐量。注意這裏是每分鐘發送的請求數。

Calculate Throughput based on 

有5個選項，分別是：

　　This thread only ：控制每一個線程的吞吐量，選擇這種模式時，總的吞吐量爲設置的 target Throughput 乘以線程的數量。

　　All active threads ： 設置的target Throughput 將分配在每一個活躍線程上，每一個活躍線程在上一次運行結束後等待合理的時間後再次運行。活躍線程指同一時刻同時運行的線程。

　　All active threads in current thread group ：設置的target Throughput將分配在當前線程組的每個活躍線程上，當測試計劃中只有一個線程組時，該選項和All active threads選項的效果徹底相同。

　　All active threads （shared ）：與All active threads 的選項基本相同，惟一的區別是，每一個活躍線程都會在全部活躍線程上一次運行結束後等待合理的時間後再次運行。

　　All active threads in current thread group （shared ）：與All active threads in current thread group 基本相同，惟一的區別是，每一個活躍線程都會在全部活躍線程的上一次運行結束後等待合理的時間後再次運行。

 

6.  JMeter常見問題

1. JMeter的工做原理是什麼？

向服務器提交請求；從服務器取回請求返回的結果。

2. JMeter的做用？

JMeter能夠用於測試靜態或者動態資源的性能（文件、Servlets、Perl腳本、java對象、數據庫和查詢、ftp服務器或者其餘的資源）。JMeter用於模擬在服務器、網絡或者其餘對象上附加高負載以測試他們提供服務的受壓能力，或者分析他們提供的服務在不一樣負載條件下的總性能狀況。你能夠用JMeter提供的圖形化界面分析性能指標或者在高負載狀況下測試服務器/腳本/對象的行爲。

 

3. 怎樣能看到jmeter提供的腳本範例？

在\JMeter\jakarta-jmeter-2.0.3\xdocs\demos目錄下。

4. 怎樣設置併發用戶數？

選中可視化界面中左邊樹的Test Plan節點，單擊右鍵，選擇Add-> Thread Group,其中Number of Threads參數用來設置發送請求的用戶數目。

5. JMeter的運行指示？

Jmeter在運行時，右上角有個單選框大小的小框框，運行是該框框爲綠色，運行完畢後，該框框爲白色。

6. User Parameters的做用是什麼？

提升腳本可用性

7. 在result裏會出現彩色字體的http response code，說明什麼呢？

 Http response code是http返回值，彩色字體較引人注目，可使用戶迅速關注。象綠色的302就說明在這一步驟中，返回值取自本機的catch，而不是server。

8. 怎樣計算Ramp-up period時間？

Ramp-up period是指每一個請求發生的總時間間隔，單位是秒。若是Number of Threads設置爲5，而Ramp-up period是10，那麼每一個請求之間的間隔就是10／5，也就是2秒。Ramp-up period設置爲0，就是同時併發請求。

9. Get和Post的區別？

他們是http協議的2種不一樣實現方式。Get是指server從Request URL取得所需參數。從result中的request中能夠看到，get能夠看到參數，可是post是主動向server發送參數，因此通常看不到這些參數的。

10. 哪些緣由可能致使error的產生？

a. Http錯誤，包括不響應，結果找不到，數據錯誤等等；

b. JMeter自己緣由產生的錯誤。

11. 爲何Aggregate Report結果中的Total值不是真正的總和？

JMeter給結果中total的定義是並不徹底指總和，爲了方便使用，它的值表現了所在列的表明值，好比min值，它的total就是所在列的最小值。下圖就是total在各列所表示的意思。

12. JMeter的Thread Number是提供多個不一樣用戶併發的功能麼？

不是，Thread Number僅僅是指併發數，若是須要實現多個不一樣用戶併發，咱們應該採用其它方法，好比經過在jmeter外創建csv文件的方法來實現。

13. 同時併發請求時，若須要模擬不一樣的用戶同時向不一樣的server併發請求，怎樣實現呢？

方法很靈活，咱們能夠將不一樣的server在thread裏面預先寫好。或者預先將固定的變量值寫入csv文件，這樣還能夠方便修改。而後將文件添加到User Parameters。

14. User Parameter中的DUMMY是什麼意思？

當其具體內容是${__CSVRead(${__property(user.dir)}${FILENAME},next())}時用來模擬讀文件的下一行。

15. 當測試對象在多server間跳轉時，應該怎樣處理？

程序運行時，有些http和隱函數會攜帶另外的server IP,咱們能夠從他們的返回值中獲取。

16. 爲什麼測試對象是http和https混雜出現？

Https是加密協議，爲了安全，通常不推薦使用http，可是有些地方，使用https過於複雜或者較難實現，會採用http協議。

17. Http和https的默認端口是什麼？

Apache server (Http)的默認端口是80；

SSL (Https)的默認端口是443。

18. 爲什麼在run時，有些頁面失敗，可是最後不影響結果？

緣由較多，值得說起的一種是由於主流頁面與它不存在依賴關係，因此即便這樣的頁面出錯，也不會影響運行獲得正常結果，可是這樣會影響到測試的結果以及分析結果。

19. 爲何腳本剛開始運行就有錯誤，其後來的腳本還可運行？

在Thread Group中有相關設置，若是選擇了continue，即便前面的腳本出現錯誤，整個thread仍會運行直到結束。選擇Stop Thread會結束當前thread；選擇Stop Test則會結束所有的thread。推薦選項是Stop Thread。

20. 在Regular expression_r Extractor會看到Template的值是$1$,這個值是什麼意思呢？

$1$是指取第一個（）裏面的值。若是Regular expression_r的數值有多個，用這種方法能夠避免沒必要要的麻煩。

21. Regular expression_r中的(.*)是什麼意思？

那是一個正則表達式（regular expression_r）。’.’等同於sql語言中的’?’,表示無關緊要。’*’表示0個或多個。’()’表示須要取值。(.*)表達任意長度的字符串。

22. 在讀取Regular expression_r時要注意什麼？

必定要保證所取數值的絕對惟一性。

23. 怎樣才能判斷什麼樣的狀況須要添加Regular expression_r Extractor？\

檢查Http Request中的Send Parameters,若是有某個參數是其前一個page中所沒有給出的，就要到原文件中查找，並添加Regular expression_r Extractor到其前一page的http request中。

24. 在自動獲取的腳本中有時會出現空的http request，是什麼意思呢？

是由於在獲取腳本時有些錯誤，是腳本工具緣由。在run時這種錯誤不參與運行的。

25. 在運行結果中爲什麼有rate爲N/A的狀況出現？

可能由於JMeter自身問題形成，再次運行能夠獲得正確結果。

26. 經常使用http錯誤代碼有哪些？

400    沒法解析此請求。

403    禁止訪問：訪問被拒絕。

404    找不到文件或目錄。

405    用於訪問該頁的HTTP動做未被許可。

410    文件已刪除。

500    服務器內部錯誤。

501    標題值指定的配置沒有執行。

502    Web服務器做爲網關或代理服務器時收到無效的響應。

27. Http request中的Send Parameters是指什麼？

是指code中寫定的值和自定義變量中獲得的值，就是在運行頁面時須要的參數。

28. Parameters在頁面中是不斷傳遞的麼？

是的。參數再產生後會在頁面中一直傳遞到所需頁面。因此咱們能夠在動態參數產生時捕獲它，也能夠在所需頁面的上一頁面捕獲。(可是這樣可能有錯誤，最好在產生頁面獲取)

29. 在使用JMeter測試時，是徹底模擬用戶操做麼？形成的結果也和用戶操做徹底相同麼？

是的。JMeter徹底模擬用戶操做，因此操做記錄會所有寫入DB.在運行失敗時，可能會產生錯誤數據，這就取決於腳本檢查是否嚴謹，不然錯誤數據也會進入DB，給程序運行帶來不少麻煩。

 

30. 製做測試腳本

手工製做測試腳本，須要你知道請求的url和攜帶的參數等等，太花費時間，因此能夠用badboy工具錄製腳本。這個工具雖然不是開源的，可是卻能夠用來免費的錄製成.jmx的腳本，使用起來很方便。官方網站是：http://www.badboy.com.au/

31. 出現亂碼了？

在用JMeter發行HTTPRequest時，在請求參數中有中文時，發現存儲到DB中後，相應的字段是亂碼，明明在參數後面的Encode選項中打了V。後來發現badboy錄製腳本的時候並無記錄編碼方式，因此修改腳本，在Content encoding中設置正確的編碼方式就不會出現亂碼了。

32. JMeter的妙用---準備測試數據

要求性能測試開始前，先準備5W條數據。固然能夠經過直接修改DB，可是若是這5W條數據涉及到不少表的關聯，甚至還要經過存儲過程的處理怎麼辦，直接修改DB很容易出現錯誤的數據，要是在客戶的機器上弄錯，可就闖禍了。這時候想到了JMeter，它原本是用來模擬大量用戶併發請求的，如今用它來批量的生成數據吧。若是要求每條數據都不一樣，就要修改腳本，使用JMeter的函數來動態產生數據，比較經常使用的是CSVRead函數，記不住名的話Ctrl+F能夠呼喚出函數助手。使用這個函數的時候須要注意幾點，首先是csv文件的編碼格式，使用ansi沒有問題，使用unicode時會使讀取的第一行數據出現錯誤；${__CSVRead(data.txt,0)}---讀取本行的第一列值                                    ${__CSVRead(data.txt,1)}${__CSVRead(data.txt,next)}---讀取本行的第二列值，並把行標移動到下一行試驗證實JMeter應該作好了同步，在多線程環境下上面的調用方法沒有問題；最後，修改JMeter的線程數會加快數據生成的速度，原理是當併發線程在20左右的時候會達到最大的吞吐量（request/分），
因此應該設定線程數20左右。

33. JMeter中debug方法

JMeter提供了log函數輸出log，可是有時候並很差用，好比我想輸出某個函數的返回值看是否是正確的，${__log(${__CSVRead(data.txt,1)})}這樣的寫法是錯誤的，JMeter會拋出異常，該怎麼辦呢？答案是巧用監聽器（Listener）來輸出想看到的數據，結果顯示爲樹的那個監聽器，它可讓你查看每一個sampler的請求數據和響應數據，在請求數據中就有你想看到的信息。

34. 經常使用的功能

使用HTTP Cookie Manager或URL重寫實現同一線程內的多個請求共享Session。

把Login的請求放到只執行一次的控制器中，那麼即便循環屢次，Login也只請求一次。若是想讓多個線程在同一時刻同時請求，那麼用Synchronizing Timer來作集合點。爲了節省系統資源，使用非窗口模式運行JMeter（jmeter -n -t test.jmx）若是模擬併發用戶過多，好比200線程，那麼能夠分散到多臺機器上運行Jmeter（好比4臺電腦，每臺50線程）
更多功能請參照使用手冊。

中文手冊（未完成）http://wiki.javascud.org/pages/viewpage.action?pageId=5566

35. 在winnt系統上，使用perfmon來幫助Jmeter採集服務器的系統資源數據，能夠配置log輸出這些數據做爲性能瓶頸分析時使用。

36. 置信區間

對數據進行更科學的分析，肯定測試結果。相似於Jmeter聚合報告的90% Line給出的參考，而不能僅僅參考均值。

 

7.　　工做中對「營銷活動管理系統」作的一次壓力測試結果分析

*****************************************************************************************************************************
前言
*****************************************************************************************************************************
一、測試過程當中頁面響應時間與測試結果不一致。具體來講就是，操做過程當中頁面響應時間過長，而測試結果卻顯示很短；

二、偏離值隨着測試樣本的增長而減少（併發較小，測試模塊單一的狀況下）；

三、測試樣本數分別爲：五、十、1五、20、50、100、150、200；

四、測試結果着重看Average和吞吐量（是否達到峯值應該具體參考服務器和系統的功能與非功能需求等酌情考慮）；

五、ITSP門戶測試時，Average要求在1.5s如下；

六、測試過程當中常常出現運行腳本錯誤的狀況，通常在測試結果裏不會看到；

*****************************************************************************************************************************
名詞解釋
*****************************************************************************************************************************
一、吞吐量：能夠理解爲服務器每分鐘處理的請求數量；吞吐率表明着單位時間內所能承受的壓力，是測試中一個重要的指標。

經過比較吞吐量，能夠發現系統的運行狀態。當隨着併發數增長時，吞吐率是不斷增長的，當達到一個服務器極限後，再增長併發數，

吞吐率會急速降低，直至服務器崩潰。因此當達到臨界點（吞吐量最高點，負載和處理均衡時）爲最大吞吐率，是系統在運行下的一

個理想閾值範圍。

二、Average：平均響應時間。默認狀況下是單個 Request 的平均響應時間；

三、#Samples：表示本次測試中一共發出了多少個請求，若是模擬10個用戶，每一個用戶迭代10次，那麼這裏顯示100；

四、Average：平均響應時間——默認狀況下是單個 Request 的平均響應時間；

五、Median：中位數，也就是 50％ 用戶的響應時間；

六、90% Line：90％ 用戶的響應時間

七、Min：最小響應時間；

八、Max：最大響應時間；

九、Error%：本次測試中出現錯誤的請求的數量/請求的總數；

十一、KB/Sec：每秒從服務器端接收到的數據量；

十二、偏離： 服務器響應時間變化、離散程度測量值的大小，或者，換句話說，就是數據的分佈。

********************************************************************************************************************************
部分計算公式
********************************************************************************************************************************
一、 吞吐量=完成的請求數/完成這些請求數所須要的時間；

二、 平均響應時間=全部響應時間的總和/完成的請求數；

三、 失敗率=失敗的個數/總數數；

四、 時間的計算方法是：經過timeStamp時間戳（發出的起始時間）相減而得

********************************************************************************************************************************
測試過程當中的異常狀況
********************************************************************************************************************************

****登陸測試****

一、頁面出現Error（Scripting Error: 語法錯誤 : line 1 char 1），測試結果出現Error，錯誤率33.33%；
二、200個併發時，Average達到1000ms左右；

****註銷測試****

一、Average在15個併發時急速提高至140ms左右，而5和10個併發時都是8ms左右；
二、200個併發時，Average達到132ms；

****修改密碼測試****
一、200個併發時，Average達到7ms；

****訂單轉化率測試****
一、70個併發時，Average達到1000ms左右；
二、100個併發時，Average達到1800ms左右；
三、150個併發時，Average達到3300ms左右，偏離值（1246）超過樣本數（1200）；
四、200個併發時，Average達到5000ms左右；

****公共標籤牆測試****
一、70個併發時，Average達到1200ms左右；
二、100個併發時，Average達到1700ms左右；
三、150個併發時，Average達到3500ms左右；
四、200個併發時，Average達到5300ms左右；

****公共管理測試****
一、50個併發時，Average達到1200ms左右；
二、70個併發時，Average達到1600ms左右；
三、100個併發時，Average達到2500ms左右；
四、150個併發時，Average達到4000ms左右；
五、200個併發時，Average達到5700ms左右；

********************************************************************************************************************************
********************************************************************************************************************************

測試結果：

一、綜合分析Average初步得出系統合適的併發數爲70個併發如下。

二、詳細結果見「圖形分析」和聚合報告。
********************************************************************************************************************************
********************************************************************************************************************************

 

參考網站

[1]http://www.51testing.com/?uid-128005-action-viewspace-itemid-84094；

[2] http://www.51testing.com/html/28/116228-238479.html；

[3] http://www.javaeye.com/topic/211216；

[4] http://dev2dev.bea.com.cn/techdoc/20060912878.html；
[5]http://www.cnblogs.com/jackei/archive/2006/11/11/557972.html；