The languages supported by VuGen are:
1) C Language
2) Visual Basic Scripting
3) Visual Basic For Applications
4) Java Scripting
1) C Language
2) Visual Basic Scripting
3) Visual Basic For Applications
4) Java Scripting
The default language supported by VuGen is "C". All
the above mentioned languages can be chosen based on the protocols.
For example:
1) COM/DCOM type of application supports all the above mentioned languages.
2) Web (HTTP/HTML) supports only "C" language
For example:
1) COM/DCOM type of application supports all the above mentioned languages.
2) Web (HTTP/HTML) supports only "C" language
Scripting in loadrunner can be done in two ways
1) By way of recording
2) By writing the test script
1) By way of recording
2) By writing the test script
Recording is the mostly recommended ways of scripting. Since
writing the test script involves lot of technical
knowledge of the application and
loadrunner scripting knowledge respective to the protocol or application.
Protocol or application type
is used for scripting in loadrunner vugen. There are two ways deciding which
type of protocol is used for scripting.
1) By talking to the architects:
2) By looking into the application design or architectural diagram
3) By using the VuGen protocol adviser. But, protocol adviser is available from loadrunner 9.5 version onwards.
2) By looking into the application design or architectural diagram
3) By using the VuGen protocol adviser. But, protocol adviser is available from loadrunner 9.5 version onwards.
Protocol advisor in loadrunner is available
from version 9.5 onwards. Follow the below mentioned steps to get benefit of
protocol adviser
1) Open the VuGen
2) Select File -> Protocol adviser -> Analyze Application
3) Protocol Adviser dialog box pops up
4) Select the application type and other application details and press "OK" button.
5) Perform the user actions on the application, till all the major areas of the application flows are covered.
6) Stop Analyzing
7) Protocol adviser results will be displayed automatically
1) Open the VuGen
2) Select File -> Protocol adviser -> Analyze Application
3) Protocol Adviser dialog box pops up
4) Select the application type and other application details and press "OK" button.
5) Perform the user actions on the application, till all the major areas of the application flows are covered.
6) Stop Analyzing
7) Protocol adviser results will be displayed automatically
To open the recording options
go to
1) File -> Tools -> Recording Options
2) Recording Options dialog box opens
3) Select Recording
1) File -> Tools -> Recording Options
2) Recording Options dialog box opens
3) Select Recording
In web (HTTP/ HTML) based recording there are two modes
available.
1) HTML based script
2) URL based script
1) HTML based script
2) URL based script
The default actions generated by loadrunner
VuGen are:
1) vuser_init
2) Action
3) vuser_end
1) vuser_init
2) Action
3) vuser_end
vuser_init : vuser_init will be
called only once at the beginning of the script execution for each virtual user. Most
of the initiation operations are done with vuser_init action
Action : Action will be called
based the number of iterations mentioned in VuGen run time setting. Action will
be iterated based the time duration mentioned in the controller. Till the
controller time duration lapses action will be iterated.
vuser_end : vuser_end will be called
only once at the end of the
script execution for each virtual
user. Most of the closure operations are done with vuser_init action
Based on the type of the user emulation we choose the actions appropriately.
If you are emulating a web end user of a business. Assume that you are
emulating bank customer. Who will be using the web interface to interact with
the application.
vuser_init : Most of the initiation operations are done with vuser_init action. Here no user operations needs to be recorded.
Action : Login into the application. Other user operations. And the logout operations will be captured into action.
vuser_end : Most of the closure operations are done with vuser_init action. No operations are captured in this actions
vuser_init : Most of the initiation operations are done with vuser_init action. Here no user operations needs to be recorded.
Action : Login into the application. Other user operations. And the logout operations will be captured into action.
vuser_end : Most of the closure operations are done with vuser_init action. No operations are captured in this actions
If you are emulating
a client server or web internal user of a business.
Assume that you are emulating bank customer. care executive or branch executive.
Who will be using the client server or web interface to interact with the application.
vuser_init : Most of the initiation
operations are done with vuser_init action. We need to execute login only once
if we are simulating a shift duration. Here login related operations needs to be recorded.
Since the bank executives login only once in their shift.
Action : All other bank executive repeated operations needs to be captured. And the login and logout operations should not be captured into action.
vuser_end : Most of the closure operations are done with vuser_end action. Here login related operations needs to be recorded. Since the bank executives login only once in their shift. We need to execute only once if we are simulating a shift duration. Here logout related operations needs to be recorded. Since the bank executives logout only once after his / her shift.
Action : All other bank executive repeated operations needs to be captured. And the login and logout operations should not be captured into action.
vuser_end : Most of the closure operations are done with vuser_end action. Here login related operations needs to be recorded. Since the bank executives login only once in their shift. We need to execute only once if we are simulating a shift duration. Here logout related operations needs to be recorded. Since the bank executives logout only once after his / her shift.
During the recording time, QTP captures the application events based on UI of the application. Whereas Loadrunner
captures the application operations based on the protocol.
Quick Test Professional (QTP): QTP captures the application events based on the Graphical user
interface (GUI) objects. The objects will be captured in object repository and
the operations on the objects will be captured in the testscript
as statements.
The objects will be identified based on the type of the application. And the add-in installed with QTP respective to theapplication.
Ex: If java based application to be recognized by QTP, java add-in
should be installed with QTP.
Loadrunner: Loadrunner captures traffic based on the protocol. Most of the applications in loadrunner are captured on the
protocol. Loadrunner captures page submits, url posts especially when it comes
to web based applications. If it
is client server application, Loadrunner captures the
traffic based on TCP/IP or ODBC etc type of protocols.
Transactions in VuGen can be added Four ways:
1) During recording, click on add start transactions and end transactions
2) After recording from Enhancements section of Tasks.
3) After recording from Tree view
4) After recording from script view
2) After recording from Enhancements section of Tasks.
3) After recording from Tree view
4) After recording from script view
The transaction response time will be displayed after the play back of the script.
And the response time will be displayed as part of the Replay log in output window.
And the response time will be displayed as part of the Replay log in output window.
Note: If the output window is not opened. Select menu option View
-> Output window
Assume that there is scenario mentioned below
step 1
lr_start_transaction(trans1)
Step 2
lr_think_time(30.3)
step3
lr_end_transaction(trans1)
lr_start_transaction(trans1)
Step 2
lr_think_time(30.3)
step3
lr_end_transaction(trans1)
In the above case the think time of 30.3 sec will be coming as
part of the measurement time. To eliminate the think time from the measurement
we will be using the statements as mentioned below
step 1
lr_start_transaction(trans1)
Step 2
lr_stop_transaction(trans1)
lr_think_time(30.3)
lr_resume_transaction(trans1)
step3
lr_end_transaction(trans1)
lr_start_transaction(trans1)
Step 2
lr_stop_transaction(trans1)
lr_think_time(30.3)
lr_resume_transaction(trans1)
step3
lr_end_transaction(trans1)
lr_stop_transaction - Freezes reporting of transaction data.
lr_resume_transaction - Resumes reporting transaction data within a script.
lr_resume_transaction - Resumes reporting transaction data within a script.
lr_stop_transaction - Freezes reporting of transaction data.
stop transaction normally followed by resume transaction. Stop transaction we use, if we want to freeze the timer and later we can resume it later
stop transaction normally followed by resume transaction. Stop transaction we use, if we want to freeze the timer and later we can resume it later
lr_end_transaction - Marks the end
of a transaction.
End transaction is the closure of the transaction. End transaction we use, if we want to get the timer to be printed or reported to a monitor graph in controller or replay log in vugen.
End transaction is the closure of the transaction. End transaction we use, if we want to get the timer to be printed or reported to a monitor graph in controller or replay log in vugen.
Wasted time is time spent on
activities whose purpose is to support test analysis,
but would never be performed by abrowser user, for example, time spent keeping
transaction statistics for later reporting. Wasted time is
calculated internally by LoadRunner. Your script can also add wasted time with lr_wasted_time.
Sometimes, you may enter activities in a script that your do not
want reported as part of the transaction statistics. Generally, these are
activities related to record keeping,
logging, or custom analysis. If you enhance the script with steps whose
durations should not be included in the test statistics,
you can track the time used by these steps with lr_start_timer and
lr_end_timer. Then, the function lr_wasted_time is used for adding this user-determined
time to the internally generated wasted
time.
The concurrency of user hits can be achieved by using rendezvous
points.
Rendezvous point will be added from VuGen. But, the rendezvous
point release settings can be made from controller to achieve the concurrency.
Rendezvous is used for achieving the concurrency during the load
testing.
When single user is run from VuGen rendezvous point never be
triggered. As it is defined for only multiple users.
Rendezvous point makes users to wait till the users mentioned in controller reach to a common step.
When the rendezvous point releases the users are going to hit the system
without any millisecond difference. The approach of hitting multiple users
hitting at a common point is called concurrency
Before the rendezvous point added in the test script.
One has to identify the appropriate step, where the rendezvous point needs to
be added.
Rendezvous points in vugen can be added in two ways:
1) Add the rendezvous point from Tree View
1) Add the rendezvous point from Tree View
a) Select the step in
tree view
b) Select the Menu "Insert -> Rendezvous"
c) Give the name of the rendezvous point
b) Select the Menu "Insert -> Rendezvous"
c) Give the name of the rendezvous point
2) Add the rendezvous point from the test script
a) Select the
step in script view
b) Select the Menu "Insert -> Rendezvous"
c) Give the name of the rendezvous point
b) Select the Menu "Insert -> Rendezvous"
c) Give the name of the rendezvous point
Rendezvous is used for generating the concurrency on the application under test.
concurrency hits will enable you identify the issues on any
resource dependency.
For example:
1) If there are any thread dependencies in application server. Those errors can be detected only by simulating the concurrency hits on the application server.
2) If there are any table accessing dependencies in the database, those can be detected by simulating the concurrency hits.
1) If there are any thread dependencies in application server. Those errors can be detected only by simulating the concurrency hits on the application server.
2) If there are any table accessing dependencies in the database, those can be detected by simulating the concurrency hits.
Rendezvous point works based on the settings given in controller
scenario.
The default setting for rendezvous point is - Release all the
vusers when all running users reached to the rendezvous point.
And the default time out period is 30 sec.
For Ex:
In the above case, if there are 10 users are running out of total 100 users. Assume that there are 4 vusers reached to the rendezvous point. The users who reached to the rendezvous point (4 vusers) are going to wait, till all the otherrunning vusers (6 vusers) reaches to the rendezvous point. once all the 10 vusers reached to the rendezvous point, then the rendezvous for the waiting vusers will be released.
In the above case, if there are 10 users are running out of total 100 users. Assume that there are 4 vusers reached to the rendezvous point. The users who reached to the rendezvous point (4 vusers) are going to wait, till all the otherrunning vusers (6 vusers) reaches to the rendezvous point. once all the 10 vusers reached to the rendezvous point, then the rendezvous for the waiting vusers will be released.
If the users are taking more than 30 sec, then the rendezvous
point for the waiting users will be
released.
Case 1:
It is been recommended that the transaction, think time and rendezvous point should be in the following order
1) think time
2) rendezvous
3) transaction
It is been recommended that the transaction, think time and rendezvous point should be in the following order
1) think time
2) rendezvous
3) transaction
Case 2:
Let us see, what kind impact will be there if we make like the below mentioned order
1) rendezvous
2) think time
3) transaction
Let us see, what kind impact will be there if we make like the below mentioned order
1) rendezvous
2) think time
3) transaction
In the above case, if the think time comes after the rendezvous
point. The concurrency may be last because of the random settings given in the
run time settings for think times
Case 3:
Let us see, what kind impact will be there if we make like the below mentioned order
1) rendezvous
2) transaction
3) think time
Let us see, what kind impact will be there if we make like the below mentioned order
1) rendezvous
2) transaction
3) think time
In the above case, think time is going to come as part of the measurement time. which is not recommended. So the case 1 is one of the best practices of all.
Run time viewer can be enabled in vugen with the below mentioned
steps.
From VuGen Menu options select
1) Tools -> General Options
2) General Options dialog opens
3) Select Display tab
4) Check "Show browser during replay" option
5) Press OK button
1) Tools -> General Options
2) General Options dialog opens
3) Select Display tab
4) Check "Show browser during replay" option
5) Press OK button
Now during the replay a run time viewer will be displayed, to
see how the web users are sending requests and getting the responses
Results can be viewed in vugen with the below mentioned steps,
after the test script execution.
From VuGen Menu options select
1) View -> Test Results
1) View -> Test Results
Recording is nothing but capturing the user actions as test
script.
When the recording happens Loadrunner vugen, the capturing of
the application events will be done through acommunication channel, mostly by using a protocol based on
the type of application.
When the recording happens, VuGen captures the application traffic which goes a through a
specific protocol like HTTP when it comes to web based applications
When the recording happens, VuGen captures the application traffic which goes a through a
specific protocol like ODBC, TCP/IP when it comes to client server based applications.
When it comes citrix or RDC kind of applications, the events
will be captured based on the screen positions. So, one have to be careful when the recording and
play back happens on these kind of applications.
When the script is played back, the requests will be posted on
to the immediate server or
servers on AUT. And the response will be returned by the server. The VuGen is going to wait
till the
complete response comes
back. We normally do not add any specific synchronizations in VuGen scripting.
VuGen validates the response based on the specific protocol
codes. When it comes to web (HTTP / HTML) application, the response is validated based on HTTP codes.
Any text based files used for parameterization in loadrunner
VuGen, those files are:
1) .CSV file
2) .txt file
3) .dat files
2) .txt file
3) .dat files
Follow the steps as mentioned below.
1) Create a data file with
multiple columns.
2) Ensure that the data file must be .csv or .dat format.
3) Open the parameter list from the menu option Vuser -> Parameter List
4) Create a parameter
5) Select the type of parameter as File
6) Browse and select the multicolumn data file
7) Map the parameter to the column name of the multicolumn data file
8) Repeat step 4 to step 7, till you create all the parameters
2) Ensure that the data file must be .csv or .dat format.
3) Open the parameter list from the menu option Vuser -> Parameter List
4) Create a parameter
5) Select the type of parameter as File
6) Browse and select the multicolumn data file
7) Map the parameter to the column name of the multicolumn data file
8) Repeat step 4 to step 7, till you create all the parameters
Assume that there are two parameters (param1 and param2)
created, and param1 is chosen with select next row as random. You want to make
param2 to be read as same line as param1. Then you need to make param2 be
dependent on param1.
This can be done with the below steps
1) Select the param2
2) Select the next row as "same line as param1"
1) Select the param2
2) Select the next row as "same line as param1"
The types of parameterizations available in loadrunner vugen
are:
1) File or Table
Parameter Types
i) Data Files
ii) Data Tables
ii) Data Tables
2) XML Parameter Types
3) Internal Data Parameter Types
3) Internal Data Parameter Types
i) Date/Time
ii) Group Name,
iii)Iteration Number
iv) Load Generator Name,
v) Random Number
vi) Unique Number
vii) Vuser ID
viii) Date / Time
ii) Group Name,
iii)Iteration Number
iv) Load Generator Name,
v) Random Number
vi) Unique Number
vii) Vuser ID
viii) Date / Time
4) User-Defined Function Parameters
Parameter simulation will be helpful to you, to understand how
exactly controller is going to read the parameter values during the multiple
vuser multiple iterations load.
The parameter simulation can be done with the below mentioned steps:
1) Enter the number of users and iterations and click on simulate
2) Now you can see how exactly, the users going to read a specific parameter.
1) Enter the number of users and iterations and click on simulate
2) Now you can see how exactly, the users going to read a specific parameter.
Offset parameter by in date type
will be used to increase or decrease the current and use it in the scripting.
1) For example when you give offset parameter by 1 days. The
resultant parameter will be substituted with current date + 1 day. This will be
used for future dates.
2) For example when you give offset parameter by 1 days. And checked the prior to current date, then the resultant parameter will be substituted with current date - 1 day.This will be used for past dates.
2) For example when you give offset parameter by 1 days. And checked the prior to current date, then the resultant parameter will be substituted with current date - 1 day.This will be used for past dates.
Number format for random numbers is
used with %lu
For ex: the parameter is used with %lu, then it is going to use
exact number without any preceded zeros.
If the parameter is used with %lu - then 1, 123 or 4444 etc. all the numbers of the parameters will be used as it is.
If the parameter is used with %lu - then 1, 123 or 4444 etc. all the numbers of the parameters will be used as it is.
For ex: the parameter is used with %08lu, then it is going to
use exact 8 digits, if the number is lesser than 8 digits. For the additional
digits the format will be filled with zeros. If the number is greater than 8
digits, then the same number without any additional digits will be used.
The date format can be
added with the below mentioned steps.
Use the link What are the date or time symbols available in loadrunner
vugen? to know more about date formatsymbols
Once you learn about the symbols, you an follow below steps to
add the date format. Assume that
you want to create a date format of type month/date/year like
05/25/2011 (May 25, 2011) then how do you add? If you look into any of the
existing formats, those will not satisfy you requirement.
Follow the steps:
1) Open the parameter list
2) Create a new parameter
3) Select the parameter type as Date / Time
4) Enter "%m/%d/%Y" in Date / Time format text field
5) Click on add format
1) Open the parameter list
2) Create a new parameter
3) Select the parameter type as Date / Time
4) Enter "%m/%d/%Y" in Date / Time format text field
5) Click on add format
From the above format you can re-use the same for any new date
parameter.
Each occurrence, each iteration, and once for updating the value
options will be used for updating parameter valueduring the vuser execution.
each occurrence: Each time the parameter called in the script, a new value gets generated within each iteration
each iteration: For each iteration a new parameter value generated. If more than one occurrence is there is the script, within the iteration parameter value will be fixed.
once: For the entire test run, single parameter value will be generated. All the iterations and all the occurrences will be having fixed value
each iteration: For each iteration a new parameter value generated. If more than one occurrence is there is the script, within the iteration parameter value will be fixed.
once: For the entire test run, single parameter value will be generated. All the iterations and all the occurrences will be having fixed value
The modes available to choose the
next row, when the parameter type is file:
1) Sequential
2) Random
3) Unique
4) Same line as <other parameter name>, if there is more than one file type parameter is there
1) Sequential
2) Random
3) Unique
4) Same line as <other parameter name>, if there is more than one file type parameter is there
We use Same line as <paramrter name>, if there is more
than one file type parameter is there.
Assume that there are two parameters pUName, pPwd. U are reading these parameter values from a file.
You want to read the values from a file randomly.
If you read both pUName, pPwd parameters randomly. Since both
the parameters are independent random parameters, though they are pointed to a single file. To
make them dependent we need to choose pUName as Select next row as random and
for pPwd Select next row as as same line as pUName
The simulate parameter is not possible for a dependent
parameter.
The simulate parameter is possible for the parameter which is
chosen as
1) Sequential
2) Random
3) Unique..
1) Sequential
2) Random
3) Unique..
If the parameters is dependent with same line as the other
parameter. The other parameter line will be come theparameter
value of the dependent
parameter. So, the simulate parameter is not possible for a dependent
parameter.
There are two types of check
points supported by LR VuGen.
1) Text check points. The functions used for the text check are:
a) web_find
b) web_reg_find
2) Image check point. The function used for the image check is: web_image_check
1) Text check points. The functions used for the text check are:
a) web_find
b) web_reg_find
2) Image check point. The function used for the image check is: web_image_check
The image and text check, with the functions web_find and web_image_check will be
executed only when the proper run time settings are set. Follow the below steps
to do that
1) Select Menu Vuser -> Run Time Settings (or press F4)
2) Run-time Settings Dialog box opens
3) Select preferences in the left frame
4) Enable the Image and text check box
1) Select Menu Vuser -> Run Time Settings (or press F4)
2) Run-time Settings Dialog box opens
3) Select preferences in the left frame
4) Enable the Image and text check box
web_find: web_find
will be processed after the response of the request comes. So, this function
will be there after the request in VuGen script.
web_reg_find:web_reg_find will be processed before the request sent. And the check value will be checked in the response of the specific request. Thats the reason this function will be there before the request in VuGen script.
web_reg_find:web_reg_find will be processed before the request sent. And the check value will be checked in the response of the specific request. Thats the reason this function will be there before the request in VuGen script.
We can pass maximum two arguments to image
check point. Those are:
src Image server file name. In the source code of the web page you can see the src attribute value. Keep the value of src for verification.
alt Alternative Image Name. In the source code of the web page you can see the alt attribute value. Keep the value of alt for verification.
src Image server file name. In the source code of the web page you can see the src attribute value. Keep the value of src for verification.
alt Alternative Image Name. In the source code of the web page you can see the alt attribute value. Keep the value of alt for verification.
Additional attribute is a run time setting in VuGen and controller in loadrunner.
This is used for reading a
attribute value from run time settings.
This will be helpful, to pass any value to the test script from
run time settings. This will
overcome the limitations of parameters in VuGen. The parameters can be read and
edited from the VuGen script only. Cannot be edited from controller.
If you want pass some value to
the script from controller, we use additional attributes. Since additional
attributes are part of run time settings,
so it can be passed from controller. But there should be corresponding
functions written in VuGen script to read the values.
43.
How can you retrieve the additional attribute values from run time settings in
loadrunner vugen?
The additional attribute values from run time settings in vugen
can be retrieved using the function lr_get_attrib_<type of attribute>.
If you are retrieving the string type of attribute you use lr_get_attrib_string. The complete syntax for retrieving the value of a
attribute in a string will be written as
Define the variable sHostName.
char* sHostName;
sHostName = lr_get_attrib_string("aHostName");
Note: Here the aHostName is the additional attribute name,
defined in run time settings.
Using the variables directly in the VuGen test script is little
difficult. It involved lots of coding. So, to avoid using the variable values directly in test script, we convert
the variable values to a parameter and use them directly
in test script.
Converting the string variable
value to a parameter in loadrunner vugen can be done with lr_save_<type of
variable >
if you converting the string variable to a parameter use
lr_save_string(sHostName, "pHostName")
Note: in the above case sHostName is a variable and pHostName is
a parameter.
The function used for converting the parameter value to a string
value in vugen is lr_eval_< data type>
if you want to convert the parameter value to a string we use as
follows
sHostName = lr_eval_string("{pHostName}");
Note: In this case sHostName is a variable
pHostName is a parameter
pHostName is a parameter
The command used for printing the
values to replay log in vugen is lr_output_message. The usage is as follows
lr_output_message("Th value is :%s", val1);
Note: val1 is the string type variable, %s is the string format
as in C language
lr_output_message :
1) Used for printing the output value in the replay log as a message.
2) No info will be displayed in verify replay view.
3) Used for displaying any parameter or variable values
1) Used for printing the output value in the replay log as a message.
2) No info will be displayed in verify replay view.
3) Used for displaying any parameter or variable values
lr_error_message :
1) Used for printing the output value in the replay log as an error message.
2) The error message can also seen from verify replay view.
3) Used for displaying any parameter or variable values with a error message
1) Used for printing the output value in the replay log as an error message.
2) The error message can also seen from verify replay view.
3) Used for displaying any parameter or variable values with a error message
1) Additional attribute will be read from the run time settings
of controller or VuGen.
2) We can pass the values to VuGen test script from the run time settings.
3) When you you change the value of the additional attribute, you do not have recompile or restore the test script in controller.
2) We can pass the values to VuGen test script from the run time settings.
3) When you you change the value of the additional attribute, you do not have recompile or restore the test script in controller.
variable :
1) Variable will be defined in VuGen, based on the C data type.
2) Variable will be used for capturing any run time values or function return values.
3) When you change the value of the variable in the script, you have to recompile or restore the test script in controller.
2) Variable will be used for capturing any run time values or function return values.
3) When you change the value of the variable in the script, you have to recompile or restore the test script in controller.
parameter :
1) Parameter will be defined in VuGen to store parsed response results for server dynamic values like user session id,
item id which are automatically generated by the server .
2) Parameter will be used in the subsequent requests to successfully play back the script with captured dynamic servervalues .
3) When you change the parameter settings, you have to recompile or restore the test script in controller.
2) Parameter will be used in the subsequent requests to successfully play back the script with captured dynamic servervalues .
3) When you change the parameter settings, you have to recompile or restore the test script in controller.
Run logic is used for executing the test script
flow. Using run logic you can define
1) how many times the action to be iterated
2) You can also define a block
3) Inside the block, the way the actions sequence flow can be defined.
4) The action weight can be defined based on the percentage in a block for multiple actions
1) how many times the action to be iterated
2) You can also define a block
3) Inside the block, the way the actions sequence flow can be defined.
4) The action weight can be defined based on the percentage in a block for multiple actions
The sequence of action execution
and repetition in loadrunner can be done by using the run logic from run time
settings of loadrunner.
1) Mention the number of iterations for Action.
2) You can also define a block
3) Inside the block, the way the actions sequence flow can be defined.
4) The action weight can be defined based on the percentage in a block for multiple actions
1) Mention the number of iterations for Action.
2) You can also define a block
3) Inside the block, the way the actions sequence flow can be defined.
4) The action weight can be defined based on the percentage in a block for multiple actions
Pacing is used for wait time between the action iterations.
Your customer says that he needs 600 user sessions to be created
with max of 100 users in 1 hour. And script execution takes around 30 Sec. To
simulate this scenario, you can give a pacing setting as follows.
600 user sessions with 100 users -> so total number of
iterations would be -> 6 per user
6 iterations in 1 hour -> so the session duration would be -> 60/6 = 10 min per user
session.
So you need to select the setting-> Start new Iteration at
"Fixed" intervals 600 sec. provided the previous iteration ends by
that time.
As soon as the previous iteration ends. The new iteration begins as soon as the previous iteration ends.
After the previous iteration ends with a fixed or random delay of ... Starts each new iteration a specified amount oftime after the end of the previous iteration. Specify either an exact number of seconds or a range of time. For example, you can specify to begin a new iteration at any time between 100 and 150 seconds after the previous iteration ends.
After the previous iteration ends with a fixed or random delay of ... Starts each new iteration a specified amount oftime after the end of the previous iteration. Specify either an exact number of seconds or a range of time. For example, you can specify to begin a new iteration at any time between 100 and 150 seconds after the previous iteration ends.
When you run the script, VuGen shows the time the Vuser waited
between the end of one iteration and the start of the next one, in the
Execution Log.
At fixed or random intervals, every ... [to ...] seconds. You specify the time between iteration—either a fixed number of
seconds or a range of seconds from the beginning of the previous iteration.
To enable extended logging in loadrunner, follow the
below steps mentioned :
1) Select Menu option
Vuser -> Run-time settings
2) Run-time settings dialog pops up
3) Select the Log from left frame in the dialog
4) Ensure the "Enable Logging" is checked
5) Select the radio button "Always send message"
6) Select the radio button "Extended Log"
2) Run-time settings dialog pops up
3) Select the Log from left frame in the dialog
4) Ensure the "Enable Logging" is checked
5) Select the radio button "Always send message"
6) Select the radio button "Extended Log"
The options available in
extended log are:
a) Parameter substitution:
Parameter substitution should be enabled, if you want the parameter and it values to be displayed in the log during the run time.
Parameter substitution should be enabled, if you want the parameter and it values to be displayed in the log during the run time.
b) Data returned by server:
During the replay, if you want to see the Request headers, Response header and response body in replay log enable this option.
During the replay, if you want to see the Request headers, Response header and response body in replay log enable this option.
c) Advanced trace:
During the replay, select this option to log all of the functions and messages sent by the Vuser during the session. This option is useful when you debug a Vuser script.
During the replay, select this option to log all of the functions and messages sent by the Vuser during the session. This option is useful when you debug a Vuser script.
The disadvantaged of using extended log when the load test is long duration in loadrunner controller:
When the log is enabled the response times get skewed. Because
of
1) high data on the load generators
2) High disk reads and writes on load generators
3) the high network resource consumption
1) high data on the load generators
2) High disk reads and writes on load generators
3) the high network resource consumption
Assume that for single user, when the test script runs for one
iteration the log generated on the disk is 1MB.
When the load test is running for 1000 users for 10 iterations the log size is going to be around 10GB.
If the load test is extended for 1000 users for 1000 iterations the log is going to be 1TB.
When the load test is running for 1000 users for 10 iterations the log size is going to be around 10GB.
If the load test is extended for 1000 users for 1000 iterations the log is going to be 1TB.
Hope now you understood the size of the log. So we enable the
log only if it is required.
We may use extended log when very few users are running the
system.
See the article with high data usage:What are the dis advantaged of using extended logging
when the load test is long duration in loadrunner?
To overcome the disadvantages of high data usage, we set the log to standard log.
When the load test is
long duration,
we set the log level to very minimal or no log.
Mostly we set the log level to standard log. We also select the
radio button "Send message only when an error occurs"
With the above setting the log will be generated only when error occurs. And we need to analyze the
erroneous pages. So this is the optimum selection for the log, when the load test is very long duration
Ignore think time is the default setting in VuGen Run-tiime
Settings.
When you run the test script
from VuGen, you are debugging a test script or enhancing the script. In that
case you do not have to simulate the think times. Because, you do not want to
spend more time during running the script.
We use the think times, when run the tests from load runner controller for multiple users.
The reason is we always want to simulate the users as they are
working in real time. The real time users normally wait between the user actions, for
understanding the content on the page or for filling the data on the pages.
Since the user wait time between the requests is captured as think time. The
think time need to be used during the actual load test. If we use the think time, the test run will be
near to the real users activity. If we do not use the think time, it will become
a stress test.
the options available to replay think times in loadrunner
are as follows
Ignore think time. Ignore the recorded think time—replay the script ignoring all lr_think_time functions.
Replay the think time. The second set of think times options let you use the recorded think time:
Ignore think time. Ignore the recorded think time—replay the script ignoring all lr_think_time functions.
Replay the think time. The second set of think times options let you use the recorded think time:
As recorded. During replay, use the argument that appears
in the lr_think_time function. For example, lr_think_time(10) waits ten
seconds.
Multiply recorded think time by. During replay, use a multiple of the recorded think time. This can increase or decrease the think time applied during playback. For example, if a think time of four seconds was recorded, you can instruct your Vuser to multiply that value by two, for a total of eight seconds. To reduce the think time to two seconds, multiply the recorded time by 0.5.
Use random percentage of the recorded think time. Use a random percentage of the recorded think time. You set a range for the think time value by specifying a range for the think time. For example, if the think time argument is 4, and you specify a minimum of 50% and a maximum of 150%, the lowest think time can be two (50%) and the highest value six (150%).
Limit think time to. Limit the think time's maximum value.
Multiply recorded think time by. During replay, use a multiple of the recorded think time. This can increase or decrease the think time applied during playback. For example, if a think time of four seconds was recorded, you can instruct your Vuser to multiply that value by two, for a total of eight seconds. To reduce the think time to two seconds, multiply the recorded time by 0.5.
Use random percentage of the recorded think time. Use a random percentage of the recorded think time. You set a range for the think time value by specifying a range for the think time. For example, if the think time argument is 4, and you specify a minimum of 50% and a maximum of 150%, the lowest think time can be two (50%) and the highest value six (150%).
Limit think time to. Limit the think time's maximum value.
Thread
1) if you run each Vuser as a thread, the Controller launches only one instance of the driver program (such as mdrv.exe), for every 50 Vusers (by default). This driver process/program launches several Vusers, each Vuser running as a thread. These threaded Vusers share segments of the memory of the parent driver process. This eliminates the need for multiple re-loading of the driver program/process saves much memory space, thereby enabling more Vusers to be run on a single load generator.
2) The main advantage of a multi thread environment is the ability to run more Vusers per load generator.
3) Only thread safe protocols should be run as threads.
1) if you run each Vuser as a thread, the Controller launches only one instance of the driver program (such as mdrv.exe), for every 50 Vusers (by default). This driver process/program launches several Vusers, each Vuser running as a thread. These threaded Vusers share segments of the memory of the parent driver process. This eliminates the need for multiple re-loading of the driver program/process saves much memory space, thereby enabling more Vusers to be run on a single load generator.
2) The main advantage of a multi thread environment is the ability to run more Vusers per load generator.
3) Only thread safe protocols should be run as threads.
Process
1) If you run each Vuser as a process, then the same driver program is launched (and loaded) into the memory again and again for every instance of the Vuser. Loading the same driver program into memory uses up large amounts of RAM (random access memory) and other system resources. This limits the numbers of Vusers that can be run on any load generator.
2) The protocols Sybase-Ctlib, Sybase-Dblib, Informix, Tuxedo, and PeopleSoft-Tuxedo are not thread safe, so need to run as process
1) If you run each Vuser as a process, then the same driver program is launched (and loaded) into the memory again and again for every instance of the Vuser. Loading the same driver program into memory uses up large amounts of RAM (random access memory) and other system resources. This limits the numbers of Vusers that can be run on any load generator.
2) The protocols Sybase-Ctlib, Sybase-Dblib, Informix, Tuxedo, and PeopleSoft-Tuxedo are not thread safe, so need to run as process
We use the network speed simulation
in loadrunner for limiting the bandwidth usage.
Assume that your LAN is having 10Gbps bandwidth. And, if the
real users is using 128 Kbps in real time. If you want to simulate such user
behavior we need to limit the network usage, by way of limiting the speed
simulation.
Emulate browsers is nothing but emulating the browser settings
during the load
test execution. Since the
load runner is not going to use the actual browser, the browser setting will be emulated based on the settings
provided.
Follow the steps to
emulate the browser settings:
1) Open the menu option Vuser -> Run-time Settings
2) Run-time Settings Dialog box opens
3) Select Browser Emulation from left navigation
4) Click on Change button
5) User Agent Dialog box opens
6) Choose your browser with version and OS
1) Open the menu option Vuser -> Run-time Settings
2) Run-time Settings Dialog box opens
3) Select Browser Emulation from left navigation
4) Click on Change button
5) User Agent Dialog box opens
6) Choose your browser with version and OS
If you have proxy to communicate with any external sites. We may
need to configure the proxy settings in the broswer for recording.
Since the loadrunner does not use the browser during replay. We
need to give the proxy settings in the run time settings of the controller or
VuGen. Then the requests will be sent through the proxy.
Follow the steps to
emulate the browser settings:
1) Open the menu option Vuser -> Run-time Settings
2) Run-time Settings Dialog box opens
3) Select Proxy settings Emulation from left navigation, under Internet Protocol
4) Select the custom proxy
5) And give the settings as required
1) Open the menu option Vuser -> Run-time Settings
2) Run-time Settings Dialog box opens
3) Select Proxy settings Emulation from left navigation, under Internet Protocol
4) Select the custom proxy
5) And give the settings as required
Script wide rule is used for checking the common content on all
the pages. If any page is not having the expectedcontent, the script throws an error and aborts the
test. So, when you choose the script wide rule, you have to be very careful in
giving the common expected content.
Follow the below mentioned steps to add script wide rule:
1) Open the menu option Vuser -> Run-time Settings
2) Run-time Settings Dialog box opens
3) Select Content Checks from left navigation, under Internet Protocol
4) Check the check box of Enable Content check during replay
5) Click on New Application button -> Give the application name
6) Click on New Rule button -> Give the Rule name
7) Enter the Search for Text, which is there in all the pages
1) Open the menu option Vuser -> Run-time Settings
2) Run-time Settings Dialog box opens
3) Select Content Checks from left navigation, under Internet Protocol
4) Check the check box of Enable Content check during replay
5) Click on New Application button -> Give the application name
6) Click on New Rule button -> Give the Rule name
7) Enter the Search for Text, which is there in all the pages
Simulate parameter can be opened with the below
mentioned steps:
1) Select the Menu option Vuser -> Parameter List
2) Parameter List dialog box opens
3) Select a parameter in the left pane
Note: ensure that the parameter type should be File type only. For other types of parameters simulate parameter will not be there.
4) On the right pane, under the data table Simulate parameter button will be there.
5) Click on Simulate parameter
6) Simulate parameter Dialog box opens.
1) Select the Menu option Vuser -> Parameter List
2) Parameter List dialog box opens
3) Select a parameter in the left pane
Note: ensure that the parameter type should be File type only. For other types of parameters simulate parameter will not be there.
4) On the right pane, under the data table Simulate parameter button will be there.
5) Click on Simulate parameter
6) Simulate parameter Dialog box opens.
The following table explains about the date/time symbols:
Symbol
|
Description
|
c
|
complete date and time in digits
|
#c
|
complete date as a string and time
|
H
|
hours (24 hour clock)
|
I
|
hours (12 hour clock)
|
M
|
minutes
|
S
|
seconds
|
p
|
AM or PM
|
d
|
day
|
m
|
month in digits (01-12)
|
b
|
month as a string - short format (e.g. Dec)
|
B
|
month as a string - long format (e.g. December)
|
y
|
year in short format (e.g. 03)
|
Y
|
year in long format (e.g. 2003)
|
During the recording time, only the requests will be captured into the
test script.
When the script is seen from the tree view in web based application,
the response pages corresponding to the request node can be seen. But the
responses are not part of the test script. The response for the requests is
captured as part of the recorded log, which will be there in the data folder
inside the test script folder.
The types of files not recommended for parameterization in
loadrunner vugen are:
1) .xls
2) .mdb
3) database connection or data source
1) .xls
2) .mdb
3) database connection or data source
The above two files requires driver for reading the data. Which will become heavy for
each virtual users. So, that is why load runner is not been implemented with
.xls and .mdb file support.
Database connection
is not recommended for parameterization. When one does the parameterization using databaseconnection
in the test script. Each virtual user is going to connect to the database, to fetch the data for
parameterization. So, there are one dedicated connection is wasted just to
fetch the data from database. And
the same virtual user is going to hit through the application as well.
The database connection is an resource consuming
operation. So, it is not recommended to have a parameterization directly with database in load testing.
