您好,登錄后才能下訂單哦!
性能測試 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開始重新錄制;
錄制時要慢,等待頁面資源下載完畢后再進行下一步操作。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。