試著使用 jmeter 實現介面自動化測試

目錄
一． 編寫目的
二． 術語定義
三． Jmeter基操

1. 測試計劃
2. 執行緒組
   
3. Test Fragment
   
4. Transaction Controller
   
5. User Defined Variables
   
6. User Parameters
   
7. Regular Expression Extractor(正規表示式)
   
8. Response Assertion
9. BeanShell Assertion
   
10. JSON Extractor
    
11. Module Controller
    四． Jmeter的介面自動化測試
    
12. 框架詳解
13. 框架的利弊
    

一．編寫目的
(1)jmeter的基本操作。（以支援介面自動化測試）
(2)如何使用jmeter，進行介面自動化測試。

二．術語定義
術語 說明
介面測試 介面測試是測試系統元件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的互動點。測試的重點是要檢查資料的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。

三．Jmeter基本操作
1.測試計劃

建立一個專案會自動生成一個測試計劃
1）測試計劃頁勾選“Run ThRead Groups consecutively”，可控制執行緒組的執行方式，使之按順序連續執行。
2）測試計劃頁的“User Defined Variables”為使用者指定變數，測試計劃下的元件都可使用，也可以在測試計劃下新增一個“User Defined Variables”的元件。
2.執行緒組

測試計劃下新增“Thread Group”
1）併發測試時，可根據“Thread Properties”欄去控制併發場景。

2）遇到請求error時的處理方式，可根據“Comments”的選項選擇適合的場景。

3.Test Fragment

是控制器上一個種特殊的執行緒組，它在測試樹上與執行緒組處於一個層級。但使用時需要和include Controller或者Module Controller配合。它的主要作用是模組化測試過程，類似於程式語言中的函式。即，將測試過程封裝成測試片段，就可以在其他地方直接引用了。
4.Transaction Controller

事務控制器
1）勾選第一個選項“Generate parent sample”，生成父樣本，在檢視樹中可看出父子關係。

5.User Defined Variables

使用者指定變數，同級或同級得子集都可使用該變數。
6.User Parameters

引數化，根據場景得併發數或執行次數迴圈多次引數值。
7.Regular Expression Extractor(正規表示式)

正規表示式，可獲取某個請求結果指定得值並定義變數，最常用得場景就是關聯所建立得Id給其他請求所利用，如商品訂單等。
1）“Apply to”應用得場景，預設選擇“Main sample only”。
2）“Field to check”欄位校驗得場景選項。
3）“Name of created variable”引數名。
4）“Regular Expression”正規表示式，常用場景為選擇所需欄位得左邊界值和有邊界值，包括引號等，() 括起來的部分就是需要提取的，括號規則如下，常用得有(.+?)。

5）“Temple”模板，用$$引用起來，如果在正規表示式中有多個正規表示式（多個括號括起來的東東），則可以是$2$，$3$等等，表示解析到的第幾個值給user_id。例如：$1$表示匹配到的第一個值。
6）“Match No”匹配數字，0代表隨機取值，-1代表所有值，此時提取結果是一個陣列，其餘正整數代表第幾個匹配的內容提取出來。
7）“Default Value”預設值，正則匹配失敗時，取的值。
8.Response Assertion

返回斷言，正常來說主要是斷言請求結果存在或不存在某些欄位或某些值，也可以宇JSON Extractor結合使用。
9.BeanShell Assertion

自定義斷言，斷言的進階，適用的語言為java，可參考如下demo

10.JSON Extractor

後置處理器，可處理較為複雜的結果獲取後置結果某個值，homin目前使用該元件主要是獲取佇列結果的長度，即一個list裡有多少個map，以此保證assert的準確性，具體方法如下：
Json Extractor

Response Assertion

_MatchNr為正則個數的統計，斷言返回結果[]中有1個{}。
11.Module Controller

模組控制器，一般與“Transaction Controller”事務控制器結合使用，選擇對應的事務控制器，執行緒組執行時，該模組就會執行所選的模組。

四．Jmeter的介面自動化測試
目前使用jmeter的框架思路主要是利用Test Fragment封裝用例單元，使之模組化，按介面劃分執行緒組，執行緒組下新增事務控制器作為測試用例，在事務控制器下利用模組控制器進行測試單元的組裝。
思路圖：

Demo：

用例圖：

1.框架詳解
~從上往下
測試計劃：=專案名稱/用例模組，如：電商專案一個測試計劃、使用者管理一個測試計劃、訂單管理一個測試計劃。
欄位引數化：字面意思，便於該用例模組的引數呼叫。
Test Fragment：=用例模組，如：使用者管理一個測試計劃、訂單管理一個測試計劃。
Transaction Controller：=用例元件，將介面請求和對應的斷言封裝起來作為用例元件，便於用例組裝。
執行緒組：=以介面為單位劃分的RunAll元件，如建立訂單的介面用例。
執行緒組下的Transaction Controller：=測試用例，由單個或多個Module Controller組裝而成。
Module Controller：=用例模組的呼叫。
結果監控，報告生成：目前暫時沒有一個適用於介面自動化的測試報告，新增一個檢視樹去看報紅的用例。

2.框架的利弊
利：
1）能夠迴圈利用已封裝的測試單元
2）單個介面場景的執行較方便，執行一個執行緒組即可

弊：
1）單個用例場景的執行較不方便，需要遮蔽執行緒組下的其他事務控制器再執行執行緒組

（只執行testCase003）
2）不利於公共斷言方法，模組控制器所能控制的最小單位為事務控制器
3）暫無適用於介面測試報告生成的方法
4）有多層級用例模組時不好劃分，目前是建立多個測試計劃解決，即多個jmx檔案。。。