程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> .NET網頁編程 >> C# >> 關於C# >> 實現LoadRunner多個場景的順序執行

實現LoadRunner多個場景的順序執行

編輯:關於C#
 

最近在學習使用load runner,使用的是load runner8.1,ie 7 。在錄制腳本時遇到了點“錄制”之後,IE打開之後又自動關閉的情況。上網收集了一下解決方法,有如下幾種說法:

1.

IE--internet屬性--高級--把"啟用第三方浏覽器擴展"前面的勾去掉.

按1方法操作後,ie不會自動關閉,但是出現了新問題:就是每次保存的時候,都會報錯,然後Loadrunner就自動關閉了。這個問題在我第一次操作的時候出現過,後來反復試驗沒有重現。針對這個問題,有人提出了另外一種解決方案,我們稱其為方法2吧:

2.

(1.卸載IE7, 使用IE6
(2.打開IE-->Internet選項-->高級,把“禁用腳本調試(Internet Explorer)”和“禁用腳本調試(其它)”前面的勾去掉
(3.同時采用3樓朋友的做法
(4.再打開Loadrunner,進行錄制和保存即可

有人提出是由於load runner8不支持ie7,8,才會出現這些問題,建議采用打補丁或者升級load runner到9.0的版本

3.

8.1的打了SP4補丁後就可以完美支持IE7了~,同時要注意下面3個問題:
1:還有就是安裝Loadruner的時候一定要記得清理掉以前安裝過LR的仍然保留在注冊表中的東西
2:清楚一些破壞IE的什麼木馬啊,流氓軟件
3:IE--internet屬性--高級--把"啟用第三方浏覽器擴展"前面的勾去掉.

 


 

實現LoadRunner多個場景的順序執行
注:以下內容部分總結自51testing論壇。
應用場景
假設有3個不同的測試場景,分別為並發登錄、核心業務、可靠性測試,3個場景有先後執行順序。由於白天測試機器另有用處,只能在晚上進行性能測試,這時我們的期望是能否把測試場景都設定好之後晚上自動運行,第二天我們回來看測試結果呢?
答案是肯定的,可以有兩種方式實現。
第一種,相對簡單
充分利用LR Controller裡面Group的功能。
新建一個場景把3個腳本都添加進來,在Edit Schedule中選擇“Schedule by Group”的方式,在StartTime中設置3個腳本的運行順序為“Start when Group xxx finished”,並在“Scenario Start Time”中設定場景在晚上的運行啟動時間。設定完定時執行場景後,點擊StartScenario按鈕,會出現一個倒計時窗口,這樣在固定的某個時間上,測試場景中的3個腳本將乖乖的按照設定的先後順序進行測試。注意,如果沒有點擊StartScenario按鈕激活測試,是不會真正進行測試的。(感謝Athenst朋友的提醒,^_^)
第二種,比較靈活
我們把應用場景稍微擴展一下,假設其中1、3場景只有一個測試腳本,而核心業務場景由數據錄入、數據查詢、數據上報3個腳本組成,同樣的,3個場景仍需按順序進行測試。這時如果采用第一種方式,由於第2個場景有3個腳本,所以第三個腳本的啟動時間就是一個問題了。由於Controller中每個腳本都對應一個Group,而且GroupName不能重復,這時第三個場景的StartTime中“Start when group finished”則只能是選擇第二個場景中的某個Group,而並非是第二個場景的3個腳本都完成之後再進行,無法達到我們的初衷。
這時,可以通過命令行的方式來進行。
首先創建並設置好3個測試場景,再創建一個一個批處理程序按先後順序調用這3個場景進行測試,最後通過Windows的定時任務設定批處理的執行時間。
批處理示例如下:
cls
SET M_ROOT="D:\Program Files\MI\Mercury LoadRunner\bin\"
%M_ROOT%\wlrun.exe -TestPath "D:\Program Files\MI\Mercury LoadRunner\scenario\Test\TestScen_1.lrs" -Run
%M_ROOT%\wlrun.exe -TestPath "D:\Program Files\MI\Mercury LoadRunner\scenario\Test\TestScen_2.lrs" -Run
%M_ROOT%\wlrun.exe -TestPath "D:\Program Files\MI\Mercury LoadRunner\scenario\Test\TestScen_3.lrs" -Run
這種方式比較靈活,但需要注意在Result Settings中設置“Automatically create a results directory for each scenario execution”,以免後面的測試結果覆蓋了前面的。
另外補充一下,如果想對某個腳本進行50、100、150...等用戶數遞增的測試,也可以用以上方法實現,但需要注意的是將事務名稱區分開以便進行分析。

 

 

 

*************************************分隔線*****************************

批量執行場景:

@echo off

echo =====================================

echo 批量執行場景...

echo =====================================

SET M_ROOT="C:\Program Files\Mercury LoadRunner\bin\"

%M_ROOT%\wlrun.exe -TestPath "D:\Fin\scenario\Scen_1.lrs" -Run

echo Scen_1執行完畢

%M_ROOT%\wlrun.exe -TestPath "D:\Fin\scenario\Scen_2.lrs" -Run

echo Scen_2執行完畢

%M_ROOT%\wlrun.exe -TestPath "D:\Fin\scenario\Scen_3.lrs" -Run

echo Scen_3執行完畢

%M_ROOT%\wlrun.exe -TestPath "D:\Fin\scenario\Scen_4.lrs" -Run

echo Scen_4執行完畢

echo. & pause

批量執行腳本:(說明,有些時候我們需要把LR 當作 功能測試使用,但是又能做到QTP所做不到的東西,例如協議驗證測試中,我們通過LR脫離客戶端,直接向後端服務器發送報文這時需要用到腳本1中的結果保存成文件給腳本2做數據執行。LR 只是一個工具,並非只能做功能測試。因為他的是真實的向目標服務器進行交互。)

@echo off

echo =====================================

echo XX項目自動化腳本執行開始...

echo =====================================

echo 讀取Data文件...

echo 傳送文件中...

copy .\Data\login.txt .\PGCreateGroup_ex\login.dat

copy .\Data\Apply.txt .\PGApplyGroup_ex\login.dat

copy .\Data\ipport.txt .\PGApplyGroup_ex\ipport.dat

copy .\Data\ipport.txt .\PGSetMemberPermission\ipport.dat

copy .\Data\ipport.txt .\PGCreateGroup_ex\ipport.dat

echo 傳送完畢...

SET M_ROOT="C:\Program Files\Mercury\LoadRunner\bin"

%M_ROOT%\vugen.exe -TestPath ".\PGCreateGroup_ex\PGCreateGroup_ex.usr" -RUN

echo 傳送文件中...

copy .\PGCreateGroup_ex\login.dat .\PGSetMemberPermission\login.dat

echo 傳送完畢...

%M_ROOT%\vugen.exe -TestPath ".\PGApplyGroup_ex\PGApplyGroup_ex.usr" -RUN

echo 傳送文件中...

copy .\PGApplyGroup_ex\AddGroup.dat .\PGSetMemberPermission\AddGroup.dat

copy .\PGApplyGroup_ex\login.dat .\PGSetMemberPermission\MemSip.dat

echo 傳送完畢...

%M_ROOT%\vugen.exe -TestPath ".\PGSetMemberPermission\PGSetMemberPermission.usr" -RUN

echo 執行完畢...

echo copyright in 02-24-2009 , Fin.

echo. & pause

曾經用過的兩種用用法,另外配上有一個兄弟發的自己做的定時執行批處理文件工具,就更完美了。技術共享。。。

 

LoadRunner性能測試指標


默認分類   2009-06-26 15:10    閱讀64    評論0
字號: 大大 中中 小小
 

LoadRunner性能測試指標

 

 

   

 

 

Object

 

Counters

 

Descrīption

 

Reference value

 

Memory

 

Available Mbytes

 

可用物理內存數.如果Available Mbytes的值很小(4 MB或更小),則說明計算機上總的內存可能不足,或某程序沒有釋放內存。

 

4 MB或更小,至少要有10%的物理內存值

 

Page/sec

(Input/Out)

 

為了解析硬頁錯誤,從磁盤取出或寫入的頁數。一般如果Page/sec持續高於幾百,那麼您應該進一步研究頁交換活動。有可能需要增加內存,以減少換頁的需求(你可以把這個數字乘以4k就得到由此引起的硬盤數據流量)。Pages/sec的值很大不一定表明內存有問題,而可能是運行使用內存映射文件的程序所致。

 

推薦00-20

如果服務器沒有足夠的內存處理其工作負荷,此數值將一直很高。如果大於80,表示有問題(太多的讀寫數據操作要訪問磁盤,可考慮增加內存或優化讀寫數據的算法)。

該系列計數器的值比較低說明響應請求比較快, 否則可能是服務器系統內存短缺引起(也可能是緩存太大, 導致系統內存太少)。

 

 

>5越低越好

 

Page Fault

 

處理器每秒處理的錯誤頁(包括軟/硬錯誤)。

當處理器向內存指定的位置請求一頁(可能是數據或代碼)出現錯誤時,這就構成一個Page Fault。如果該頁在內存的其他位置,該錯誤被稱為軟錯誤(用Transition Fault/sec記數器衡量);如果該頁必須從硬盤上重新讀取時,被稱為硬錯誤。許多處理器可以在有大量軟錯誤的情況下繼續操作。但是,硬錯誤可以導致明顯的拖延。

 

Page Input/sec

 

為了解決硬錯誤頁,從磁盤上讀取的頁數。

 

Page Output/sec

 

 

 

Page reads/sec

 

為了解決硬錯誤頁,從磁盤上讀取的次數。解析對內存的引用,必須讀取頁文件的次數。阈值為>5.越低越好。大數值表示磁盤讀而不是緩存讀。

 

Cache Bytes

 

文件系統緩存,默認情況下為50%的可用物理內存。如IIS5.0運行內存不夠時,它會自動整理緩存。需要關注該計數器的趨勢變化

 

 

 

內存洩露

 

如果您懷疑有內存洩露,請監視Memory\\ Available Bytes和Memory\\ Committed Bytes,以觀察內存行為,並監視您認為可能在洩露內存的進程的Process\\Private Bytes、Process\\Working Set和Process\\Handle Count。如果您懷疑是內核模式進程導致了洩露,則還應該監視Memory\\Pool Nonpaged Bytes、Memory\\ Pool Nonpaged Allocs和Process(process_name)\\ Pool Nonpaged Bytes。

 

 

 

Process

 

Page Faults/sec

 

將進程產生的頁故障與系統產生的相比較,以判斷這個進程對系統頁故障產生的影響。

 

 

 

Private Bytes

 

此進程所分配的無法與其它進程共享的當前字節數量。如果系統性能隨著時間而降低,則此計數器可以是內存洩漏的最佳指示器。

 

 

 

Work set

 

處理線程最近使用的內存頁,反映了每一個進程使用的內存頁的數量。如果服務器有足夠的空閒內存,頁就會被留在工作集中,當自由內存少於一個特定的阈值時,頁就會被清除出工作集。

 

 

 

Processor

 

% Processor Time

 

被消耗的處理器時間數量.如果服務器專用於sqlserver可接受的最大上限是80% -85%.也就是常見的CPU使用率.

 

 

 

ProcessorQueue Length

 

判斷CPU瓶頸,如果processor queue length顯示的隊列長度保持不變(>=2)並且處理器的利用率%Processor time超過90%,那麼很可能存在處理器瓶頸.如果發現processor queue length顯示的隊列長度超過2,而處理器的利用率卻一直很低,或許更應該去解決處理器阻塞問題,這裡處理器一般不是瓶頸.

 

 

 

Physical

Disk

 

%DiskTime

 

指所選磁盤驅動器忙於為讀或寫入請求提供服務所用的時間的百分比。

正常值<10,此值過大表示耗費太多時間來訪問磁盤,可考慮增加內存、更換更快的硬盤、優化讀寫數據的算法。若數值持續超過80 (此時處理器及網絡連接並沒有飽和),則可能是內存洩漏。

 

 

 

CurrentDiskQueueLength

 

讀取和寫入請求(為所選磁盤在實例間隔中列隊的)的平均數。(磁盤數1.5-2倍)

 

 

 

Avg.Disk Queue

Length

Avg.Disk Read

QueueLength

Avg.Disk Write

QueueLength

Disk Read/sec

Disk Write/sec

 

讀取和寫入請求(為所選磁盤在實例間隔中列隊的)的平均數。

磁盤瓶頸判斷公式:

每磁盤的I/O數=(讀次數+(4*寫次數))/磁盤個數。

如果計算出來的每磁盤的I/O數大於磁盤的處理能力,那麼磁盤存在瓶頸。

 

Avg.DiskQueue Length正常值<0.5,此值過大表示磁盤IO太慢,要更換更快的硬盤。

 

 

附:

1、SQL數據庫:

1. User 0 Connections (用戶連接數,也就是數據庫的連接數量);

2. Number of deadlocks/Sec/-Total (數據庫死鎖)

3. Memory\ Availalle Mbyte 內存監控 (可用內存)

4. Physicsdisk \disk time \-Total(磁盤讀寫總時間)(出現瓶頸時檢查讀磁盤的時間長還是寫磁盤的時間長)

5. Butter Caile hit(數據庫緩存的選取命中率)

6. 數據庫的命中率不能低於92%

2、Web Server:

1. Processor \ Processon time \ Tatol cpu時間

2. Memory \ Availalle MbyteAvai 應用服務器的內存

3. Requst Quened 進入HTTP隊列的時間;隊列/每秒

4. Total request 總請求數時間

5. Avg Rps 平均每秒鐘響應次數= 總請求時間 / 秒數

6. Avg time to last byte per terstion (mstes)平均每秒迭代次數 ; 上一個頁面到下一個頁面的時間是你錄入角本的一個過程的執行

7. Http Error 無效請求次數

8. Send 發送請求次數字節數

Webload的壓力參數:

l Load Size(壓力規模大小)

l Round Time(請求時間)

l Rounds (請求數)

l Successful Rounds(成功的請求)

l Failed Rounds (失敗的請求)

l Rounds Per Second (每秒請求次數)(是指你錄入角本的任務在一秒中執行的次數,類似Avg time to last byte per terstion (mstes))

l Successful Rounds Per Second(每秒成功的請求次數)

l Failed Rounds Per Second(每秒失敗的請求次數)

l Page Time 頁面響應時間

l Pages (頁面數)

l Pages Per Second (每秒頁面響應數)

l H it Time(點擊時間)

l Hits(點擊次數,也可以是請求次數,不過有一些不一樣)

l Successful Hits (成功的點擊次數)

l Failed Hits (失敗的點擊次數)

l Hits Per Second (每秒點擊數)

l Successful Hits Per Second (每秒成功的點擊次數)

l Failed Hits Per Second (每秒失敗的點擊次數)

l Attempted Connections (嘗試鏈接數)

l Successful Connections(成功的連接數)

l Failed Connections(失敗的連接數)

l Connect Time(連接時間)

l Process Time(系統執行時間,一般用來顯示CPU的運算量,服務器端與客戶端都要記錄)

l Receive Time(接受時間)

l Send Time(請求時間)

l Time To First Byte ()

l Throughput (Bytes Per Second)()

l Response Time(回應時間)

l Response Data Size()

l Responses()

 

 

 

Transactions per second(每秒處理事務數) http連接Get or Post方法的事務數

Rounds per second(每秒完成數) 每秒完全執行Agenda〔代理〕的數量

Throughput(吞吐量)(bytes per second〔每秒字節數〕) 測試服務器每秒傳送的字節數

Round Time 完成一次事務所用的必要時間,單位是秒

Transaction Time是完成一次事務的必須時間。事務:包括連接時間,發送、響應和處理時間。

Connect Time 客戶端到測試服務器的一個連接完成的時間,單位秒(包括建立和收到的TCP/IP時間)

Send Time 是將事務寫入測試服務器的緩沖必要時間 ,單位秒

Response Time 是客戶端請求接受測試服務器響應的必要時間,單位秒

Process Time 處理數據的必要時間

Load Size 負載測試時開啟的虛擬客戶數量〕

Rounds 在測試會話期間執行議程腳本的時間數

Attempted Connections 嘗試連接測試服務器的數量

HTTP Response Status 每一個http響應被結束的時間數量

Response Data Size 由測試服務器發送的響應大小,單位字節。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved