效能測試 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開始重新錄製；
錄製時要慢，等待頁面資源下載完畢後再進行下一步操作。