性能測試 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/buy12.歸納 基準測試：
方法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開始重新錄製；
錄製時要慢，等待頁面資源下載完畢後再進行下一步操作。