JMeter介面測試實戰-請求異常測試
請求異常測試
1.請求引數異常
在介面資訊介紹中說過，建立使用者使用的3個引數，都是有一定的規則限制，不是輸入任意值都是成功建立使用者的
1.1新增請求
1）新增一個HTTP請求，放到簡單控制器下面，並修改名稱中“建立使用者失敗_引數異常”
2）設定HTTP請求（參照建立使用者請求），請求引數設定為不能成功建立使用者的引數，比如使用者名稱為 a (使用者名稱要求是4到20的字母數字組合)，結果如下
（這裡還處於指令碼除錯階段，所以我會暫時先禁用掉迴圈控制器中成功建立使用者的請求）
3）試執行指令碼
可以看到，當建立使用者時，name設定a，是不能建立使用者的，並且系統返回了對應的錯誤資訊
4）新增斷言
與建立使用者成功一樣，這裡同樣會加3個斷言，分別用來驗證請求響應碼，請求響應資訊，資料庫內容
引數異常，請求響應碼應該是400
- 響應資訊
- 按名稱查詢使用者
（簡單來說，直接從建立使用者的請求中複製過來的，但修改了引數值為當前請求用到的值：a）
- 判斷資料庫中的使用者資訊
引數異常，建立使用者失敗，資料庫中不應該查詢到該使用者的資訊
5）試執行指令碼
why? 結果是紅色的，但斷言什麼的沒有錯。
前面介紹jmeter常用元件》響應斷言時應該說過，jmeter會將響應碼不是2XX,3XX的請求預設為失敗，而這裡，請求響應碼是400，如果想要400設定為期待值，需要在響應斷言中選中“Ignore Status”
Ok，修改第一個響應斷言如下（有2個響應斷言，但只要修改一個就好，原因回去元件介紹中找啦）
重新執行指令碼，結果成功
- 響應資訊
1.2 引數化
就像建立使用者成功一樣，建立使用者失敗也會需要測試不同的資料集合，同樣也會用到引數化
（過程神馬的與建立使用者成功是一樣的，所以下面只給出完成版本的截圖了）
- createuser_fail.csv
不同的引數錯誤，請求返回的資訊是不一樣的，所以在這裡設定最終會更加方便
- 最終執行結果
從“察看結果樹”中，可以看到jmter傳送了8個建立使用者的請求，分別對應createuser_fail.csv的8行測試資料，並且最終斷言結果通過
2. 使用者名稱不能重複
建立使用者介面中說過，name是不可重複的。
要測試使用者名稱重複這種情況，必須先要知道在資料庫已經存在的一個使用者。我們可以事先準備一個使用者，然後再次使用這個使用者名稱來測試建立使用者。或者，看下指令碼，之前我們已經測試過成功建立使用者的情況，現在只需要取出其中一個使用者來進行測試也一樣能行吧。。
下面基於這種考慮，修改指令碼
2.1 新增僅一次控制器
在成功建立使用者的迴圈控制器下，新增一個僅一次控制器
2.2 新增HTTP請求
在僅一次控制器新增一個HTTP請求：建立使用者失敗_使用者名稱重複，用來測試使用者名稱重複的情況
name 使用變數獲取，與建立使用者請求取同樣的值，因為jmeter按順序執行請求，當第一次建立使用者成功後，第二次就是使用者名稱重複了
注意：這有個前提，就是前面建立使用者的請求必須成功，不然到第二次建立使用者失敗_使用者名稱重複請求中，使用者名稱就不是重複的了，如果有必要的話，可以再增加一個如果（if）控制器來判斷前面的請求建立使用者使用者是否成功。我是直接去查詢資料庫看是否已經有重複使用者
2.3 新增斷言
同樣會有3個斷言
- 響應碼：409
- 響應資訊
- 資料庫資訊判斷
- 在這裡，需要先做一個判斷，看看資料庫中是否已經有重名的使用者。
新增一個前置處理器> JDBC PreProcessor，在請求傳送之前用來查詢資料庫資料
請求傳送後查詢資料庫資料
BeanShell斷言
2.4 試執行指令碼
從結果中可以檢視到，第一個建立使用者請求使用的使用者名稱與第二個建立使用者失敗使用者名稱重複的請求使用的使用者名稱是相同的，都是“xiaoming”，結果第一個建立使用者的請求成功建立了xiaoming的使用者，但第二個建立使用者失敗使用者名稱重複的請求，返回了Name已經存在的錯誤資訊
3. 使用者沒有許可權
只有ADMIN使用者有許可權去建立使用者。為了測試這種情況，需要分別使用ADMIN使用者與NORMAL使用者登入，再去傳送請求建立使用者。
回去看指令碼，之前登入的使用者使用的是固定的ADMIN使用者，所以在這裡在新增一個使用NORMAL使用者登入的測試就可以了
一個簡單的方法是複製當前使用ADMIN使用者登入的執行緒組，修改下登入使用者名稱，建立使用者的請求就可以完成測試
或者從另一個角度考慮，給jmeter提供2個使用者，使用邏輯控制器的如果（if）控制器去判斷使用者屬於哪個角色，再去確定他應該走哪個測試流程，也是同樣完成許可權控制的測試的。（更智慧一點嗎……）
下面的例子是按第二種方法設計的
3.1 新增CSV Data Set Config
首先要明白執行緒組也是配合CSV Data Set Config可以迴圈執行的。所以我們可以新增一個CSV Data Set Config來讀取使用者名稱與密碼
loginuser.csv:
3.2 設定執行緒組迴圈次數為2
3.3 修改登入請求
前面的指令碼是使用固定使用者登入的，使用者名稱、密碼必須修改為對應的變數名
3.4 新增2個如果（If）控制器
1）在指令碼的簡單控制下，新增如果（If）控制器，如果登入使用者的角色為ADMIN，將指令碼原來的測試建立使用者成功與失敗的部分拉到這個分支下
2）如果登入使用者的角色為NORMAL，則是新增的使用者沒有許可權建立使用者的測試
3.5 建立無許可權建立使用者測試請求
注意請求引數要合法（包括使用者名稱不要重複），排除掉因為引數錯誤引起的請求錯誤。
3.6 新增斷言
使用者沒有許可權時，響應碼應該是403，返回資訊是{“errorMsg”:”不允許訪問”}，並在資料庫中查詢，不應該存在該名字的使用者
3.7 試執行指令碼
從圖中可以看到，登入的使用者為normal，而他的角色是NORMAL
當登入使用者的角色為NORMAL時，建立使用者失敗，返回不允許訪問的錯誤資訊
4 使用者未登入不能建立使用者
只要伺服器沒有接收到user session，都會認為使用者未登入。在本例子中，user session是存放在cookie中，所以只要讓建立使用者的請求位於jmeter的HTTP Cookie 管理器作用域外，就可模擬使用者未登入的場景。比如將前面的指令碼全部歸放到一個簡單控制器下，再新起一個簡單控制器來測試使用者未登入場景，或者也可以新建一個執行緒組來測試使用者未登入場景
這裡使用新建一個執行緒組的方式來測試使用者未登入的場景
先分析下介面行為，使用者未登入的情況下，直接傳送建立使用者請求，系統會重定向到登入頁面
4.1 新增一個執行緒組
並將原來的執行緒組重新命名為使用者已登入測試，用以區分新增的未登入測試執行緒組
4.2新增建立使用者請求
注意請求引數要合法
4.3 新增斷言
未登入的情況下發送建立使用者請求，系統會重定向到登入頁，這在jmeter表現為會產生2個對應的子請求。
- 響應斷言判斷重定向後的URL
- BeanShell斷言判斷重定向資訊
4.4試執行指令碼
察看結果樹中，可以清楚看到未登入情況下被重定向到了登入頁
（注，這裡我沒有再做資料庫資料判斷，如果需要的話，與前面使用者沒有許可權的驗證過程是一樣的，未登入情況下應該不能建立新使用者）
