Apache JMeter 應該是應用最廣泛的效能測試工具。怎麼用 JMeter 編寫效能測試指令碼？
1. 編寫 HTTP 效能測試指令碼
STEP 1. 新增 HTTP 請求
STEP 2. 瞭解配置資訊
HTTP 請求各項資訊說明（以 JMeter 5.1 為例）。
如下圖所示：
- Web伺服器：指定協議、HTTP 請求的主機地址和埠號，不需要加上“
http://”，JMeter 會自動加上，一般的 Web 服務埠號預設是 80，如果你訪問的地址中帶有其他埠號在此填入，協議根據目標地址實際情況填入http或https。 - 客戶端實現：實現裡面有
HttpClient4和Java兩個選項。HTTPClient4可以看成是一個沒有介面的瀏覽器，可以透過它高效的訪問Http協議的資源；Java選項是使用 JDK 提供的net包中的工具類來訪問。 - 方法：下拉選單中有 8 個選項，我們常用的是 POST 和 GET。GET 是提交請求時將引數連線在瀏覽器位址列，且長度有限制（1 MB 以內）；POST 提交請求沒有長度限制，使用者一般也看不到提交的內容，相對來說安全些，其他相關選項請大家自行參考 HTTP 協議。
- 路徑：除去主機地址部分的訪問連結。
- 內容編碼：字元編碼格式，預設是
iso8859，一般寫成UTF-8即可，當然也可以和開發人員確認。 - 自動重定向：自動重定向可以自動轉向到最終目標頁面，但 JMeter 是不記錄重定向過程內容的，勾選了這一項後，【跟隨重定向】則會失效，且無法做關聯。
- 跟隨重定向：HTTP 請求的預設選項，當響應
code是3xx時，自動跳轉到目標地址。與自動重定向不同，JMeter 會記錄重定向過程中的所有請求響應，在檢視結果樹中可以看到伺服器返回的內容，選了這個可以對響應內容做關聯。 - 使用 KeepAlive：HTTP 請求的預設選項，對應
HTTP響應投中的Connection:keep-Alive。 - 對 POST 使用multipart/form-data：這個屬性是和方法 POST 繫結的，一般檔案上傳時會用到它。
- 與瀏覽器相容的頭：瀏覽器相容模式，若選了【對
POST使用multipart/form-data】，建議也勾選此項。 - 同請求一起傳送引數：填要傳送的引數和值的區域，引數項是以 key 和 value 形式填寫，訊息體資料是以JSON 格式填寫，檔案上傳項需要填寫檔名稱、引數名稱和 MIME 型別，如果你不知道 MIME 型別，可諮詢開發人員或使用抓包工具檢視。
填好以上這些選項後，HTTP 單介面就準備的差不多了，這裡給 GET、POST、檔案上傳三個示例圖，供參考。
- GET 請求 + 引數
- POST 請求 + 訊息體資料
- POST 請求 + 檔案上傳
STEP 3. 響應斷言
指令碼製作原則裡有說到每個請求必須要有響應斷言，是因為若對介面返回不做判斷的話，我們無法判斷請求的有效性，從而無法評估出效能測試的真實性，故每個請求必須要有響應斷言。接下里我們看看響應斷言。
斷言是透過獲取伺服器響應資料，再根據斷言規則去匹配這些響應資料；若匹配到了是正常現象，不會進行任何提示，若匹配不到，JMeter 則會斷定這個請求失敗，在後面除錯指令碼中我們會看到檢視結果樹中的請求名稱是紅色字型。斷言元件有很多，我這裡講到的響應斷言基本能滿足 80% 以上的斷言需求。
首先，我們增加斷言，在請求名稱上右鍵->新增->斷言->響應斷言：
再說說響應斷言中一些引數的意義：
- 名稱和註釋：可以隨意設定，最後有業務意義。
- Apply to：應用範圍，有 4 個選項
- Main sample and sub-samples：匹配範圍包括當前父取樣器並覆蓋子取樣器
- Main sample only：匹配範圍是當前父取樣器
- Sub-sample only：僅匹配子取樣器
- JMeter Variable：支援JMeter變數值進行匹配
- 測試欄位：對響應資料的不同部分進行匹配，有 7 個選項。
- 響應文字：返回的文字內容
STEP 4. 除錯指令碼
寫好指令碼後，接下來是除錯指令碼，JMeter 一般是結合察看結果樹來除錯指令碼，可以從察看結果樹元件中看到伺服器的返回資訊。察看結果樹會顯示取樣器的每一次請求，若是有大量的請求，在壓測時建議關閉，否則會比較消耗壓測機資源。
察看結果樹這元件一般只用來除錯指令碼，這裡也大概科普下察看結果樹各項引數用途。
- 名稱：自定義內容，預設為察看結果樹，可為空。
- 註釋：預設為空，可以為空，自定義內容。
- 所有資料寫入一個檔案：可以將結果儲存，這裡是一個路勁地址。
- Text 下拉選單：顯示請求內容的形式列表，這個下拉選單裡有 Text、Xpath Tester、JSON 等。
- 取樣器結果：顯示取樣器結果，這裡的資訊和瀏覽器上展示的內容差不多。
- 請求：展現請求表單內容，不同的取樣器有不同顯示格式。
- 響應資料：顯示伺服器響應資料，分為 Response Body 和 Response headers，提供了查詢功能，也可以區分大小寫查詢和正規表示式查詢。
2. 編寫 Dubbo 效能測試指令碼
STEP 1. 將我們自己實現的請求 Dubbo 的服務打成 jar 包放到 JMeter/lib/ext 目錄下。
STEP 2. 開啟 JMeter，新增執行緒組，線上程組中新增 Java 請求。
STEP 3. 在 Java 請求中類名稱中選擇自己上傳的類，在引數欄填入相關引數內容。
STEP 4. 對 Java 請求增加相應斷言以及透過察看結果樹除錯指令碼，和 HTTP 指令碼一致，不再贅述。
3. 編寫效能測試指令碼的參考規範
程式碼有編碼規範，寫指令碼也有規範，比較推薦的規範是：
- 指令碼中只能有一個測試計劃。JMeter 指令碼在客戶端介面中展示的樹型結構，測試計劃是根節點，根節點只能是一個。
- 測試計劃中至少有一個執行緒組。JMeter 執行壓測都是從執行緒組發起的，所以測試計劃中至少要有一個執行緒組，另外 JMeter 支援多個執行緒組。
- 至少要有一個取樣器。指令碼中若無取樣器則是一個空指令碼，無法模擬使用者請求，無任何執行意義。
- 每個取樣器必須有斷言。無斷言則無法判斷請求是否成功，更無法判斷壓測有效性。
- 至少要有一個監聽器。非命令列執行指令碼時，需要檢視執行結果，則會需要有聚合報告等監聽器；若使用命令列執行指令碼時，則可生成結果檔案。監聽器是用來展示執行結果，而執行結果則是用來分析系統效能的。
- 非除錯時禁用察看結果樹。察看結果樹一般是用來除錯指令碼的，但壓測時使用的話，大量的請求返回資料會消耗壓測機資源，可能導致壓力機效能下降。
- 減少使用不必要的外掛。JMeter 外掛是很豐富，但使用不當會影響 JMeter 本身效能，從而導致壓力機自身成為壓測瓶頸，比如使用監控外掛，大量的伺服器資源採集會影響壓測機的磁碟 IO 及消耗壓測機其他資源。
遵循這些規則可以讓我們養成良好的習慣，避免不必要的錯誤。
總結
本文簡單介紹了編寫 HTTP 和 Dubbo 效能測試指令碼的步驟，並且給出了效能測試指令碼的參考規範，希望對大家有幫助。
最後感謝每一個認真閱讀我文章的人，禮尚往來總是要有的，這些資料，對於【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，雖然不是什麼很值錢的東西，如果你用得到的話可以直接拿走：
