本文的方法是如今圖形界面下添加好組件，生成jmx腳本文件，而後將jmx文件放到linux環境下用命令行運行腳本，進行性能測試。html
- 用Jmeter進行打壓測試
若是能夠打開圖形界面，則能夠參看圖形界面的使用教程；
此外，在Linux下用命令行進行測試。
1.1 在圖形界面編輯打壓測試腳本
參考《Jmeter教程 簡單的壓力測試》：http://www.cnblogs.com/TankXiao/p/4059378.htmllinux
其實所謂的腳本文件，就是用圖形界面配置好信息後保存的jmx文件，jmx是一個xml格式的文本，能夠用來在命令行做爲參數執行。apache
如下流程是在《Jmeter教程 簡單的壓力測試》的基礎上根據 Y公司 的測試習慣作得補充和修改：服務器
什麼是壓力測試
顧名思義：壓力測試，就是 被測試的系統，在必定的訪問壓力下，看程序運行是否穩定/服務器運行是否穩定（資源佔用狀況）
好比： 2000個用戶同時到一個購物網站購物，這些用戶打開頁面的速度是否會變慢，或者網站是否會奔潰併發
作壓力測試的經常使用工具分佈式
作壓力測試，通常要使用工具， 人工是沒辦法作的。 最經常使用的工具是LoadRunner, 可是LoadRunner畢竟是收費軟件，並且使用上也比較複雜。 如今愈來愈多的人開始使用Jmeter來作壓力測試。 免費， 並且使用上很是簡單。ide
作壓力測試的步驟以下:工具
-
寫腳本 或者錄製腳本oop
-
使用用戶自定義參數性能
-
場景設計
-
使用控制器，來控制 模擬多少用戶。
-
使用監聽器， 查看測試結果
本文作壓力測試的例子
本文舉的實例是： 在一臺電腦用Jmeter模擬200個用戶，同時去使用bing搜索不一樣的關鍵字， 查看頁面返回的時間是否在正常範圍內。
第一步： 使用CSV Data Set Config 來參數化
首先咱們把測試須要用到的2個參數放在txt文件中，
新建一個data.txt文件，輸入些數據， 一行有兩個數據，用逗號分隔。
-
啓動Jmeter, 會出現以下界面，系統自動添加了一個Test Plan（測試計劃），在名稱位置能夠更改測試計劃名稱，好比： Bing接口測試樣本
- 先添加一個Thread Group (右擊 Test Plan(測試計劃) -> Add(添加) -> Thread（Users）-> Thread Group（線程組） )；
線程組也能夠重命名，好比：Bing 200併發
- 而後在「線程組」 下 添加一個CSV Data Set Config (右擊線程組 -> Add（添加） -> Config Element（配置元件） -> CSV Data Set Config)；
在 CSV Data Set Config 中配置測試中要用到的文件內容信息，
第二步：添加HTTP Request.
咱們添加http 請求，發送get 到 http://cn.bing.com/search?q=${param1}+${param2} （）
-
選擇Thread Group 右鍵 (Add（添加） ->Sampler -> HTTP Request（HTTP 請求）)，
- 須要填的數據以下：
A. 在路徑中使用變量
B. 在變量欄中添加變量
C. 在變量中添加變量，同時路徑中也含有變量
本文後續採用第二種方式
第三步： 使用Thread Group， 控制模擬多少用戶
選中Thread Group
Number of Threads(users 線程數): 一個用戶佔一個線程， 200個線程就是模擬200個用戶
Ramp-Up Period(in seconds)（準備時長）: 設置線程須要多長時間所有啓動。若是線程數爲200 ，準備時長爲10 ，那麼須要1秒鐘啓動20個線程。也就是每秒鐘啓動20個線程。
Loop Count（循環次數）: 每一個線程發送請求的次數。若是線程數爲200 ，循環次數爲100 ，那麼每一個線程發送100次請求。總請求數爲200*100=20000 。若是勾選了「永遠」，那麼全部線程會一直髮送請求，直到選擇中止運行腳本。
注：若是想保證線程數裏的線程能同時執行，全部線程的執行時間必須大於Ramp-up Period的時間。Jmeter打壓的同時運行線程數最大不會超過咱們設置的線程數。
關於 Number of Threads、Ramp-Up Period 以及 Loop Count 之間關係的解釋，可參考：http://blog.csdn.net/hsd412237463/article/details/49929173
主要是對於 Ramp-Up Period 參數的理解(http://www.knowsky.com/367353.html)。
（ 每一個線程均獨立運行測試計劃。所以， 線程組經常使用來模擬併發用戶訪問。假如客戶機沒有足夠的能力來模擬較重的負載，可使用Jmeter的分佈式測試功能來經過一個Jmeter控制檯來遠程控制多個Jmeter引擎完成測試。
線程組的大部分參數是不言自明的，只有ramp-up period有些難以理解， 由於如何設置適當的值並不輕易。 首先，假如要使用大量線程的話，ramp-up period 通常不要設置成零。 由於假如設置成零，Jmeter將會在測試的開始就創建所有線程並當即發送訪問請求， 這樣一來就很輕易使服務器飽和，更重要的是會隱性地增長了負載，這就意味着服務器將可能過載，不是由於平均訪問率高而是由於全部線程的第一次併發訪問而引發的不正常的初始訪問峯值，能夠經過Jmeter的聚合報告監聽器看到這種現象。
基於一樣的緣由，過大的ramp-up period 也是不恰當的，由於將會下降訪問峯值的負載，換句話說，在一些線程還未啓動時，初期啓動的部分線程可能已經結束了。 ）
此外，對於Thread Group 的循環次數的設置，能夠選用調度器來指定：
第四步： 添加監聽器 查看測試結果
有兩種比較經常使用的監聽器，一個是察看結果樹（View Result Tree），右擊線程組 -> Add -> Listener（監聽器）-> View Result Tree（察看結果樹）
一個是聚合報告（Aggregate Report），右擊線程組 -> Add -> Listener（監聽器）-> Aggregate Report（聚合報告）
下面運行完成以後再簡單解釋這兩個監聽器的做用
第五步： 運行一下
到目前爲止， 腳本就全寫好了， 咱們來運行下， 如何看下測試的結果
點擊啓動以後，腳本就會執行，在「察看結果數」界面會看到咱們發送的請求的具體信息和響應數據。
在實際的應用中，建議勾選「僅日誌錯誤」，由於運行的請求太多時，若是全都顯示，系統容易崩潰，且咱們比較關心的是錯誤的結果。
聚合報告會顯示不少詳細信息，請求數量，99響應時間，錯誤率以及吞吐等。詳細的解釋請參看 《JMeter 聚合報告》（ http://www.cnblogs.com/jackei/archive/2007/01/17/623166.html）。
1.2 在命令行下運行腳本
將1.1中的腳本保存，在編輯是隨時能夠保存，保存後是一個jmx格式的文件（如圖），這個就是要在命令行下運行的腳本（做爲參數運行）。
這個腳本文件能夠不包含1.1中第四和第五步，便可以不須要添加監聽器，運行是在命令行下執行。
進到解壓apache-jmeter-2.13的路徑下，
執行Jmeter 腳本的命令是：
./bin/jmeter -n -t .jmx文件（腳本） -l .jtl文件（測試運行結果文件）
例：
./bin/jmeter -n -t /home/test/Bing接口測試樣本.jmx -l /home/test/Bing接口測試樣本.jtl
參數說明：
-n表示以nogui方式運行測試計劃
-t表示測試計劃，後面跟測試計劃名稱
-l表示測試結果，後面跟測試結果文件名稱
運行後顯示以下界面，即成功運行了腳本：
運行結束後，會顯示：
顯示 ... end of run 即腳本運行結束，在輸入的測試運行結果文件的路徑下就會出現命令中輸入的jtl文件了。
- 查看測試結果
將上一步運行結束後生成的jtl文件傳輸到可視化圖形界面可打開的路徑下， 打開可視化圖形界面的jmeter
隨便新建一個項目，也能夠用先用的項目，添加監聽器，在監聽器界面，點擊瀏覽，選擇測試運行的結果文件 .jtl文件，就能夠查看結果了。
打開文件後，就會顯示文件中的結果，可是如上述給出的命令在linux下獲得的jtl文件裏只有取樣器結果，請求和相應數據爲空
一樣，在聚合報告中也能夠打開jtl文件，查看結果：
備註： 另外，在Linux下咱們有時候但願線程能夠在後臺運行，這樣咱們關閉當前鏈接後，線程依然能夠運行，這裏提供一個將 jmeter命令設置爲後臺線程的方法。使用setsid命令： setsid bin/jmeter -n -t .jmx文件 -l .jtl文件setsid ./bin/jmeter -n -t .jmx文件 -l .jtl文件有沒有 ./ 當前目錄的表示符均可以