LR11-效能測試基本概念-策略
效能測試 LoadRunner11
一、效能測試基本概念(術語)
1、併發 Concurrency
線上 Online
並行:多個任務佔據各自資源,一起執行
併發:多個任務佔據同一資源,一起執行,需要爭搶資源
1)、併發和線上的區別: 併發的壓力是一個瞬時壓力,一般針對同一型別的業務。 線上的壓力是一段時間內的壓力情況。 2)、20使用者併發的壓力相當於200使用者線上的壓力。(1:10的比例) 寫測試計劃時,可以參考,比如2000使用者線上,一般是200個使用者併發。 (併發登入、併發查詢、併發刪除等) 2、請求響應時間(TTLB,Time to last byte)=客戶端時間+網路時間+伺服器時間 單位,一般是秒/毫秒 可以通過內網測試規避掉網路的問題,客戶端一般不會成為效能的瓶頸, 所以大部分情況下,如果請求響應時間長,效能瓶頸出現在伺服器端。 建議:Web伺服器和資料庫伺服器最好分開部署,可以分別監控 3、事務響應時間:前提是在錄製指令碼時,插入事務點 4、吞吐量(TP):Throuthput 是總量,是累計時間的全部資料量, 使用者在任意給定1秒從伺服器獲得的全部資料量,單位,位元組 吞吐率(TPS):在單位時間內的吞吐量 吞吐量/傳輸時間 每秒 TPS: Transaction Per Second 每秒事務數(事務數/秒) 點選率:每秒鐘使用者向Web伺服器提交的Http請求數。 不是指滑鼠點選的次數,比如:點選一個按鈕,伺服器返回一個頁面,頁面中包括了3個圖片, 則當前發起的點選數:1+3 = 4個Http請求。 *.html 帶有<img src="" /> 每個圖片都是一個資源.都會重新發請求 吞吐率和點選率區別: 吞吐率:伺服器每秒處理的資料量 點選率:客戶端每秒向伺服器提交的HTTP請求數 5、請求和響應: 客戶端向伺服器發起請求(Request), 伺服器向客戶端返回應答(響應 Response)。 6、資源利用率:一般指系統中CPU、記憶體、磁碟、網路等主要資源的使用情況。(瞭解,有難度)
案例:測試登入模組在8個使用者的情況下系統的效能情況
要求:使用者數:8人 VU
使用者載入方式:每2秒載入1個VU
執行時間:所有使用者執行完指令碼
登入使用者名稱:jojo
密碼:bean
操作:
1)錄製好指令碼 login day02/login
->點選New圖示 -> New Virtual User -> 預設協議
-> Create 準備錄製
-> 填寫基本資訊:
選擇軟體架構:Internet Applications (B/S) 預設
Win32 Applications (C/S)
選擇瀏覽器型別:預設IE
URL Address: 被測系統的網址
http://127.0.0.1:1080/WebTours/
或http://localhost:1080/WebTours/
Working directory: LR工作路徑 預設 常用工具命令
Record into Action: 錄製指令碼的位置 預設Action
(vuser_init 初始化 Action vuser_end 結束)
-> OK 自動開啟瀏覽器 AUT,開始錄製
關注小操作條 (錄製控制 關注數字變化,數字穩定才繼續)
-> 輸入jojo bean
-> 開始事務 名稱login (插入事務) -> OK
-> Login按鈕
-> 結束事務 login -> OK
-> 改為vuser_end模式,點選Sign Off 退出
-> 關閉瀏覽器 -> 點選藍色按鈕 Stop 結束錄製
-> 儲存到新建立的day02/login資料夾中,指令碼名:login
2)開啟控制檯Controller,使用login指令碼,配置場景
開啟Controller -> 預設手工場景模式 ->
將Use the Percentage Mode to... 去掉打鉤
目的:使用者數不使用百分比模式
-> Browse按鈕 選擇指令碼 login -> OK
提示:如果指令碼選錯了,可以在後續主介面中修改
-> 設定8個VU: Run Mode: 選擇Basic schedule
將Quantity 改為 8
-> 每2秒鐘載入一個VU: 左下角視窗 Global Schedule
-> Start vusers: Start all Vusers simultaneously
預設是 同時載入8個虛擬使用者,需要更改
-> 雙擊Start vusers -> Edit Action
-> 選擇第2個單選鈕,改為 1 Vusers every 00:00:02
(HH:MM:SS)
-> OK
-> Schedule Graphics 計劃預覽圖
橫座標:Time 測試時間 縱座標:Vusers 虛擬使用者個數
每隔2秒鐘載入一個虛擬使用者
虛線表示 不確定
-> 設定執行時間: -> Duration中
Run until completion 執行直到結束 (指令碼結束) 選擇
Run for __ days and ___ (HH:MM:SS) 固定時間多久
Run indefinitely 不限定 無限制執行,測試者點選結束才結束
-》正常測試,還需要設定Windows Resources 監控的系統資源
(暫時不配置)
-> 切換到Run介面(執行場景)
(之前是Design 設定場景)
-> 設定好場景,可以執行場景
-> Start Scenario 按鈕
點選Vusers按鈕,進一步檢視VU執行狀態:
Done. Passed 1 iteration(s) attemped: 1successed.
結束 經過 1次迭代嘗試1次成功了
觀察場景執行結果圖:
Running Vusers 正在執行的虛擬使用者
Hit per Second 點選率
Throughput 吞吐量
點選正上方,右邊倒數第3個圖示按鈕:
檢視 Hp LoadRunner Analysis 結果分析報告
Reports 報告
Graphs 圖片
Running Vusers 虛擬使用者執行情況
Hit per Second 點選率
Throughput 吞吐量
Transaction Summary 事務概要
Average Transaction Response Time 平均事務響應時間
二、效能測試策略
重要的:
基準測試(單使用者)、併發測試、綜合場景測試 (前3個專案必備)
極限測試、遞增測試
次要的:
疲勞強度測試(大型系統中)、記憶體洩露測試、
資料容量測試。
共同點:向被測系統發起***
1、基準測試:就是單使用者測試 (重點)
注意:還是需要使用控制檯,執行場景,自動蒐集資料,通過Analysis進行結果分析。
2、併發測試:多使用者併發執行某一操作(同一時刻,LR精確到毫秒級別)。
注意:併發測試是一種嚴格的測試,主要考察系統對瞬時較大壓力的承受能力。
3、綜合場景測試:號稱“能夠最真實的模擬 實際生產環境”。
綜合場景的幾個要素:
多使用者、
多個指令碼(至少3個,就是做多個不同的任務)、
線上執行一段時間(1個小時、50分鐘等)
注意:一般不需要設定併發點。
多使用者一起執行,一定會有併發。
綜合場景測試過程中,所有使用者 迴圈 執行相應的操作。
比如:100使用者線上綜合場景
100使用者 共同對被測系統執行操作,
其中30使用者執行瀏覽首頁操作,
50使用者執行查詢訂單操作,
20使用者執行提交訂單操作。
(要真實模擬人數比例)
問題:為什麼不模擬大量的登入操作?
因為使用者不可能一直在登入,模擬真實情況。
以上操作,使用者在迴圈執行。
響應時間:業內一般有“358原則”,
系統響應時間在3秒以內,則使用者能夠接受;
響應時間在5秒以內,使用者能夠忍受;
響應時間超過8秒,使用者不能忍受。
比如:一般需求指標,不超過3秒
4、遞增測試:每隔一定的時間(1s,5s,10s)逐步載入虛擬使用者,逐步加壓。
用途:登入測試時,可以遞增測試
極限測試:使用併發測試、線上測試等方法,測試出系統能夠承受的極限壓力(如最大使用者數),
或系統能夠達到的最大處理能力(如最大吞吐量)。
測試方法可以採用遞增測試,比如對系統進行100使用者、500使用者、1000使用者等測試。
(也稱為:摸高測試)
5、疲勞強度測試:在一定的強度(壓力)下,對系統進行長時間的效能測試,
一般為724小時、或24小時、12小時等。
比如:銀行系統,724*365 全天候不間斷執行
考察疲勞強度測試時,要考察其平均響應時間,以及各臺伺服器的各項資源情況。
比如:叢集 負載均衡、降低成本
以上是比較常見的測試型別,經常出現在測試計劃中。
6、記憶體洩露測試:
通過正常的效能測試,如果被測系統的記憶體曲線走勢不正常,則關注其相應的各項重要的記憶體指標,
通過對應走勢來確定是否發生記憶體洩露。
7、資料容量測試:使用大容量的資料新增到資料庫中,觀察被測系統是否能夠正常執行。
比如:向資料庫中新增200G的資料量,再進行測試。甚至幾個T
大資料 Big Data 一般是T級、P級的資料量
1024Byte = 1KB
1024K = 1M
1024M = 1G
1024G = 1T
1024T = 1P
E Z Y
三、基準測試:單使用者測試
1、測試指令碼要加檢查點。
原因:LR報告中的驗證只是針對網路層面上,伺服器收到客戶端傳送的資料包,之後將應答包發回給客戶端,
但是LR不會驗證應答包中資料是否正確。
案例1:對下訂單操作進行基準測試。先錄製指令碼,插入檢查點。
先開啟AUT,熟悉整個業務流程;
開啟VuGen -> 新建 輸入URL -> 先錄製登入
-> vuser_init -> 輸入jojo和bean -> 開始事務 login
-> 點選Login -> 歡迎頁面:
新增檢查點:
選中“Welcome, jojo” 點選Insert text check 插入文字檢查點
-> 結束事務login
-> Action模式 -> 點選Flights
-> 選擇城市:從Denver 到 London
-> Continue -> Continue
-> 開始事務buy -> Continue -> 訂單結果頁面
新增檢查點:
選中“Denver for London” 插入文字檢查點
-> 結束事務buy
-> vuser_end模式 -> Sign Off -> 關閉瀏覽器 -> Stop
指令碼儲存:day02\buy 再回放
web_reg_find("Text=Welcome, <b>jojo,",LAST);
web_reg_find("Text=Denver for London",LAST);
檢查點函式:web_reg_find() web_或lr_開頭
reg字樣的函式:註冊性函式
web_submit_form() 提交表單的請求
對於B/S系統,LR指令碼中的LR函式都是以lr_或web_開頭。
(另外,還有C語言函式 strcmp)
web_reg_find函式,帶有reg字樣的函式稱為:註冊性函式
該類函式的特殊:必須寫在相應請求之前。
加過檢查點的指令碼如果執行(回放)正確,則說明該指令碼正確。
(學會除錯指令碼)
需求:迴圈訂3張票
VuGen中的Run-time Settings按鈕 (執行時設定)
Run Logic 執行邏輯 -> Iteration Count 迭代次數 預設1 改為3
注意:迴圈的只是Action. 次數登入僅一次
init和end指令碼僅執行一次。
注意:
1、控制檯中和VuGen中設定Run-time Settings當前區別和聯絡:
1)如果從控制檯直接開啟指令碼,則指令碼中Run-time Settings設定會自動顯示在控制檯的Run-time Settings中。(帶過來)
2)如果控制檯和指令碼中同時設定了Run-time Settings,並且值不同,控制檯的優先順序高。
2、Pacing值:每次迭代之間的時間間隔。
迭代:指令碼Action從第一行到最後一行。迭代一次
Pacing值越大,對AUT的壓力越小。
3、Think time: 指令碼中步驟之間的時間間隔。
(請求之間的間隔)
案例:針對buy指令碼,進行基準測試 (方法1:單使用者迴圈5次)
開啟VUG錄製指令碼
1)除錯好指令碼(在VuGen中執行成功)
儲存指令碼檔案:scrip/day02/buy1
開啟Controller,設定場景
2)開啟控制檯,載入buy指令碼
首先設定人數: Run Mode 單選Basic schedule模式
Quantity改為1 單使用者模式
3)開啟控制檯Run-time Settings設定
Run Logic 迭代次數 5 (優先使用)
Pacing值 -- Start new Iteration 建議設定隨機2~3秒
As soon as the previous interation ends 只要前一次迭代結束
關注第3項:
At fixed intervals, every 60.000 sec
random every 2.000 to 3.000 sec
fixed: 固定的
intervals 間隔
random: 隨機的
Think time:
Ignore think time 忽略思考時間 選擇 為了簡單化
Replay think time 具體設定思考時間策略
-> 點選OK
6) Global Schedule設定
Initialize:初始化 Vuser在Run之前先初始化(保持預設)
Start Vusers: Start all Vusers simulaneously
就一個VU 預設
Duration: Run until completion 執行直到結束 預設
-> 切換到Run
開始執行場景: Start Scenario
6)結果分析
分析結果圖:Running Vusers
橫軸:Elapsed Time 測試時間
縱軸:# of Vusers 虛擬使用者數量
點選啟動後,場景初始化需要時間,無需關注
分析結果圖:Hits per Second 點選率(每秒點選量)
橫軸:Elapsed Time 測試時間
縱軸:# Hits per Second 點選率
資料偏低,因為是單使用者
分析結果圖:Throughput 吞吐量(伺服器處理過的資料)
橫軸:Elapsed Time 測試時間
縱軸:# Bytes/sec
由於時間不長,規律無法體現
儲存場景檔案:ctl/day02/buy1
開啟Anlysis:倒數第3個圖形按鈕
最關心的是:事務響應時間
Transcation Name Average 平均事務響應時間
buy 0.23 合理的
login 0.406 合理的
細節可以關注左上角列表:各種常用指標圖表
(先了解,後續會專門講解)
儲存結果檔案:result/day02/buy1
2.歸納 基準測試:
方法1:單使用者迴圈5次
1)除錯好指令碼(加檢查點,在VuGen中執行成功)
2)開啟控制檯,設定Run-time Settings
3)迭代次數:5
4)Pacing值:隨機2~3 (每次迭代之間的時間間隔)
5)Think time: 忽略 (請求之間的時間間隔)
忽略的原因:單使用者對系統壓力較小,忽略與否對結果影響不大。
方法2:單使用者持續執行1分鐘
1)除錯好指令碼(加檢查點,在VuGen中執行成功)
2)開啟控制檯,設定Run-time Settings
3)Pacing值:隨機2~3
4)Think time: 忽略
5)Duration: 1分鐘
提示:配置好後,觀察圖表狀態,有所變動,才修改成功。
3、注意點:
當Run-time Settings中迭代和VU部署設定(Duration)有衝突時,Duration的優先順序較高。
比如:Duration選擇第二項,就以此為準
Run for __ days and __ (HH:MM:SS)
如果選擇第一項:Run until completion 還是聽Duration
只是它放權了。Duration是一把手,讓二把手看著辦,此時Run-time Settings說的算。
Duration:指Run的Action時間
測試報告中的結果,應該測試三次,取中間值。
(如:0.1秒 0.3秒 0.4秒 結果取0.3秒)
以上就是基準測試。
簡答題:
2、基準測試、併發測試的概念和做法?
1)基準測試就是單使用者測試,需要開啟控制檯,獲取Analysis中的結果。
(方法1:單使用者迴圈n次;方法2:單使用者執行n時間)
2)併發測試是多使用者執行某一操作,形成瞬時壓力(精確到毫秒),是一種嚴格的測試,
主要考察系統對瞬時較大壓力的承受能力。
3、併發測試和線上測試的區別?
1)併發和線上的區別:
併發的壓力是一種瞬時壓力,
線上的壓力是一段時間的壓力。
2)20使用者併發的壓力相當於200使用者線上的壓力。(1:10比例)
在寫測試計劃時作為參考依據。2000使用者線上,設計為200使用者併發。
(併發操作:查詢、登入、刪除、新增)
4、吞吐量和點選率的概念、區別?
1)吞吐量(Throughput):使用者從伺服器端獲得全部資料量,單位是位元組(Byte)。
2)吞吐量/傳輸時間,就是吞吐率,是伺服器每秒處理的資料量。
3)點選率(Hits per Second):客戶端每秒向伺服器提交Http請求數。
(滑鼠的一次點選,請求數可能為n個)
說明:吞吐量是總量,是累計時間內全部資料量。
吞吐率反映伺服器的處理速度和效能,也是衡量網路效能的重要指標。
點選率越大,對伺服器的壓力也越大。
Files/Doc.zip
指令碼中如何加註釋
1)單行註釋 //
2)多行註釋 / /
一、昨天作業題:
1、思考:QTP和LoadRunner的區別。
1)QTP: 功能測試工具 (自動化)
LR: 效能測試工具 可以測多使用者
2)QTP關心的是介面(UI),關心的是物件(物件庫的概念);
LR只關心客戶端和伺服器之間的資料包(請求包、應答包),
不關心物件,更不需要比對物件的屬性值,只關心抓包(捕捉資料包)。
如果使用者介面變了,但是業務邏輯不變:QTP指令碼需要變化,LR指令碼不需改變。
3)LR關心的是客戶端和伺服器之間的對話,前提是選擇正確的網路協議(相當於網路的語言)
4)LR不能補錄。錄製失敗,從頭再來。
注意:錄製過程中出現失誤,該次錄製作廢,從New開始重新錄製;
錄製時要慢,等待頁面資源下載完畢後再進行下一步操作。