1. 建立JMeter指令碼

當我們分析完一個介面後，就可以開始準備測試指令碼了。
新建一個測試計劃，並新增一個執行緒組，並儲存指令碼為“建立使用者.jmx”

2. 設定登入請求

建立使用者首先需要登入，新增一個HTTP請求：登入

2.1 先獲取登入請求所需要的資訊

（假設前端已經完成，我是使用chrome的開發工具來檢視請求的，如果前端未完成的話，就只能找文件設計或詢問開發）
從截圖可以看到需要用到的資訊

URL：http://localhost:8080/login
Method：POST
Form Data:
1. username:admin
2. password:123456
3. submit:Login

2.2 設定HTTP請求：登入

協議、伺服器名稱或IP、埠號：都是從URL資訊中獲取
方法： POST
請求引數：登入請求使用的是form data（表單），對應到jmeter使用Parameters

2.3 新增一個監聽器：察看結果樹，並執行指令碼

如果響應資料返回“登入成功”，表示登入請求設定OK

3. 設定建立使用者請求

（這個我沒準備前端，只能從文件說明中獲取需要的資訊了，具體看“介面分析”部分）
協議、伺服器名稱或IP、埠號、方法：在文件中有直接說明，容易理解
請求引數: 因為使用的是JSON，所以不好用Paramters表單形式來發送引數了，改用Body Data，具體如截圖（注意json格式要正確）

設定好登入、建立使用者請求，是否就意味著指令碼基本OK了呢？跑下結果看看吧

結果並沒有建立使用者成功，建立使用者的請求被重定向到了登入頁面，說明建立使用者的請求並沒有獲取到user session的（就是說到這個請求時，系統認為還沒有登入呢，雖然前面有發登入的請求）

4. 新增HTTP Cookie 管理器

伺服器必須通過user session 來判斷使用者是否已經登入，但指令碼中傳送建立使用者請求時，並未設定，所以需要加上（我這裡用的就是cookies，這個看實際情況跟開發們溝通吧，只能說cookies是比較常用的）。
新增一個HTTP Cookie 管理器

再次執行指令碼，看結果

why?
返回去看下“介面資訊”，建立使用者介面使用的是json協議，但指令碼中卻沒有對應的設定，檢視請求中的Content-Type，這用的是application/x-www-form-urlencoded，而json協議需要的是application/json

5. 新增HTTP資訊頭管理器

我們需要設定Request Headers的Content-Type，新增一個HTTP資訊頭管理器，並新增一個
Content-Type的值

這裡要注意的是HTTP資訊頭管理器的作用域範圍（HTTP資訊頭管理器會作用於同級或子級元件）
先試下新增HTTP資訊頭管理器後，是這樣的：

執行指令碼看看結果

結果登入請求被重定向到了relogin頁面（登入失敗需要重新登入）

why?
還記得剛開始設定登入請求時，說過登入請求是使用form data 傳送請求引數的。可以返回去看下成功登入的請求， Content-Type與建立使用者請求的值是不一樣的，這意味著需要分別去設定2個請求的Content-Type（注：登入請求其實不用設定，未配置HTTP資訊頭管理器時，Content-Type預設值就是application/x-www-form-urlencoded）

6. 新增簡單控制器

一個簡單的方法，將HTTP資訊頭管理器作為建立使用者請求的子元件，可以解決作用域的問題。

但這樣的問題在於HTTP資訊頭管理器就只能作用於建立使用者這個請求了，而HTTP資訊頭管理器通常是作為一個公共元件存在的。
所以在這裡，就會用邏輯控制器來控制組件的作用域
新增一個簡單控制器，並將HTTP資訊頭管理器、建立使用者請求都拉進控制器中，結果如下

再次執行指令碼，結果OK！

6. 新增斷言

自動化應該可以自動進行結果判斷，這一般是通過斷言來實現的。
如何判斷建立使用者請求成功建立使用者？
首先要看請求返回結果，然後還要去資料庫看下，使用者是否已經新增進去了
當建立請求成功，請求響應碼應該是201；
返回資訊是這樣的（格式化後的json, jmeter中預設是文字形式的，可以在察看結果樹中選擇“JSON Path Tester”型別方便察看）

{
    "code": 201,
    "message": "新使用者建立成功!",
    "user": {
        "id": 4,
        "name": "xiaoming",
        "password": "123456",
        "role": "ADMIN"
    }
}

其中code, message是固定值，user的name, password, role與請求傳送的引數有關（id是後臺自動生成，暫時不管）

6.1 判斷請求響應碼

新增一個響應斷言
在Response Headers 中應該包括HTTP/1.1 201（從察看結果樹的取樣器結果中可以看到）

斷言如下：

6.2 判斷請求響應資料

響應資訊指的是這個

新增一個響應斷言，在響應文字中查詢

（這裡是因為返回資料格式是固定的而且內容也不多，所以會用響應斷言進行判斷，但如果返回資料內容格式不固定或者複雜度較高時，使用響應斷言會變得相當麻煩，這時建議用beansheel 斷言會更方便一些）

6.3 判斷資料庫資料

當請求成功後，還需要到資料庫中檢查使用者資料是否已經匯入到對應的表中
在這裡，我需要使用JDBC PostProcessor到資料庫中查詢使用者資料，然後用BeanShell斷言來進行判斷資料是否正確
1）新增JDBC PostProcessor
（注意：需要先配置好JDBC Connection Configuration）

2）新增BeanShell斷言

3）試執行指令碼
再次新增一個監聽器： 斷言結果，最終結構如下，並執行指令碼

可以看到，察看結果樹中，請求是綠色OK的（證明斷言都通過了）

斷言結果中沒有出現錯誤，證明斷言驗證通過了

（注意，在上面的例子中，已經執行過好幾次這個指令碼了，但建立使用者是不能重複的，我是預先刪除了建立好的使用者的）

至此，一個介面指令碼已經初步完成了！。。