淺析Jmeter多用戶token使用問題
背景
在測試的時候,經常會有模擬用戶登錄,拿到用戶 token 後再去請求接口的場景。
這個模擬用戶登錄就會分為兩種,一種是單用戶,另一種是多用戶。
日常自動化測試的時候可能一個用戶對應 n 個用例就可以滿足大多數場景;
如果是在壓力測試的場景下面,可能就會略顯單調,也無法滿足一些真實業務場景。
對於單用戶的情況下,和我們常規的多接口有依賴的測試其實沒什麼太大的差別。
所以這裡主要講的是多用戶產生多個 token 的情況。
下面來看一個具體的例子來瞭解一下。
場景接口
在這裡的話,隻有兩個接口,一個是登錄拿 token,一個是有 token 才能請求的。
下面是各接口定義
登錄接口
請求:
POST http://localhost:8532/MultiToken/Login Content-Type: application/json { "UserName":"catcherwong-1", "Password":"123" }
響應:
{"code":0,"msg":"ok","data":"catcherwong-1-token"}
業務接口
請求:
GET http://localhost:8532//MultiToken/do?account=xxx Content-Type: application/json token: catcherwong-1-token
響應:
{"code":0,"msg":"ok","data":"catcherwong-1-token"}
登錄接口處理
登錄接口屬於預請求,所以我們一般會選擇把它放在 setUp 線程組裡面。
我們需要準備一個 csv 文件,裡面用來存放需要登錄的用戶名和密碼。
接下來就是把這個 csv 配置好,定義瞭兩個變量 account
和 pwd
然後是把登錄的 HTTP 請求配置好:
由於後面要用到 token,所以要先把 token 提取出來,這裡用的是 JSON Extractor。
到這裡就要開始註意瞭!!!!
由於我們會有多個用戶進行登錄,但是這一個提取操作每次都會把 token 賦值到 access_token 這個變量上面,是覆蓋的操作。
換句話就是說,每登錄一個用戶,這個 access_token 的值就會是最後一個登錄的用戶的 token,。
換個思路,每次它會覆蓋,那麼把這些 token 存到一個地方,然後業務接口去這個地方取就可以瞭。
如果沒有用戶登錄這一步,給的直接是 token,那麼我們也是直接把這個 token 放到 csv 文件裡面,然後讓 jmeter 去循環使用裡面的 token。
那麼要做的東西其實就很確定瞭,就是在提取到 token 後,把這個 token 寫到一個 csv 文件裡面。
要想做到這一步,需要在登錄接口後面加一個後置的處理。
String p1 = System.getProperty("user.dir"); String p2 = System.getProperty("file.separator"); String p3 = "user_token.csv"; String path = p1 + p2 + p3; FileWriter fileWriter = new FileWriter(new File(path), true); BufferedWriter writer = new BufferedWriter(fileWriter); writer.append(vars.get("accout")+","+vars.get("access_token")+"\n"); writer.close(); fileWriter.close();
這段代碼的意思是,把用戶名和提取到的 access_token 寫進到 csv 文件裡面,這個文件在的位置是 jmeter 的目錄。
這裡是對文件路徑做瞭處理,可以適配所有操作系統的。不會出現說指定瞭一個 windows 系統的路徑,然後放到 linux 系統下面就跑不瞭瞭。
還有最重要的一個是,要修改 setUp 線程組的屬性,把循環次數改成 3 。因為前面的 csv 文件裡面有 3 個用戶,這樣它才會觸發三次登錄。
業務接口處理
業務接口要放到正常的線程組裡面,獨立於 setUp 線程組。
前面提到,登錄後會有一個 csv 文件,所以這裡第一個要做的是把 csv 配置好。
上面的截圖用的是 ${__P(user.dir,)}${__P(file.separator,)}user_token.csv
這個文件路徑,這個在本地環境的 Jmeter 是可以通過的,不過在一些雲服務上面是不行的,如阿裡雲 PTS 。
這裡可以忽略前面的路徑,直接填寫 user_token.csv
即可,填這兩個,得到的文件路徑是一樣的,一個是絕對路徑一個是相對路徑。
然後就是配置 HTTP 請求瞭
PS:不要忘記把請求頭也配置瞭,這裡就不截圖瞭。
這裡試跑兩次,可以發現業務請求的接口,它的 token 請求頭每次都是不一樣的,在交替變化,這個是符合預期的。
但是會發現生成 csv 文件裡面的數據會重復,沒有自動清理掉上一次產生的數據。如果上一次產生的 token 過期瞭,那麼用瞭這些過期的 token === 涼涼。
所以這裡還有必要加一步 tearDown 線程組,每次跑完腳本把這個文件刪除掉。
String p1 = System.getProperty("user.dir"); String p2 = System.getProperty("file.separator"); String p3 = "user_token.csv"; String path = p1 + p2 + p3; log.info("準備刪除文件:" + path); File file = new File(path); if (!file.exists()) { log.info("刪除文件失敗:" + path + "不存在!"); } else { file.delete(); }
這個時候跑腳本就基本沒什麼問題瞭。
寫在最後
多用戶獲取多 token 再使用的場景其實挺多的,這篇內容簡單講解瞭老黃正在用的一個方案,如果您有更好的建議,也歡迎一起溝通交流。
老黃把 JMeter 系列的內容都放在 github 瞭,方便大傢查閱和測試。
https://github.com/catcherwong/JmeterSample
到此這篇關於聊一聊Jmeter多用戶token使用問題的文章就介紹到這瞭,更多相關Jmeter多用戶token使用內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!
推薦閱讀:
- jmeter實現接口關聯的兩種方式(正則表達式提取器和json提取器)
- jmeter執行python腳本的實現示例
- 詳解Jmeter中的BeanShell腳本
- PHP中token的生成案例
- 使用springcloud+oauth2攜帶token去請求其他服務