聊一聊 Jmeter 的簡單使用

背景

近段時間，團隊想補強測試這一塊，減少重複性的一些工作，讓一些內容可以自動化起來，同時對開發同學寫的接口的性能也開始有所要求了。

考慮到團隊內沒有人有測試開發的經驗，所以前期的選擇還是以工具爲主，編程爲輔。

說起工具，用的比較多的是 Jmeter ，它即可以處理自動化的測試，也可以完成性能測試。

後面也會不定期更新一些在使用 Jmeter 時候的經驗。

開篇往往都會是比較簡單的內容。

所以這一篇寫的內容主要是拿一個 HTTP 接口出來，然後通過配置，在 Jmeter 中成功訪問這個接口，並斷言請求成功與否，查看結果。

最後還會通過 CLI 來跑測試計劃，輸出 HTML 格式的報告。

下面就開始吧！

準備一個 HTTP 接口

這裏創建一個 ASP.NET Core Web API 項目，同時寫一個簡單到不能再簡單的接口，直接返回一個 JSON 串。

[ApiController]
[Route("[controller]")]
public class RunController : ControllerBase
{        
    [HttpGet]
    public IActionResult Get()
    {
        return Ok(new 
        {
            code = 0,
            msg = "ok"
        });
    }
}

把這個項目啓動起來，暴露出 8532 端口。

下面就開始在 Jmeter 裏面對這個接口進行配置和調試了。

添加線程組

在測試計劃添加一個線程組 (Thread Group)

添加完成之後可以看到下面的內容

在線程組中，最爲主要的就是 Thread Properties 的配置了，不過這裏先不對這個進行修改，先保持默認值。

因爲首先要做的事情是，把測試接口調試通！如果接口沒調好，設置再多的線程也沒有意義！

所以這裏只把名字改成了 sample1 。

線程組有了，就相當於有了一個骨架，下面就要對這個線程組填充內容，讓它豐富起來。

由於我們主要是對 HTTP 接口進行測試，所以大部分內容會是和 HTTP 相關的。

添加 HTTP 請求默認值

在線程組裏面，添加一個 HTTP 請求默認值的配置元件 （HTTP Request Defaults）

這裏一般會配置一些不怎麼變的東西，正常就是接口的域名信息，指定好之後，後面就可以不用在填接口的域名了。

下面就把測試接口的 IP 和 端口填上去。

添加 HTTP 信息頭管理器

請求頭，大部分接口都會有要求的，最常見的應該就是 Content-Type 。

這裏就可以添加一個 HTTP 信息頭管理器（HTTP Header Manager）來管理這些請求頭。

測試接口是 JSON 格式的，所以要把 Content-Type 和 application/json 配置上去。

再下一步就是真正的請求了。

添加 HTTP 請求

在線程組裏面添加一個 HTTP Request 類型的 Sampler。

這一個步驟要根據對應的測試接口填寫對應的信息。

以測試接口爲例：

  1. Web Server 這一塊內容不用填，我們在 HTTP 請求默認值 裏面已經配置了。

  2. 測試接口是 GET 請求， 測試接口的相對路徑是 /run

  3. 接口參數填了 a=b&c=d ，因爲是 GET 請求，放到相對路徑上面去也是可以的。

到這裏的話，對這個接口的請求內容已經準備好了。

要怎麼判斷請求這個接口是不是成功了呢？

接口成功與否，一般會有幾類標識，一類是當狀態碼爲 2xx 時就當作是成功的，一類是返回的 JSON 裏面包含了一個 code ，用這個 code 的值來判斷。

上面的測試接口是屬於第二類，所以要判斷的是返回內容裏面 code 的具體值是什麼。

回想到單元測試，會有一個斷言的步驟去判斷是不是達到了預期的結果。

同樣的，Jmeter 這裏也有這個內容。這裏選用的是 JSON 斷言。

添加 JSON 斷言

在線程組裏面添加一個 JSON 斷言（JSON Assertion）

示例接口返回 code 爲 0 時，纔是成功的，所以可以這樣填寫

首先是判斷節點存在與否，其次是勾選斷言值，填上期望值。

現在請求有了，斷言有了，要怎麼查看結果呢？

這裏就要請出監聽器這個神奇的東西了。

添加監聽器

監聽器的種類有很多，這裏選擇查看結果樹（View Results Tree）和聚合報告（Aggregate Report）兩個。

這個時候，整一個測試計劃是這樣的：

運行一下，打開查看結果樹，可以看到測試接口已經跑成功了，返回的 code 確實也是 0。

如果把 JSON 斷言裏面的 code 調整成 1，查看結果樹這裏就會有錯誤提示：

再來看看聚合報告長什麼樣：

主要就是平均響應時間，中位數，錯誤率，吞吐量這些常見指標。

到這裏是不是就結束了呢？

當然沒有結束，從剛纔的結果來看，明顯才請求了一次接口，請求一次接口怎麼測試接口的壓力呢？

其實一直到看到結果是能成功請求接口，返回正常的數據了，纔算是剛剛把接口那部分配置調試好，並沒有真正的給壓力到測試接口。

前面在創建線程組的時候，採取的都是默認值 1，下面可以調整線程組的一些配置來達到壓測的目的。

好比說把線程數調成 100，循環 100 次。

CLI 運行 Jmeter

在啓動 Jmeter 時，可以看到下面這段話。

就是讓我們做壓力測試的時候不要用圖形化界面，而是用腳本來操作。

要用腳本操作，還是要先有配置文件，這個配置文件在保存測試計劃的那個 jmx 文件。

下面是幾個常用的參數說明：

90n5Gx

下面我們通過 CLI 來執行一下，並生成一個 HTML 報告。

 .\jmeter.bat -n -t ..\..\jmeterfiles\jmx\sample1.jmx -l result\sample1.jtl -e -o result\sample1

sample1.jmx 就是上面保存的腳本文件。

同時看看輸出的測試報告

打開 index.html 可以看到測試報告了。

這個面板的內容是很詳細的。

寫在最後

這一篇內容比較基礎，就是走了一遍 Jmeter 的基本操作。

對於一些常見的參數化，引用自定義 jar 包這些內容還沒有介紹到。

相對來說，Jmeter 在測試的場景用起來還是比較 OK 的。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/qC0WIwy3aD1x4dbyXkLnMw

猜你喜歡