LoadRunner Scripting Guidelines
1 Executive Summary............................................................................ 3
1.1 Objectives.................................................................................. 3
1.2 Document Structure...................................................................... 3
1.3 Assumptions............................................................................... 3
2 Script Development Procedure.............................................................. 4
2.1 Pre Script Preparation................................................................... 4
2.2 Recording the Script...................................................................... 6
3 Script Format & Documentation Standard............................................... 13
3.1 Script Header............................................................................. 13
3.2 Parameter length Setting............................................................... 13
3.3 web_reg_save_param Statements.................................................... 14
3.4 Comments................................................................................ 14
3.5 Think Time................................................................................ 14
3.6 User Messages............................................................................ 15
3.7 Verification Checks...................................................................... 15
3.8 Use of Flags to Control Script Flow................................................... 17
3.9 Parameter Capture on Exit............................................................ 18
3.10 Use and Location of Data Files...................................................... 18
4 Debugging Tips................................................................................ 19
4.1 Useful Tools.............................................................................. 19
4.2 Run the Script............................................................................ 22
4.3 Re-Record The Script.................................................................... 22
4.4 Re-Record with Correlation Turned Off.............................................. 23
4.5 Parameter Capture Tips................................................................ 23
5 Terminology................................................................................... 24
5.1 LoadRunner Objects..................................................................... 24
The objective of this document is to set down in a permanent form the lessons I have learned about the recording, debugging, and formatting of LoadRunner scripts.
This document will be a resource both for experienced team members to use as a reference, and for those team members who are learning to create scripts to use as a training guide.
This document is broken up into three sections, each of which covers a different aspect of script development.
Script Development Procedure
This section details the steps to go through when creating a script. When followed, these steps should save a lot of time and effort, because the resulting scripts will be well structured, robust, and maintainable.
Script Format & Documentation Standard
This section details the formatting and documentation standards that should be applied to scripts. When applied, these standards will make scripts understandable and maintainable, and therefore more easily re-used.
Debugging Tips
Some useful techniques, and traps for the unwary, that can be used to help find where a script is falling over.
It is assumed that the determination of which part(s) of the application to script, and the identification of scripts that need to created has already been done. These activities are outside the scope of this document.
Using the correct script development procedure can make the life of a scripter a lot easier. Firstly it makes sure that you know what you are doing before you start to record. Secondly, while recording you are using Actions and comments throughout so that the resultant code will be easy to navigate. Thirdly both of these things will save you time in the long run.
Script development generally follows three phases: preparation; recording; and parameterisation and debugging.
There are three main pre-script preparation activities, these are to decide on a Naming Convention; Document the Navigation sequence; and Practice the Navigation.
Naming Convention
When the project requires a number of scripts to be written it is wise to use a naming convention. This allows each script to be identified uniquely both during development, and execution. This avoids any confusion about which script is being referred to at any time.
The naming convention should also be extended to the Transactions within each script, and the Datafiles used by the scripts. This ensures that the Transactions can be traced to the script in which they were executed and that datafiles specific to a particular script can be easily found.
Naming Convention (as used by the ISI project)
Script:
Group_SubGroup.ID_DescriptiveTitle
Examples:
ESS_1.1_Logon_Logoff
ESS_3.1_Timesheet_Entry
ESS_3.2_Timesheet_Approve
MDT_1.1_Logon_Logoff
Transaction:
Group_SubGroup.ID_SequenceNo_DescriptiveTitle
Notes:
The Transaction names should include the Script ID, plus a sequence number, so that the order in which the transactions are executed can be identified, plus a descriptive title.
Where the same transactions are executed within different scripts, all of these common transactions should have the same name. This prevents clutter of the test results, and it ensures that the response times for those transactions are accurately reported.
Examples:
MDT_1.1_1_Logon (common login transaction for all MDT scripts)
MDT_1.1_2_Enter_Managers_Desktop (common transaction for all MDT scripts)
MDT_1.1_3_Logoff (common transaction for all MDT scripts)
MDT_5.1_1_Expand_Menus (first script specific transaction)
MDT_5.1_2_Click_Payroll_Validation
MDT_5.1_6_Exit_Report (last script specific transaction)
Data Files:
Group_SubGroup.ID_DescriptiveTitle
Notes:
The data file names should include the script ID plus a descriptive title. In general datafiles specific to a script must be stored in the script’s directory. Also where a data file is used by multiple scripts. It is preferable for each script to have its own copy, stored in each script’s directory. This is so that when a script is moved, the datafiles go with it, making the scripts portable both within, and between systems.
The exception to this is when two or more scripts must have unique data between them to avoid clashes and lockups. In this case these scripts must share them same datafile.
Examples:
ALL_1.0_Connect_Params (common to all scripts)
ESS_1.1_Staff_Users (common to all ESS scripts)
ESS_5.1_Personal_Details (specific to the ESS_5.1 script)
Document the Navigation Sequence
Before attempting to record a script it is important to know what steps it is going to follow, what data needs to be entered, and what checks need to be made to ensure that it is working properly during execution.
Determine the Navigation Sequence
Either from documentation, or a domain expert, find out the steps involved and run through them.
If using a domain expert, have the domain expert go through the navigation ON THE SYSTEM, while you take notes. Ask any questions necessary to ensure that there is no ambiguity about the steps, or the data to be entered.
Create a Text File
Write your note into a text file. This can then be pasted into your script header, and any documentation such as a test case.
Practice the Navigation
Go through the steps you have written as many times as necessary to ensure that you are confident of reproducing them while recording the script. Make additions to your notes if required.
The final sequence should contain the steps required, and for each step, any data to be entered, and the expected result.
Example:
Open the MDT
Expand Menus Employee Administration > Reports > Leave
Select the top level on right hand side
Click Leave Balances
Leave the default settings and click the Execute button
(execution takes a while)
Report displayed - Leave Liability report - New Zealand
Exit the report - back to previous screen
Exit - back to MDT
Exit - MDT
Prior to recording the script, it is important to ensure that VUGen has the correct settings. It is also useful to pre-determine the Actions that you intend to use. During recording you should enter comments, and possibly Actions and Transactions.
Script Protocol
It is important that the correct protocol is selected as use of the wrong one can mean costly rework and lost time.
Generally as most of the applications that we are testing are Web based, we use the Web(HTTP/HTML) script protocol. The selection of this protocol is shown in the screen shot below.
The use of other protocols is currently beyond the author’s experience. The other likely protocol that may be used in our environment is the Web/Winsocket Dual Protocol, also shown below.
Advice should be sought before using any protocol other than the Web(HTTP/HTML).
VUGen Recording options
Prior to recording the script, it is important to ensure that the Recording Options are set correctly. Again, selection of the wrong recording options can mean, extra work, rework and lost time.
Generally the default Recording Options are correct. However there are a few exceptions.
1. The complexity of the scripts that we write generally requires that the script be URL based, rather than the default, which is HTML based. This setting is shown below.
2. To facilitate the inclusion of checks to verify correct operation of the script, it is useful to turn on the “Generate web_reg_find functions for page titles”. This automatically inserts web_reg_find statements for each page title while recording. These statements can then be used as checks during execution to pass/fail the script. Any unwanted ones can be commented out or deleted during the later stages of development. This setting is shown below.
3. When recording scripts for SAP applications, I have found correlation during recording to be useful. When using this function I have found that the setting to “Perform correlation in script” to be the best. Also it is important that the correct Action in the correlation rule is important for optimum operation and time saving. The default setting for the AutoDetect_MySap1 rule of “Search for parameters in links and form actions” is the correct one to use. These settings are shown below.
Use of Actions
The use of actions within a script depends largely on the structure of the script, and the application under test. This document deals with the use of actions during the recording process.
There are two ways to add Actions to a script in the recording phase. These are to create and name the Actions in the new script before recording, or to create them on the fly while recording.
I prefer to set up the Actions prior to the recording. This means one less thing to think about during recording. It should be easy to work out the Actions required, once the navigation is known.
For those who prefer to create Actions during recording, this is also a valid approach.
Once the Actions have been created, it is important to give them descriptive names that describe what they do.
Use of Transactions (timers)
As with Actions, Transaction Start and End points can be added to a script in two ways. These are to add them during recording or after the recording is completed.
I prefer to add Transactions to the script after the recording. This allows the placement of the Transaction start and end points to be made correctly. It also allows the naming convention to be applied to the transaction.
If transactions are added to the scrip during recording, their placement, naming, and think time generated while they are being entered, will need to be checked, adjusted and/or removed afterwards.
In general ALL functionality must be covered by a Transaction. This way the full time taken for the script to execute can be determined. Also ensure that there are no think times within transactions. These would give consistently wrong response times if left in.
Use of Comments
During recording it is important to add a comment at each step. This ensures that when working on the recorded code later, it will always be possible to identify which part of the script applies to which step in the navigation.
This means that when I insert the Transactions I generally get an lr_end_transaction followed by a comment and a lr_start_transaction as follows:
lr_end_transaction("ESS_9.1_1_Open_Change_Address_Details", LR_AUTO);
/*
* Address Page Loaded
*/
lr_think_time( 5 );
lr_start_transaction("ESS_9.1_2_Click_Change");
Note that the think time is between transactions and not within them.
Comments should also be placed at the locations where web_reg_save_param statements are added, to identify what the captured parameter is used for.
For example:
/* search for HR dept processing data message */
web_reg_save_param("HRProcessingData","LB=webguiMessageLine = \"","RB=\";","Ord=1","NotFound=EMPTY","Search=All",LAST);
web_reg_save_param("MySapSessionID2","LB/IC=/scripts/wgate/","RB/IC=\"","Ord=3","Search=body","RelFrameId=1",LAST);
web_submit_data("~flN0YXRlPTI1ODI2LjAwMS4wMi4wMg==",
Script Version Control
I like to keep up to three versions of each script, the recorded version, the current version, and if the script has been updated, the old version.
I always keep the original recorded version of the script under the name “ScriptName_RECORDED”. This version is useful during development in two main ways. I use the Recording log to find where the values I wish to capture occur. I also use it as a back up in case of a catastrophic cut and paste, or find/replace error; it will always have the original values in it. If necessary you can always start again from scratch, but without needing to re-record. Another useful feature is the recording snapshots. These have been useful to identify changes to the system that may have occurred since the recording was made. By comparing the recorded snapshot with the current page any changes can be identified.
The current version of a script is obvious. It has the name “ScriptName” and is the one that is used for load testing.
I always keep the previous version of the script under the name “ScriptName_OLD”. This version has two uses. If the functionality change that forced the script to be updated is reversed, then you can revert to the old version. Secondly I use it during script update activity so that I can copy the features I added to it into the new recording.
When updating a script I follow the following steps:
· Save the current script as an old version, “ScriptName” -> “ScriptName_OLD”
· Copy (don’t use Save As, use copy and paste) the new recording into the script, “ScriptName_RECORDED” -> “ScriptName”
· Copy the transactions, and web_reg_find statements from the OLD script as these are usually exactly the same in the new version, “ScriptName_OLD” -> (features) -> “ScriptName”.
· By using Copy from the RECORDED version into the “current” version of the script, the parameter and runtime settings of the script are retained, saving time adding them in again.
Once the script is finished/updated the OLD and RECORDED versions of the script can be moved into an OLD directory and eventually deleted.
It is important that all scripts are formatted and documented to the same standard. This makes it much easier for others to understand and maintain the scripts later on.
The script header contains details about the recording date, the author, the navigation steps, and any, maintenance changes made to the script.
Where a script uses a common action i.e. for login and logout, it will be necessary to insert a separate header for each action.
The header looks like this:
/*********************************************************************************/
/* Script Name: MDT_4.1_Dis_Lve_Bal */
/* */
/* Description: Opens the MDT */
/* Expand Menus Employee Administration > Reports > Leave */
/* Select the top level on right hand side */
/* Click Leave Balances */
/* Leave the default settings and click the Execute button */
/* (execution takes a while) */
/* Report displayed - Leave Liability report - New Zealand
/* Exit the report - back to previous screen */
/* Exit - back to MDT */
/* Exit - MDT */
/* */
/* Author: Michael Foster Date: 19/05/2003 */
/* */
/* Comments: */
/* NOTE: This script assumes that the MDT opens on the */
/* "People Manager: Employee Administration" page. */
/* */
/* Change History: */
/* */
/* */
/*********************************************************************************/
The statement below should be inserted at the beginning of the script. It sets the maximum length of any parameters captured by web_reg_find and web_reg_save_param statements. The default value is 1024.
web_set_max_html_param_len("4096");
Note that VUGen often places this statement within a web_concurrent_start / web_concurrent_end group. This will cause an error. The statement must be outside any such group.
When VUGen inserts web_reg_save_param statements into a script, they are formatted over multiple lines. This makes them harder to read when there are multiple parameters captured on the same post statement.
This is how the automatic formatting looks:
web_reg_save_param("MySapSessionID2",
"LB/IC=/scripts/wgate/",
"RB/IC=?",
"Ord=2",
"Search=Body",
"RelFrameId=1",
LAST);
web_submit_data("~flN0YXRlPTE0NjUwLjAwMS4xNi4xOQ==_3",
This is how it should look (note that the middle was deleted so that it will fit on one line of this document):
web_reg_save_param("MySapSessionID2",/deleted/,"RelFrameId=1",LAST);
web_submit_data("~flN0YXRlPTE0NjUwLjAwMS4xNi4xOQ==_3",
This also applies to web_reg_find statements.
Comments should be added wherever necessary to explain the operation of the script. Generally these are at each step of the navigation, where parameters are captured, and wherever extra functionality is added, or changes are made, including the date when the change occurred.
Think time statements need to be managed carefully. A missed or misplaced think time statement can artificially increase a response time.
Think times are necessary to simulate user activity, but they need to be placed in the correct location within the script. These locations are generally, between script steps, and sometimes at the start or end.
Think times must not be placed within a transaction timer. This would artificially increase that particular response time by the fixed amount of the think time, making the results invalid.
It is a good practice to use lr_vuser_status_message statements to allow the progress of the script to be tracked during execution.
For example, the following statement should be included near the start of the script. This is most useful as it gives the iteration and user ID:
lr_vuser_status_message("Iteration%4d ,Login ID = %s", atoi(lr_eval_string("{IterationNumber}")), lr_eval_string("{UserName}"));
Other points where these statements are useful include when the script fails (see next section) and when a decision point is reached, such as when conditional navigation is used in the script.
It is most important that checks be placed into the script to verify that the scripted operation is behaving correctly under load. Generally there are two checks that should be made in each script. These are at login (if a login is required), and at the culmination step of the navigation (when notification of the success of the operation is displayed).
Ideally checks should be made at each navigation step (time doesn’t always permit this). Having a series of checks through the script has two benefits. First it will catch a problem as soon as it occurs without waiting until the end of the script before failing. Also it allows the step at which the failure occurred to be identified. This will allow the cause of the failure to be identified more quickly and appropriate action taken.
Checks usually involve the capture of either a page title, or a text message that notifies that the operation has been successful. Other checks are used to ensure that the required data is available before the next step is taken.
Here is an example of a login check (note the flag that is set upon success of the check, more about this later):
web_reg_save_param("VerifyWelcome","LB=SIappdoctitle\" nowrap>","RB=<","Ord=1","RelFrameId=1","Search=body","SaveLen=7","NOTFOUND=warning", LAST);
web_url("~flN0YXRlPTI1ODIxMzIwODU=2",
"URL=http://{SAPServerDOMAIN}:8100/scripts/wgate/{MySapSessionID3}?~next_template=homeArea&sapwp_debug=&mix_personalization=X&~design=&~designbaseurl=",
"Resource=0",
"RecContentType=text/html",
"Referer=http://{SAPServerDOMAIN}:8100/scripts/wgate/{MySapSessionID2}",
"Snapshot=t5.inf",
"Mode=HTTP",
LAST);
if (strcmp(lr_eval_string("{VerifyWelcome}"),lr_eval_string("Welcome"))!=0) {
lr_vuser_status_message( "It %4d *** Logon Failed *** (%s)",
atoi(lr_eval_string("{IterationNumber}")),
lr_eval_string("{UserName}") );
lr_error_message( "It %4d *** Logon Failed *** (%s)",
atoi(lr_eval_string("{IterationNumber}")),
lr_eval_string("{UserName}") );
lr_end_transaction("MDT_1.1_1_Logon", LR_FAIL);
return 1;
}
CurrentlyLoggedIn = 1;
Here is an example of a page title check:
web_reg_save_param("VerifySuccess","LB=title>","RB=<","Ord=1","RelFrameId=1","Search=body","NOTFOUND=warning",LAST);
web_submit_data("~flN0YXRlPTE5MDkzLjAwMS4wNi4wNg==_3",
-
-(rest of lines removed here)
-
LAST);
if (strcmp(lr_eval_string("{VerifySuccess}"),lr_eval_string("Overview Basic pay"))!=0) {
lr_vuser_status_message( "It %4d *** View Basic Pay Failed *** (%s)",
atoi(lr_eval_string("{IterationNumber}")),
lr_eval_string("{UserName}") );
lr_error_message( "It %4d *** View Basic Pay Failed *** (%s)",
atoi(lr_eval_string("{IterationNumber}")),
lr_eval_string("{UserName}") );
lr_end_transaction("MDT_10.1_2_View_Basic_Pay", LR_FAIL);
return 1;
}
Here is an example of a check to ensure that the correct page/or data is displayed before the script can continue. Note that in this case it may be more accurate to use an LR_STOP instead of LR_FAIL because the lack of data may not be a failure:
web_reg_find("Text=People Manager: Employee Administration", "SaveCount=ManagersDesktopCount", LAST);
web_url("!_4",
"URL=http://{SAPServerDOMAIN2}:8100/scripts/wgate/webgui/!?~client=200&..DELETED",
"Resource=0",
"RecContentType=text/html",
"Referer=http://{SAPServerDOMAIN}:8100/scripts/wgate/sapwp66074791/..DELETED",
"Snapshot=t17.inf",
"Mode=HTTP",
LAST);
if (strcmp(lr_eval_string("{ManagersDesktopCount}"), "0") == 0) {
lr_vuser_status_message( "It %4d *** Open Manager's Desktop Failed *** (%s)",
atoi(lr_eval_string("{IterationNumber}")),
lr_eval_string("{UserName}") );
lr_error_message( "It %4d *** Open Manager's Desktop Failed *** (%s)",
atoi(lr_eval_string("{IterationNumber}")),
lr_eval_string("{UserName}") );
lr_end_transaction("MDT_1.1_2_Enter_Managers_Desktop", LR_FAIL);
return 1;
}
Note the use of both an lr_user_status_message and an lr_error_message in the event the check fails. The lr_error_message is most useful because it is stored in the controller’s error log, and so it is available as a permanent record that can be used at the completion of a test to investigate errors.
A useful technique that can be used to skip actions that become redundant or invalid, such as when the login fails, is with the use of a flag.
The use of a flag is quite simple, an integer variable is created and initialised in the vuser_init() action, the flag is set/reset after a check statement, and it is re-initialised at the end of the script.
For example the vuser_init action would contain the following:
int CurrentlyLoggedIn = 0; /* 0 = not currently logged on */
vuser_init()
{
return 0;
}
In the script body after the login is confirmed to have passed (as shown in a previous section) the following statement is inserted:
CurrentlyLoggedIn = 1;
Then the following statement is added to the start of all following actions:
if (CurrentlyLoggedIn == 0) { /* Don't continue if have not yet logged on!! */
return;
}
Then most importantly the flag must be reset at the end of the script. This is necessary because the vuser_init action is executed only once per test, and if there are multiple iterations, after the first successful login, the flag will always be set (falsely indicating successful logins) without this statement:
CurrentlyLoggedIn = 0;
One thing to note is that it is just as necessary to parameterise variables on the script steps that exit the application as it is on entry to the application. This is because if the script doesn’t correctly exit it can leave open sessions that can cause problems with the system under test.
So when debugging the script, don’t stop at the operation notification step, continue right through to the end and ensure that the script exits the application correctly.
Script specific parameters should be stored in a separate data file. Parameters that are common to more than one script should be stored in a common data file. The names of these data files must follow the naming convention specified earlier in this document.
The locations of data files depend on their use. Script specific data files must be stored in the same directory as the script. Also where scripts will not interfere with each other if they both use the same parameter value at the same time, they should each have a copy of the common data file(s) stored in the script directory.
The reason for storing data files with each script is script portability. When the script is copied the data files will be copied with it. This makes the reuse of scripts, and the transfer of scripts between systems much simpler.
Where multiple scripts must share the same data file to ensure uniqueness of the parameter then this common file should be stored on the C: drive. Simply because every PC has a C: drive. In addition to this each script should have a copy of the common file in its directory just to ensure that when that script is copied, there is a copy of the data file that goes with it.
There are a number of tools built into VUGen that can aid debugging. These are the Execution and Recording logs, the tree view display, the Test Results window, and the Runtime Viewer.
Logs
The Recording log contains all of the data returned by the server in addition to what was sent to it. This is useful for identifying the locations of parameters that must be captured. It is also useful at times as a comparison to the Execution log.
The Execution log has a number of settings. The most used are the Extended Log settings: Parameter substitution; and Data returned by server. Generally I always keep the Parameter substitution turned on as it shows that the script is working properly. The Data returned by server setting is useful when identifying parameters to be captured, and for checking that the data that you wish to capture is being returned by the server when you execute the script.
The advantage of the Execution log over the Recording log is that the Execution log is linked to the step in the script which generated the response. Beware though that as soon as you add or delete a line from the script, this linkage is broken until you next execute the script.
Tree View
Selecting the Tree View and selecting each script step will display the page returned as a result of that script. This is useful for determining if your script worked correctly.
Test Results
The test results window will identify where a script caused an error. It will also like the tree view provide a snapshot of the returned page that is useful for checking correct script execution.
Runtime Viewer
The runtime viewer is useful for displaying the returned web pages from your script as it is running. This is useful when you are trying to see a problem occur during the script execution, or to do a final check that it is working properly.
I say this because the runtime viewer has limitations. It slows down the execution, it can’t display multiple frames, it shows them one at a time, it can’t display PDF files, and sometimes it can hang up the script (until it is closed). Therefore I prefer to use the other tools and only turn on the runtime viewer when necessary.
Make sure that the options to view Active X and JavaScript are turned on in the viewer window.
After recording the script, adding comments, transactions, parameter capture and substitution, and check statements, it is time to hit the execution button and see what happens.
Then by using the tools listed above determine how the script performed and make changes if necessary.
By comparing the differences between the first and second recordings, it should be possible to identify differences that are dynamic values that need to be parameterised.
It is not necessary to re-record the whole script. Only the section of the script where the problem is occurring needs to be re-recorded. This can be done into a dummy Action within the script that you are working on.
Where automatic correlation has been used as for MYSAP, to aid understanding of what is actually happening with the script, especially what the correlated data looks like, it can be useful to re-record the script with the correlation turned off.
If your parameter is not being captured one reason could be that it is within a concurrent group. If the post that generates the text to be captured is between an lr-concurrent_start and lr-concurrent_end then this may be the problem. Try commenting out the concurrent start and end statements.
There are three levels of script readiness.
Level One: Does it execute successfully once.
Level Two: Does it execute successfully for multiple iterations.
Level Three: Does it execute successfully multiple times with multiple Vusers.
Level 1 Single Iteration
The definition of success is that there were no errors or failed transactions, and the operation that the script is simulating was successfully carried out without any errors generated in the application.
Level 2 Multiple Iterations
Once the script runs successfully for a single iteration, it must be tested for multiple iterations. A rule of thumb is to test it over 10 iterations. Generally try it for 2 or 3 iterations first, and once that works run it for 10 as a final test.
This of course assumes that it is valid to execute the script for this number of iterations and that there is enough data to do so.
Level 3 Multiple Iterations and Multiple VUsers
Once the script runs successfully for multiple iterations it is not considered to be 100% ready until it runs for both multiple iterations and multiple VUsers.
Create a test scenario in the controller, add the script and set it to run for 10 iterations with 10 Vusers. Once the script executes successfully for 10x10 then it is 100% ready.
Again this assumes that 10 iterations and 10 VUsers are valid for this script. Lower numbers can be used if necessary.
Script Sociability
This point could equally be called Script Level 4 or Scenario Level 1. However where there are multiple scripts within a test scenario, all of the scripts should be run together to ensure that they are sociable. Issues that arise are usually data related such as User Ids and dates.
| Term | Definition |
| Vuser Scripts | A Vuser script describes the actions that a Vuser performs during the scenario. Each Vuser executes a Vuser script during a scenario run. The Vuser scripts include functions that measure and record the performance of your application’s components. |
| Load Test | Tests a system's ability to handle a heavy workload. A load test simulates multiple transactions or users interacting with the computer at the same time and provides reports on response times and system behavior. |
| Run-Time Settings | Run-Time settings allow you to customize the way a Vuser script is executed. You configure the run-time settings from the Controller or VuGen before running a scenario.You can view information about the Vuser groups and scripts that were run in each scenario, as well as the run-time settings for each script in a scenario, in the Scenario Run-Time Settings dialog box. |
| Scenario | A scenario defines the events that occur during each testing session. For example, a scenario defines and controls the number of users to emulate, the actions that they perform, and the machines on which they run their emulations. |
| Scheduler | The Schedule Builder allows you to set the time that the scenario will start running, the duration time of the scenario or of the Vuser groups within the scenario, and to gradually run and stop the Vusers within the scenario or within a Vuser group. It also allows you to set the load behaviour of Vusers in a scenario. |
| Session | When you work with the Analysis utility, you work within a session. An Analysis session contains at least one set of scenario results (lrr file). The Analysis utility processes the scenario result information and generates graphs and reports. The Analysis stores the display information and layout settings for the active graphs in an file with an .lra extension. Each session has a session name, result file name, database name, directory path, and type. |
| Transactions | A transaction represents an action or a set of actions used to measure the performance of the server. You define transactions within your Vuser script by enclosing the appropriate sections of the script with start and end transaction statement. |
| Vusers | Vusers or virtual users are used by LoadRunner as a replacement for human users. When you run a scenario, Vusers emulate the actions of human users working with your application. A scenario can contain tens, hundreds, or even thousands of Vusers running concurrently on a single workstation. |
1 comment:
I had a great knowledge after reading your article, thanks for the comparison of QTP vs. Selenium.
Regards,
Qtp training in Chennai|
Qtp training
Post a Comment