Now you can know everything in the world, but the only way you're findin' out that one is by givin' it a shot.
你可以了解世間萬物,但追根溯源的唯一途徑便是親身嘗試。
電影《心靈捕手》
測試用例描述:
性能測試要求:5個用戶循環2次。
用例名稱 | 操作步驟 | 預期結果 | 備注 |
新建項目並設置團隊時統計項目總工時 | 1、 進入項目視圖,點擊右側的”添加項目“鏈接。 | 系統會自動計算這個項目總的可用工時。 | |
2、 出現項目添加的頁面,添加一個新項目並保存 項目名稱為: Test_Project_01 項目編號為: TP_01 項目時間為2016-01-01~2016-01-31 團隊名稱:TestTeam 關聯產品:禪道管理系統 項目描述為:“測試組合模塊之間的功能、性能” |
|||
3、 在保存后彈出的對話框中,選擇“設置團隊” | |||
4、 為該項目設置5個測試人員,不包括“管理員” |
這個測試用例僅僅是舉例,實際測試設計工作中此類一般應用軟件的類似功能是不涉及如此復雜的並發性能測試的,有興趣的可以參考性能測試設計相關知識。
第一步: 創建測試計划
第二步: 創建線程組(調試過程中將用戶數和循環次數均設置為1)
線程組說明:
域Ramp-Up Period:這個屬性表示每個用戶啟動的遲延時間。例如,如果你輸入Ramp-Up Period為5秒,JMeter將會在5秒結束前完成啟動所有的用戶。所以,如果你有五個用戶並且Ramp-Up Period為五秒,那么開始用戶的延遲就是1秒。(5個用戶 / 5秒 = 1 用戶每秒)。如果你設置其值為0,JMeter將會立即啟動你所有的用戶。
域Loop Count:這個屬性表示你的測試的重復次數。如果你設置為1,JMeter將你的測試只運行一次。要讓JMeter不斷的運行,你要選擇"永遠"這個復選框。
第三步: 添加HTTP請求默認值
所有的HTTP請求都將發送到相同的Web服務器127.0.0.1。向這個域中輸入這個域名,這是唯一一個需要我們去修改它的默認值的文本域,其它的文本域都保留它們的默認值。
注意: HTTP請求默認值元件並不告訴JMeter來發送HTTP請求,它僅僅定義這個HTTP請求所用的默認值。
第四步: 添加HTTP cookie
除非你的應用程序明確的不使用Cookies,幾乎所有的網站應用程序都會使用cookie支持。要添加cookie支持,可以簡單的在你的測試計划中給每一個線程組添加一 HTTP Cookie管理器。這樣確保每個線程組有自己的cookies,但是共享跨越所有的HTTP請求對象。添加 HTTP Cookie管理器,簡單地選擇這個線程組,選擇添加-->配置元件-->HTTP Cookie管理器,也可以從編輯菜單或通過右鍵點擊來實現添加。
第五步: 添加設置HTTP代理服務器
第六步: 錄制腳本
第七步: 回放腳本
以上5~7步如有清楚可以參考上一篇文章《使用JMeter錄制腳本並調試》
第八步: 優化腳本(參數化關鍵字段)
1、明確哪些變量(字段)需要參數化
從回放結果中看到“項目名稱”、“項目代號”重復了,導致回放失敗,接下來就對這兩個字段進行參數化
2、點擊JMeter菜單欄的“選項”-“函數助手”,彈出函數助手設置框。
a. 選擇一個功能:“_CSVRead”
b. CSV文件路徑: 選擇存放CSV文件的路徑
c. CSV文件序列號: 從0開始
CSV文件格式如下, 參數的值之間使用逗號分隔,第1列"Test_Project_0X"對應上圖中的序列號為0, 第2列為1。
d. 點擊“生成”按鈕,復制生成的字符串。
e. 找到對應的HTTP請求,用生成的字符串替換原HTTP請求中的值
3、1個用戶循環1次,再次回放腳本並查看回放結果, 腳本回放通過。
第九步: 執行並發測試
設置線程組的用戶數為5, 循環次數為2, 執行並發測試。
注意:
1. CSV文件中使用過的第一行的值,不能再被使用, 執行並發測試之前應該刪除該行的值。
2. 5個用戶循環2次,總共執行10次,參數值的數量需要滿足10次測試使用。
第十步: 通過監聽器查看測試結果。
summary report 摘要報告
摘要報告在測試中為每個不同命名的請求創建表行。這類似於聚合報表,但它使用的內存較少。
aggregate graph 聚合圖
聚合圖類似於聚合報表。主要的區別是聚合圖提供了一個簡單的方法來生成條形圖,並保存為PNG文件的圖形。
圖形結果
圖形結果監聽器生成一個簡單的圖,繪制所有采樣時間。沿着圖的底部,當前樣本(黑色),當前所有樣品的平均值(藍色),當前標准偏差(紅色),當前吞吐量率(綠色)以毫秒為單位顯示。
“吞吐量”表示服務器處理的請求/分鍾的實際數目,包括實際測試事務和JMeter自己的內部處理時間。這個數字代表服務器每分種處理請求的真實值,可以增通過加線程數和/或減少延遲,以發現服務器的最大吞吐量。