1、如何進行性能測試？ 先整體，后局部
1）分析需求（功能需求-業務邏輯、性能需求-性能指標）
常用指標：平均事務響應時間、
TPS Transaction Per Second每秒事務數、
最大並發用戶數、系統資源特性...
2）制定性能測試計划 - 測試經理
主要考慮：測試范圍、人員分配、時間進度、用例設計
測試策略：基准測試、並發測試、在線綜合場景測試...
3）執行計划，使用LoadRunner，結合三大組件：
<1> VuGen: 根據協議錄制和調試腳本，模擬1VU運行腳本
設置Run-time Settings 運行時設置
腳本增強技術：事務（平均事務響應時間、TPS）、檢查點、集合點、參數化、關聯...
<2> Controller: 設置、運行和監控場景，自動獲取測試結果數據；
a. 場景模式：手工場景、共享設置、不使用百分比分配VU
b. 腳本組：組名、腳本路徑、VU數量、...
c. VU的行為：初始化、加載方式、持續時間...
d. 設置Run-time Settings： 運行時設置
e. 系統資源監控
<3> Analysis: 對測試結果以各種圖表形式展示，便於性能分析，獲得性能測試報告。
一、性能測試的策略
重要的：基准測試、並發測試、在線綜合場景測試
遞增測試、極限測試...
1、基准測試：Benchmark Testing
含義：就是單用戶測試，單用戶、單測試點、執行n次；
作為后續測試的標桿，基本的准繩。
說明：還需要使用三大組件，VuGen 腳本-> Controller 場景 -> Analysis 結果
2、遞增測試：不斷加壓，負載測試、壓力測試的共性。
比如：每隔一定時間（1s, 5s, 10s ..）逐步加載VU，逐步加壓；或在不同場景中使用不同VU數表示不同的壓力。
3、並發測試：Concurrency Testing
含義：多用戶在幾乎同一時刻執行某一業務操作，形成一種嚴格的並發訪問（LR精確到毫秒級別），觀察系統在瞬時較大壓力情況下的承受能力。
4、在線綜合場景測試：號稱“更真實模擬實際生產環境”
也稱為：混合交易測試
交易也叫事務Tranasction
三個要素：
1）多用戶：結合需求考慮在線用戶數
2）多任務（腳本）：至少3個
3）在線執行一段時間：1個小時左右
注意：
1）多用戶一起運行，就可能存在並發；
但是，不需要像並發測試那樣設置集合點，不需要嚴格的刻意並發。
2）綜合場景測試過程中，所有VU循環執行相應的業務操作。
舉例：100用戶在線綜合場景
100VU共同對被測系統SUT執行各自操作，其中50VU查詢商品、30VU添加購物車、20VU查詢訂單，在線持續運行1h.
問題：為什么不模擬大量的登錄操作？
業務用戶不可能一直在登錄，要模擬真實的用戶體驗。
996 247
5、疲勞強度測試：壓力更大、時間更長的在線綜合場景測試。比如：對SUT進行長時間測試，一般12h、24h、7*24h
銀行、互聯網系統要求全年7*24不間斷運行
要求：穩定*、安全
目的：檢測系統的穩定性，比如長時間運行過程中是否出現內存泄露、磁盤空間不足、大量異常等問題。
6、內存泄露檢查：通過正常的性能測試，如果SUT的內存曲線走勢不正常時，則關注其他相關指標，通過其走勢判斷是否出現內存泄露。（了解）
內存泄露：C/C++/Java都存在，就是內存不夠用。
以Java為例：JVM內存 棧區、堆區、方法區
Student s1 = new Student();
引用 --> 對象 在堆區分配
(對象的內存地址)
對象不斷分配而未及時回收，導致堆內存空間不足，內存泄露。Java雖然有GC機制（內存對象垃圾收集機制-自動），但是也可能存在內存泄露問題。
7、數據容量測試：大數據量測試
比如：向數據庫中添加200GB的數據量，再進行測試，有時甚至是幾個TB.
大數據：Big Data 一般是T級、P級以上的數據量
核心：數據建模、數據挖掘 商業分析
根據以往的交易數據分析出未來的趨勢，為商業決策提供重要依據。
1024Byte = 1KB
1024K = 1M
1024M = 1G
1024G = 1T
1024T = 1P
E Z Y ...
面試題：如何向數據庫中插入大量的數據？比如插入10億條
思路：SQL insert into 表名 values(值1, ...);
自動化：循環 反復執行insert
變量、參數化 代替固定的字面值
數據庫可以寫過程化語句，結合sql編程。
8、極限測試：也稱為壓力測試、摸高測試
含義：使用並發測試、在線綜合場景測試等方法，測試出系統能夠承受的極限壓力（如最大並發用戶數）或系統能達到的最大處理能力（最大吞吐量、TPS），可以采用遞增測試等方法，比如對系統進行100VU、200VU、300VU...的性能測試。
二、基准測試：單用戶、單測試點、執行n次/一段時間；
1、需求：對購票操作進行基准測試。
2、測試腳本中要加檢查點。
原因：LR報告中（Test Results）驗證的只是針對網絡層面，服務器收到客戶端的請求包，並將應答包返回給客戶端，但是LR默認不會驗證應答包中的數據是否正確。
性能測試的前提是功能的實現，如果誤以為功能實現，會引起測試結果的誤差。
案例：先錄制buy腳本，插入文本檢查點。
先打開SUT，熟悉購票業務流程；
錄制流程：
New -> 選擇vuser_init -> OK -> 首頁面
-> 輸入jojo和bean
-> 開始事務login -> 點擊Login
-> 選中"Welcome, jojo, to" -> 插入文本檢查點
Insert text check (小望遠鏡圖標按鈕)
-> 結束事務login
-> 切換到Action -> 點擊Flights（等待頁面加載完畢）
-> 選擇城市從Denver到London -> Continue -> Continue
-> 開始事務buy -> 點擊Continue
-> 針對"Denver for London" 添加文本檢查點
-> 結束事務buy
-> 切換到vuser_end -> 點擊Sign Off
-> 關閉瀏覽器 -> Stop
保存在：D:\work\script\day03\buy 編譯 -> 回放
定義和調用函數的目的：復用已有的功能 不斷的使用
web_reg_find("Text=Welcome, <b>jojo</b>, to",
LAST);
web_reg_find("Text=Denver for London",
LAST);
web_reg_find("Text=待檢查的頁面源代碼文本", LAST);
來自於協議 HTTP響應數據包文本
3、檢查點函數：web_reg_find("Text=xxx", LAST);
xxx就是需要檢查的文本
規律1：對於B/S系統，LR腳本中具有兩種函數：
1）C語言函數：函數名比較簡約 strcmp 字符串比較
2）LR函數：一般lr_或web_開頭
<1> 通用的函數：不同協議代碼通用 - 重要！
lr_start_transaction lr_end_transaction 事務
lr_think_time 思考時間、等待時間
<2> Web[HTTP/HTML]協議下的函數： web_開頭
web_url URL請求 web_submit_form 提交表單請求
web_link 模擬點擊鏈接發送請求
web_reg_find 檢查點函數
規律2：web_reg_find函數 帶有reg字樣
帶有reg字樣的函數，稱為“注冊性函數” regist 注冊
特殊之處：必須寫在相應請求之前！
相應請求：引起需要檢查的響應所對應的請求。
相應請求之后，返回響應，響應中需要檢查文本。
規律3：檢查的是頁面源代碼文本 HTML語法
Welcome, <b>jojo</b>, to
Denver for London
初始化腳本 36行 附近相關代碼 錯誤
vuser_init.c(36): Error -26366:
檢查點的文本找不到
"Text=Welcome, <b>jojo1</b>, to" not found for web_reg_find
技巧：如何快速提高調試代碼的能力？
必要時可以故意將代碼改錯，分析錯誤提示和原因。
根據錯誤提示信息找到錯誤位置，並調試。
4、只有添加過檢查點的腳本運行正確，才說明腳本基本正確。（腳本需要適當的增強）
需求：循環訂3張票 VuGen中Run-time Settings按鈕
運行時設置
Run Logic 運行邏輯
Iteration Count: 迭代次數
Number of Iteration: 默認1 改為3次
注意：循環的只是Action部分
vuser_init和vuser_end部分僅執行一次
5、控制台和VuGen中設置Run-time Settings的聯系和區別
1）如果從控制台中直接打開腳本，VuGen中的設置會帶過來
2）如果控制台中也進行了設置，並且值不同，控制台的優先級更高；
3）建議：統一在控制台中設置
步調
6、Pacing值：每次迭代之間的時間間隔。 單位：秒
每次迭代：LR每次執行Action腳本代碼
規律：Pacing值越大，對SUT的壓力越小。
7、Think time：腳本每個步驟之間的時間間隔。 單位：秒
每個步驟：一般都是每個請求
web_url 訪問某個URL請求
web_submit_form 提交表單請求
web_link 點擊超級鏈接請求
用途：可以控制腳本中是否使用think time，以及如何使用
如果Ignore 忽略，則腳本中lr_think_time(18); 會失效。
規律：Think time值越大，對SUT的壓力越小。
面試題：Pacing和Think time有何區別？
共同點：都是時間間隔，單位都是秒
時間間隔越長，對服務器壓力越小
Pacing是迭代Action的時間間隔；
Think time是步驟、請求之間的時間間隔。
8、完成案例：針對buy進行基准測試 buy_基准測試_v1
方法1：單用戶循環執行n次 比如5次
1）調試好腳本（在VuGen運行通過）
2）打開控制台，加載buy腳本
設置腳本組：組名、腳本路徑、VU數量
Run Mode中，單選Basic Schedule
將Quantity改為1 單用戶
3）打開控制台中的Run-time Settings:
迭代次數： 改為5
4）Pacing值：迭代的間隔時間
有三種方案：
<1> As soon as the previous iteration ends
只要上一次迭代結束 -- 緊鑼密鼓
<2> 在上一次迭代結束后 設置為隨機的2.000~3.000秒
固定的 延遲
With a _fixed_ delay of _6.000_ sec
隨機的 時間精確到小數點后3位 2.768
With a _random_ delay of _2.000_ to _3.000_ sec
間隔
<3> At _fixed_ intervals, every _6.000_ sec
_random_ every _2.000_ to _3.000_ sec
5）Think time: 思考時間/等待時間
Ignore think time: 忽略思考時間 （選擇）
腳本中lr_think_time函數會失效，目前對結果無影響
Replay think time: 可設置具體策略
-> 點擊OK
6）設置VU的行為：
<1> 初始化：默認運行前初始化
<2> 加載方式：默認同時加載 就1VU
<3> 持續時間Duration：默認運行直到結束
保存場景文件：D:\work\scenario\day03\buy_基准測試1
-> 切換到Run視圖
運行場景 Start Scenario
歸納基准測試：
方法1：單用戶循環執行n次 比如5次
1）調試好腳本（加事務、檢查點，在VuGen運行成功）
2）打開控制台，加載相關腳本 buy
3）設置VU數量：1個
4）設置VU 行為：初始化、加載方式、持續時間
5）設置Run-time Settings:
<1> 迭代次數：n次 比如5次
<2> Pacing: 隨機2.000~3.000秒 迭代之間的間隔時間
<3> Think time: 可忽略 請求之間的間隔時間
原因：單用戶對系統的壓力較小，忽略對結果無影響。
方法2：單用戶持續運行n時間 比如1分鍾
1）調試好腳本（加事務、檢查點，在VuGen運行成功）
2）打開控制台，加載相關腳本 buy
3）設置VU數量：1個
4）設置VU 行為：初始化、加載方式、
持續時間Duration: 改為持續運行1分鍾
5）設置Run-time Settings:
<1> 迭代次數：1次 此處不起作用，取決於Duration
<2> Pacing: 隨機2.000~3.000秒 迭代之間的間隔時間
<3> Think time: 可忽略 請求之間的間隔時間
原因：單用戶對系統的壓力較小，忽略對結果無影響。
說明：
1）當Run-time Settings中的迭代次數和Duration沖突時，Duration的優先級更高。
Duration：
第一項：運行直到結束
還是聽Duration的，只是放權了，運行的次數取決於迭代次數。（方法1）
適用於：明確迭代次數時使用，比如迭代5次 限次數
第二項：Run for __ days and __(HH:MM:SS)
運行時間是由Duration說的算，Action迭代的次數取決於實際情況，Duration指的是Action持續迭代的時間，時間將至，LR會發出指令，通知VU結束運行。 Stop
適用於：明確限定Action迭代的時間，比如1分鍾 限時間
2）如何統計性能測試結果數據？
建議對場景運行3次，在測試報告中，取中間值：
場景運行 平均事務響應時間
第1次 0.216s
第2次 0.203s
第3次 0.279s
結果取值：0.216s
3）目前暫時忽略系統資源監控（后續統一補充）
以上就是基准測試。
三、並發測試 Concurrency Testing
1、含義：多用戶在幾乎同一時刻執行某一業務操作，形成一種嚴格的並發訪問（LR精確到毫秒級別），觀察系統在瞬時較大壓力情況下的承受能力。
2、並發測試的三要素（面試題：並發測試需要注意什么）
1）Action腳本中要添加事務；
既可以獲取和事務相關的性能指標；時間 TPS 成功率
又可以作為並發的范圍，從事務開始處一起並發
Action腳本中才可能執行並發
2）事務開始之前要加集合點（並發點）；嚴格的並發
3）控制台場景中要設置並發策略。 並發的規模
集合點：5個線程，代表5個VU，並發執行一次購票
buy事務的開始
o-----------|o----------
o-----------|o----------
o-----------|o----------
o-----------|o----------
o-----------|o----------
此處設置集合點（並發點）
Action腳本中，在buy事務開始之前，設置集合點；
等所有VU到達集合點時，才一起釋放，此時的壓力最大
-- 瞬時壓力
並發策略：比如，當所有VU到達集合點時一起釋放
3、集合點只有在並發測試時才使用。
-- 營造一種嚴格的並發（狹義的並發）
日常多任務也存在並發（廣義的並發）
4、案例：5VU並發購票
1）先錄制buy腳本，添加事務、檢查點
技巧：腳本的備份 File -> Save As 另存為 buy1
2）Action中，buy事務開始之前添加集合點
光標在事務開始之前 lr_start_transaction("buy");
點擊 Insert -> Rendezvous 集合點
-> 輸入集合點名稱 Rendezvous Name: buy 同事務名
就會生成腳本：lr_rendezvous("buy");
LR的通用函數 集合點函數
-> 及時保存 -> 編譯 Compile 保證最新版本
3）打開控制台，設置並發策略
加載buy1腳本
注意：如果加載后的腳本修改了，先編譯腳本，並在控制台中刷新腳本：
針對控制台中腳本組 右擊-> Details 細節
-> Refresh 刷新 下拉菜單：
1) 常用Script: 刷新腳本
2) Runtime Settings: 不常用 將VuGen中設置覆蓋過來
建議統一在控制台中設置為好
選擇Scenario菜單 -> Rendezvous 設置並發策略
-> 窗口中，點擊Policy按鈕 策略
第1項：Release when 100% of all Vusers arrive at the
rendezvous. （選擇此項）
當100%的所有VU到達集合點時一起釋放
比如：10VU都算 10*100% 10*n%
第2項：Release when 100% of all running Vusers arrive at the rendezvous.
當100%的正在運行的VU到達集合點時一起釋放
比如：10VU中只有5個正在運行 5*100% 5*n%
第3項：Release when 1 Vusers arrive at the rendezvous. 指定n個VU到達集合點時一起釋放
補充：Timeout between Vusers: 30sec
超時時間：從先到達集合點的VU開始計時，如果超時30秒用戶未到齊，先釋放到達集合點的用戶，形成局部並發。
4）完成5VU並發購票其它設置：
<1> 控制台中：VU數 5個
<2> VU行為：
初始化：默認
加載方式：默認同時 目前VU較少
持續時間：運行直到結束 每個VU只需迭代1次
<3> Run-time Settings:
迭代次數：1次
Pacing: 無需間隔時間
Log: 默認日志
Think time: 默認忽略，讓VU更快到達集合點，更嚴格
<4> 系統資源監控 目前只添加部分一項 未來十幾項
Run視圖 -> Windows Resources Windows系統資源
右鍵 -> 添加指標 Add Measurements...
Add 添加監控的主機名Name：localhost
平台Platform：WINXP
清空舊的指標，Add添加新的：
類別：Processor 處理器，就是CPU
%Processor Time CPU使用率
閾值：不超過80%
-> 運行場景 -> 查看結果報告 buy_並發測試_5VU_r1
平均事務響應時間：0.384秒
CPU使用率平均值：73.698% 接近80% 擔心CPU瓶頸
場景文件：buy_並發測試_5VU
業務名 策略名 並發規模
buy_並發測試_10VU
平均事務響應時間：0.386秒
CPU使用率平均值：88.542% 超過80% 存在CPU瓶頸
歸納：
1、測試策略：基准測試、並發測試、在線綜合場景測試
2、基准測試：單用戶、單測試點、執行n次/n時間
3、並發測試：多用戶並發執行某功能點
三要素：Action中加事務、事務前加集合點、場景中設置並發策略 集合點函數：lr_rendezvous("集合點名");