JMeter 可以做什麼？

• 能夠對 HTTP 和 FTP 伺服器進行壓力和效能測試，也可以對任何資料庫進行同樣的測試（通過 JDBC）。
• 完全的可移植性和 100% 純 Java，對 JavaWeb 專案相容性好。
• 完全 Swing 和輕量元件支援（預編譯的 JAR 使用 javax.swing.*）包。
• 完全多執行緒框架允許通過多個執行緒併發取樣和通過單獨的執行緒組對不同的功能同時取樣。
• 精心的 GUI 設計允許快速操作和更精確的計時。
• 快取和離線分析/回放測試結果。

以上內容來源於“360百科”。

JMeter 的優劣

優勢

• 輕量級、體積小、免安裝；
• 開源軟體、擴充套件性好，我們可以根據自己的需要修改原始碼；
• 支援代理錄製，支援第三方軟體 Badboy 錄製的指令碼，指令碼可移植性好；
• 對 JavaWeb 支援性好，符合當前形勢，Java 語言編寫的系統和專案多；
• 支援分散式效能測試；
• 容易與 Jenkins 進行整合。

劣勢

當然工具沒有絕對性的好壞，它也有其劣勢，我們只有認清它的劣勢，才能更好的使用它。缺點如下：

• 不支援自動關聯，必須手動書寫關聯指令碼；
• 不支援 HTTPS 的指令碼，但是可以直接測試 HTTPS 的請求；
• 不支援模擬瀏覽器的使用者行為，每個使用者只能代表一個併發；
• 沒有自帶的資源監控體系，需要藉助第三方外掛；
• 支援的協議較少（這裡要說一點，支援的協議雖然少，但是確精）。
• 不支援錄製的指令碼和回放指令碼進行比較。

當然這些所謂的劣勢如果反過來想，它支援的不好，那就說明它支援的功能一定非常完備，並且我所列舉的劣勢是和強大的 LoadRunner 作的比較，如果讀者有足夠的時間，我個人也鼓勵研究下 Loadrunner。

JMeter 的執行環境說明

JMeter 的執行是依賴於 Java 環境的，所以機器必須確保已經安裝 JDK，才能使用 JMeter。

需要說明的是：本地的 JDK 版本最好安裝 1.7 版本以上，推薦 JDK 1.8 版本，否則會與從官網下載下來的最新 JMeter 不相容。

（2）選擇最新的版本進行下載：

請注意，若下載的最新版本為 3.3 的話，已經明確要求，JDK 版本必須為 1.8。單擊 Binaries 下的紅框標註部分進行下載。

（3）下載完成後放在本地的自建目錄下，進行解壓操作：

（4）配置環境變數

新建系統變數為：JMETER_HOME，變數值為：D:\TestTool\Jmeter\apache-jmeter-3.1，如圖所示。

配置 CLASSPATH（沒有的話要新建），變數值為：

%JMETERHOME%\lib\ext\ApacheJMetercore.jar;

%JMETER_HOME%\lib\jorphan.jar;

%JMETER_HOME%\lib\logkit-2.0.jar;如果沒有其他值，那麼前面應該加.;這三個 jar 必須配置在 CLASSPATH 中。

（5）JMeter 的啟動

Windows 系統的啟動：在 bin 目錄下啟動 jmeter.bat；展示出如下介面即啟動成功：

認識 JMeter 的操作元件

我們用一個例項先來嚐嚐鮮，看看如何用 JMeter 完成一次簡單的效能測試實踐。

測試背景

（1）被測試網站為部落格園網站。

（2）場景為：

• 執行緒數：虛擬使用者數。
• Ramp-Up period（in seconds，即單位為秒）：即為場景載入的策略，設定的虛擬使用者數需要多長時間全部啟動。如果執行緒數為 10，時間為 5，也就是說每秒啟動 2（2 是執行緒數 10 除以 Ramp-Up period 而來）個執行緒。
• 迴圈次數：每個執行緒傳送請求的次數。如果執行緒數為 10，迴圈次數為 5，那麼每個執行緒傳送 5 次請求，總請求數為 10×5=50。

如果勾選了永遠，那麼所有執行緒會一直請求直到停止；不勾選永遠預設。總的請求執行時間為 Ramp-Up period × 迴圈次數 = 5 × 5 = 25 秒。

（3）我們想要的指標為：響應時間、錯誤率以及平均響應時長。

