JMeter介面測試：如何實現斷言？

斷言是什麼

什麼是斷言？在介面測試中，我們預設介面響應結果中會出現一個片段，我們稱之為預期值，斷言會在介面呼叫後嘗試捕捉這個預期值，如果能捕捉到，則判定介面成功，否則判定介面為失敗。用過loadrunner的朋友一定記得檢查點這個概念，斷言和檢查點實質上是一樣的。

為什麼需要斷言？因為JMeter預設介面響應碼200即為成功：

其實，介面的業務並非成功。

為了甄別介面是否實現業務上的成功，我們便需要引入斷言。

斷言的實現

在取樣器上右鍵–新增–斷言，可以看到，JMeter提供了豐富的斷言實現（

JMeter版本：5.1.1，下同

）

響應斷言

這大概是最常用的斷言了。

建立方式：線上程組或者HTTP請求上右鍵–>新增–>斷言–>響應斷言，就建立了一個斷言：

關於斷言的作用域：線上程組上建立斷言，則該斷言對執行緒組下所有取樣器生效，而在取樣器上建立，則只對該取樣器生效。

一般情況下，我們用預設配置即可。各個專案也簡略解釋一下。

Apply to：即應用範圍，一般使用Main sample only模式。Main sample代表主請求，Sub-samples代表主請求下的子請求。

測試欄位（Field to test）：表示在何種內容中匹配預期欄位，一般選擇響應文字。

響應文字：介面的Response的全部資料響應程式碼：取樣器結果中的Response code，常見的有200（成功）、302（重定向）、404（不存在）、400（引數錯誤）、500（伺服器錯誤）等。但當我們要驗證404，501等http響應程式碼時，需要勾選 ignore status，因為當http響應程式碼為404、500時，JMeter會預設這個請求是失敗的。

響應資訊：取樣器結果中的Response message

響應頭：響應資料的Response headers

請求頭：請求的Request headers

URL樣本：有跟隨重定向時，URL樣本包含了請求的URL和重定向的URL，否則只包含請求URL。

模式匹配規則（Pattern Matching Rules）：即響應資料與預期值的對比方式。包括（Contains）：響應資料包含預期值（相當於String的contains方法），則判定介面成功。支援正則匹配。匹配（Matches）： 用正則表示式匹配返回結果，且必須能匹配整個返回值，而不是返回值的一部分。相等（Equals）：響應資料與預期值完全相同才判定介面成功。不支援正則表示式。字串（Substring）：與【包括】類似，但不支援正則匹配。否（Not）：取反，也就是前面【包括】等判定結果為true，斷言結果為false。反之，前面判定為false，斷言結果為true。或者（Or）：勾選此項後，可以設定多個預期值，只要有一項判定成功，則斷言判定成功。

測試模式（Patterns to test）：預期值表示式，可以是正則表示式，也可以是字串。可以透過【新增】按鈕新增一個或多個，有多個的話，不勾選【模式匹配規則】中的【或者】，則為並集模式，即全部匹配成功才斷言成功。

自定義失敗訊息（Custom failure message）：當判斷返回值為錯誤的時候，自定義的失敗訊息會在斷言結果中顯示。

下面用看一個小例子：

請求百度：

響應資料：

在【百度一下】請求下新增響應斷言：

執行請求，檢視結果樹：

結果被標紅，介面判定為失敗。可見，你預設的斷言決定了介面是否被判定成功。把上面斷言中的“百度兩下”改為“百度一下”，再次執行，則介面判定為成功。

JSON斷言

JSON斷言針對響應結果是applicaton/json格式的請求進行斷言。

在取樣器下右鍵–>新增–>斷言–>JSON斷言，就建立了一個JSON斷言，介面如下：

Assert JSON PATH exists：針對響應結果中特定欄位進行提取的路徑表示式。

Additionally assert value：附加斷言值，勾選此項後才能填寫Expected value。

Match as regular expression：作為正則表示式匹配。

Expected value：預期值，這個值將與Assert JSON PATH exists提取到的值對比，一致則判定介面成功。

下面照例進行一個例項演示。

首先，建立一個Beanshell取樣器模擬介面，返回JSON資料。

return “{\”code\“：0，\”message\“：\”操作成功\“，\”data\“：{\”student\“：［{\”name\“：\”zhangxu\“，\”age\“：18}，{\”name\“：\”zhoushuang\“，\”age\“：18}，{\”name\“：\”changhua\“，\”age\“：17}］}}”；

在該取樣器下新增JSON斷言，照下圖寫入：

這裡解釋一下【JSON Path expression】的寫法，首先$。這部分是固定寫法，後面根據層級關係去逐級獲取資料。

$。data表示在JSON串以“data”為key獲取value，也就是{“student”：［{“name”：“zhangxu”，“age”：18}，{“name”：“zhoushuang”，“age”：18}，{“name”：“changhua”，“age”：17}］}。

$。data。student對應的是［{“name”：“zhangxu”，“age”：18}，{“name”：“zhoushuang”，“age”：18}，{“name”：“changhua”，“age”：17}］，因此要透過索引定位到陣列中的具體物件，也就是$。data。student［0］獲取到了{“name”：“zhangxu”，“age”：18}

$。data。student［0］。name就定位到了“zhangxu”這個值。

執行指令碼，察看結果樹顯示介面成功。

如果我們把Expected value改為“zhangxu2”，再次執行，發現介面被判定失敗：

BeanShell斷言

這種斷言是應對複雜校驗的利器，為什麼這麼說呢？因為BeanShell斷言可以寫較複雜的邏輯判斷來對結果進行校驗。

還以上文中的模擬介面為例，建立一個Beanshell斷言：

執行指令碼，察看結果樹：

大小斷言&斷言持續時間

大小斷言：判斷響應結果選定部分的位元組大小是否與預期的值相符。

斷言持續時間：判斷介面的響應時間是否小於等於設定值。