課程簡介

本課程制作的主要目的是為了讓大家快速上手 JMeter，期間穿插了大量主流項目中用到的技術，以及結合當今主流微服務技術提供了測試 Dubbo 接口、Java 工程技術具體實施方案，註重實踐、註意引導測試思維、拒絕枯燥的知識點羅列、善於用實例展示實踐過程。學完本課程，可以快速錄制、開發、調試性能腳本，建立測試場景並且可以進行性能測試分析。特色如下：

• 覆蓋 JMeter 的每一個細節；
• 介紹了 JMeter 在性能、自動化的雙領域應用；
• 有完善的性能測試體系的展現；
• 為 Java、MySQL、Dubbo 提供完備的測試方案。

作者介紹

王海寶，高級測試工程師，課課家講師，Testfan 社區、博客園知名撰稿人。任職於中科軟科技，服務過中國銀行、陽光信保、寺庫電商，長期在消費金融領域從事一線測試工作，擅長自動化測試、接口測試、功能測試，尤其擅長分布式框架的測試。

課程內容

導讀：課程概要

讀者或許可以在網上搜尋到許多關於 JMeter 的應用案例，不免會有疑惑，為什麽還要購買這個課程？如果在網上搜索過資料，是不是有過這樣的困擾：

• 明明是按照文檔中的說明操作的，但有時總是出錯，然後會瘋狂搜索各類與問題相關的資料，東拼西湊的尋找答案，浪費了大量的時間和精力。

• 讀者是不是也遇到過這種情況，開始操做的時候，舉步維艱，做過之後再來看，其實很簡單，好吧，這是我們做過一件事情之後的想法，當然這也是在網上分享學習心得的大牛們的想法，所以對於初學者，看到的永遠都是大牛們思維提煉後的知識產物，很多內容我們根本無法真正的領會。道理很簡單，我們應該從金字塔的最底層開始學起，而搜索到的資料往往都是金字塔頂端的產物。

下面舉幾個例子來說明上面的兩種場景。

• 若要測試接口，並且現在產品還沒有 Web 界面，無法直接錄制腳本，於是想到要麽使用 Loadrunner 的 Java vuser 去測試，要麽使用 JMeter 的 Java 請求去測試，考慮到後者輕量級，則采用後者去做。於是搜尋大量資料，大部分是如何將 Java 的 jar 導入到 JMeter 中，但是卻沒有介紹應該如何開發 JavaSampler，怎樣開發 JavaSampler。

• 若去做測試分析，會有資料介紹如何從測試指標中分析，但是沒有介紹要從內存→硬盤→CPU 的前後順序一 一去排查瓶頸。

• 編寫性能測試腳本應該去參數化，但是很少有資料介紹為什麽要做參數化，還有也沒有資料介紹腳本中最應該參數化的腳本就是：“一次性數據”和“時間”。

……

所以跟著本課程從第一節開始，認真的學習下去，到最後掌握的不僅是性能測試這個理論體系，更是實打實的實踐能力。本課程的特色在於可以從基本的理論知識入手，用最快的時間掌握並應用、註重實踐，盡量避免乏味單一的理論知識介紹。

學習動力

學習是有時間成本的，所以我們必須找到學習的動力，最主要的無非是以下三個：

（1）個人能力的提升，個人能力提升之後才能勝任更具價值的崗位；

（2）公司認可，無論是招聘還是公司內部，領導層對性能測試情有獨鐘。具體可以看下國內知名公司對性能測試的招聘情況：

更多信息可以去瀏覽智聯招聘、拉勾網等招聘網站去瀏覽性能測試工程師的待遇和要求，可以確定的是，即使很多公司沒有特定的性能測試工程師崗位，但是大多也會要求會性能測試，並且是作為重要的加分項。

（3）掌握了性能測試這門技術，升職加薪自然不是夢想，定能薪水翻番。

學習思路

學習性能測試要掌握好基本的三板斧操作，即：

性能腳本開發

• 參數化學習
• 關聯學習
• 集合點學習
• 檢查點學習
• 元件作用域與執行順序
• 常見 JMeter 的參數講解

測試場景建立

測試瓶頸分析

• CPU
• 硬盤
• 內存
• 中間件
• 數據庫
• 分析原則

特殊業務處理

• Dubbo 接口
• Java 請求
• 分布式性能測試介紹

請讀者深入淺出的學習，每一篇都會酌情配備實例，畢竟“做”才是第一位的。

最後的話

請跟著我的節奏和思路一起進步，一起擁抱性能測試，當然水平有限，錯漏難免，歡迎各路大神指正糾錯！

第01課：認識 JMeter

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 不兼容。

var express = require(‘express‘);
var router = express.Router();
var http = require("ykt-http-client");     // 中間件的客戶端  參數存放在req.bdoy裏面
/* GET users listing. */
var comm = require(‘.www.feifanyule.cn/./public/js/constant‘);   // 這裏面是定義服務器的地址
var ip = comm.IP;
const IP = comm.IP;

router.get(‘/‘, function (req, res, next) {
  res.send(‘respond with a resource‘);
});
// 獲取頻道
router.post(‘/aa‘, function (req, res) {
  http.post(ip www.yongshiyule178.com + ‘aaaa‘, req.body).then((data) => {
    //console.log(JSON.stringify(data))
    res.send(data);
  })
});
// 主頁     這就是要用到的接口
router.post(‘/main‘,www.yigouyule2.cn  function (req, res) {
    http.post(IP+‘/xhhms/rest/interfacesLoginController/getMenu‘, req.body ,req.headers).then((data) => {
      console.log(IP+‘/www.chaoyueyule.com xhhms/rest/interfacesLoginController/getMenu‘);
        res.send(data);
    })
});

（1）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。

JMeter 性能測試進階實戰