測試基本流程

開啟 JMeter 介面後，我們以 HTTP 請求為例開始實踐效能測試，基本流程如下所示。

（1）單擊“測試計劃”|“新增”|“Threads（Users）”|“執行緒組”命令，如圖所示：

（2）單擊“執行緒組”|“新增”|“Sampler”|“HTTP 請求”命令，如圖所示：

對 HTTP 請求的主介面說明如下，下圖為 HTTP 主介面：

• 名稱：原則上可以隨意命名，但是最好採用一個有意義的名字，方便後續指令碼管理；示例中命名為：部落格園 HTTP 請求。
• 註釋：使用者記錄使用者可讀的註釋資訊，但在測試中無任何作用。
• 伺服器名稱或 IP：HTTP 請求傳送的目標伺服器地址或 IP。本案例中伺服器名稱是：www.cnblogs.com。
• 埠號：目標伺服器的埠號，預設為80。
• timeouts 超時定義可以不用填寫。
• 協議：向目標伺服器傳送 HTTP 請求時的協議，可以是 HTTP 或是 HTTPS，預設為 HTTP。
• 方法：傳送 HTTP 請求的方法，有 POST 或是 GET 等。
• content encoding：內容的編碼方式。
• 路徑：目標 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 中所有引數設定在本表中，表中的每一行是一個引數值對，一一對應。
• 同請求一起傳送檔案：在請求中傳送檔案，通常 HTTP 檔案上傳行為可以通過這種方式進行模擬。
• 從 HTML 檔案獲取所有有內含的資源：當該選項被選中時，JMeter 在發出 HTTP 請求並獲得相應的 HTML 檔案內容後，還對該 HTML 進行 Parse 並獲取 HTML 中包含的所有資源（圖片、Flash 等），預設不選中。

如果使用者只希望獲取頁面中的特定資源，可以在下方的 Embedded URLs must match 檔案框中填入需要下載的特定資源表示式，這樣，只有能匹配指定正則表示式的 URL 指向資源會被下載。

• 用作監視器：此取樣器被當成監視器，在 Monitor Results Listener 中可以直接看到基於該取樣器的圖形化統計資訊，預設不選中。
• Save reponse as MD5 hash?：選中該項，在執行時僅記錄服務端響應資料的 MD5 值，而不記錄完整的響應資料，在需要進行資料量非常大的測試時，建議選中該項以減少取樣器記錄響應資料的開銷。

以上說的各項內容一般情況下都選擇預設項即可，無需配置。本示例中只需要填寫【伺服器名稱或 IP】即可。

（3）單擊“部落格園 HTTP 請求（即 HTTP 請求）”|“新增”|“監聽器”|“檢視結果樹”命令，用來觀測請求是否成功：

（4）單擊“部落格園 HTTP 請求（即 HTTP 請求）”|“新增”|“監聽器”|“聚合報告”命令，用來監聽測試指標：

（5）執行指令碼：

（6）檢視結果樹：

從結果樹中可以發現，請求已經全部成功。

（7）檢視聚合報告：

對其監控的指標說明如下：

• Label：定義的 HTTP 請求名稱。
• Samples：表示這次測試中一共發出的請求總數。
• Average：平均響應時長，預設情況下是單個 Request 的平均響應時長，當使用了 Transaction Controller 時，也可以以 Transaction 為單位顯示平均響應時長。
• Median：中位數，也就是50%使用者的響應時長。
• 90%line：90%使用者的響應時長；
• 95%line：95%使用者的響應時長；
• 99%line：99%使用者的響應時長。
• Min：訪問頁面的最小響應時長。
• Max：訪問頁面的最大響應時長。
• Error%：錯誤請求的數量/請求的總數。
• Throughput：預設情況下表示每秒完成的請求數（Request per second），當使用了 Transaction Controller 時，也可以表示類似 Loadrunner 的 transaction per second 數。
• Received KB/Sec：每秒從伺服器端接收到的資料量。
• Sent KB/sec：每秒向伺服器傳送的資料量。

另外補充兩點：

• 響應時長：如 Median、90%line、95%line、99%line、Max、Min 的單位都是毫秒；
• 所有的監聽資料都可以寫在一個已經建立好的檔案中，這個檔案的檔案格式必須為 .jtl。

（8）變更測試場景後，再次執行，需要清楚執行記錄：