聊一聊Jmeter的參數化
背景
前面一篇講了 JMeter 的一個最簡單的例子，這篇聊一下 JMeter 的參數化。
在開始之前先來一個單元測試的例子，感受一下參數化。
上面是一個用 xUnit 寫的單元測試，這個單元測試就是一個參數化的例子：
模擬了不同的輸入，調用同一個方法，得到了不同的輸出。
對某一個場景，要驗證不同的輸入得到不同的輸出是非常有用的。
在 JMeter 裡面就可以通過參數化來實現這個效果。
JMeter 的參數化有很多種方法，本文主要是介紹基於 CSV Data Set Config 的參數化。
在這篇文章裡面，會通過一個簡單的場景來了解 JMeter 參數化的使用，以及自定義 jar 包的使用。
場景
這裡用一個大家最熟悉的登錄場景做為例子。
登錄最重要的就是用戶名和密碼這兩個內容，這裡會有兩種結果，登錄成功和登錄失敗。
在這個場景下，假設我們的介面定義是這樣的
POST //localhost:8532/run?sign=sssss&appkey=aaaaa
Content-Type: application/json
{
"userName":"catcherwong",
"password":"xxxxx"
}
- sign 的值是簽名，用來驗證參數是否被修改，這裡是不校驗的，所以隨便生成一個隨機數就可以了。
- appKey 是定義的另一個參數，這裡也不做校驗的，也是隨機定義即可。
這個介面，會有兩種返回
登錄失敗的， code 會是 1， msg就是錯誤資訊。
{"code":1,"msg":"用戶名或密碼錯誤"}
登錄成功的， code 會是 0。
{"code":0,"msg":"ok","data":{"token":"626b97f78d794f4da927bc09ae6be245"}}
針對這個場景，簡單起見，只考慮 code 的值來判斷登錄是否成功。
準備數據
場景有了，介面也有了，再下一步就是準備要用的數據了。
這裡是用 CSV 文件來做為數據源，所以我們把介面要用到的參數放進去。
準備了20條數據，第一列是用戶名，第二列是密碼，第三列是appkey，第四列是結果，表明用前面三列數據去調用登錄介面，應該成功還是失敗。
然後在執行緒組裡面添加一個 CSV 的配置原件。
在裡面最主要的配置是 文件路徑和變數名。
文件路徑沒什麼好說的，就是 csv 文件所在的具體路徑。
可以看到上面的 csv 文件，我們是沒有定義頭部的，放的直接是數據，所以每一列數據代表什麼需要有一個標識。
這裡的變數名可以認為就是給準備的每一列數據起個別名，便於後面的使用，示例這裡是有4個的，每一個都是用英文逗號隔開。
配置HTTP請求
其中 name, pwd 和 appKey 這三個變數是前面已經定義好了的，所以這裡可以直接用 ${xx} 的方式去使用。
sign 這個參數是沒有定義的，所以要加一個 BeanShell PreProcessor 來處理一下。
到這裡，請求已經配置好了，下面就是要判斷登錄是不是成功的了。
斷言
斷言這裡是要判斷返回的 JSON 結構裡面的 code 值是不是和 csv 文件裡面定義的一樣。
所以這裡選擇的還是 JSON Assertion 。
要把期望值調整成變數名，這樣它才會根據不同的入參判斷不同的結果，上圖的例子是 ${login_res}
添加結果樹，調整執行緒組的循環次數為20，再運行這個執行緒組，就可以看到對應的結果了。
可以看到的是，20條數據都跑了一次，所有的用例都是可以過的。
但是這裡有一個問題，密碼是明文傳輸的！！！
這個是大忌，絕對不允許的，正常都會加密或哈希之後再傳輸。所以這裡要做一個優化。
也就引入了，自定義 jar 包的使用。
自定義jar包調整
首先我們需要寫一些 JAVA 程式碼來編譯成一個 jar 包。
這裡老黃是直接寫好了，直接用就可以了。
調整一下 BeanShell PreProcessor ，如下圖所示：
首先是先引入自定義 jar 包，其次是從 vars 裡面拿到明文密碼，然後是調用 jar 包裡面的 getPwd 的方法對密碼進行處理，最後再把處理好之後的密碼放到一個新變數 ePwd 裡面。
由於之前的 sign 參數是寫死的123，這裡也改成調用 jar 包裡面的 getSign 方法來生成。
由於密碼參數換了一個變數，所以要調整一下 HTTP 請求。
最後再次運行，可以看到 密碼不再是明文了，sign值也不再是固定的了。
自定義的 jar 包，記得要在測試計劃裡面添加一下！
寫在最後
參數化是一個很有用的功能，可以讓我們的參數動起來。
