Learn "VuGen" Module of HP – LoadRunner through FAQ’s:
Q. 1: What is the basic purpose of HP LoadRunner?
LoadRunner is a tool for performance testing, which stresses the complete software application to isolate and identify potential client, network, and server bottlenecks.
<<<<<< =================== >>>>>>
Q. 2: What is Virtual User Generator or VuGen when talking about LoadRunner?
When testing or monitoring an environment, we need to emulate the true behavior of various users on the system. The testing tools like Loadrunner emulate an environment in which users concurrently work on the system.
For doing such an emulation, the human being is replaced with a virtual user - called a Vuser. All the actions performed by Vusers are recorded in a Vuser script. The basic tool for creating Vuser scripts is the Virtual User Generator called VuGen.
These scripts help us in emulating real-life situations of user performing various business processes.
<<<<<< =================== >>>>>>
Q. 3: What is the purpose of HP Performance Center?
Performance Center operates in conjunction with LoadRunner & implements the capabilities of LoadRunner on an enterprise level.
<<<<<< =================== >>>>>>
Q. 4: What actions are performed by VuGen during recording?
During recording VuGen monitors the client end of the database and traces all the requests sent by the user and received from the user, to the server. It records all the actions performed by us during the recording session and records only the activity between the client and the server.
VuGen automatically generates functions that accurately model and emulate the real world situations.
Duiring recording of a Vuser script, VuGen generates various functions which define the actions that we perform during the recording session. VuGen inserts these functions into the VuGen editor to create a basic Vuser script.
<<<<<< =================== >>>>>>
Q. 5: How a Vuser script enables running of large number of Vusers during the playback?
During playback, Vuser scripts communicate directly with the server by executing calls to the server API.
When a Vuser communicates directly with a server, system resources are not required for the client interface. This lets us run a large number of Vusers simultaneously on a single workstation, and enables us to use only a few testing machines to emulate large server loads.
For example, we can observe how a server behaved when one thousand Vusers simultaneously withdrew cash from a bank’s ATM.
<<<<<< =================== >>>>>>
Q. 6: What are the advantages of creating Vusers?
1) Since Vuser scripts do not depend on client software, we can use Vusers to check server performance even before the user interface of the client software has been fully developed.
2) With the help of VuGen, we can run scripts as standalone tests.
3) Running scripts through VuGen is useful for debugging since it enables us to see how a Vuser will behave and which enhancements need to be made.
<<<<<< =================== >>>>>>
Q. 7: What are the advantages of VuGen?
VuGen enables us to record a variety of Vuser types, each suited to a particular load testing environment or topology. When we open a new test, VuGen displays a complete list of the supported protocols.
VuGen not only records Vuser scripts, but also runs them. Running scripts from VuGen is useful for debugging. It enables us to emulate how a Vuser script will run when executed as part of a larger test.
<<<<<< =================== >>>>>>
Q. 8: What are the Steps of Creating Vuser Scripts?
Following steps are used for creating a Vuser script:
1) Recording a basic script using VuGen: For testing Windows-based GUI applications or complex Web environments like applets and Flash, we need to use GUI-based tools like HP QuickTest Professional.
2) Enhancing the basic script: By adding control-flow statements and other LoadRunner API functions into the script.
3) Configuring the run-time settings: Settings like iteration, log, and timing information need to be configured, and Vuser behavior needs to be defined during a script run.
4) Verifying the script’s functionality: By running it in standalone mode.
5) Integrating the Vuser script: After verification that the script is functional, it is integrated into our environment
<<<<<< =================== >>>>>>
Q. 9: What platforms are supported by VuGen?
VuGen records sessions on Windows platforms only.
However, a recorded Vuser script can run on both Windows as well as UNIX platform.
<<<<<< =================== >>>>>>
Q. 10: What Environment Options are available for setting up VuGen?
VuGen working environment can be set up by configuring following options:
1) Auto Recovery Option: For restoring our script’s settings in the event of a crash or power outage. For allowing auto recovery, we can specify a desired time interval between the saves in minutes. By default, Auto Recovery is set to 10 seconds.
2) Editor Option: For selecting a particular font and enable VuGen’s Intellisense capabilities which automatically fill in words and function syntax.
Q. 11: What types of views are provided by VuGen for examining the contents of our scripts?
VuGen provides several views for examining the contents of the script:
1) A text-based Script view: This view lets us examine the actual API functions which were recorded or inserted into the script. This view is ideal for advanced users who want to program within the script by adding "C" or Vuser API functions as well as control flow statements.
2) An icon based Tree view with snapshots, or an icon based Thumbnail view: This view shows the Vuser script in an icon-based format, with each step represented by a different icon. Within the Tree view, we can manipulate steps by dragging them to the desired location. We can also add additional steps between existing steps in the tree hierarchy.
<<<<<< =================== >>>>>>
Q. 12: What are the snapshots as displayed by the VuGen?
A snapshot is a graphical representation of the current step.
When working in Tree view, VuGen displays the snapshot of the selected step in the right pane. The snapshot shows the client window after the step was executed.
VuGen captures a base snapshot during recording and another one during replay. We can compare the Record and Replay snapshots to determine the dynamic values that need to be correlated in order to run the script.
<<<<<< =================== >>>>>>
Q. 13: How and when we examine multiple snapshots for a single step?
In many protocols like Microsoft Remote Desktop Protocol (RDP), we can view multiple snapshots for a single step.
This occurs when a mismatch occurs during replay and we decide to append the new image to the step.
<<<<<< =================== >>>>>>
Q. 14: What is the format of Snapshot Files & where these are stored?
Every time we replay the script, VuGen saves the snapshot files in the script directory with an .inf extension.
The replay snapshots are located in the script’s result directory like Iteration1, Iteration2 etc. for every set of results.
<<<<<< =================== >>>>>>
Q. 15: How many tabs are available In the Snapshot window for Web Vusers?
In the Snapshot window for Web Vusers, following tabs are available:
1) Page View: Display the snapshot in HTML as it would appear in a browser. This button is available for both the recording and replay snapshots. This viewis used to make sure that we are viewing the correct snapshot. In this view we do not see the values which need to be correlated.
2) Server Response: Displays the server response HTML code of the snapshot. This button is available for both the recorded and replayed snapshots. The HTML view also shows a tree hierarchy of the script in the left pane, with a
breakdown of the document’s components like: Header and Body with the title, links & forms etc.
3) Client Request: Displays the client request HTML code of the snapshot. This button is available for both the recorded and replayed snapshots. The HTML view also shows a tree hierarchy of the script in the left pane, with a breakdown of the document’s components like: Header and Body and their subcomponents.
<<<<<< =================== >>>>>>
Q. 16: What are Vuser functions created by VuGen?
When we record a Vuser script, VuGen generates Vuser functions and inserts them into the script.
Vuser functions are of following two types:
1) General Vuser Functions: This is also known as LR functions because each LR function has an lr prefix. The LR functions can be used in any type of Vuser script.
2) Protocol-Specific Vuser Functions: These are particular to the type of Vuser that we are recording. For example, VuGen inserts LRD functions into a database script, LRT functions into a Tuxedo script, and LRS functions into a
Windows Sockets script.
The general Vuser functions and the protocol-specific functions together form the LoadRunner API. This API enables Vusers to communicate directly with a server.
<<<<<< =================== >>>>>>
Q. 17: What is the purpose of Gneral Vuser functions or LR Functions?
General Vuser functions or LR Functions enable us to do the following:
1) Getting run-time information about a Vuser, its Vuser Group, and its host.
2) Adding transactions and synchronization points to a Vuser script. For example, the lr_start_transaction (lr.start_transaction in Java) function indicates the beginning of a transaction, and the lr_end_transaction (lr.end_transaction in Java) function indicates the end of a transaction.
3) Sending messages to the output, indicating an error or a warning.
<<<<<< =================== >>>>>>
Q. 18: What is Word Completion feature in VuGen?
Word Completion feature is a part of the IntelliSense enhancements in VuGen.
When the we begin typing a function, after we type the first underscore, VuGen opens a list box displaying all available matches to the function prefix, along with the function’s syntax and description. To use one of the displayed functions, select it, or scroll to the desired item and then select it. VuGen inserts the function at the location of the cursor. To close the list box, press the Esc key.
By default, VuGen uses word completion feature globally. But we can manually disable the word completion feature.
<<<<<< =================== >>>>>>
Q. 19: What is Show Function Syntax feature in VuGen?
Show Function Syntax is also a part of the IntelliSense enhancements in VuGen.
When we type the opening parenthesis of a function, VuGen shows the syntax of the function with its arguments and prototypes and a brief description.
By default, Show Function Syntax is enabled globally, but it can be disabled manually.
<<<<<< =================== >>>>>>
Q. 20: What is purpose of Header Files?
All of the non-Java function prototypes are listed in the library header files. The header files are located within the include directory of the product installation.
Header Files contain detailed syntax information and return values. Header Files also contain definitions of constants, availability, and other advanced information which is not included in the Function Reference.
In most of the cases, the name of the header file corresponds to the prefix of the protocol. For example, Database functions that begin with an lrd prefix, are listed in the lrd.h file.
. 21: How can we view the VuGen Workflow while creating scripts?
VuGen provides a set of workflow screens, which guide us through the different steps of creating a script. A basic script is created in the beginning and then we adapt it for our test or production environment.
By default, after installation VuGen opens with the Workflow view. We can also work in the Tree view or Script view. The next time we start VuGen and open a script, it opens to the view that we had open when we exited VuGen the last time. We can switch back to the wizard view by clicking on any task in the Task Pane.
<<<<<< =================== >>>>>>
Q. 22: What are the steps involved in parameterizing an argument in a script?
Various steps of parameterization are:
1) Locating the argument you want to parameterize
2) Giving the parameter a name
3) Selecting a parameter type
4) Defining properties for the parameter type
5) Replacing the argument with a parameter
<<<<<< =================== >>>>>>
Q. 23: What are the steps to run the load tests on the system to check the response and capacity of the machine?
This involves following two steps:
1) Iterations: This portion of the Workflow Wizard provides an introduction to iterations and allows us to open the Run-Time settings for setting their values.
2) Concurrent Users: This portion of the Workflow Wizard guides us through the process of creating a scenario using the LoadRunner Controller. In a scenario, we can specify the number of users to run concurrently and we can observe the behavior of our system with multiple users.
<<<<<< =================== >>>>>>
Q. 24: What are the steps involved while Finishing our Script?
The final Finishing step of the Workflow wizard involves the following actions:
1) Creating a Scenario: For running a load test on our system using the LoadRunner Controller.
2) Uploading to Performance Center: For running a test through a Performance Center server installation.
3) Uploading to Quality Center: For adding a test to the test repository.
4) Creating Business Process Report: Creating a Microsoft Word document containing a summary of the VuGen script.
<<<<<< =================== >>>>>>
Q. 25: What are the various sections of Vuser Script?
Every Vuser script created by VuGen contains a minimum of following three sections. Before and during the recording, we can chose the section of the script into which VuGen should insert the recorded functions.
1) vuser_init Section: This section is used when recording a login to a server. This section gets executed when the Vuser gets initialized or loaded. While running multiple iterations of a Vuser script, this section does not get repeated.
2) Actions Section: This section is used when recording client activity. This section gets executed when the Vuser is in Running status. When we run multiple iterations of a Vuser script, this is the only section of the script which gets repeated.
3) vuser_end Section: This section is used when recording a logoff procedure. This section gets executed when the Vuser finishes or is stopped. While running multiple iterations of a Vuser script, this section does not get repeated.
<<<<<< =================== >>>>>>
Q. 26: How do we view and edit the contents of script sections?
VuGen script editor is used to view and edit the contents of every section of the script. We can display the contents of only a single section at a time. To display a section, we just need to highlight its name in the left pane.
<<<<<< =================== >>>>>>
Q. 27: What is an actions class related to Vuser scripts?
We place all the code in the actions class, while working with Vuser scripts which use Java classes.
The Actions class contains following three methods, which correspond to the sections of scripts developed using other protocols:
1) Init method: This is used for inserting initialization routines.
2) Action method: This is used for inserting client actions.
3) End method: This is used for inserting log off procedures
<<<<<< =================== >>>>>>
Q. 28: How can we import actions into our script from another Vuser script?
We can import actions into our script from another Vuser script, only for the types of Vusers which support multiple actions.
We can import the actions from Vusers of the same type only. As a result, all parameters associated with the imported action, will get merged with the script.
Following two options are available for importing actions :
1) Import From Vuser.
2) Action to Import.
<<<<<< =================== >>>>>>
Q. 29: How do we convert our script to some presentable format describing the business process?
At the final stage of script creation, we can create a report describing our business process. VuGen exports the script information to a Microsoft Word document.
We can use a pre-designed template or the one provided with VuGen, to create structured reports with summary information about our test run. VuGen allows us to customize the contents of the report by indicating what type of information we want to include in it.
<<<<<< =================== >>>>>>
Q. 30: What type of preferences are necessary to be set before Script Generation?
Before recording a session, VuGen allows us to set the following preferences:
1) Specification of a language for script generation: The available languages for script generation vary according to the protocol. Some of the available languages are C, C#, Visual Basic, Visual Basic .NET, VB Script, and Javascript. By default, VuGen generates a script in the most common language suitable to the protocol, but we can change this through the Script recording options.
A script recorded in one language can be easily regenerated in another language after the recording.
2) Specification of language-specific recording options: This is done to instruct the recorder as to what to include in the script and how to generate it.
Q. 31: How do we select the best possible Scripting Language while recording?
While we begin a recording session, VuGen automatically creates a script which emulates our actions by default.
Various script generation languages used by VuGen are:
1) For MS .NET the default language is C or C# .
2) For the FTP, COM/DCOM, and mail protocols (IMAP, POP3, and SMTP): Visual Basic, VB Script, and Javascript.
Following languages are best suited for the respective applications:
1) C Language: For recording applications that use complex COM constructs and C++ objects.
2) C # Language: For recording applications that use complex applications and environments under MS .NET protocol only.
3) Visual Basic .NET Language: For VB .NET applications, using the full capabilities of VB.
4) Visual Basic for Applications: For VB-based applications, using the full capabilities of VB.
5) Visual Basic Scripting: For VBscript-based applications, such as ASP.
6) Java Scripting: For Javascript-based applications such as js files and dynamic HTML applications.
<<<<<< =================== >>>>>>
Q. 32: How can we can map the network traffic from a specific server while recording Vuser scripts?
While recording Vuser scripts which record network traffic on a socket level like -HTTP, SMTP, POP3, FTP, IMAP, Oracle NCA and WinSocket, we can set the Port Mapping options.
With such options, we can map the traffic from a particular server by defining the port combination to the desired communication protocol.
Mapping is created by specifying a server name, port number, or a complete server - port combination. Few examples are:
1) Specify that all the traffic from the server ABC on port 25, should be handled as SMTP.
2) Specify that all traffic from the server called XYZ should be mapped to the FTP protocol, regardless of the port.
3) Specify to map all traffic on port 23 to SMTP, regardless of the server name.
<<<<<< =================== >>>>>>
Q. 33: What is Forced Mapping?
If we specify a mapping for a port number, server name, or combination server - port, VuGen forces the network traffic to use that service.
For example, if we were to specify server on port 80 to use FTP, VuGen uses the FTP protocol to record that communication, even though the actual communication may be HTTP. In this instance, the Vuser script might be empty.
<<<<<< =================== >>>>>>
Q. 34: What is Traffic Forwarding & when do we use it?
Traffic Forwarding refers to the process of forwarding all traffic from a specific port to another server. This is useful in situations where VuGen cannot run properly on the client, such as unique UNIX machines, or instances where it is impossible to launch the application server through VuGen.
An option "Allow forwarding to target server from local port" is available wherein we configure VuGen to intercept the traffic from the problematic client machine, and pass it on to the server. Thus VuGen is able to process the data and generate code for the actions.
<<<<<< =================== >>>>>>
Q. 35: What type of enhancements are done to the Vuser Scripts?
We can enhance a Vuser script :
1) By adding General Vuser functions
2) By adding Protocol-Specific Vuser functions
3) By adding Standard ANSI C functions.
We can enhance the Vuser script either during the recording or after the recording.
<<<<<< =================== >>>>>>
Q. 36: What is the utility of General Vuser Functions in Vuser Scripts?
General Vuser functions are added to any Vuser scripts to enhance its functionality. For example, we can use General Vuser functions to measure the server performance, control server load, add debugging code, or to retrieve the run-time information about the Vusers participating in the test.
Some of the General Vuser functions are generated by VuGen and are inserted into the Vuser script during recording.
General Vuser functions can be used in any type of Vuser script. All General Vuser functions have an LR prefix.
<<<<<< =================== >>>>>>
Q. 37: What is the utility of Protocol-Specific Functions in Vuser Scripts?
The aim of having Protocol-Specific Functions is also to enhance the Vuser scripts. Many libraries of special functions are available for use.
We have libraries of functions specific to a particular type of Vuser. For example, we use the LRS functions in a Windows Sockets Vuser script and LRT functions in a Tuxedo Vuser script.
<<<<<< =================== >>>>>>
Q. 38: What is the utility of Standard ANSI C Functions in Vuser Scripts?
The aim of having Standard ANSI C Functions is also to enhance the Vuser scripts.
ANSI C functions allow us to add comments, control flow statements, conditional statements etc. to the Vuser scripts. we can add standard ANSI C functions to any type of Vuser script.
<<<<<< =================== >>>>>>
Q. 39: What is the purpose of transactions in Vuser Scripts?
Transactions are defined to measure the performance of the server. Every transaction measures the time it takes for the server to respond to specified Vuser requests. These requests can be simple tasks like waiting for a response for a single query, or complex tasks like submitting several queries and generating a report.
We insert Vuser functions in the Vuser scripts to mark the beginning and the end of a task for measuring a transaction.
We can mark any number of transactions in a script, and each transaction can be specified with a different name.
The transactions can be created during the recording as well after the recording by using transaction editor.
<<<<<< =================== >>>>>>
Q. 40: What steps are needed to create a transaction to measure a business process?
Before creating a script, we need to decide on the business processes we want to measure. Next step is to mark every business process or sub-process as a transaction.
Transaction creation has two basic steps.
1) Marking the start of the transaction
2) Marking the end of the transaction
We can create nested transactions that is creating transactions within transactions.
Q. 41: What is the purpose of Rendezvous Points in LoadRunner?
While doing the load testing of our system, we need to emulate heavy user load on the system. For simultaneous application of a particular amount of load, we synchronize Vusers to perform a particular task exactly at the same moment. Thus the point at which all the Vusers act simultaneously is called Rendezvous Point
In Vuser script we mark the meeting place for all Vusers by inserting a rendezvous in it. When some Vuser arrives at the rendezvous point, it waits until all the remaining Vusers participating in the rendezvous arrive. When the designated number of Vusers arrive at the rendezvous point, the Vusers are released from the rendezvous for performing the next task in the script.
<<<<<< =================== >>>>>>
Q. 42:The Rendezvous points are operative in how many sections of Vuser scripts?
Rendezvous points are effective only in the Action section of Vuser scripts. They are not effective in either the init section or the end section of the Vuser scripts.
<<<<<< =================== >>>>>>
Q. 43: How many types of functions can be added to the Vuser scripts to retrieve Vuser information?
We can add following functions to our Vuser scripts:
1) lr_get_attrib_string: For returning a command line parameter string.
2) lr_get_host_name: For returning the name of the machine running the Vuser script.
3) lr_get_master_host_name: For returning the name of the machine running the Controller.
4) lr_whoami : For returning the name of a Vuser executing the script.
<<<<<< =================== >>>>>>
Q. 44: What are the mechanisms available for Vuser to handle the errors during script execution?
By default, when a Vuser detects an error, the Vuser stops executing the script. We can instruct a Vuser to continue with the next iteration when an error occurs using one of the following methods:
1) By run-time settings method: We can specify the Continue on Error run-time setting. The Continue on Error run-time setting applies to the entire Vuser script. We can use the lr_continue_on_error function to override the Continue on Error run-time setting for a portion of a script.
2) By lr_continue_on_error function: This function enables us to control error handling for a specific segment of a Vuser script. To mark the segment, enclose it with lr_continue_on_error(1);and lr_continue_on_error(0); statements. The new error settings apply to the enclosed Vuser script segment.
<<<<<< =================== >>>>>>
Q. 45: What is think time?
The time for which a user waits between performing successive actions is known as the think time.
Vusers use the lr_think_time function to emulate user think time. When we record a Vuser script, VuGen records the actual think times and inserts appropriate lr_think_time statements into the Vuser script.
We can edit the recorded lr_think_time statements, and manually add more lr_think_time statements to a Vuser script.
While recording Java Vuser scripts, lr_think_time statements are not generated in the Vuser script.
<<<<<< =================== >>>>>>
Q. 46: What functions we use to read the command line arguments & to pass the values to a Vuser script?
We use following three functions for reading the command line arguments, and then to pass the values to a Vuser script:
1) lr_get_attrib_double: For retrieving double precision floating point type arguments.
2) lr_get_attrib_long: For retrieving long integer type arguments.
3) lr_get_attrib_string: For retrieving character strings.
<<<<<< =================== >>>>>>
Q. 47: Why do we use VuGen Parameters?
When we record a business process, VuGen generates a Vuser script composed of functions. The values of the arguments in the functions are the actual values used during the recording session.
For example, when we recorded a Vuser script while operating a web application. VuGen had generated a statement which searches a library’s database for the title say "ABC". Now when we replay the script using multiple Vusers and iterations, we would not want to repeatedly use the same value "ABC". Instead, we would replace the constant value with a parameter:
The resulting Vusers then substitute the parameter with values from a data source that we specify. The data source can be either a file, or internally generated variables.
<<<<<< =================== >>>>>>
Q. 48: What are the actions involved in parameterizing a Vuser script?
Parameterization of Vuser script involves the following two tasks:
1) Replacing the constant values in the Vuser script with parameters.
2) Setting the properties and data source for the parameters.
<<<<<< =================== >>>>>>
Q. 49: What are the advantages of parameterizing Vuser scripts?
Parameterizing a Vuser script has two advantages:
1) It reduces the size of the script.
2) It provides the ability to test the script with different values.
For example, if we want to search a library’s database for several titles, we only need to write the submit function once. Instead of instructing our Vuser to search for a specific item, use a parameter. During replay, VuGen substitutes different values for the parameter.
<<<<<< =================== >>>>>>
Q. 50: What are the limitations associated with parametrization of Vuser scripts?
Few limitations of parametrization of Vuser scripts are:
1) We can use parameterization only for the arguments within a function.
2) We cannot parameterize text strings which are not function arguments.
3) We can not parameterize all the function arguments.
Q. 51: What special commands are available for parameterization of VuGen generated Vuser scripts?
1) We can use the lr_eval_string function to "parameterize" a function argument which cannot be parameterized by using standard parameterization.
2) We can use the lr_eval_string function to "parameterize" any string in a Vuser script.
3) For VB, COM, and Microsoft .NET protocols, we need to use the lr.eval string function to define a parameter. For example,
r.eval_string("{Custom_param}").
<<<<<< =================== >>>>>>
Q. 52: How many Parameter Types are there in Vugen?
While creating a parameter, we specify the following four type of sources for the parameter data. Accordingly there are four type of parameters like:
1) File or Table Parameter
2) XML Parameter
3) Internal Data Parameter
4) User-Defined Function
<<<<<< =================== >>>>>>
Q. 53: What are Datafiles?
Data files store all the data accessed by the Vuser during script execution. Data files are of two types viz. 1) Local Data Files 2) Global Data Files.
Data files are useful when we have many known values for our parameter. The data in a data file is stored in the form of a table. One file can contain values for many parameters. Each column holds the data for one parameter. Column breaks are marked by a delimiter like a comma. For example, the undermentioned data file contains ID numbers and the Name of the persons:
id,name
250,Arun
251,Vivek
252,Sneha
We can use an existing ASCII file, or can import a database file or can instruct VuGen to create a new datafile for us.
<<<<<< =================== >>>>>>
Q. 54: What are File and Table Parameter Types?
While creating a parameter, we specify the source of the parameter data. We use parameters, by instructing the Vusers to take values from an data table or an external file which contains values defined by the user.
These parameters are called File and Table type parameters.
The Table parameter type is meant for applications needing testing by filling in table cell values. Whereas the file type uses one cell value for each parameter occurrence, the table type uses several rows and columns as parameter values, similar to an array of values. Using the table type, we can fill in an entire table with a single command.
<<<<<< =================== >>>>>>
Q. 55: What are the XML Parameter Types?
XML Parameter Types are the placeholder for multiple valued data contained in an XML structure. We can use an XML type parameter to replace the entire structure with a single parameter. For example, an XML parameter by the name Address can replace a contact name, an address, city, and postal code.
With the help of XML parameters we can have cleaner input of the data, and enables cleaner parameterization of Vuser scripts. XML parameters are recommended for use with Web Service scripts or for SOA services.
<<<<<< =================== >>>>>>
Q. 56: What are the Internal Data Parameter Types?
Internal data gets created automatically when a Vuser runs. These are like Date/Time, Group Name, Iteration Number, Load Generator Name, Random Number, Unique Number, and Vuser ID etc.
We can define the properties for the data getting generated internally by the Vuser.
<<<<<< =================== >>>>>>
Q. 57: What are the User Defined Parameter Types?
User Defined Parameter Types are the data being generated using a function from an external DLL.
A user-defined function replaces the parameter with a value returned from a function located in an external DLL.
Before we assign a user-defined function as a parameter, we need to create an external library (DLL) with the function. The format of the user defined function is: __declspec(dllexport) char *(char *, char *)
<<<<<< =================== >>>>>>
Q. 58: What is the Global Directory option for Parameterization in VuGen?
Global Directory option is available only for backward compatibility with earlier versions of VuGen. In earlier versions like 4.51 and below, when we created a new data table, there was a need to specify local or global. A local table is saved in the current Vuser script directory and is only available to Vusers running that script. A global table is available to all Vuser scripts. The global directory can be on a local or network drive.
However it is essential that the global directory is available to all machines running the script. We can change the location of the global tables at any time with the help of General Options dialog box.
In newer versions of VuGen, we need to specify the location of the data table either in the Parameter Properties dialog box or in the Parameter List dialog box. VuGen is able to retrieve the data from any location that we specify. It may be either the default script directory or another directory on the network.
<<<<<< =================== >>>>>>
Q. 59: How do we Import Data for parameterization from an Existing Database?
VuGen allows us to import data from a database for use with parameterization. We can import the data in either of the following two ways:
1) Creating a New Query via an MS Query
2) Specifying an SQL Statement
We can use the wizard provided by the VuGen for importing data from a database. Here we need to specify the way of importing the data as described above. After completion of importing the data, it is saved as a file with a .dat extension and stored as a regular parameter file.
<<<<<< =================== >>>>>>
Q. 60: What are the ways to assign data from a file source to the parameters in VuGen?
Three methods are used for assigning data from a file source to the parameters:
1) Sequential Method: It assigns data to a Vuser sequentially. As a running Vuser accesses the data table, it takes the next available row of data. If there are not enough values in the data table, VuGen returns to the first value in the table, continuing in a loop until the end of the test.
2) Random Method: It assigns a random value from the data table to each Vuser at the start of the test run.
When running a scenario, we can specify a seed number for random sequencing. Each seed value represents one sequence of random values used for test execution. Whenever we use this seed value, the same sequence of values is assigned to the Vusers in the scenario. We enable this option in case of any problem in the test execution and there is a need to repeat the test using the same sequence of random values.
3) Unique Method: It assigns a unique sequential value to the parameter for each Vuser.
For using this method we need to ensure that there is enough data in the table for all the Vusers and their iterations. If there are 20 Vusers and we want to perform 5 iterations, our table must contain at least 100 unique values. If there are not enough values in the data table, we can instruct VuGen how to proceed.
Q. 61: How many methods are available in VuGen for updating several parameter types?
Following three parameter update methods are available:
1) Each Occurrence method: It instructs the Vuser to use a new value for each occurrence of the parameter. This is useful when the statements using a parameter are unrelated. For example, for random data, it may be useful to use a new value for each occurrence of the parameter.
2) Each Iteration method: It instructs the Vuser to use a new value for each script iteration. If a parameter appears in a script several times, the Vuser uses the same value for all occurrences of the parameter, for the entire iteration. This is useful when the statements using a parameter are related.
3) Once method: It instructs the Vuser to update the parameter value only once during the scenario run. The Vuser uses the same parameter value for all occurrences and all iterations of the parameter. This type may be useful when working with dates and times.
<<<<<< =================== >>>>>>
Q. 62: What is Simulation of File Type Parameters for LoadRunner users?
Once a File type parameter is created, we can use the File Parameter Simulator to simulate the parameter substitution in an actual scenario.
Simulator allows us to correct any wrong parameters before we run the script in the Controller.
<<<<<< =================== >>>>>>
Q. 63: What is the purpose of correlating statements in VuGen?
VuGen provides "Correlated Query" feature for linking the statements by using the results of one statement as input for the other. Correlating statements are used for optimizing the Vuser scripts.The objective of correlating statements are:
1) To simplify or optimize the code: For example, if we perform a series of dependent queries one after another, the code tends to become very long. To reduce the size of the code, we can nest the queries, but in this process we lose the precision and the code becomes complex and difficult to understand. In such a situation, correlating the statements enables us to link the queries without nesting.
2) To generate dynamic data: Many applications and Web sites identify a session by the current date and time. When we try to replay a script, it will fail because the current time is different than the recorded time. Correlating the data enables us to save the dynamic data and use it throughout the scenario run.
3) To accommodate unique data records: Certain applications like databases require the use of unique values. A value that was unique during recording is no longer unique for script execution. Lt us take an example, wherein we record the process of opening a new bank account. Each new account is assigned a unique number which is unknown to the user. This account number is inserted into a table with a unique key constraint during recording. If we try to run the script as recorded, it tries to create an account with the recorded number, rather than a new unique number. An error will result because the account number already exists.
<<<<<< =================== >>>>>>
Q. 64: What are the various types of C Vuser correlation functions?
Following three types of C Vuser correlation functions are used for correlating the statements for protocols which do not have any specific functions. These can be used to save a string to a parameter and retrieve it as and when required.
1) lr_eval_string Function: Replaces all occurrences of a parameter with its current value.
2) lr_save_string Function: Saves a null-terminated string to a parameter.
3) lr_save_var Function: Saves a variable length string to a parameter.
<<<<<< =================== >>>>>>
Q. 65: What are the various types of Java Vuser correlation functions?
Following seven types of Java Vuser correlation functions are used . These can be used to save a string to a parameter and retrieve it as and when required.
1) lr.eval_string Function: Replaces a parameter with its current value.
2) lr.eval_data Function: Replaces a parameter with a byte value.
3) lr.eval_int Function: Replaces a parameter with an integer value.
4) lr.eval_string Function: Replaces a parameter with a string.
5) lr.save_data Function: Saves a byte as a parameter.
6) lr.save_int Function: Saves an integer as a parameter.
7) lr.save_string Function: Saves a null-terminated string to a parameter.
<<<<<< =================== >>>>>>
Q. 66: What is the purpose of WDiff utility?
WDiff is a tool for determining which values to correlate. With the help of this we can compare recorded scripts and results to find out as to which values need to be correlated.
While working with other protocols, we can view the Execution log to find out where the script failed and then use the WDiff utility to help us in locating the values that need to be correlated.
For making an effective use of WDiff utility, we need to record the identical operation twice, and compare the scripts. It displays differences in yellow color.
<<<<<< =================== >>>>>>
Q. 67: Why do we configure th run-time settings for Vuser Scripts?
After a Vuser script is recorded, we need to set its run-time settings to define the way the new script should run. These run-time settings get applied to the Vusers when a script is made to run through LoadRunner's VuGen or Controller.
These run-time settings are stored in the "default.cfg" file, located in the Vuser script directory.
By defining the run-time settings we can emulate various types of user activity. For example, we can emulate a user who responds immediately to output from the server, or a user who stops and thinks before each response. We can use these run-time settings to specify how many times the Vuser should repeat its set of actions.
<<<<<< =================== >>>>>>
Q. 68: What are Action Blocks in Scripts?
Action blocks are groups of actions within the script. We can create separate action blocks for groups of actions by adding the same action to several blocks. We can instruct VuGen to execute action blocks or individual actions sequentially or randomly.We can set the properties of each action block independently. These properties can be like the following:
1) Sequence: means the order of actions within your script.
2) Iterations: Means the number of times Vusers repeat all of the Actions.
3) Weighting:Means weight or percentage of each action within a block.
<<<<<< =================== >>>>>>
Q. 69: What is the purpose of Pacing Run Time settings for multiple actions?
Pacing Run Time settings allows us to control the time between iterations. The pace tells the Vuser how long to wait between iterations of your actions. We can instruct the Vusers to start each iteration by either of the following methods:
1) As soon as the previous iteration ends: The new iteration begins as soon as possible after the previous iteration ends.
2) After the previous iteration ends with a fixed or random delay: It starts each new iteration a specified amount of time after the end of the previous iteration. Specify either an exact number of seconds or a range of time. For example, we can specify to begin a new iteration at any time between 60 and 90 seconds after the previous iteration ends.
3) At fixed or random intervals: We specify the time between iteration - either a fixed number of seconds or a range of seconds from the beginning of the previous iteration. For example, we can specify to begin a new iteration every 30 seconds, or at a random rate ranging from 30 to 45 seconds from the beginning of the previous iteration. Each scheduled iterations will only begin when the previous iteration is complete.
<<<<<< =================== >>>>>>
Q. 70: How many type of information logging are available?
We can specify the type of information that is logged in following ways
1) Standard Log: Creates a standard log of functions and messages sent during script execution to use for debugging. Disable this option for large load testing scenarios or profiles.
2) Extended Log: Creates an extended log, including warnings and other messages. It is recommended to disable this option for large load testing scenarios or profiles.
Q. 71: What type of Extended log options are available for posting additional information?
Following Extended log options are available:
1) Parameter substitution: This option is selected to log all parameters assigned to the script along with their values.
2) Data returned by server: This option is selected to log all of the data returned by the server.
3) Advanced trace: This option is selected to log all of the functions and messages sent by the Vuser during the session. This option is useful while debugging a Vuser script.
<<<<<< =================== >>>>>>
Q. 72: What is a Message Class?
Message Class is the degree to which VuGen logs various events likeStandard, Parameter substitution etc.
There are five types of Message Classes:
1) Brief 2) Extended 3) Parameters 4) Result Data 5) Full Trace.
A Message Class can be manually set within our script with the help of lr_set_debug_message function. This is useful when we want to receive debug information about a small section of the script.
<<<<<< =================== >>>>>>
Q. 73: What options are available for setting the Think Time in our Scripts?
Vuser think time emulates the time that a real user waits between actions. By default, when a Vuser script is run, the Vuser uses the think time values that were recorded into the script during the recording session.
VuGen allows us to use following options:
1) Use the recorded think time
2) Ignore the recorded think time
3) Use a value related to the recorded time
<<<<<< =================== >>>>>>
Q. 74: What type of Miscellaneous run-time options are available for a Vuser script?
Following Miscellaneous run-time options are available for a Vuser script:
1) Error Handling Settings: Following three types of settings are available under this category
a) Continue on Error: This setting instructs Vusers to continue script execution when an error occurs. This option is turned off by default, indicating that the Vuser will exit if an error occurs.
b) Fail open transactions on lr_error_message: This option instructs VuGen to mark all transactions in which an lr_error_message function was issued, as Failed. The lr_error_message function is issued through a programmed If
statement, when a certain condition is met.
c) Generate Snapshot on Error: This option generates a snapshot when an error occurs. We can see the snapshot by viewing the Vuser Log and doubleclicking on the line at which the error occurred.
2) Multithreading Settings: Vusers support multithread environments. The primary advantage of a multithread environment is the ability to run more Vusers per load generator.
3) Automatic Transactions Settings: We can instruct LoadRunner to handle every step or action in a Vuser script as a transaction. This is called using automatic transactions. LoadRunner assigns the step or action name as the name of the transaction. By default, automatic transactions per action are enabled.
<<<<<< =================== >>>>>>
Q. 75: How can we do the speed simulation for the Network while working on Loadrunner?
With the help of Speed Simulation settings, we can select a bandwidth which best suits the environment under test.
Three options are available to us for speed simulation of network:
1) Use maximum bandwidth: By default, bandwidth emulation is disabled and the Vusers run at the maximum bandwidth that is available over the network.
2) Use bandwidth: Indicate a specific bandwidth level for our Vuser to emulate. We can select a speed ranging from 14.4 to 512 Kbps, emulating analog modems, ISDN, or DSL.
3) Use custom bandwidth: Indicate a bandwidth limit for your Vuser to emulate. Specify the bandwidth in bits, where 1 Kilobit=1024 bits.
<<<<<< =================== >>>>>>
Q. 76: What are Breakpoints?
Breakpoints pause the execution at specific points in the script. Breakpoints enable us to examine the effects of the script on our application at pre-determined points during execution.
All breakpoints in our script can be viewed and manipulated by using the Breakpoint Manager of VuGen.
<<<<<< =================== >>>>>>
Q. 77: What tools are available in VuGen for debugging the Web Vuser Scripts?
VuGen provides following two tools to help us debug our Web Vuser scripts
1) Run-time viewer: It shows each Web page as it is accessed by the Vuser. This is useful when we debug Web Vuser scripts because it allows us to check that the Vuser accesses the correct Web pages.
2) Results Summary report: It summarizes the success or failure of each step in the Web Vuser scripts and allows us to view the Web page returned by each step.
<<<<<< =================== >>>>>>
Q. 78: How can we run a Vuser Script from a Command Prompt?
We can test a Vuser script from a Command Prompt or from the Windows Run dialog box without the VuGen user interface by following method.
1) Select Start > Programs > Command Prompt to open a Command Prompt window, or select Start > Run to open the Run dialog box.
2) Type /bin/mdrv.exe -usr -vugen_win 0 and press enter
Here script_name is the full path to the .usr script file, for example, c:\temp\mytest\mytest.usr.
And the mdrv executable runs a single instance of the script without the user interface.
<<<<<< =================== >>>>>>
Q. 79: What information is needed for Integrating Scripts into the Test environment?
After successfully testing the script in standalone mode and confirming its perfect functionality, we integrate it into the full-fledged environment like: a LoadRunner scenario, Performance Center load test, or Business Process Monitor profile etc.
Following information is provided while integrating the test:
1) Which is the script that needs to be integrated.
2) Details of Vusers, which will run the script.
3) Details of load generator upon which the script will be executed.
4) Details of scheduling etc.
<<<<<< =================== >>>>>>
Q. 80: How do we create a LoadRunner Scenario?
Generally we create a scenario from the LoadRunner Controller module.
However we can create a basic scenario from VuGen using the current script as well.
Q. 81: How do we manage Vuser Scripts created in VuGen?
VuGen works seamlessly with HP Quality Center, which is a Web-based test management tool. With Quality Center we can efficiently store and retrieve the Vuser scripts, scenarios and results.
Scripts are stored in a Quality Center project and can be organized into unique groups. When VuGen is connected to a Quality Center project, we can create new scripts in VuGen and save them directly to our project.
<<<<<< =================== >>>>>>
Q. 82: How do we manage Scripts with HP Performance Center?
VuGen provides integration with HP - Performance Center, which is a Web-enabled global load testing tool providing facility to test our system from different geographical locations.
Through the user interface of VuGen we can upload and download scripts to and from Performance Center . The scripts are uploaded to the Performance Center to add them to the Vuser Scripts list and for use later our test. The scripts can be downloaded for editing and saving them locally.
VuGen can access a Performance Center project, after a connection is established with the Web server on which Performance Center is installed.
<<<<<< =================== >>>>>>
Q. 83: How can we create Vuser script through programming?
We can create a Vuser script through programming within the Visual C and Visual Basic environments. We can develop our Vuser script within our development application, while importing the Vuser API libraries.
We can program a Vuser script from within the VuGen editor while incorporating all our libraries or classes of the application.
We use a VuGen template for creating a Vuser script through programming, which forms the basis for a larger Vuser script.
<<<<<< =================== >>>>>>
Q. 84: How do we create XML script using VuGen?
VuGen allows us to dynamically work with XML code and retrieve the values during test execution.
Steps for creating XML script are:
1) Record a script in the desired protocol, usually Web, Web Services, or Wireless.
2) Copy the XML structures into the script.
3) Add XML functions from the LR API in order to retrieve dynamic data and the XML element values.
<<<<<< =================== >>>>>>
Q. 85: How many functions are available in VuGen for writing values to an XML tree?
We can write values to an XML tree using following five functions:
1) lr_xml_delete : For deleting fragments from an XML string.
2) lr_xml_insert : For inserting a new XML fragment into an XML string.
3) lr_xml_replace : For replacing fragments of an XML string.
4) lr_xml_set_values : For setting the values of XML elements found by a query.
5) lr_xml_transform : For applying Extensible Stylesheet Language (XSL) transformation to XML data.
<<<<<< =================== >>>>>>
Q. 86: How can we use VuGen as a General Debugging tool?
VuGen can be used as a regular text editor. We can open any text file in it and edit it.
When an error message comes up during replay in the output window, we can double click on it and VuGen jumps the cursor to the line of the test that caused the problem.
We can place the cursor on the error code and press F1 to view the online help explanation for the error code.
<<<<<< =================== >>>>>>
Q. 87: Why a data driven two tier database script fails, while it works fine with the same values in the application?
The failure can be due to presence of trailing spaces in our data values.
Even though we type the data values directly into the GUI, there is a probability of data getting truncated. Hence we should manually eliminate the trailing spaces from the data file. Tab -delimited files can hide trailing spaces and can cause problems. Hence comma-delimited files are the most recommended ones. However It is suggested to view the files in Excel to confirm their correctness before hand.
<<<<<< =================== >>>>>>
Q. 88: How can we create Vuser scripts for running on UNIX platforms?
We can create Vuser scripts which can run on UNIX platforms by following two methods:
1) By using VuGen: We record our application in a Windows environment and run it in UNIX, because recording is not supported on UNIX.
2) By Programming: Scripts can be programmed in C or C++ and they must be compiled into a dynamic library. To create a script through programming, we can use a Vuser template as a basis for a larger Vuser scrips.
<<<<<< =================== >>>>>>
Q. 89: How do we use VuGen to create test scripts for testing SOA environment?
We can use a test generation wizard in VuGen to automatically generate scripts, or create the scripts manually.
To automatically generate test scripts, we use the SOA Test Generator. A wizard guides us through the process of selecting testing aspects such as interoperability with different toolkits, boundary testing, and standard compliance.
<<<<<< =================== >>>>>>
Q. 90: What type of manual scripts can be created by using VuGen under SOA environment?
For manual scripts, we use VuGen to create following types of scripts.
1) Single Protocol Script: A script that emulates SOAP traffic by sending SOAP requests to the Web service.
2) Multi Protocol Script: A script that emulates several protocols in a single script. For example, if our environment contains a client accessing Web Services and Web pages, choose both the Web Services and Web protocols.
Q. 91: What are the steps for creating a Web Services / SOA Vuser script?
Step -1: Creating a new Web Services script: using the SOA Test Generator, or manually create a new single or multiple protocol script, or a Business Process Testing component.
Step -2: Adding content to the script
Step -3: Setting properties, values, and checkpoints: we can enhance the script by customizing the step properties, inserting argument values, and setting checkpoints.
Step -4: parameterizing the script: Parameterization allows us to replace constant values with a variable to substitute new values for each iteration. To parameterize a value, doubleclick on a step to open its properties and click the ABC icon adjacent to the value box.
Step -5: Configuring the Run -Time settings: The Run -Time settings control the script’s behavior during execution. These settings include Web Service-specific settings and General settings like run logic, pacing, logging, and think time.
Step -6: Verifying that the script is functional: Replay the script in VuGen to verify that it runs correctly.
Step -7: Saving the script: Save the script in the file system or in a Quality Center repository. If we save the scripts in Quality Center, we can associate them to a test set and perform functional and regression testing directly from Quality Center.
<<<<<< =================== >>>>>>
Q. 92: How do we compare the WSDL Files?
When we import a WSDL file, VuGen makes a working copy and saves it along with the script. This saves resources and enables a more scalable and stable environment.
It is possible, however, that by the time we run the script, the original WSDL file will have changed. If we run the script, the test results may be inaccurate and the script may no longer be functional. Therefore, before replaying a Web Services script that was created at an earlier date, we should run a comparison test on the WSDL file.
VuGen provides a comparison tool, which compares the local working copy of the WSDL file with the original file on the file system or Web server. If the differences are significant, we can update the WSDL from the original copy using the Synchronize option in the Service Management dialog box.
VuGen provides a general utility, which allows us to compare any two XML files.
<<<<<< =================== >>>>>>
Q. 93: How VuGen displays the differences between two XML files in a Comparison report?
The Comparison report uses the following legend to mark the differences between the two XML files:
1) Yellow: Indicates changes to an existing element and is shown in both versions.
2) Green: Indicates a new element added and is shown in the original file copy.
3) Pink: Indicates a deleted element.
<<<<<< =================== >>>>>>
Q. 94: What are the ways of testing our system after creating the script?
Our completed script can be used to test our system in following ways:
1) Functional Testing: Run the script to see if our Web services are functional. We can also check to see if the Web service generated the expected values.
2) Load Testing: Integrate the script into a LoadRunner Controller scenario to test its performance under load.
3) Production Testing: Check your Web service’s performance over time through a Business Process Monitor profile.
<<<<<< =================== >>>>>>
Q. 95: What is the Service Test Management utility?
Service Test Management is an add-on utility for HP- Quality Center. This helps us to manage SOA testing by permitting import, storage and defining various services in Quality Center.
The Service Test Management integration allows us to do the following:
1) Store Web Services: Allows us to store and organize Web Services in Quality Center for use within Service Test.
2) Write Service Test scripts: Allows us to create scripts based on the services stored in Quality Center, while maintaining up-to-date WSDLs throughout the life-cycle of the service and the script.
3) Compose a Business Process Test: Allows us to create a BPT (Business Process Test) in Quality Center based on services defined through Service Test Management.
<<<<<< =================== >>>>>>
Q. 96: What are the benefits of Service Test Management utility towards quality improvement in an organization?
With the help of Service Test Management add-on for Quality Center, the organizations can draw following benefits in terms of improved quality processes:
1) Business analysts define application requirements and testing objectives.
2) Test managers and project leads design test plans and develop test cases.
3) Test managers automatically create QA testing requirements and test assets for SOA services and environments.
4) Test automation engineers create automated scripts and store them in the repository.
5) QA testers run manual and automated tests, report execution results, and enter defects.
6) Developers review and fix defects logged into the database.
7) Project managers can export test and resource data in various reports, or in native Microsoft Excel for analysis.
8) Product managers decide whether an application is ready to be released.
9) QA analysts can auto-generate test asset documentation in Microsoft Word format.
<<<<<< =================== >>>>>>
Q. 97: What is the use of Analyze Traffic feature of VuGen?
The Analyze Traffic feature of VuGen examines a capture file containing the server network traffic, and creates a script which emulates requests sent to or from the server. Such a script is created after analyzing the server traffic.
<<<<<< =================== >>>>>>
Q. 98: How many types of network traffic emulations are there?
There are two types of emulations:
1) Incoming traffic emulation: Incoming traffic scripts emulate situations in which we want to send requests to the server, but we do not have access to the client application, may be due to security constraints. The most accurate solution in this case is to generate a script from the traffic going into the server, from the side of the client.
2) Outgoing traffic emulation: Outgoing Traffic scripts emulate the server acting as a client for another server. In an application server that contains several internal servers, we may want to emulate communication between server machines, say between Server A and Server B. The solution in this case is to generate a script from the traffic sent as output from a particular server.
<<<<<< =================== >>>>>>
Q. 99: What is a Capture File?
A capture file is a trace file containing a log of all TCP traffic over the network.
Using a sniffer application, we obtain a dump of all of the network traffic. The sniffer captures all of the events on the network and saves them to a capture file.
We can generate a capture file using the command line utility or any other capture tool.
<<<<<< =================== >>>>>>
Q. 100: What is the use of Web Service Call View?
Web Service Call view is used to display snapshots, set properties, and add checkpoints to Web Service calls. These are applicable for Web Services and SOA Vuser scripts only.
To open the Web Service Call view, we need to open the Tree view from the VuGen window
******************LOAD Runner -Controller *****************************************
Q. 1: What is the purpose of using HP - LoadRunner?
In real world scenario, it is not possible to create situation involving say one thousand users using a system simultaneously so as to test the behavior of the system under such stressful conditions. LoadRunner can create such a situation.
LoadRunner artificially simulates several thousand users - which are called Virtual Users. These artificial / digitally created users are simultaneously forced to operate on the same task, thereby loading the system in a way it is expected to be loaded by real human users in actual practice.
With LoadRunner we can simulate situation with hundreds or thousands of artificial users & we can impose definite, consistent and repeatable loads on the system thereby stressing it from end-to-end. This way we can emulate several business processes & production conditions, which a deployed application is going to encounter.
LoadRunner accurately measures, monitors, and analyzes a system’s performance and functionality.
<<<<<< =================== >>>>>>
Q. 2: What are the essential capabilities we look in a typical application performance-testing Tool?
Essential capabilities of an application performance testing tool are that:
1) It must be able to test a system which combines many software applications and hardware platforms.
2) It must be able to determine the suitability of a server for any given application.
3) It must be able to test the server before the necessary client software has been developed.
4) It must be able to emulate an environment where multiple clients interact with a single server application.
5) It must be able to test an application under the load of tens, hundreds, or even thousands of potential users.
<<<<<< =================== >>>>>>
Q. 3: What are the drawbacks of manual load testing processes?
Load testing of a complete system can be done manually by building an environment where many users work simultaneously on the system. Each user is made to work on his standalone machine and every individual submits input to the system. However due to complexity of such a system, following drawbacks are there
1) Manual testing methods offer only a partial solution to the load testing.
2) Manual testing is expensive & requires large amounts of manpower & equipment.
3) Manual testing is complicated, especially while coordinating and synchronizing multiple testers.
4) Manual testing involves a high degree of organization, especially to record and analyze results meaningfully.
5)The repeatability of the manual tests is limited.
<<<<<< =================== >>>>>>
Q. 4: How LoadRunner takes care of the shortcomings of manual performance testing?
1) LoadRunner reduces manpower requirements by replacing human users with virtual users or Vusers. These Vusers emulate the behavior of real users operating real applications.
2) Since several Vusers can run on a single computer, LoadRunner reduces the amount of hardware required for testing.
3) LoadRunner Controller allows us to easily and effectively control all the Vusers from a single point of control.
4) LoadRunner monitors the application performance online, enabling us to fine-tune the system during test execution.
5) LoadRunner automatically records the performance of the application during a test. We can choose from a wide variety of graphs and reports to view the performance data.
6) LoadRunner checks where performance delays occur: network or client delays, CPU performance, I/O delays, database locking, or other issues at the database server. LoadRunner monitors the network and server resources to help us improve performance.
7) Because LoadRunner tests are fully automated, we can easily repeat them as often as we need.
<<<<<< =================== >>>>>>
Q. 5: What are the process elements of using LoadRunner?
Process elements of LoadRunner are :
1) Scenario: Before using LoadRunner, we divide the application performance testing requirements into various scenarios. A scenario defines the events which occur during each testing session. Thus, 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.
2) Vusers: In the scenario, LoadRunner replaces human users with virtual users or Vusers. When we run a scenario, Vusers emulate the actions of human users working with our application. While a workstation accommodates only a single human user, many Vusers can run concurrently on a single workstation. In fact, a scenario can contain tens, hundreds, or even thousands of Vusers.
3) Vuser Scripts: The actions that a Vuser performs during the scenario are described in a Vuser script. When we run a scenario, each Vuser executes a Vuser script. The Vuser scripts include functions that measure and record the performance of our application’s components.
4) Transactions: To measure the performance of the server, we define transactions. A transaction represents an action or a set of actions that we are interested in measuring. We define transactions within our Vuser script by enclosing the appropriate sections of the script with start and end transaction statements. For example, we can define a transaction that measures the time it takes for the server to process a request to view the balance of an account and for the information to be displayed at the ATM.
5) Rendezvous points: We insert rendezvous points into Vuser scripts to emulate heavy user load on the server. Rendezvous points instruct Vusers to wait during test execution for multiple Vusers to arrive at a certain point, so that they may simultaneously perform a task. For example, to emulate peak load on the bank server, we can insert a rendezvous point instructing 100 Vusers to deposit cash into their accounts at the same time.
6) Controller: We use the LoadRunner Controller to manage and maintain our scenarios. Using the Controller, we control all the Vusers in a scenario from a single workstation.
7) Load Generator: When we execute a scenario, the Controller distributes each Vuser in the scenario to a load generator. The load generator is the machine that executes the Vuser script, enabling the Vuser to emulate the actions of a human user.
8) Performance analysis: Vuser scripts include functions that measure and record system performance during load-testing sessions. During a scenario run, we can monitor the network and server resources. Following a scenario run, we can view performance analysis data in reports and graphs.
<<<<<< =================== >>>>>>
Q. 6: What are our expectations from a scenario load testing an application Server?
The scenario would define the following actions which would be required to be performed on the server during the load test.
1) Emulating the conditions of controlled load on the server.
2) Emulating the conditions of maximum load on the server.
3) Measuring the server performance under load.
4) Check where performance delays occur: network or client delays, CPU performance, I/O delays, database locking, or other issues at the server.
5) Monitoring the network and server resources under load.
<<<<<< =================== >>>>>>
Q. 7: What is the role of Remote Agent Dispatcher in LoadRunner?
The role of Remote Agent Dispatcher is to enable the Controller to start applications on the load generator.
<<<<<< =================== >>>>>>
Q. 8: What is the role of LoadRunner Agent?
1) LoadRunner Agent enables the Controller and the load generator to communicate with each other.
2) When we run a scenario, the Controller instructs the Remote Agent Dispatcher to launch the LoadRunner agent.
3) The agent receives instructions from the Controller to initialize, run, pause, and stop Vusers.
4) The agent relays data on the status of the Vusers back to the Controller.
<<<<<< =================== >>>>>>
Q. 9: What type of actions a Vuser can perform during database server testing?
A Vuser script can perform following actions while testing a database server:
1) Logging in to the Web application.
2) Connecting to the database server.
3) Submitting an SQL query.
4) Retrieving and processing the server response.
5) Disconnecting from the server and the Web.
<<<<<< =================== >>>>>>
Q. 10: What are the broad steps involved in testing process by LoadRunner?
LoadRunner follows a Six–step process for testing the application under the load:
Step - 1: Planning the Test: Involves development of a thorough test plan for the success of the load testing effort.
Step - 2: Creating the Vuser Scripts: Vusers emulate human users interacting with our application. A Vuser script contains the actions which each Vuser performs during scenario execution.
Step - 3: Creating the Scenario: A scenario describes the events that occur during a testing session. A scenario includes a list of machines on which Vusers run, a list of scripts that the Vusers run, and a specified number of Vusers or Vuser groups that run during the scenario. We can create scenarios using the Controller.
Step - 4: Running the Scenario: User load is emulated on the server by instructing multiple Vusers to perform tasks simultaneously. We can set the level of load by increasing and decreasing the number of Vusers that perform tasks at the same time.
Step - 5: Monitoring a Scenario: This can be done by executing scenario monitoring with the help of LoadRunner's set of many resources.
Step - 6: Analyzing Test Results: During scenario execution, LoadRunner records the performance of the application under different loads. We can use LoadRunner’s graphs and reports to analyze the application’s performance.
Q. 11: What are the benefits of a test plan for a successful load testing?
A well-defined test plan is the first essential step to successful testing.
Planning of load testing helps us in:
1) Building test scenarios which accurately emulate our working environment. Load testing means testing our application under typical working conditions, and checking for system performance, reliability, capacity, and so forth.
2) Understanding as to which resources are required for testing. Application testing requires hardware, software, and human resources. Before we begin testing, we need to know which resources are available and decide how to use them effectively.
3) Defining success criteria in measurable terms. Focused testing goals and test criteria ensure successful testing. For example, it’s not enough to define vague objectives like "Check server response time under heavy load." A more focused success criterion would be "Check that 100 customers can check their account balance simultaneously, and that the server response time will not exceed one minute."
<<<<<< =================== >>>>>>
Q. 12: What are the elements of Load Test Planning Process using LoadRunner?
Load test planning is a three-step process:
Step -1: Analyzing the Application: Involves becoming thoroughly familiar with the hardware and software components, the system configuration, and the typical usage model. This step ensures that the testing environment created by us will accurately reflect the environment and configuration of the application under test.
Step -2: Defining Testing Objectives: Before starting the testing process, we need to define exactly what we want to achieve.
Step -3: Planning LoadRunner Implementation: Involves decision making on how to use LoadRunner to achieve our testing goals.
<<<<<< =================== >>>>>>
Q. 13: What factors do we consider while planning the system configuration before its load testing?
We describe the configuration of every system component like client machines, network, middleware, and servers in ample detail giving answers to the following:
1) How many users are anticipated to connect to the system?
2) What is the configuration of application client machine. Configuration includes information on hardware, memory, operating system, software, development tool etc.?
3) What types of database and Web servers are used with the information of hardware, database type, operating system, file server etc.?
4) How does the server communicate with the application client?
5) What is the middleware configuration and application server between the front-end client and back-end server?
6) What other network components are used like modems etc. which may affect response time?
7) What is the throughput of the communications devices & How many concurrent users can each device handle?
<<<<<< =================== >>>>>>
Q. 14: What factors do we consider regarding system usage while planning the load testing?
1) Consideration as to how the system is typically used, and decide which functions are important to test.
2) Consideration as to who uses the system, what are the number of each type of user and what are the common tasks performed by each user.
3) Consideration of any background load which might affect the system response time.
For example, say 500 persons log on to the accounting system every morning, and the same office network has a constant background load of 100 users performing various word processing and printing tasks. We would create a LoadRunner scenario with 600 virtual users signing in to the accounting database, and check the server response time.
<<<<<< =================== >>>>>>
Q. 15: What are the broad objectives before planning load testing?
Before starting testing, we need to define our objectives precisely as to what we want to achieve.
Broad application testing objectives for load testing with LoadRunner can be:
1) Measuring end-user response time: To know how long does it take to complete a business process?
2) Defining optimal hardware configuration: To know which hardware configuration provides the best performance?
3) Checking reliability: To know how hard or long can the system work without errors or failures?
4) Checking hardware or software upgrades: To know how does the upgrade affect performance or reliability?
5) Evaluating new products: To know which server hardware or software should we choose?
6) Measuring system capacity: To know how much load can the system handle without significant performance degradation?
7) Identifying problem areas: To know which element is slowing down the response time?
<<<<<< =================== >>>>>>
Q. 16: Load Testing is applicable during which stages of product life cycle?
Load testing is necessary throughout the product life cycle.
Load Testing activities performed during various stages of product life cycle are:
1) During Planning and Design stage: Evaluation of new products & measurement of response time of every activity.
2) During Product Development stage: Measurement of response time of every activity, checking of optimum hardware configuration, checking of hardware and software upgrades and checking of reliability.
3) During Product Deployment stage: Checking of reliability, measurement of response time of every activity and measurement of system capacity.
4) During Production stage: Measurement of response time of every activity and Identification of various problem areas.
5) During Evolution stage: Checking of hardware and software upgrades and measurement of system capacity.
<<<<<< =================== >>>>>>
Q. 17: At which points we use LoadRunner to measure the response time in our application?
Following type of response times are measured to decide as to where to run the Vusers and which Vusers to run, according to our predefined test objectives:
1) Measurement of end-to-end response time: We can measure the response time which a user experiences by running a GUI Vuser at the front end. GUI Vusers emulate real users by submitting input to and receiving output from the client application.
We can run GUI Vusers at the front end to measure the response time across the entire network, including a terminal emulator or GUI front end, network, and server.
2) Measurement of network and server response times: We can measure network and server response time, excluding response time of the GUI front end, by running Vusers on the client machine. Vusers emulate client calls to the server without the user interface. When we run many Vusers from the client machine, we can measure how the load affects network and server response time.
3) Measurement of GUI response time: We can find out as to how the client application interface affects response time by calculating the difference among the previous two measurements i.e.
GUI response time = (End-to-end response time) - (Network and server response time)
4) Measurement of server response time: We can measure the time it takes for the server to respond to a request without going across the network. When we run Vusers on a machine directly connected to the server, we can measure the server performance.
5) Measurement of middleware-to-server response time: We can measure response time from the server to middleware if we have access to the middleware and its API. We can create Vusers with the middleware API and measure the middleware-server performance.
<<<<<< =================== >>>>>>
Q. 18: What are the broad basis for creating Vuser scripts?
Since Vusers emulate the actions of a typical enduser, the Vuser scripts are created with a consideration of end-user tasks.
Vuser scripts are created based on the following:
1) Analysis of Vuser types: For finding out the number and type of Vusers expected to be created.
2) Activities expected to be performed by the Vusers: For example, for load testing a banking application, we would create a Vuser script which performs typical banking related activities.
3) Test objectives: Form the basis of taking decision on tasks to be measured and defining their transactions.
<<<<<< =================== >>>>>>
Q. 19: What factors do we consider while selecting hardware for using LoadRunner?
For running the desired number of Vusers the hardware and Operating system must be adequately powerful and fast.
Following factors are given due consideration while deciding the number of machines and their configuration:
1) Make a provision of running LoadRunner Controller on a separate machine.
2) Make a provision of a separate Windows-based machine for every GUI Vuser. However one UNIX machine can take care of running of several GUI Vusers.
3) Keep the configuration of GUI Vusers testing machine same like the actual user’s machine.
<<<<<< =================== >>>>>>
Q. 20: How LoadRunner can be helpful in checking the reliability of a hardware system?
LoadRunner can provide good pointers to decision making in following areas pertaining to hardware:
1) Finding out the level of system stability under heavy or continuous work loads, by creating stress on the system.
2) Testing the system by forcing it to handle the extended activity in a compressed time period to simulate the kind of activity a system would normally experience over a period of weeks or months.
Q. 21: How do we measure the system capacity?
We measure system capacity to find out how much excess capacity the system can handle without any degradation in its performance .
For checking the capacity of a system, we compare the performance versus load on the existing system, and find out a point at which significant degradation of response-time starts taking place. Point is known as "knee" when plotted over a response time curve.
<<<<<< =================== >>>>>>
Q. 22: What is the purpose of creating Scenarios in LoadRunner?
For testing a system by using LoadRunner, we need to create a scenario. Scenario is a file containing complete information about the testing session. The scenario is a means of emulating a real-life user.
The scenario contains following information about the mechanism of emulating the real users:
1) Details of groups of virtual users or Vusers.
2) Details of test scripts the Vusers will run.
3) Details of load generators upon which the scripts shall be made to run.
<<<<<< =================== >>>>>>
Q. 23: How many types of scenarios can be created while using Controller of LoadRunner?
We can create any one type of scenario out of the following:
1) Manual Scenario: Scenario is created manually by defining the number of Vuser groups we want to run, and building a schedule for LoadRunner to run these groups. Manual scenario can be created by defining the total number of Vusers to be used in the scenario, or assigning a percentage of the total number of Vusers to each script.
2) Goal-Oriented Scenario: We define the goals that we want to achieve in our test and LoadRunner automatically builds a scenario for us, based upon our goals.
<<<<<< =================== >>>>>>
Q. 24: How can we change the maximum number of scripts displayed in the Available Scripts list?
We can change the maximum number of scripts displayed in the Available Scripts list by modifying the registry key:
HKEY_CURRENT_USER\Software\Mercury Interactive\RecentScripts\max_num_of_scripts
<<<<<< =================== >>>>>>
Q. 25: What is the purpose of Scenario Files?
A scenario provides detailed description of various events taking place during every load testing session.
A scenario is created by using the Design view of Controller in LoadRunner. Once a scenario is created, LoadRunner saves the information in a
scenario file having an extension (*.lrs).
<<<<<< =================== >>>>>>
Q. 26: What methods are available in LoadRunner for building scenarios?
Two methods are available through which we can create scenarios.
1) Manual Scenario creation method: Involves creating groups and specifying the script, the load generator, and the number of Vusers included in each group. We can chose to opt for using Percentage Mode to distribute our Vusers among various scripts.
2) Goal Oriented Scenario creation method: Involves defining the goals we want our test to achieve, and LoadRunner automatically builds a scenario for us, based on these goals.
<<<<<< =================== >>>>>>
Q. 27: How can we change the maximum number of scripts displayed in the Available Scripts list?
We can change the maximum number of scripts displayed in the Available Scripts list by modifying the registry key:
HKEY_CURRENT_USER\Software\Mercury Interactive\RecentScripts\max_num_of_scripts
<<<<<< =================== >>>>>>
Q. 28: What is the purpose of having Vuser groups in scenarios?
A scenario consists of groups of Vusers which simulate the actions of human users on the application under test. When a particular scenario is run, the Vusers generate load on the server, and LoadRunner monitors the server and transaction performance..
Vuser groups are created to organize several Vusers in a scenario into manageable groups. Vuser groups are created by including Vusers having similar characteristics. For example, when many Vusers run the same Vuser script, we can club them into one Vuser group.
<<<<<< =================== >>>>>>
Q. 29: What type of actions can be performed on a Vuser group or scenario?
Following actions can be performed on a Vuser group:
1) Defining the group name, Vuser quantity, load generators, and scripts for the Vuser group.
2) Adding load generators to the Vuser group and configuring the load generators.
3) Adding and configuring scripts to the Vuser group.
4) Enabling or disabling a Vuser group for the scenario.
5) Removing a Vuser group from the scenario.
6) Scheduling the Vuser group execution.
7) Defining service level agreements for the scenario.
8) Running, stopping & resetting the scenario.
9) Configuring the settings of scenario results.
<<<<<< =================== >>>>>>
Q. 30: What is the meaning of pending status for a Vuser?
Pending status for a V user indicates that the Vuser is ready to be initialized and is waiting for an available load generator, or is transferring files to the load generator. The Vuser will run when the conditions set in its scheduling attributes are met.
Q. 31: What is the meaning of rendezvous status for a Vuser?
Rendezvous status for a Vuser indicates that the Vuser has arrived at the rendezvous and is waiting to be released by LoadRunner.
<<<<<< =================== >>>>>>
Q. 32: What is the purpose of Gradual Stop option for the Vusers?
Gradual Stop option Instructs the Controller to complete the current iteration or action before stopping the Vuser. This option is only available when the Vuser is in the RUN state.
<<<<<< =================== >>>>>>
Q. 33: How do we modify the run-time settings of multiple scripts?
We need to chose the method of modifying the run-time settings:
1) Modification method for Shared run-time settings: This method opens one window containing all of the run-time settings in blank mode. In this mode, we set only the options that we want to modify for all selected scripts. All other run-time settings remain unchanged.
Some of the run-time settings cannot be modified in shared mode. These settings do not appear. To modify them, we need to open the run-time settings for each individual script.
2) Modification method for Individual run-time settings: This method opens a separate window for each selected script. In this mode, we modify each script’s settings individually.
<<<<<< =================== >>>>>>
Q. 34: What configuration settings we can define for Load Generators in a scenario?
With the help of Load Generators dialog box, we can set following type of load generator’s attributes:
1) Defining which load generators will run Vusers in the scenario. For example, if a load generator is unavailable for a particular scenario run, we can exclude it temporarily instead of removing it entirely from your list of load generators.
2) Selecting which load generators will take part in the scenario by using the Enable and Disable commands. Disabling a load generator temporarily removes it from the list. Enabling a load generator reinstates it.
<<<<<< =================== >>>>>>
Q. 35: What is the role of controller in LoadRunner?
The Controller monitors a Windows load generator’s CPU usage and automatically stops loading Vusers on a load generator when it becomes overloaded.
We can monitor the status of a machine’s CPU usage. When the CPU usage of a load generator becomes problematic, the icon to the left of the load generator name contains a yellow bar. When the machine becomes overloaded, the icon contains a red bar.
<<<<<< =================== >>>>>>
Q. 36: What are the Terminal Services in LoadRunner?
Terminal services allows centralized management of computing resources for each client connected to the server, and provides each user with their own working environment.
We use LoadRunner’s Terminal Services Manager to remotely manage multiple load generators running in our load testing scenario on a terminal server. With the help of Terminal Services Manager, we can select the number of terminals to be used in our scenario & the maximum number of Vusers which can be run per terminal. The Terminal Services Manager then evenly distributes the number of virtual users among the client sessions.
With the help of Terminal Server Client, we can operate in a server-based computing environment from a remote machine. The terminal server transmits applications over the network and displays them via terminal emulation software. Every user logs on and sees only his individual session, which is managed transparently by the server operating system, independent of any other client session.
<<<<<< =================== >>>>>>
Q. 37: What is the use of Creating a Manual Scenario Using the Percentage Mode?
A manual scenario is created in the Percentage mode by defining the total number of Vusers to be used in the scenario, and assigning load generators and a percentage of the total number of Vusers to each script.
While creating a new scenario, we can access the Percentage Mode directly by selecting the "Use the Percentage Mode to distribute the Vusers among the scripts" in the New Scenario dialog box.
A scenario created in the Vuser Group Mode can be easily converted to the Percentage Mode.
<<<<<< =================== >>>>>>
Q. 38: What are the key considerations while converting a scenario from Vuser Group Mode to Percentage Mode?
1) In case we have defined multiple scripts for a Vuser group, the number of Vuser scripts created in the Percentage Mode will be same as the number of scripts defined for the group.
2) All Load Generators will be assigned to all Vuser scripts created in the Percentage Mode. In case we have defined multiple load generators for a Vuser group, the Vusers we assign to the scripts in the Percentage Mode will be distributed evenly among the load generators previously assigned by us to the group.
3) All Vuser group schedule settings will be lost. All profiles will contain scenario schedule settings only.
<<<<<< =================== >>>>>>
Q. 39: What are the key considerations while converting a scenario from Percentage Mode to Vuser Group Mode?
1) Each script will be converted to a Vuser group.
2) In case we have defined multiple load generators for a Vuser script, the Vuser group which is created when converting the scenario will also contain multiple load generators.
3) All schedule settings will be retained as it is.
<<<<<< =================== >>>>>>
Q. 40: What is the purpose of Scheduling Scenarios?
After creating a scenario, we schedule it to start running at a specified time. We can make a schedule defining the time at which to initialize, start, and stop Vusers during the scenario run, and how long an action should continue running.
We can restrict the execution duration of the scenario or of a Vuser group within the scenario. We can also stipulate how many Vusers to start and stop running within a certain time frame. We can specify whether LoadRunner should start or stop running all Vusers in a scenario simultaneously, or only a certain number of Vusers within a specified amount of time.
Q. 41: What is the effect of Rendezvous points on the running of scenarios as per schedule?
Rendezvous points, if present in a script, interfere with the scheduled scenario run. The scenario will not run as scheduled due to the presence of rendezvous points in the script.
<<<<<< =================== >>>>>>
Q. 42: What are the methods by which we can schedule the enabled Vuser groups in a scenario?
After creating a scenario, we can schedule the enabled Vuser groups to run according to either of the following:
1) As a part of a whole scenario: When we run a scenario, LoadRunner runs all the Vuser groups enabled in the scenario. The schedule defined for running the scenario is applied to all the Vuser groups concurrently, and LoadRunner applies each action proportionately to all the Vusers groups.
2) As per its own schedule: For each enabled Vuser group in a scenario, we can design a separate execution schedule. We can specify when to start running the Vuser group, how many Vusers to start and stop running within given time intervals, and how long the Vuser group should continue running.
<<<<<< =================== >>>>>>
Q. 43: How many modes are available to us for scheduling the running of scenario?
We can schedule a scenario to run in one of the following modes:
1) Real-life schedule: The scenario runs according to a user-defined group of actions that simulate a real-life schedule of events. Vuser groups run according to the iterations defined in their run-time settings, but we can define how many Vusers to run at a time, how long Vusers should continue to run, and how many Vusers to stop running at a time.
2) Classic Schedule: All enabled Vuser groups run together on one schedule, each according to its own run-time settings. We can schedule how many Vusers to start running at a time, how long to run the Vusers, and how many Vusers to stop running at a time.
3) Run until complete: All the Vuser groups in the scenario run according to the iterations defined in their run-time settings. Each Vuser group in the scenario runs its defined course, and when all the Vuser groups have finished running, the scenario run is complete.
<<<<<< =================== >>>>>>
Q. 44: What is the purpose of specifying Service Level Agreements in scenarios?
While creating a load testing scenario, we can specify our goals or service level agreements - SLA's for the performance measurement.
When this scenario is made to run the LoadRunner captures all the performance related data. During analysis phase, Analysis compares this data against the SLAs and determines SLA status for the defined measurements.
<<<<<< =================== >>>>>>
Q. 45: What methods LoadRunner uses to find out the SLA status?
Depending on the measurements being evaluated by us, LoadRunner finds out the SLA status in one of the following ways:
1) As per time interval within the run: Analysis displays SLA statuses at set time intervals in the timeline. For example, every 10 seconds - Analysis checks to see if the measurement’s performance has deviated from the threshold defined in the SLA.
2) As per the whole run: Analysis displays a single SLA status for the whole scenario run. The measurements include - Total Hits, Average Hits, Total Throughput, and Average Throughput.
<<<<<< =================== >>>>>>
Q. 46: How many types of Goal Oriented Scenarios can be created in LoadRunner?
In a goal-oriented scenario, we define the goals required to be achieved through our tests, and LoadRunner automatically builds a scenario for us based on these goals.
When we want to test how many Vusers the application can run simultaneously, it is better to define a type of goal for the Virtual Users.
Following five types of goals can be defined in a goal-oriented scenario:
1) Defined number of virtual users
2) Defined number of hits per second by the Web Vusers.
3) Defined number of transactions per second.
4) Defined number of pages per minute by the Web Vusers.
5) Defined transaction response time we want our scenario to reach.
<<<<<< =================== >>>>>>
Q. 47: Under what circumstances a Pages per Minute or Hits per Second goal-oriented scenario fails?
Pages per Minute or Hits per Second goal-oriented scenario is assigned a "Failed" status in situations like:
1) When the Controller has twice attempted to reach the goal using the maximum number of Vusers specified, and the goal could not be reached.
2) When no pages per minute or hits or transactions per second were registered after the first batch of Vusers was run.
3) When the number of pages per minute or hits or transactions per second did not increase after the Controller ran a certain number of Vuser batches.
4) When all the Vusers that were run failed.
5) When there were no available load generators for the type of Vusers we attempted to run.
<<<<<< =================== >>>>>>
Q. 48: What is Load Balancing process in LoadRunner?
Load balancing is the process, which evenly distributes the load generated by Vusers among the requested load generators, thereby ensuring an accurate load test.
When a Windows load generator’s CPU usage becomes overloaded, the Controller stops loading Vusers on the overloaded load generator, and automatically distributes them among load generators taking part in the scenario.
Load balancing option is available only in goal-oriented scenarios and manually controlled scenarios in the Percentage Mode.
<<<<<< =================== >>>>>>
Q. 49: What policy attributes can be defined for rendezvous points?
Setting the rendezvous policy determines how the Vusers handle a rendezvous point. We can set the following policy attributes for every rendezvous point:
1) Release policy: Defines how many Vusers will be released from a rendezvous point at a time.
2) Timeout policy: Defines how long the Controller shall wait before releasing Vusers from a rendezvous point.
<<<<<< =================== >>>>>>
Q. 50: Can we disable a particular Vusers at Rendezvous Points?
We can disable a rendezvous point for all Vusers in a scenario.
In addition to this we can disable a rendezvous point for a particular Vusers.
By disabling Vusers at a rendezvous point, we temporarily exclude them from participating in the rendezvous. Enabling disabled Vusers returns them back to the rendezvous.
Q. 51: What type of status related Rendezvous Information is available to us during creation of a scenario?
Following Rendezvous Information is available to us for viewing & necessary modifications:
1) Current Status: The number of Vusers that arrived at the rendezvous point out of the total number of Vusers assigned to the rendezvous.
2) Time: The time at which the Vusers at the rendezvous point were released.
3) Reason: The reason the Vusers at the rendezvous point were released. The possible reasons are Timeout or Arrived.
<<<<<< =================== >>>>>>
Q. 52: Out of Individual Load Generator settings & Global Settings, which ones come into effect?
When the global scenario settings differ from those of an individual load generator, the load generator settings override them.
<<<<<< =================== >>>>>>
Q. 53: What is the use of LoadRunner Expert mode?
We can configure additional settings for the LoadRunner agent and other LoadRunner components with the help of LoadRunner Expert mode.
<<<<<< =================== >>>>>>
Q. 54: How LoadRunner takes care of timeout value requirements in case of large number of Vusers?
LoadRunner automatically understands the fact that the number of active Vusers has a significant effect on the timeout values.
For example, 1000 Vusers trying to initialize will take much longer than 10 Vusers. Taking care of this, LoadRunner automatically adds an internal value, based on the number of active Vusers, to the timeout value specified by us.
<<<<<< =================== >>>>>>
Q. 55: While running a scenario, the run-time files are stored at which location by default?
While we run a scenario, by default the run-time files get stored locally on each load generator machine running the Vuser script.
The default location of the files is under the temporary directory specified by the load generator’s environment variables like Windows - TEMP or TMP Directory.
If no environment variable is defined, the files get saved to the /tmp directory.
<<<<<< =================== >>>>>>
Q. 56: What are the various types of Primary Run-time files?
Primary run-time files are of following types:
1) Vuser Script files: When we run a Vuser, the Controller sends a copy of the associated Vuser script to the Vuser load generator. These script files are stored in the load generator’s temporary run-time directory.
2) Result files: While we run a scenario, the participating Vusers write their results to the temporary run-time file directory. After scenario execution, these result files are consolidated and the results from all the load generators are transferred to the results directory.
<<<<<< =================== >>>>>>
Q. 57: How transfer of script files takes place at run time in case Vusers access the scripts at some shared location?
If we specify that all Vusers access their Vuser scripts directly at some shared location, no transfer of script files take place at run time.
<<<<<< =================== >>>>>>
Q. 58: What is Path translation in LoadRunner
Path translation is a mechanism used by LoadRunner to convert remote path names. We need to do path translation, when we specify a shared network drive for run-time file storage.
<<<<<< =================== >>>>>>
Q. 59: What preparatory steps are recommended for running a scenario?
Before running a scenario following are suggested steps:
1) Specify the location of the results.
2) Assign a name to the results.
3) Scheduling of the scenario.
4) Providing scenario summary information.
5) Specification of applications to be invoked at the start of the scenario.
<<<<<< =================== >>>>>>
Q. 60: What is the extension of scenario result file?
The general information about the scenario are stored in a result file with an extension (.eve and .lrr)
Q. 61: How Analysis module of LoadRunner interacts with the results files?
When analysis graphs and reports are generated, the Analysis module of LoadRunner copies all the scenario result files to a database.
Then the Analysis module directly interacts with the database and does not require the individual result files.
<<<<<< =================== >>>>>>
Q. 62: What are the benefits of saving scenarios in a Quality Center Project?
When Controller module of LoadRunner is connected to a Quality Center project, we can create a new scenario in the Controller and save it directly to the Quality Center project.
This helps us in keeping a track of all scenarios created for each subject and allows monitoring the progress of test planning and creation.
<<<<<< =================== >>>>>>
Q. 63: How can we test the functionality of an application under heavy load using LoadRunner?
LoadRunner integrates functional testing scripts created by Functional testing Tools like QTP or WinRunner. These scripts in the form of GUI Vuser scripts integrate into the scenarios of LoadRunner.
<<<<<< =================== >>>>>>
Q. 64: What are the benefits of running functional test scripts in LoadRunner?
1) To see how the functionality of the application gets affected under the heavy load.
2) To measure the end-to-end response time experienced by a typical user on the client side while the application is under load.
3) By including QTP test scripts at specific points in a LoadRunner scenario we can confirm that the functionality of our application does not get affected by the extra load at these sensitive points.
4) When a GUI Vuser script runs on our screen during the LoadRunner scenario, we can watch the actual steps executed by the Vuser in a real time.
<<<<<< =================== >>>>>>
Q. 65: What is a GUI Vuser?
A GUI Vuser emulates the complete environment of a human user. GUI Vusers enable us to measure and monitor end-to-end user response times while our client/server system is under load.
A GUI Vuser can be programmed to read and act on information that appears on its machine’s display. All actions of every GUI Vuser are described in a GUI Vuser script generally created in QTP or WinRunner.
GUI Vusers are monitored and managed through the Controller module of LoadRunner.
<<<<<< =================== >>>>>>
Q. 66: Can we use VuGen module of LoadRunner to run a GUI Vuser script?
We cannot use VuGen to run a GUI Vuser script.
We use the Controller module of LoadRunner to run a GUI Vuser script as part of a scenario. Whereas we use QTP or WinRunner to run a GUI Vuser script in the standalone mode.
<<<<<< =================== >>>>>>
Q. 67: What is End-to-end response time in relation to GUI Vuser Technology?
End-to-end response time means the total time that a user waits for a response after submitting a request. GUI Vusers measure real end-to-end response times. End-to-end response times include GUI response times plus network and server response times.
<<<<<< =================== >>>>>>
Q. 68: What are the special design constraints with QTP Tests while adopting in LoadRunner?
1) Only simple QTP tests should be adopted for use in LoadRunner & should be designed to pinpoint specific operations.
2) LoadRunner cannot run nested action iterations.
3) Do not include references to external actions or other external resources, like an external Data Table file, environment variable file, shared object repositories etc.
4) Include transactions in QTP test since LoadRunner only provides performance information for data that is included within a transaction.
<<<<<< =================== >>>>>>
Q. 69: How do we define transactions within our Vuser script?
Transactions are defined as an action or a set of desired actions to measure the performance of a server.
We define transactions within our Vuser script by enclosing the appropriate sections of the script with start and end transaction statements. For example, we can define a transaction, which measures the time it takes for the server to process a request to view the balance of an account and for the information to be displayed at the ATM.
<<<<<< =================== >>>>>>
Q. 70: For use in LoadRunner, which statements are manually added to basic Vuser script recorded in WinRunner?
Since LoadRunner provides performance-related information only for the data included within a transaction. Hence WinRunner test scripts are manually edited to include transactions needed to be used by LoadRunner. Thus following statements are manually inserted into WinRunner test scripts :
1) Transaction statements to measure the performance of the server.
2) Rendezvous statements to emulate a specific user load.
Q. 71: What are the special considerations while running the LoadRunner scenario integrated with GUI Vuser script created in QTP or WinRunner?
1) Run just the one GUI Vuser concurrently per machine.
2) Ensure that QTP and WinRunner are closed before running the scenario.
3) In the Run-time Settings for script dialog box, only the General categories and sub-categories like General, Iterations, Miscellaneous, Think Time etc. are relevant for QTP and WinRunner tests.
4) The Replay options are not relevant for QTP and WinRunner tests.
<<<<<< =================== >>>>>>
Q. 72: What actions are performed by the LoadRunner during scenario execution?
While executing a scenario, the LoadRunner does the following:
1) Recording of the duration of the transactions you defined in the Vuser scripts
2) Performing the rendezvous included in the Vuser scripts
3) Collecting error, warning, and notification messages generated by the Vusers
During running of scenarios Controller module of LoadRunner performs following actions:
a) Checking the scenario configuration information.
b) Invokes the applications selected by us for running with the scenario.
c) Distributing each Vuser script to its specified load generator. When the Vuser groups become re ready, they start executing their respective scripts.
<<<<<< =================== >>>>>>
Q. 73: Can we activate an additional Vuser while a scenario is running?
With the help of Run / Stop Vusers dialog box, we can activate an additional Vuser while a scenario is running.
The scenario will finally end when all the Vusers have completed their scripts, or when the specified duration finishes out, or when we terminate it.
<<<<<< =================== >>>>>>
Q. 74: What are the brief steps of running a scenario?
Scenario execution by & large follows following basic steps:
Step -1:Opening of an existing scenario or creating a fresh one.
Step -2:Configuring and scheduling the scenario.
Step -3:Setting the results directory.
Step -4:Running and monitoring the scenario.
<<<<<< =================== >>>>>>
Q. 75: How running of individual Vusers differ from running an entire scenario?
We can run all the Vusers and Vuser groups all together in a scenario, alternatively we can chose the specific Vuser groups and Vusers and can run them individually.
The difference in operation lies as under:
1) When We run an entire scenario, LoadRunner does not begin running Vusers until they all reach the Ready state.
2) When we run individual groups or Vusers, LoadRunner runs each Vuser immediately after it reaches the Ready state.
<<<<<< =================== >>>>>>
Q. 76: What do we mean by initialization of Vusers in a group?
By initializing the Vusers, we distribute the Vusers in the group to their specified load generators so that they get ready to execute their script.
The status of the Vuser group changes from Down to Pending to Initializing to Ready. In case a particular Vuser group does not get initialized due to any reason, the status of this Vuser group changes to Error.
By initializing all the Vusers in a group before running them, we can ensure that they all begin executing the scenario at the same time.
<<<<<< =================== >>>>>>
Q. 77: How the addition of new Vusers differ among various modes of running a scenario?
We run a scenario or Vuser in two modes like: 1) Vuser Group Mode 2) Percentage Mode.
1) Vuser Group Mode: Here we control the number of new Vusers that can be added to each Vuser Group, and the load generators on which these additional Vusers will run.
2) Percentage Mode: Here we control the number of new Vusers that can be distributed among the Vuser scripts according to the percentage you define, and the load generators on which these additional Vusers will run.
<<<<<< =================== >>>>>>
Q. 78: What type of Vuser activity can be seen while a scenario is running?
LoadRunner allows us to see the following Vuser activity during a scenario run:
1) On the Controller load generators, we can view the Output window, monitor Vuser performance online, and check the status of Vusers executing the scenario.
2) On remote machines, we can view the Agent summary with information about the active Vusers.
<<<<<< =================== >>>>>>
Q. 79: How connections are established among Controller & Load Generators under fire walled environment?
In a conventional non-firewalled load test scenario, the Controller can directly connect to the LoadRunner agents running on remote machines.
While running Vusers over a firewall, the direct connection between the controller and the Load Generator gets blocked by the firewall. The reason being that the Controller does not have permissions to open the firewall.
LoadRunner addresses this problem by using a communication configuration based on HTTPS or secured TCP/IP.
In such a fire walled environment, a LoadRunner agent is installed on load generators running Vusers, and on Monitor machines which monitor the servers. This agent communicates through port 443 in the firewall.
<<<<<< =================== >>>>>>
Q. 80: What is a MI Listener machine?
The MI Listener machine works as a router between the following:
1) The agent on the load generator machine and the Controller, enabling the Controller to run Vusers over a firewall.
2) The agent on the Monitor over Firewall machine and the Controller, enabling the Controller to monitor the servers that are located over a firewall.
MI Listener components are installed on a dedicated machine.
Q. 81: How the communication takes place across MI Listener machine in a fire-walled environment?
The MI Listener serves the purpose of a router between the Controller and the LoadRunner agent.
When the LoadRunner agent connects to the MI Listener machine, the MI Listener keeps a listing of the connection to the agent using a symbolic name that the agent passed to it.
When the Controller connects to the MI Listener machine, it communicates to the MI Listener through port 50500.
<<<<<< =================== >>>>>>
Q. 82: How many types of online monitors are available for controller machines?
1) Run-Time Monitors: For displaying the number and status of Vusers participating in the scenario, as well as the number and types of errors that the Vusers generate.
2) Transaction Monitors: For displaying the transaction rate and response time during scenario execution.
3) Web Resource Monitors: For providing information about the number of Web connections, throughput volume, HTTP responses, server retries, and pages downloaded to the Web servers during the scenario.
4) System Resource Monitors: For measuring the Windows, UNIX, Tuxedo, SNMP, Antara FlameThrower, and SiteScope resources used during a scenario.
5) Network Delay Monitor: For displaying the information about the network delays on our system.
6) Firewall Monitor: For measuring the statistics of the firewall servers during the scenario.
7) Web Server Resource Monitors: For measuring the statistics of the Apache, Microsoft IIS, iPlanet Web servers during the scenario.
8) Web Application Server Resource Monitors: For measuring the statistics of the Ariba, ATG Dynamo, BroadVision, ColdFusion, Fujitsu INTERSTAGE, iPlanet, Microsoft ASP, Oracle9iAS HTTP, SilverStream, WebLogic and WebSphere application servers during the scenario.
9) Database Server Resource Monitors: For measuring the statistics of the SQL server, Oracle, Sybase, and DB2 databases during the scenario.
10) Streaming Media Monitors: For measuring the statistics of the Windows Media Server and RealPlayer audio/video servers, as well as the RealPlayer and Media Player client during the scenario.
11) ERP/CRM Server Resource Monitors: For measuring the statistics of the SAP Portals, Siebel Servers, and PeopleSoft servers during the scenario.
12) Java Performance Monitor: For measuring the statistics of Java Platforms and Java-based applications using J2EE machines.
13) J2EE & .NET Diagnostics Monitors: For providing information to trace, time, and troubleshoot individual transactions through J2EE & .NET Web, application, and database servers.
14) Application Component Monitor: For measuring the statistics of the Microsoft COM+ server during a scenario run.
15) Application Deployment Solutions Monitor: For measuring the statistics of the Citrix MetaFrame servers during a scenario run.
16) Middleware Performance Monitors: For measuring the statistics of the Tuxedo and IBM Web servers during a scenario run.
17) Infrastructure Resources Monitor: For measuring the statistics of the network client data points during a scenario run.
<<<<<< =================== >>>>>>
Q. 83: What is Merging Graphs in LoadRunner?
LoadRunner allows us to merge the results of two graphs from the same scenario into a single graph.
The merging helps us to compare several different measurements at once. For example, we can make a merged graph to display the Web Throughput and Hits per Second, as a function of the elapsed time.
To merge two graphs, the x-axis of both the graphs must be the same measurement.
<<<<<< =================== >>>>>>
Q. 84: What situations are best suited for performing path translation?
1) When saving run-time result files to a shared drive which has been mapped differently by the Controller and remote load generator.
2) When the remote machine maps the path as another drive letter or path, path translation is necessary to enable the load generator to recognize the script location.
2) Across platforms - to translate Windows-based paths as seen by the Controller into paths recognized by the UNIX Vuser load generator.
<<<<<< =================== >>>>>>
Q. 85: What is the use of Expert mode of Controller module of LoadRunner?
It is basically meant for the support personnel & helps us in getting access to the system information.
When we work in the Expert mode, the Controller dialog boxes contains additional options for fine tuning the Controller operation.
<<<<<< =================== >>>>>>
Q. 86: How to check whether a particular problem lies with a scenario or lies with the Vuser script?
1) Verify that the script runs properly on all remote load generators in stand-alone mode.
2) Test the GUI Vuser scripts on Windows platforms using WinRunner.
3) Test the Vuser scripts on UNIX platforms by running them from the command line.
4) Test all other types of Vuser scripts on Windows platforms by running them from VuGen, or by running a single user from the Controller.
<<<<<< =================== >>>>>>
Q. 87: What to do when a test passes when run in VuGen, but fails when run in Controller?
When a test runs in VuGen, the full browser is used. However when this test is run in Controller, it use the browser basics only.
Hence before running a scenario in the Controller with multiple Vusers, it is a best practice to run a single Vuser in stand-alone mode to ensure that the test is free from bugs.
<<<<<< =================== >>>>>>
Q. 88: What to do when Controller machine fails to connect to the remote load generator machine?
Check the following items:1) Check TCP/IP connectivity: Ensure full TCP/IP connectivity among the Controller and Vuser machines. Use the ping utility from the DOS command line to verify communication with a remote machine.
2) Check Load generator connections: Ensure full connectivity of the load generator with every remote load generators from the Controller’s Load Generators dialog box.
3) Check UNIX shell: For UNIX Vusers, make sure that the Windows Controller can execute a remote shell command.
<<<<<< =================== >>>>>>
Q. 89: What is the use of LoadRunner Agent?
LoadRunner Agent runs on the load generators and enables communication between the Controller, load generators, and MI Listeners under fire-walled environment.
The LoadRunner agent receives instructions from the Controller to initialize, run, pause, and stop Vusers. At the same time, the agent also relays data on the status of the Vusers back to the Controller.
<<<<<< =================== >>>>>>
Q. 90: How can we increase the load during the Load test?
We can increase the load on the application during a running load test by manually adding more Vusers.
Q. 91: What to do in case of a warning message that Controller cannot activate additional Vusers?
This is a hardware related problem. It happens when we use our local machine having limited memory resources, as a load generator.
Hence it is better to use a dedicated machine as a load generator to avoid such problems.
<<<<<< =================== >>>>>>
Q. 92: How to know as to whether my application performed well under the load?
Look at the transaction response time and find out whether the transaction was within an acceptable limit for the customer.
If the transaction response time degrades, we need to look for problems.
<<<<<< =================== >>>>>>
Q. 93: When do we use of goal-oriented scenario in LoadRunner?
Prior to deploying an application, we want to run an acceptance test to make sure that the system will withstand the real-life expected workload.
We have an idea about a rate at which we expect the server should perform say in terms of number of hits or transactions per second.
Using a goal-oriented scenario we define a goal for the number of hits per second, transactions per second, or the transaction response time which we want to generate.
<<<<<< =================== >>>>>>
Q. 94: How many types of goals are provided by LoadRunner in a goal oriented scenario?
LoadRunner provides following five types of goals in a goal oriented scenario:
1) Number of concurrent Vusers.
2) Number of hits per second.
3) Number of transactions per second.
4) Number of pages per minute.
5) Transaction response time which we want the scenario to reach.
<<<<<< =================== >>>>>>
Q. 95: What is the objective of an analysis session after the load test?
The aim of an analysis session is to find out the failures in performance of our system and then to point out the root cause of such failures.
Following questions are asked during the analysis session.
1) Were the test expectations met?
2) What was the transaction response time on the user’s end under load?
3) Did the SLA meet or deviate from its goals?
4) What was the average transaction response time of the transactions?
5) What parts of the system could have contributed to the decline in performance?
6) What was the response time of the network and servers?
7) Can we find a possible cause by correlating the transaction times and backend monitor matrix?
<<<<<< =================== >>>>>>
Q. 96: What to do when a script fails during simple playback, while during recording same actions were successful?
Many applications use dynamic values which change every time we use the application. For example, some servers assign a unique session ID for every new session. When we try to replay a recorded session, the application creates a new session ID which happen to differ from the recorded session ID.
LoadRunner addresses this issue through correlation. Correlation saves the changing values, in this case the session ID, to a parameter. When running the emulation, the Vuser does not use the recorded value and instead of it, it uses the new session ID, assigned to it by the server.
<<<<<< =================== >>>>>>
Q. 97: How to confirm as to whether the desired content is the same as the returned web page?
This can be done through the content check which verifies that the expected information appears on a Web page while the script is running.
We can insert following two types of content checks:
1) Text check: For checking that a text string appears on a Web page.
2) Image check: For checking an image on a Web page.
<<<<<< =================== >>>>>>
Q. 98: What is the use of a Throughput graph?
The Throughput graph shows the amount of data in terms of bytes which the Vusers receive from the server at any given second.
We then compare this graph with the Transaction Response Time graph to see how throughput affects transaction performance.
<<<<<< =================== >>>>>>
Q. 99: How to know that the test has finished running?
When the test finishes its run, the Scenario Status pane shows the Down status. This indicates that the Vusers have stopped running.
We can look in the Vuser dialog box to see the status of each individual Vuser.
<<<<<< =================== >>>>>>
Q. 100: How can we instruct LoadRunner to randomly run only one Vuser in a group?
This can be done by right-clicking the Vuser group and selecting "Run One Vuser Until Complete".
A Vuser script log will open, displaying the run-time information about the Vuser.
*****************************Load Runner Basic**********************
Q. 1: What is the process of manual correlation in LoadRunner?
It is the method adopted for capturing the dynamic data resulting from the server responses & further reusing it in the script. It can be done in two ways like:
1.Manual correlation
2. Auto Correlation
<<<<<< =================== >>>>>>
Q. 2: What is the Load testing process in LoadRunner?
Step 1: Planning the test: Involves development of a clearly defined test plan to ensure that the newly developed test scenarios are able to accomplish the load-testing objectives.
Step 2: Creation of Vusers: Involves creation of Vuser scripts which contain various tasks performed by every Vuser, tasks performed by Vusers as a whole, and tasks measured as transactions.
Step 3: Creation of the scenarios: A scenario describes the events that occur during a testing session. It includes a list of machines, scripts, and Vusers that run during the scenario. Scenarios are created by using LoadRunner Controller. We can create manual scenarios as well as goal-oriented scenarios. In manual scenarios, we define the number of Vusers, the load generator machines, and percentage of Vusers to be assigned to each script. For web tests, we may create a goal-oriented scenario where we define the goal that our test has to achieve. LoadRunner automatically builds a scenario for us.
Step 4: Running the scenario: The load on the server is emulated by instructing multiple Vusers to perform the tasks simultaneously. Before the testing, we set the scenario configuration and scheduling. We can run the entire scenario, Vuser groups, or individual Vusers.
Step 5: Monitoring the scenario: Scenario execution is monitored using the LoadRunner online runtime, transaction, system resource, Web resource, Web server resource, Web application server resource, database server resource, network delay, streaming media resource, firewall server resource, ERP server resource, and Java performance monitors.
Step 6: Analyzing test results: During scenario execution, LoadRunner records the performance of the application under different loads. We use LoadRunner's graphs and reports to analyze the application's performance.
<<<<<< =================== >>>>>>
Q. 3 : When load and performance Testing are done?
Load testing is performed after the completion of interface (GUI) testing.
Single user testing focuses on functionality and user interface of a system component, while application testing focuses on performance and reliability of an entire system.
For example, a typical application-testing scenario might depict 1000 users logging in simultaneously to a system. This gives rise to issues such as what is the response time of the system, does it crash, will it go with different software applications and platforms, can it hold so many hundreds and thousands of users, etc.
<<<<<< =================== >>>>>>
Q. 4: What are the components of LoadRunner?
The components of LoadRunner are The Virtual User Generator, Controller, and the Agent process, LoadRunner Analysis and Monitoring, LoadRunner Books Online.
<<<<<< =================== >>>>>>
Q. 5: What Component of LoadRunner are used for recording a Script?
Virtual User Generator (VuGen) component is used to record a script. It enables you to develop Vuser scripts for a variety of application types and communication protocols.
<<<<<< =================== >>>>>>
Q. 6: What is a rendezvous point LoadRunner?
Rendezvous points are inserted into Vuser scripts to emulate heavy user load on the server.
Rendezvous points instruct Vusers to wait during test execution for multiple Vusers to arrive at a certain point, in order that they may simultaneously perform a task. For example, to emulate peak load on the bank server, you can insert a rendezvous point instructing 100 Vusers to deposit cash into their accounts at the same time.
<<<<<< =================== >>>>>>
Q. 7: What Component of LoadRunner are used to play Back the script in multi user mode?
Controller component is used to playback the script in multi-user mode. This is done during a scenario run where a vuser script is executed by a number of vusers in a group.
<<<<<< =================== >>>>>>
Q. 8: What is a scenario in LoadRunner?
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 to be performed, and the machines on which the virtual users run their emulations.
<<<<<< =================== >>>>>>
Q. 9 : What is the recording mode for web Vuser script in LoadRunner?
We use VuGen to develop a Vuser script by recording a user performing typical business processes on a client application. VuGen creates the script by recording the activity between the client and the server.
For example, in web based applications, VuGen monitors the client end of the database and traces all the requests sent to, and received from, the database server. We use VuGen to: Monitor the communication between the application and the server; Generate the required function calls; and Insert the generated function calls into a Vuser script.
<<<<<< =================== >>>>>>
Q. 10: Why do we create parameters in LoadRunner?
Parameters are like script variables. They are used to vary input to the server and to emulate real users. Different sets of data are sent to the server each time the script is run. Better simulate the usage model for more accurate testing from the Controller; one script can emulate many different users on the system.
Q. 11: What is a correlation in LoadRunner?
Correlation is used to obtain data which are unique for each run of the script and which are generated by nested queries. Correlation provides the value to avoid errors arising out of duplicate values and also optimizing the code (to avoid nested queries).
Corelations are of two types like :
1) Automatic correlation iinvolves setting of some rules for thecorrelation. It can be application server specific. Here values are replaced by data which are created by these rules.
2) Manual correlation, the value we want to correlate is scanned and create correlation is used to correlate.
<<<<<< =================== >>>>>>
Q. 12: How can we find out as to where correlation is required in LoadRunner?
There are two ways to find out the place of use of corelation
1) We can scan for correlations, and see the list of values which can be correlated. From this we can pick a value to be correlated.
2) We can record two scripts and compare them.
<<<<<< =================== >>>>>>
Q. 13: Where can we set automatic correlation options in LoadRunner?
We can set the automatic correlation from web point of view in recording options and correlation tab. Here we can enable correlation for the entire script and choose either issue online messages or offline actions, where we can define rules for that correlation.
Automatic correlation for database can be done using show output window and scan for correlation and picking the correlate query tab and choose which query value we want to correlate. If we know the specific value to be correlated, we just do create correlation for the value and specify how the value to be created.
<<<<<< =================== >>>>>>
Q. 14: What is the function to capture dynamic values in the web Vuser script in LoadRunner?
Web_reg_save_param function saves dynamic data information to a parameter.
<<<<<< =================== >>>>>>
Q. 15: When do you disable log in Virtual User Generator in LoadRunner?
Once we debug our script and verify that it is functional, we can enable logging for errors only. When we add a script to a scenario, logging is automatically disabled.
<<<<<< =================== >>>>>>
Q. 16: When do we use standard and extended logs in LoadRunner?
Standard Log Option: It creates a standard log of functions and messages sent during script execution to use for debugging.
It is suggested to disable this option for large load testing scenarios. When you copy a script to a scenario, logging is automatically disabled.
Extended Log Option: Is selected to create an extended log, including warnings and other messages. We can specify all additional information that needs to be added to the extended log.
<<<<<< =================== >>>>>>
Q. 17: How do we debug a script in LoadRunner?
VuGen contains two options to help debug Vuser scripts-the Run Step by Step command and breakpoints.
The Debug settings in the Options dialog box allow us to determine the extent of the trace to be performed during scenario execution.
The debug information is written to the Output window. We can manually set the message class within our script using the lr_set_debug_message function. This is useful if we want to receive debug information about a small section of the script only.
<<<<<< =================== >>>>>>
Q. 18:How do we write user defined functions in LoadRunner?
Before we create the User Defined functions we need to create the external library (DLL) with the function. We add this library to VuGen bin directory. Once the library is added then we assign user defined function as a parameter.
The function should have the following format: __declspec (dllexport) char* (char*, char). Few examples of user defined functions are GetVersion, GetCurrentTime, GetPltform etc.
<<<<<< =================== >>>>>>
Q. 19: What are the changes possible to be made in run-time settings in LoadRunner?
The Run Time Settings are:
a) Pacing - Has iteration count.
b) Log - Needs to Disable the Logging Standard Log
c) Extended Think Time - In think time there are two options like Ignore think time and Replay think time.
d) General - Under general tab we can set the vusers as process or as multithreading and each step as a transaction.
<<<<<< =================== >>>>>>
Q. 20: Where do we set Iterations for Vuser testing in LoadRunner?
Iterations are set in the Run Time Settings of the VuGen. The navigation for this is Run time settings, Pacing tab, set number of iterations.
Q. 21: How do we perform functional testing under load?
Functionality under load can be tested by running several Vusers concurrently. By increasing the amount of Vusers, we can determine how much load the server can sustain.
<<<<<< =================== >>>>>>
Q. 22: What is Ramp up in LoadRunner?
It is an option is used to gradually increase the amount of Vusers/load on the server. An initial value is set and a value to wait between intervals can be specified. To set Ramp Up, go to 'Scenario Scheduling Options'
<<<<<< =================== >>>>>>
Q. 23: What are the advantages of running the Vuser as thread in LoadRunner?
VuGen provides the facility to use multithreading. This enables more Vusers to be run per generator. If the Vuser is run as a process, the same driver program is loaded into memory for each Vuser, thus taking up a large amount of memory.
This limits the number of Vusers that can be run on a single generator. If the Vuser is run as a thread, only one instance of the driver program is loaded into memory for the given number of Vusers (say 100).
Each thread shares the memory of the parent driver program, thus enabling more Vusers to be run per generator.
<<<<<< =================== >>>>>>
Q. 24: How can we stop the execution of script when an error occurs?
The lr_abort function aborts the execution of a Vuser script. It instructs the Vuser to stop executing the Actions section, executes the vuser_end section and terminates the execution.
This function is useful when you need to manually abort a script execution as a result of a specific error condition. When you terminate a script using this function, the Vuser is assigned the status "Stopped". For this to take effect, we have to first uncheck the "Continue on error" option in Run-Time Settings.
<<<<<< =================== >>>>>>
Q. 25: What is the relation between Response Time and Throughput?
The Throughput graph shows the amount of data in bytes that the Vusers received from the server in a second.
When we compare this with the transaction response time, we will notice that as throughput decreased, the response time also decreased. Similarly, the peak throughput and highest response time would occur approximately at the same time.
<<<<<< =================== >>>>>>
Q. 26: What is the Configuration of systems in relation to the LoadRunner?
The configuration of our systems refers to that of the client machines on which we run the Vusers.
The configuration of any client machine includes its hardware settings, memory, operating system, software applications, development tools, etc.
This system component configuration should match with the overall system configuration that would include the network infrastructure, the web server, the database server, and any other components that go with this larger system so as to achieve the load testing objectives.
<<<<<< =================== >>>>>>
Q. 27: How do we identify the performance bottlenecks in LoadRunner?
Performance Bottlenecks can be detected by using monitors. These monitors might be application server monitors, web server monitors, database server monitors and network monitors. They help in finding out the troubled area in our scenario which causes increased response time.
The measurements made are usually performance response time, throughput, hits/sec, network delay graphs, etc.
<<<<<< =================== >>>>>>
Q. 28: How can we find out the web server related issues?
Using Web resource monitors we can find the performance of web servers. Using these monitors we can analyze throughput on the web server, number of hits per second that occurred during scenario, the number of http responses per second, the number of downloaded pages per second.
<<<<<< =================== >>>>>>
Q. 29: How can we find out the database related issues?
By running "Database" monitor and help of "Data Resource Graph" we can find database related issues.
<<<<<< =================== >>>>>>
Q. 30: How do we plan the Load in LoadRunner?
Load test is planned to decide the number of users, what kind of machines we are going to use and from where they are run. It is based on 2 important documents, Task Distribution Diagram and Transaction profile.
Task Distribution Diagram gives us the information on number of users for a particular transaction and the time of the load. The peak usage and off-usage are decided from this Diagram. Transaction profile gives us the information about the transactions name and their priority levels with regard to the scenario we are deciding.
Q. 31: What is the purpose of vuser_init action in LoadRunner?
Vuser_init action contains details of procedures to login to a server.
<<<<<< =================== >>>>>>
Q. 32: What is the purpose of vuser_end action in LoadRunner?
Vuser_end section contains details of log off procedures.
<<<<<< =================== >>>>>>
Q. 33: What is think time in LoadRunner?
It is the time that a real user waits between two actions.
For example: When a user receives data from a server, he may need to wait for some time may be several seconds to review the data before responding. This time delay is known as the think time.
<<<<<< =================== >>>>>>
Q. 34: What is think time threshold in LoadRunner
Threshold level is the level below which the recorded think time will be ignored. The default value is five (5) seconds. We can change the think time threshold in the Recording options of the Vugen.
<<<<<< =================== >>>>>>
Q. 35: What is the difference between standard log and extended log in LoadRunner?
The standard log sends a subset of functions and messages sent during script execution to a log. The subset depends on the Vuser type.
Extended log sends a detailed script execution messages to the output log. This is mainly used during debugging when we want information about parameter substitution, data returned by the server & advanced trace.
<<<<<< =================== >>>>>>
Q. 36: What is the purpose of lr_debug_message in LoadRunner?
The lr_debug_message function sends a debug message to the output log when the specified message class is set.
<<<<<< =================== >>>>>>
Q. 37: What is the purpose of lr_output_message in LoadRunner?
The lr_output_message function sends notifications to the Controller Output window and the Vuser log file.
<<<<<< =================== >>>>>>
Q. 38: What is the purpose of lr_error_message in LoadRunner?
The lr_error_message function sends an error message to the LoadRunner Output window.
<<<<<< =================== >>>>>>
Q. 39: What is the purpose of lrd_stmt in LoadRunner?
The lrd_stmt function associates a character string (usually a SQL statement) with a cursor. This function sets a SQL statement to be processed.
<<<<<< =================== >>>>>>
Q. 40: What is the purpose of lrd_fetch in LoadRunner?
The lrd_fetch function fetches the next row from the result set.
Q. 41: Waht are the various types of goals in a goal oriented scenario in LoadRunner?
Load Runner provides five different types of goals in a goal oriented scenario:
1) The number of concurrent Vusers
2) The number of hits per second
3) The number of transactions per second
4) The number of pages per minute
5) The transaction response time that you want your scenario
<<<<<< =================== >>>>>>
Q. 42: Where do we set automatic correlation options in LoadRunner?
Automatic correlation from web point of view, can be set in recording options and correlation tab. Here we can enable correlation for the entire script and choose either issue online messages or offline actions, where we can define rules for that correlation.
Automatic correlation for database, can be done using show output window and scan for correlation and picking the correlate query tab and choose which query value we want to correlate. If we know the specific value to be correlated, we just do create correlation for the value and specify how the value to be created.
<<<<<< =================== >>>>>>
Q. 43: How can we capture dynamic values in the web vuser script in LoadRunner?
Web_reg_save_param function saves dynamic data information to a parameter.
<<<<<< =================== >>>>>>
Q. 44: How do we use the recording mode for web Vuser script in LoadRunner?
We use VuGen to develop a Vuser script by recording a user performing typical business processes on a client application. VuGen creates the script by recording the activity between the client and the server.
For example, in web based applications, VuGen monitors the client end of the database and traces all the requests sent to, and received from, the database server. We use VuGen to: Monitor the communication between the application and the server; Generate the required function calls; and Insert the generated function calls into a Vuser script.
<<<<<< =================== >>>>>>
Q. 45: What is the use of parameters in LoadRunner?
Parameters are like script variables. These are used to vary input to the server and to emulate real users.
Different sets of data are sent to the server each time the script is run. It is better to simulate the usage model for more accurate testing from the Controller where one script can emulate many different users on the system.
<<<<<< =================== >>>>>>
Q. 46: For load testing, what you should know in addition to the knowldege of LoadRunner tool?
1) Management aspects of Load Testing especially the Planning.
2) Requirements gathering, Profile/Mix, SLA, Acceptance Criteria....
3) Broad understanding of the protocol we need to work with.
4) Basic knowledge of C programming.
<<<<<< =================== >>>>>>
Q. 47: How many users can we emulate with Load-Runner on a PC?
There is no limit. However it depends on system response. That too inturn depends on various factors like entire system configuration etc.
If system comes across bottle necks during the begining or with minimum no of Vusers, no further addition of vusers should be considered unless & until the previously observed bottleneck are adequately resolved.
<<<<<< =================== >>>>>>
Q. 48: How can we find out memory leak using Load Runner?
Setup the scenario with Available Bytes and Committed Bytes as one of the counters to monitor. Run the load test as per the norms. Observe the pattern of memory usage on the designated server with the ramp up of Vusers and see if they correlate.
When the memory usage goes to its peak, exit the Vusers gradually. If there wasn't any leakage, the Available Bytes should increase and Committed Bytes should decrease in correlation with the existing Vusers. If it doesn't happen, means that the memory usage had been very high, and the Vusers have successfully exited. It may indicate the memory leak had existed in the application and this aspect would need to be resolved at the code-level.
<<<<<< =================== >>>>>>
Q. 49: How can we record a command prompt operation in LoadRunner?
We can't record a command prompt operation in LoadRunner. Because LR works on a environment where Client and server talks with each other. It records only the communication of Client to Server and verifies the reply from Server.
<<<<<< =================== >>>>>>
Q. 50 :How can we run QTP scripts in LoadRunner?
1) Install QTP and Loadrunner in same machines.
2) Open the QTP script.
3) .Open Vugen and click on record then all provide all required information in all fields then click "OK" Button.
4) Click F5 or Replay in QTP script.
Q. 1: What is the basic purpose of HP LoadRunner?
LoadRunner is a tool for performance testing, which stresses the complete software application to isolate and identify potential client, network, and server bottlenecks.
<<<<<< =================== >>>>>>
Q. 2: What is Virtual User Generator or VuGen when talking about LoadRunner?
When testing or monitoring an environment, we need to emulate the true behavior of various users on the system. The testing tools like Loadrunner emulate an environment in which users concurrently work on the system.
For doing such an emulation, the human being is replaced with a virtual user - called a Vuser. All the actions performed by Vusers are recorded in a Vuser script. The basic tool for creating Vuser scripts is the Virtual User Generator called VuGen.
These scripts help us in emulating real-life situations of user performing various business processes.
<<<<<< =================== >>>>>>
Q. 3: What is the purpose of HP Performance Center?
Performance Center operates in conjunction with LoadRunner & implements the capabilities of LoadRunner on an enterprise level.
<<<<<< =================== >>>>>>
Q. 4: What actions are performed by VuGen during recording?
During recording VuGen monitors the client end of the database and traces all the requests sent by the user and received from the user, to the server. It records all the actions performed by us during the recording session and records only the activity between the client and the server.
VuGen automatically generates functions that accurately model and emulate the real world situations.
Duiring recording of a Vuser script, VuGen generates various functions which define the actions that we perform during the recording session. VuGen inserts these functions into the VuGen editor to create a basic Vuser script.
<<<<<< =================== >>>>>>
Q. 5: How a Vuser script enables running of large number of Vusers during the playback?
During playback, Vuser scripts communicate directly with the server by executing calls to the server API.
When a Vuser communicates directly with a server, system resources are not required for the client interface. This lets us run a large number of Vusers simultaneously on a single workstation, and enables us to use only a few testing machines to emulate large server loads.
For example, we can observe how a server behaved when one thousand Vusers simultaneously withdrew cash from a bank’s ATM.
<<<<<< =================== >>>>>>
Q. 6: What are the advantages of creating Vusers?
1) Since Vuser scripts do not depend on client software, we can use Vusers to check server performance even before the user interface of the client software has been fully developed.
2) With the help of VuGen, we can run scripts as standalone tests.
3) Running scripts through VuGen is useful for debugging since it enables us to see how a Vuser will behave and which enhancements need to be made.
<<<<<< =================== >>>>>>
Q. 7: What are the advantages of VuGen?
VuGen enables us to record a variety of Vuser types, each suited to a particular load testing environment or topology. When we open a new test, VuGen displays a complete list of the supported protocols.
VuGen not only records Vuser scripts, but also runs them. Running scripts from VuGen is useful for debugging. It enables us to emulate how a Vuser script will run when executed as part of a larger test.
<<<<<< =================== >>>>>>
Q. 8: What are the Steps of Creating Vuser Scripts?
Following steps are used for creating a Vuser script:
1) Recording a basic script using VuGen: For testing Windows-based GUI applications or complex Web environments like applets and Flash, we need to use GUI-based tools like HP QuickTest Professional.
2) Enhancing the basic script: By adding control-flow statements and other LoadRunner API functions into the script.
3) Configuring the run-time settings: Settings like iteration, log, and timing information need to be configured, and Vuser behavior needs to be defined during a script run.
4) Verifying the script’s functionality: By running it in standalone mode.
5) Integrating the Vuser script: After verification that the script is functional, it is integrated into our environment
<<<<<< =================== >>>>>>
Q. 9: What platforms are supported by VuGen?
VuGen records sessions on Windows platforms only.
However, a recorded Vuser script can run on both Windows as well as UNIX platform.
<<<<<< =================== >>>>>>
Q. 10: What Environment Options are available for setting up VuGen?
VuGen working environment can be set up by configuring following options:
1) Auto Recovery Option: For restoring our script’s settings in the event of a crash or power outage. For allowing auto recovery, we can specify a desired time interval between the saves in minutes. By default, Auto Recovery is set to 10 seconds.
2) Editor Option: For selecting a particular font and enable VuGen’s Intellisense capabilities which automatically fill in words and function syntax.
Q. 11: What types of views are provided by VuGen for examining the contents of our scripts?
VuGen provides several views for examining the contents of the script:
1) A text-based Script view: This view lets us examine the actual API functions which were recorded or inserted into the script. This view is ideal for advanced users who want to program within the script by adding "C" or Vuser API functions as well as control flow statements.
2) An icon based Tree view with snapshots, or an icon based Thumbnail view: This view shows the Vuser script in an icon-based format, with each step represented by a different icon. Within the Tree view, we can manipulate steps by dragging them to the desired location. We can also add additional steps between existing steps in the tree hierarchy.
<<<<<< =================== >>>>>>
Q. 12: What are the snapshots as displayed by the VuGen?
A snapshot is a graphical representation of the current step.
When working in Tree view, VuGen displays the snapshot of the selected step in the right pane. The snapshot shows the client window after the step was executed.
VuGen captures a base snapshot during recording and another one during replay. We can compare the Record and Replay snapshots to determine the dynamic values that need to be correlated in order to run the script.
<<<<<< =================== >>>>>>
Q. 13: How and when we examine multiple snapshots for a single step?
In many protocols like Microsoft Remote Desktop Protocol (RDP), we can view multiple snapshots for a single step.
This occurs when a mismatch occurs during replay and we decide to append the new image to the step.
<<<<<< =================== >>>>>>
Q. 14: What is the format of Snapshot Files & where these are stored?
Every time we replay the script, VuGen saves the snapshot files in the script directory with an .inf extension.
The replay snapshots are located in the script’s result directory like Iteration1, Iteration2 etc. for every set of results.
<<<<<< =================== >>>>>>
Q. 15: How many tabs are available In the Snapshot window for Web Vusers?
In the Snapshot window for Web Vusers, following tabs are available:
1) Page View: Display the snapshot in HTML as it would appear in a browser. This button is available for both the recording and replay snapshots. This viewis used to make sure that we are viewing the correct snapshot. In this view we do not see the values which need to be correlated.
2) Server Response: Displays the server response HTML code of the snapshot. This button is available for both the recorded and replayed snapshots. The HTML view also shows a tree hierarchy of the script in the left pane, with a
breakdown of the document’s components like: Header and Body with the title, links & forms etc.
3) Client Request: Displays the client request HTML code of the snapshot. This button is available for both the recorded and replayed snapshots. The HTML view also shows a tree hierarchy of the script in the left pane, with a breakdown of the document’s components like: Header and Body and their subcomponents.
<<<<<< =================== >>>>>>
Q. 16: What are Vuser functions created by VuGen?
When we record a Vuser script, VuGen generates Vuser functions and inserts them into the script.
Vuser functions are of following two types:
1) General Vuser Functions: This is also known as LR functions because each LR function has an lr prefix. The LR functions can be used in any type of Vuser script.
2) Protocol-Specific Vuser Functions: These are particular to the type of Vuser that we are recording. For example, VuGen inserts LRD functions into a database script, LRT functions into a Tuxedo script, and LRS functions into a
Windows Sockets script.
The general Vuser functions and the protocol-specific functions together form the LoadRunner API. This API enables Vusers to communicate directly with a server.
<<<<<< =================== >>>>>>
Q. 17: What is the purpose of Gneral Vuser functions or LR Functions?
General Vuser functions or LR Functions enable us to do the following:
1) Getting run-time information about a Vuser, its Vuser Group, and its host.
2) Adding transactions and synchronization points to a Vuser script. For example, the lr_start_transaction (lr.start_transaction in Java) function indicates the beginning of a transaction, and the lr_end_transaction (lr.end_transaction in Java) function indicates the end of a transaction.
3) Sending messages to the output, indicating an error or a warning.
<<<<<< =================== >>>>>>
Q. 18: What is Word Completion feature in VuGen?
Word Completion feature is a part of the IntelliSense enhancements in VuGen.
When the we begin typing a function, after we type the first underscore, VuGen opens a list box displaying all available matches to the function prefix, along with the function’s syntax and description. To use one of the displayed functions, select it, or scroll to the desired item and then select it. VuGen inserts the function at the location of the cursor. To close the list box, press the Esc key.
By default, VuGen uses word completion feature globally. But we can manually disable the word completion feature.
<<<<<< =================== >>>>>>
Q. 19: What is Show Function Syntax feature in VuGen?
Show Function Syntax is also a part of the IntelliSense enhancements in VuGen.
When we type the opening parenthesis of a function, VuGen shows the syntax of the function with its arguments and prototypes and a brief description.
By default, Show Function Syntax is enabled globally, but it can be disabled manually.
<<<<<< =================== >>>>>>
Q. 20: What is purpose of Header Files?
All of the non-Java function prototypes are listed in the library header files. The header files are located within the include directory of the product installation.
Header Files contain detailed syntax information and return values. Header Files also contain definitions of constants, availability, and other advanced information which is not included in the Function Reference.
In most of the cases, the name of the header file corresponds to the prefix of the protocol. For example, Database functions that begin with an lrd prefix, are listed in the lrd.h file.
. 21: How can we view the VuGen Workflow while creating scripts?
VuGen provides a set of workflow screens, which guide us through the different steps of creating a script. A basic script is created in the beginning and then we adapt it for our test or production environment.
By default, after installation VuGen opens with the Workflow view. We can also work in the Tree view or Script view. The next time we start VuGen and open a script, it opens to the view that we had open when we exited VuGen the last time. We can switch back to the wizard view by clicking on any task in the Task Pane.
<<<<<< =================== >>>>>>
Q. 22: What are the steps involved in parameterizing an argument in a script?
Various steps of parameterization are:
1) Locating the argument you want to parameterize
2) Giving the parameter a name
3) Selecting a parameter type
4) Defining properties for the parameter type
5) Replacing the argument with a parameter
<<<<<< =================== >>>>>>
Q. 23: What are the steps to run the load tests on the system to check the response and capacity of the machine?
This involves following two steps:
1) Iterations: This portion of the Workflow Wizard provides an introduction to iterations and allows us to open the Run-Time settings for setting their values.
2) Concurrent Users: This portion of the Workflow Wizard guides us through the process of creating a scenario using the LoadRunner Controller. In a scenario, we can specify the number of users to run concurrently and we can observe the behavior of our system with multiple users.
<<<<<< =================== >>>>>>
Q. 24: What are the steps involved while Finishing our Script?
The final Finishing step of the Workflow wizard involves the following actions:
1) Creating a Scenario: For running a load test on our system using the LoadRunner Controller.
2) Uploading to Performance Center: For running a test through a Performance Center server installation.
3) Uploading to Quality Center: For adding a test to the test repository.
4) Creating Business Process Report: Creating a Microsoft Word document containing a summary of the VuGen script.
<<<<<< =================== >>>>>>
Q. 25: What are the various sections of Vuser Script?
Every Vuser script created by VuGen contains a minimum of following three sections. Before and during the recording, we can chose the section of the script into which VuGen should insert the recorded functions.
1) vuser_init Section: This section is used when recording a login to a server. This section gets executed when the Vuser gets initialized or loaded. While running multiple iterations of a Vuser script, this section does not get repeated.
2) Actions Section: This section is used when recording client activity. This section gets executed when the Vuser is in Running status. When we run multiple iterations of a Vuser script, this is the only section of the script which gets repeated.
3) vuser_end Section: This section is used when recording a logoff procedure. This section gets executed when the Vuser finishes or is stopped. While running multiple iterations of a Vuser script, this section does not get repeated.
<<<<<< =================== >>>>>>
Q. 26: How do we view and edit the contents of script sections?
VuGen script editor is used to view and edit the contents of every section of the script. We can display the contents of only a single section at a time. To display a section, we just need to highlight its name in the left pane.
<<<<<< =================== >>>>>>
Q. 27: What is an actions class related to Vuser scripts?
We place all the code in the actions class, while working with Vuser scripts which use Java classes.
The Actions class contains following three methods, which correspond to the sections of scripts developed using other protocols:
1) Init method: This is used for inserting initialization routines.
2) Action method: This is used for inserting client actions.
3) End method: This is used for inserting log off procedures
<<<<<< =================== >>>>>>
Q. 28: How can we import actions into our script from another Vuser script?
We can import actions into our script from another Vuser script, only for the types of Vusers which support multiple actions.
We can import the actions from Vusers of the same type only. As a result, all parameters associated with the imported action, will get merged with the script.
Following two options are available for importing actions :
1) Import From Vuser.
2) Action to Import.
<<<<<< =================== >>>>>>
Q. 29: How do we convert our script to some presentable format describing the business process?
At the final stage of script creation, we can create a report describing our business process. VuGen exports the script information to a Microsoft Word document.
We can use a pre-designed template or the one provided with VuGen, to create structured reports with summary information about our test run. VuGen allows us to customize the contents of the report by indicating what type of information we want to include in it.
<<<<<< =================== >>>>>>
Q. 30: What type of preferences are necessary to be set before Script Generation?
Before recording a session, VuGen allows us to set the following preferences:
1) Specification of a language for script generation: The available languages for script generation vary according to the protocol. Some of the available languages are C, C#, Visual Basic, Visual Basic .NET, VB Script, and Javascript. By default, VuGen generates a script in the most common language suitable to the protocol, but we can change this through the Script recording options.
A script recorded in one language can be easily regenerated in another language after the recording.
2) Specification of language-specific recording options: This is done to instruct the recorder as to what to include in the script and how to generate it.
Q. 31: How do we select the best possible Scripting Language while recording?
While we begin a recording session, VuGen automatically creates a script which emulates our actions by default.
Various script generation languages used by VuGen are:
1) For MS .NET the default language is C or C# .
2) For the FTP, COM/DCOM, and mail protocols (IMAP, POP3, and SMTP): Visual Basic, VB Script, and Javascript.
Following languages are best suited for the respective applications:
1) C Language: For recording applications that use complex COM constructs and C++ objects.
2) C # Language: For recording applications that use complex applications and environments under MS .NET protocol only.
3) Visual Basic .NET Language: For VB .NET applications, using the full capabilities of VB.
4) Visual Basic for Applications: For VB-based applications, using the full capabilities of VB.
5) Visual Basic Scripting: For VBscript-based applications, such as ASP.
6) Java Scripting: For Javascript-based applications such as js files and dynamic HTML applications.
<<<<<< =================== >>>>>>
Q. 32: How can we can map the network traffic from a specific server while recording Vuser scripts?
While recording Vuser scripts which record network traffic on a socket level like -HTTP, SMTP, POP3, FTP, IMAP, Oracle NCA and WinSocket, we can set the Port Mapping options.
With such options, we can map the traffic from a particular server by defining the port combination to the desired communication protocol.
Mapping is created by specifying a server name, port number, or a complete server - port combination. Few examples are:
1) Specify that all the traffic from the server ABC on port 25, should be handled as SMTP.
2) Specify that all traffic from the server called XYZ should be mapped to the FTP protocol, regardless of the port.
3) Specify to map all traffic on port 23 to SMTP, regardless of the server name.
<<<<<< =================== >>>>>>
Q. 33: What is Forced Mapping?
If we specify a mapping for a port number, server name, or combination server - port, VuGen forces the network traffic to use that service.
For example, if we were to specify server on port 80 to use FTP, VuGen uses the FTP protocol to record that communication, even though the actual communication may be HTTP. In this instance, the Vuser script might be empty.
<<<<<< =================== >>>>>>
Q. 34: What is Traffic Forwarding & when do we use it?
Traffic Forwarding refers to the process of forwarding all traffic from a specific port to another server. This is useful in situations where VuGen cannot run properly on the client, such as unique UNIX machines, or instances where it is impossible to launch the application server through VuGen.
An option "Allow forwarding to target server from local port" is available wherein we configure VuGen to intercept the traffic from the problematic client machine, and pass it on to the server. Thus VuGen is able to process the data and generate code for the actions.
<<<<<< =================== >>>>>>
Q. 35: What type of enhancements are done to the Vuser Scripts?
We can enhance a Vuser script :
1) By adding General Vuser functions
2) By adding Protocol-Specific Vuser functions
3) By adding Standard ANSI C functions.
We can enhance the Vuser script either during the recording or after the recording.
<<<<<< =================== >>>>>>
Q. 36: What is the utility of General Vuser Functions in Vuser Scripts?
General Vuser functions are added to any Vuser scripts to enhance its functionality. For example, we can use General Vuser functions to measure the server performance, control server load, add debugging code, or to retrieve the run-time information about the Vusers participating in the test.
Some of the General Vuser functions are generated by VuGen and are inserted into the Vuser script during recording.
General Vuser functions can be used in any type of Vuser script. All General Vuser functions have an LR prefix.
<<<<<< =================== >>>>>>
Q. 37: What is the utility of Protocol-Specific Functions in Vuser Scripts?
The aim of having Protocol-Specific Functions is also to enhance the Vuser scripts. Many libraries of special functions are available for use.
We have libraries of functions specific to a particular type of Vuser. For example, we use the LRS functions in a Windows Sockets Vuser script and LRT functions in a Tuxedo Vuser script.
<<<<<< =================== >>>>>>
Q. 38: What is the utility of Standard ANSI C Functions in Vuser Scripts?
The aim of having Standard ANSI C Functions is also to enhance the Vuser scripts.
ANSI C functions allow us to add comments, control flow statements, conditional statements etc. to the Vuser scripts. we can add standard ANSI C functions to any type of Vuser script.
<<<<<< =================== >>>>>>
Q. 39: What is the purpose of transactions in Vuser Scripts?
Transactions are defined to measure the performance of the server. Every transaction measures the time it takes for the server to respond to specified Vuser requests. These requests can be simple tasks like waiting for a response for a single query, or complex tasks like submitting several queries and generating a report.
We insert Vuser functions in the Vuser scripts to mark the beginning and the end of a task for measuring a transaction.
We can mark any number of transactions in a script, and each transaction can be specified with a different name.
The transactions can be created during the recording as well after the recording by using transaction editor.
<<<<<< =================== >>>>>>
Q. 40: What steps are needed to create a transaction to measure a business process?
Before creating a script, we need to decide on the business processes we want to measure. Next step is to mark every business process or sub-process as a transaction.
Transaction creation has two basic steps.
1) Marking the start of the transaction
2) Marking the end of the transaction
We can create nested transactions that is creating transactions within transactions.
Q. 41: What is the purpose of Rendezvous Points in LoadRunner?
While doing the load testing of our system, we need to emulate heavy user load on the system. For simultaneous application of a particular amount of load, we synchronize Vusers to perform a particular task exactly at the same moment. Thus the point at which all the Vusers act simultaneously is called Rendezvous Point
In Vuser script we mark the meeting place for all Vusers by inserting a rendezvous in it. When some Vuser arrives at the rendezvous point, it waits until all the remaining Vusers participating in the rendezvous arrive. When the designated number of Vusers arrive at the rendezvous point, the Vusers are released from the rendezvous for performing the next task in the script.
<<<<<< =================== >>>>>>
Q. 42:The Rendezvous points are operative in how many sections of Vuser scripts?
Rendezvous points are effective only in the Action section of Vuser scripts. They are not effective in either the init section or the end section of the Vuser scripts.
<<<<<< =================== >>>>>>
Q. 43: How many types of functions can be added to the Vuser scripts to retrieve Vuser information?
We can add following functions to our Vuser scripts:
1) lr_get_attrib_string: For returning a command line parameter string.
2) lr_get_host_name: For returning the name of the machine running the Vuser script.
3) lr_get_master_host_name: For returning the name of the machine running the Controller.
4) lr_whoami : For returning the name of a Vuser executing the script.
<<<<<< =================== >>>>>>
Q. 44: What are the mechanisms available for Vuser to handle the errors during script execution?
By default, when a Vuser detects an error, the Vuser stops executing the script. We can instruct a Vuser to continue with the next iteration when an error occurs using one of the following methods:
1) By run-time settings method: We can specify the Continue on Error run-time setting. The Continue on Error run-time setting applies to the entire Vuser script. We can use the lr_continue_on_error function to override the Continue on Error run-time setting for a portion of a script.
2) By lr_continue_on_error function: This function enables us to control error handling for a specific segment of a Vuser script. To mark the segment, enclose it with lr_continue_on_error(1);and lr_continue_on_error(0); statements. The new error settings apply to the enclosed Vuser script segment.
<<<<<< =================== >>>>>>
Q. 45: What is think time?
The time for which a user waits between performing successive actions is known as the think time.
Vusers use the lr_think_time function to emulate user think time. When we record a Vuser script, VuGen records the actual think times and inserts appropriate lr_think_time statements into the Vuser script.
We can edit the recorded lr_think_time statements, and manually add more lr_think_time statements to a Vuser script.
While recording Java Vuser scripts, lr_think_time statements are not generated in the Vuser script.
<<<<<< =================== >>>>>>
Q. 46: What functions we use to read the command line arguments & to pass the values to a Vuser script?
We use following three functions for reading the command line arguments, and then to pass the values to a Vuser script:
1) lr_get_attrib_double: For retrieving double precision floating point type arguments.
2) lr_get_attrib_long: For retrieving long integer type arguments.
3) lr_get_attrib_string: For retrieving character strings.
<<<<<< =================== >>>>>>
Q. 47: Why do we use VuGen Parameters?
When we record a business process, VuGen generates a Vuser script composed of functions. The values of the arguments in the functions are the actual values used during the recording session.
For example, when we recorded a Vuser script while operating a web application. VuGen had generated a statement which searches a library’s database for the title say "ABC". Now when we replay the script using multiple Vusers and iterations, we would not want to repeatedly use the same value "ABC". Instead, we would replace the constant value with a parameter:
The resulting Vusers then substitute the parameter with values from a data source that we specify. The data source can be either a file, or internally generated variables.
<<<<<< =================== >>>>>>
Q. 48: What are the actions involved in parameterizing a Vuser script?
Parameterization of Vuser script involves the following two tasks:
1) Replacing the constant values in the Vuser script with parameters.
2) Setting the properties and data source for the parameters.
<<<<<< =================== >>>>>>
Q. 49: What are the advantages of parameterizing Vuser scripts?
Parameterizing a Vuser script has two advantages:
1) It reduces the size of the script.
2) It provides the ability to test the script with different values.
For example, if we want to search a library’s database for several titles, we only need to write the submit function once. Instead of instructing our Vuser to search for a specific item, use a parameter. During replay, VuGen substitutes different values for the parameter.
<<<<<< =================== >>>>>>
Q. 50: What are the limitations associated with parametrization of Vuser scripts?
Few limitations of parametrization of Vuser scripts are:
1) We can use parameterization only for the arguments within a function.
2) We cannot parameterize text strings which are not function arguments.
3) We can not parameterize all the function arguments.
Q. 51: What special commands are available for parameterization of VuGen generated Vuser scripts?
1) We can use the lr_eval_string function to "parameterize" a function argument which cannot be parameterized by using standard parameterization.
2) We can use the lr_eval_string function to "parameterize" any string in a Vuser script.
3) For VB, COM, and Microsoft .NET protocols, we need to use the lr.eval string function to define a parameter. For example,
r.eval_string("{Custom_param}").
<<<<<< =================== >>>>>>
Q. 52: How many Parameter Types are there in Vugen?
While creating a parameter, we specify the following four type of sources for the parameter data. Accordingly there are four type of parameters like:
1) File or Table Parameter
2) XML Parameter
3) Internal Data Parameter
4) User-Defined Function
<<<<<< =================== >>>>>>
Q. 53: What are Datafiles?
Data files store all the data accessed by the Vuser during script execution. Data files are of two types viz. 1) Local Data Files 2) Global Data Files.
Data files are useful when we have many known values for our parameter. The data in a data file is stored in the form of a table. One file can contain values for many parameters. Each column holds the data for one parameter. Column breaks are marked by a delimiter like a comma. For example, the undermentioned data file contains ID numbers and the Name of the persons:
id,name
250,Arun
251,Vivek
252,Sneha
We can use an existing ASCII file, or can import a database file or can instruct VuGen to create a new datafile for us.
<<<<<< =================== >>>>>>
Q. 54: What are File and Table Parameter Types?
While creating a parameter, we specify the source of the parameter data. We use parameters, by instructing the Vusers to take values from an data table or an external file which contains values defined by the user.
These parameters are called File and Table type parameters.
The Table parameter type is meant for applications needing testing by filling in table cell values. Whereas the file type uses one cell value for each parameter occurrence, the table type uses several rows and columns as parameter values, similar to an array of values. Using the table type, we can fill in an entire table with a single command.
<<<<<< =================== >>>>>>
Q. 55: What are the XML Parameter Types?
XML Parameter Types are the placeholder for multiple valued data contained in an XML structure. We can use an XML type parameter to replace the entire structure with a single parameter. For example, an XML parameter by the name Address can replace a contact name, an address, city, and postal code.
With the help of XML parameters we can have cleaner input of the data, and enables cleaner parameterization of Vuser scripts. XML parameters are recommended for use with Web Service scripts or for SOA services.
<<<<<< =================== >>>>>>
Q. 56: What are the Internal Data Parameter Types?
Internal data gets created automatically when a Vuser runs. These are like Date/Time, Group Name, Iteration Number, Load Generator Name, Random Number, Unique Number, and Vuser ID etc.
We can define the properties for the data getting generated internally by the Vuser.
<<<<<< =================== >>>>>>
Q. 57: What are the User Defined Parameter Types?
User Defined Parameter Types are the data being generated using a function from an external DLL.
A user-defined function replaces the parameter with a value returned from a function located in an external DLL.
Before we assign a user-defined function as a parameter, we need to create an external library (DLL) with the function. The format of the user defined function is: __declspec(dllexport) char *(char *, char *)
<<<<<< =================== >>>>>>
Q. 58: What is the Global Directory option for Parameterization in VuGen?
Global Directory option is available only for backward compatibility with earlier versions of VuGen. In earlier versions like 4.51 and below, when we created a new data table, there was a need to specify local or global. A local table is saved in the current Vuser script directory and is only available to Vusers running that script. A global table is available to all Vuser scripts. The global directory can be on a local or network drive.
However it is essential that the global directory is available to all machines running the script. We can change the location of the global tables at any time with the help of General Options dialog box.
In newer versions of VuGen, we need to specify the location of the data table either in the Parameter Properties dialog box or in the Parameter List dialog box. VuGen is able to retrieve the data from any location that we specify. It may be either the default script directory or another directory on the network.
<<<<<< =================== >>>>>>
Q. 59: How do we Import Data for parameterization from an Existing Database?
VuGen allows us to import data from a database for use with parameterization. We can import the data in either of the following two ways:
1) Creating a New Query via an MS Query
2) Specifying an SQL Statement
We can use the wizard provided by the VuGen for importing data from a database. Here we need to specify the way of importing the data as described above. After completion of importing the data, it is saved as a file with a .dat extension and stored as a regular parameter file.
<<<<<< =================== >>>>>>
Q. 60: What are the ways to assign data from a file source to the parameters in VuGen?
Three methods are used for assigning data from a file source to the parameters:
1) Sequential Method: It assigns data to a Vuser sequentially. As a running Vuser accesses the data table, it takes the next available row of data. If there are not enough values in the data table, VuGen returns to the first value in the table, continuing in a loop until the end of the test.
2) Random Method: It assigns a random value from the data table to each Vuser at the start of the test run.
When running a scenario, we can specify a seed number for random sequencing. Each seed value represents one sequence of random values used for test execution. Whenever we use this seed value, the same sequence of values is assigned to the Vusers in the scenario. We enable this option in case of any problem in the test execution and there is a need to repeat the test using the same sequence of random values.
3) Unique Method: It assigns a unique sequential value to the parameter for each Vuser.
For using this method we need to ensure that there is enough data in the table for all the Vusers and their iterations. If there are 20 Vusers and we want to perform 5 iterations, our table must contain at least 100 unique values. If there are not enough values in the data table, we can instruct VuGen how to proceed.
Q. 61: How many methods are available in VuGen for updating several parameter types?
Following three parameter update methods are available:
1) Each Occurrence method: It instructs the Vuser to use a new value for each occurrence of the parameter. This is useful when the statements using a parameter are unrelated. For example, for random data, it may be useful to use a new value for each occurrence of the parameter.
2) Each Iteration method: It instructs the Vuser to use a new value for each script iteration. If a parameter appears in a script several times, the Vuser uses the same value for all occurrences of the parameter, for the entire iteration. This is useful when the statements using a parameter are related.
3) Once method: It instructs the Vuser to update the parameter value only once during the scenario run. The Vuser uses the same parameter value for all occurrences and all iterations of the parameter. This type may be useful when working with dates and times.
<<<<<< =================== >>>>>>
Q. 62: What is Simulation of File Type Parameters for LoadRunner users?
Once a File type parameter is created, we can use the File Parameter Simulator to simulate the parameter substitution in an actual scenario.
Simulator allows us to correct any wrong parameters before we run the script in the Controller.
<<<<<< =================== >>>>>>
Q. 63: What is the purpose of correlating statements in VuGen?
VuGen provides "Correlated Query" feature for linking the statements by using the results of one statement as input for the other. Correlating statements are used for optimizing the Vuser scripts.The objective of correlating statements are:
1) To simplify or optimize the code: For example, if we perform a series of dependent queries one after another, the code tends to become very long. To reduce the size of the code, we can nest the queries, but in this process we lose the precision and the code becomes complex and difficult to understand. In such a situation, correlating the statements enables us to link the queries without nesting.
2) To generate dynamic data: Many applications and Web sites identify a session by the current date and time. When we try to replay a script, it will fail because the current time is different than the recorded time. Correlating the data enables us to save the dynamic data and use it throughout the scenario run.
3) To accommodate unique data records: Certain applications like databases require the use of unique values. A value that was unique during recording is no longer unique for script execution. Lt us take an example, wherein we record the process of opening a new bank account. Each new account is assigned a unique number which is unknown to the user. This account number is inserted into a table with a unique key constraint during recording. If we try to run the script as recorded, it tries to create an account with the recorded number, rather than a new unique number. An error will result because the account number already exists.
<<<<<< =================== >>>>>>
Q. 64: What are the various types of C Vuser correlation functions?
Following three types of C Vuser correlation functions are used for correlating the statements for protocols which do not have any specific functions. These can be used to save a string to a parameter and retrieve it as and when required.
1) lr_eval_string Function: Replaces all occurrences of a parameter with its current value.
2) lr_save_string Function: Saves a null-terminated string to a parameter.
3) lr_save_var Function: Saves a variable length string to a parameter.
<<<<<< =================== >>>>>>
Q. 65: What are the various types of Java Vuser correlation functions?
Following seven types of Java Vuser correlation functions are used . These can be used to save a string to a parameter and retrieve it as and when required.
1) lr.eval_string Function: Replaces a parameter with its current value.
2) lr.eval_data Function: Replaces a parameter with a byte value.
3) lr.eval_int Function: Replaces a parameter with an integer value.
4) lr.eval_string Function: Replaces a parameter with a string.
5) lr.save_data Function: Saves a byte as a parameter.
6) lr.save_int Function: Saves an integer as a parameter.
7) lr.save_string Function: Saves a null-terminated string to a parameter.
<<<<<< =================== >>>>>>
Q. 66: What is the purpose of WDiff utility?
WDiff is a tool for determining which values to correlate. With the help of this we can compare recorded scripts and results to find out as to which values need to be correlated.
While working with other protocols, we can view the Execution log to find out where the script failed and then use the WDiff utility to help us in locating the values that need to be correlated.
For making an effective use of WDiff utility, we need to record the identical operation twice, and compare the scripts. It displays differences in yellow color.
<<<<<< =================== >>>>>>
Q. 67: Why do we configure th run-time settings for Vuser Scripts?
After a Vuser script is recorded, we need to set its run-time settings to define the way the new script should run. These run-time settings get applied to the Vusers when a script is made to run through LoadRunner's VuGen or Controller.
These run-time settings are stored in the "default.cfg" file, located in the Vuser script directory.
By defining the run-time settings we can emulate various types of user activity. For example, we can emulate a user who responds immediately to output from the server, or a user who stops and thinks before each response. We can use these run-time settings to specify how many times the Vuser should repeat its set of actions.
<<<<<< =================== >>>>>>
Q. 68: What are Action Blocks in Scripts?
Action blocks are groups of actions within the script. We can create separate action blocks for groups of actions by adding the same action to several blocks. We can instruct VuGen to execute action blocks or individual actions sequentially or randomly.We can set the properties of each action block independently. These properties can be like the following:
1) Sequence: means the order of actions within your script.
2) Iterations: Means the number of times Vusers repeat all of the Actions.
3) Weighting:Means weight or percentage of each action within a block.
<<<<<< =================== >>>>>>
Q. 69: What is the purpose of Pacing Run Time settings for multiple actions?
Pacing Run Time settings allows us to control the time between iterations. The pace tells the Vuser how long to wait between iterations of your actions. We can instruct the Vusers to start each iteration by either of the following methods:
1) As soon as the previous iteration ends: The new iteration begins as soon as possible after the previous iteration ends.
2) After the previous iteration ends with a fixed or random delay: It starts each new iteration a specified amount of time after the end of the previous iteration. Specify either an exact number of seconds or a range of time. For example, we can specify to begin a new iteration at any time between 60 and 90 seconds after the previous iteration ends.
3) At fixed or random intervals: We specify the time between iteration - either a fixed number of seconds or a range of seconds from the beginning of the previous iteration. For example, we can specify to begin a new iteration every 30 seconds, or at a random rate ranging from 30 to 45 seconds from the beginning of the previous iteration. Each scheduled iterations will only begin when the previous iteration is complete.
<<<<<< =================== >>>>>>
Q. 70: How many type of information logging are available?
We can specify the type of information that is logged in following ways
1) Standard Log: Creates a standard log of functions and messages sent during script execution to use for debugging. Disable this option for large load testing scenarios or profiles.
2) Extended Log: Creates an extended log, including warnings and other messages. It is recommended to disable this option for large load testing scenarios or profiles.
Q. 71: What type of Extended log options are available for posting additional information?
Following Extended log options are available:
1) Parameter substitution: This option is selected to log all parameters assigned to the script along with their values.
2) Data returned by server: This option is selected to log all of the data returned by the server.
3) Advanced trace: This option is selected to log all of the functions and messages sent by the Vuser during the session. This option is useful while debugging a Vuser script.
<<<<<< =================== >>>>>>
Q. 72: What is a Message Class?
Message Class is the degree to which VuGen logs various events likeStandard, Parameter substitution etc.
There are five types of Message Classes:
1) Brief 2) Extended 3) Parameters 4) Result Data 5) Full Trace.
A Message Class can be manually set within our script with the help of lr_set_debug_message function. This is useful when we want to receive debug information about a small section of the script.
<<<<<< =================== >>>>>>
Q. 73: What options are available for setting the Think Time in our Scripts?
Vuser think time emulates the time that a real user waits between actions. By default, when a Vuser script is run, the Vuser uses the think time values that were recorded into the script during the recording session.
VuGen allows us to use following options:
1) Use the recorded think time
2) Ignore the recorded think time
3) Use a value related to the recorded time
<<<<<< =================== >>>>>>
Q. 74: What type of Miscellaneous run-time options are available for a Vuser script?
Following Miscellaneous run-time options are available for a Vuser script:
1) Error Handling Settings: Following three types of settings are available under this category
a) Continue on Error: This setting instructs Vusers to continue script execution when an error occurs. This option is turned off by default, indicating that the Vuser will exit if an error occurs.
b) Fail open transactions on lr_error_message: This option instructs VuGen to mark all transactions in which an lr_error_message function was issued, as Failed. The lr_error_message function is issued through a programmed If
statement, when a certain condition is met.
c) Generate Snapshot on Error: This option generates a snapshot when an error occurs. We can see the snapshot by viewing the Vuser Log and doubleclicking on the line at which the error occurred.
2) Multithreading Settings: Vusers support multithread environments. The primary advantage of a multithread environment is the ability to run more Vusers per load generator.
3) Automatic Transactions Settings: We can instruct LoadRunner to handle every step or action in a Vuser script as a transaction. This is called using automatic transactions. LoadRunner assigns the step or action name as the name of the transaction. By default, automatic transactions per action are enabled.
<<<<<< =================== >>>>>>
Q. 75: How can we do the speed simulation for the Network while working on Loadrunner?
With the help of Speed Simulation settings, we can select a bandwidth which best suits the environment under test.
Three options are available to us for speed simulation of network:
1) Use maximum bandwidth: By default, bandwidth emulation is disabled and the Vusers run at the maximum bandwidth that is available over the network.
2) Use bandwidth: Indicate a specific bandwidth level for our Vuser to emulate. We can select a speed ranging from 14.4 to 512 Kbps, emulating analog modems, ISDN, or DSL.
3) Use custom bandwidth: Indicate a bandwidth limit for your Vuser to emulate. Specify the bandwidth in bits, where 1 Kilobit=1024 bits.
<<<<<< =================== >>>>>>
Q. 76: What are Breakpoints?
Breakpoints pause the execution at specific points in the script. Breakpoints enable us to examine the effects of the script on our application at pre-determined points during execution.
All breakpoints in our script can be viewed and manipulated by using the Breakpoint Manager of VuGen.
<<<<<< =================== >>>>>>
Q. 77: What tools are available in VuGen for debugging the Web Vuser Scripts?
VuGen provides following two tools to help us debug our Web Vuser scripts
1) Run-time viewer: It shows each Web page as it is accessed by the Vuser. This is useful when we debug Web Vuser scripts because it allows us to check that the Vuser accesses the correct Web pages.
2) Results Summary report: It summarizes the success or failure of each step in the Web Vuser scripts and allows us to view the Web page returned by each step.
<<<<<< =================== >>>>>>
Q. 78: How can we run a Vuser Script from a Command Prompt?
We can test a Vuser script from a Command Prompt or from the Windows Run dialog box without the VuGen user interface by following method.
1) Select Start > Programs > Command Prompt to open a Command Prompt window, or select Start > Run to open the Run dialog box.
2) Type /bin/mdrv.exe -usr -vugen_win 0 and press enter
Here script_name is the full path to the .usr script file, for example, c:\temp\mytest\mytest.usr.
And the mdrv executable runs a single instance of the script without the user interface.
<<<<<< =================== >>>>>>
Q. 79: What information is needed for Integrating Scripts into the Test environment?
After successfully testing the script in standalone mode and confirming its perfect functionality, we integrate it into the full-fledged environment like: a LoadRunner scenario, Performance Center load test, or Business Process Monitor profile etc.
Following information is provided while integrating the test:
1) Which is the script that needs to be integrated.
2) Details of Vusers, which will run the script.
3) Details of load generator upon which the script will be executed.
4) Details of scheduling etc.
<<<<<< =================== >>>>>>
Q. 80: How do we create a LoadRunner Scenario?
Generally we create a scenario from the LoadRunner Controller module.
However we can create a basic scenario from VuGen using the current script as well.
Q. 81: How do we manage Vuser Scripts created in VuGen?
VuGen works seamlessly with HP Quality Center, which is a Web-based test management tool. With Quality Center we can efficiently store and retrieve the Vuser scripts, scenarios and results.
Scripts are stored in a Quality Center project and can be organized into unique groups. When VuGen is connected to a Quality Center project, we can create new scripts in VuGen and save them directly to our project.
<<<<<< =================== >>>>>>
Q. 82: How do we manage Scripts with HP Performance Center?
VuGen provides integration with HP - Performance Center, which is a Web-enabled global load testing tool providing facility to test our system from different geographical locations.
Through the user interface of VuGen we can upload and download scripts to and from Performance Center . The scripts are uploaded to the Performance Center to add them to the Vuser Scripts list and for use later our test. The scripts can be downloaded for editing and saving them locally.
VuGen can access a Performance Center project, after a connection is established with the Web server on which Performance Center is installed.
<<<<<< =================== >>>>>>
Q. 83: How can we create Vuser script through programming?
We can create a Vuser script through programming within the Visual C and Visual Basic environments. We can develop our Vuser script within our development application, while importing the Vuser API libraries.
We can program a Vuser script from within the VuGen editor while incorporating all our libraries or classes of the application.
We use a VuGen template for creating a Vuser script through programming, which forms the basis for a larger Vuser script.
<<<<<< =================== >>>>>>
Q. 84: How do we create XML script using VuGen?
VuGen allows us to dynamically work with XML code and retrieve the values during test execution.
Steps for creating XML script are:
1) Record a script in the desired protocol, usually Web, Web Services, or Wireless.
2) Copy the XML structures into the script.
3) Add XML functions from the LR API in order to retrieve dynamic data and the XML element values.
<<<<<< =================== >>>>>>
Q. 85: How many functions are available in VuGen for writing values to an XML tree?
We can write values to an XML tree using following five functions:
1) lr_xml_delete : For deleting fragments from an XML string.
2) lr_xml_insert : For inserting a new XML fragment into an XML string.
3) lr_xml_replace : For replacing fragments of an XML string.
4) lr_xml_set_values : For setting the values of XML elements found by a query.
5) lr_xml_transform : For applying Extensible Stylesheet Language (XSL) transformation to XML data.
<<<<<< =================== >>>>>>
Q. 86: How can we use VuGen as a General Debugging tool?
VuGen can be used as a regular text editor. We can open any text file in it and edit it.
When an error message comes up during replay in the output window, we can double click on it and VuGen jumps the cursor to the line of the test that caused the problem.
We can place the cursor on the error code and press F1 to view the online help explanation for the error code.
<<<<<< =================== >>>>>>
Q. 87: Why a data driven two tier database script fails, while it works fine with the same values in the application?
The failure can be due to presence of trailing spaces in our data values.
Even though we type the data values directly into the GUI, there is a probability of data getting truncated. Hence we should manually eliminate the trailing spaces from the data file. Tab -delimited files can hide trailing spaces and can cause problems. Hence comma-delimited files are the most recommended ones. However It is suggested to view the files in Excel to confirm their correctness before hand.
<<<<<< =================== >>>>>>
Q. 88: How can we create Vuser scripts for running on UNIX platforms?
We can create Vuser scripts which can run on UNIX platforms by following two methods:
1) By using VuGen: We record our application in a Windows environment and run it in UNIX, because recording is not supported on UNIX.
2) By Programming: Scripts can be programmed in C or C++ and they must be compiled into a dynamic library. To create a script through programming, we can use a Vuser template as a basis for a larger Vuser scrips.
<<<<<< =================== >>>>>>
Q. 89: How do we use VuGen to create test scripts for testing SOA environment?
We can use a test generation wizard in VuGen to automatically generate scripts, or create the scripts manually.
To automatically generate test scripts, we use the SOA Test Generator. A wizard guides us through the process of selecting testing aspects such as interoperability with different toolkits, boundary testing, and standard compliance.
<<<<<< =================== >>>>>>
Q. 90: What type of manual scripts can be created by using VuGen under SOA environment?
For manual scripts, we use VuGen to create following types of scripts.
1) Single Protocol Script: A script that emulates SOAP traffic by sending SOAP requests to the Web service.
2) Multi Protocol Script: A script that emulates several protocols in a single script. For example, if our environment contains a client accessing Web Services and Web pages, choose both the Web Services and Web protocols.
Q. 91: What are the steps for creating a Web Services / SOA Vuser script?
Step -1: Creating a new Web Services script: using the SOA Test Generator, or manually create a new single or multiple protocol script, or a Business Process Testing component.
Step -2: Adding content to the script
Step -3: Setting properties, values, and checkpoints: we can enhance the script by customizing the step properties, inserting argument values, and setting checkpoints.
Step -4: parameterizing the script: Parameterization allows us to replace constant values with a variable to substitute new values for each iteration. To parameterize a value, doubleclick on a step to open its properties and click the ABC icon adjacent to the value box.
Step -5: Configuring the Run -Time settings: The Run -Time settings control the script’s behavior during execution. These settings include Web Service-specific settings and General settings like run logic, pacing, logging, and think time.
Step -6: Verifying that the script is functional: Replay the script in VuGen to verify that it runs correctly.
Step -7: Saving the script: Save the script in the file system or in a Quality Center repository. If we save the scripts in Quality Center, we can associate them to a test set and perform functional and regression testing directly from Quality Center.
<<<<<< =================== >>>>>>
Q. 92: How do we compare the WSDL Files?
When we import a WSDL file, VuGen makes a working copy and saves it along with the script. This saves resources and enables a more scalable and stable environment.
It is possible, however, that by the time we run the script, the original WSDL file will have changed. If we run the script, the test results may be inaccurate and the script may no longer be functional. Therefore, before replaying a Web Services script that was created at an earlier date, we should run a comparison test on the WSDL file.
VuGen provides a comparison tool, which compares the local working copy of the WSDL file with the original file on the file system or Web server. If the differences are significant, we can update the WSDL from the original copy using the Synchronize option in the Service Management dialog box.
VuGen provides a general utility, which allows us to compare any two XML files.
<<<<<< =================== >>>>>>
Q. 93: How VuGen displays the differences between two XML files in a Comparison report?
The Comparison report uses the following legend to mark the differences between the two XML files:
1) Yellow: Indicates changes to an existing element and is shown in both versions.
2) Green: Indicates a new element added and is shown in the original file copy.
3) Pink: Indicates a deleted element.
<<<<<< =================== >>>>>>
Q. 94: What are the ways of testing our system after creating the script?
Our completed script can be used to test our system in following ways:
1) Functional Testing: Run the script to see if our Web services are functional. We can also check to see if the Web service generated the expected values.
2) Load Testing: Integrate the script into a LoadRunner Controller scenario to test its performance under load.
3) Production Testing: Check your Web service’s performance over time through a Business Process Monitor profile.
<<<<<< =================== >>>>>>
Q. 95: What is the Service Test Management utility?
Service Test Management is an add-on utility for HP- Quality Center. This helps us to manage SOA testing by permitting import, storage and defining various services in Quality Center.
The Service Test Management integration allows us to do the following:
1) Store Web Services: Allows us to store and organize Web Services in Quality Center for use within Service Test.
2) Write Service Test scripts: Allows us to create scripts based on the services stored in Quality Center, while maintaining up-to-date WSDLs throughout the life-cycle of the service and the script.
3) Compose a Business Process Test: Allows us to create a BPT (Business Process Test) in Quality Center based on services defined through Service Test Management.
<<<<<< =================== >>>>>>
Q. 96: What are the benefits of Service Test Management utility towards quality improvement in an organization?
With the help of Service Test Management add-on for Quality Center, the organizations can draw following benefits in terms of improved quality processes:
1) Business analysts define application requirements and testing objectives.
2) Test managers and project leads design test plans and develop test cases.
3) Test managers automatically create QA testing requirements and test assets for SOA services and environments.
4) Test automation engineers create automated scripts and store them in the repository.
5) QA testers run manual and automated tests, report execution results, and enter defects.
6) Developers review and fix defects logged into the database.
7) Project managers can export test and resource data in various reports, or in native Microsoft Excel for analysis.
8) Product managers decide whether an application is ready to be released.
9) QA analysts can auto-generate test asset documentation in Microsoft Word format.
<<<<<< =================== >>>>>>
Q. 97: What is the use of Analyze Traffic feature of VuGen?
The Analyze Traffic feature of VuGen examines a capture file containing the server network traffic, and creates a script which emulates requests sent to or from the server. Such a script is created after analyzing the server traffic.
<<<<<< =================== >>>>>>
Q. 98: How many types of network traffic emulations are there?
There are two types of emulations:
1) Incoming traffic emulation: Incoming traffic scripts emulate situations in which we want to send requests to the server, but we do not have access to the client application, may be due to security constraints. The most accurate solution in this case is to generate a script from the traffic going into the server, from the side of the client.
2) Outgoing traffic emulation: Outgoing Traffic scripts emulate the server acting as a client for another server. In an application server that contains several internal servers, we may want to emulate communication between server machines, say between Server A and Server B. The solution in this case is to generate a script from the traffic sent as output from a particular server.
<<<<<< =================== >>>>>>
Q. 99: What is a Capture File?
A capture file is a trace file containing a log of all TCP traffic over the network.
Using a sniffer application, we obtain a dump of all of the network traffic. The sniffer captures all of the events on the network and saves them to a capture file.
We can generate a capture file using the command line utility or any other capture tool.
<<<<<< =================== >>>>>>
Q. 100: What is the use of Web Service Call View?
Web Service Call view is used to display snapshots, set properties, and add checkpoints to Web Service calls. These are applicable for Web Services and SOA Vuser scripts only.
To open the Web Service Call view, we need to open the Tree view from the VuGen window
******************LOAD Runner -Controller *****************************************
Q. 1: What is the purpose of using HP - LoadRunner?
In real world scenario, it is not possible to create situation involving say one thousand users using a system simultaneously so as to test the behavior of the system under such stressful conditions. LoadRunner can create such a situation.
LoadRunner artificially simulates several thousand users - which are called Virtual Users. These artificial / digitally created users are simultaneously forced to operate on the same task, thereby loading the system in a way it is expected to be loaded by real human users in actual practice.
With LoadRunner we can simulate situation with hundreds or thousands of artificial users & we can impose definite, consistent and repeatable loads on the system thereby stressing it from end-to-end. This way we can emulate several business processes & production conditions, which a deployed application is going to encounter.
LoadRunner accurately measures, monitors, and analyzes a system’s performance and functionality.
<<<<<< =================== >>>>>>
Q. 2: What are the essential capabilities we look in a typical application performance-testing Tool?
Essential capabilities of an application performance testing tool are that:
1) It must be able to test a system which combines many software applications and hardware platforms.
2) It must be able to determine the suitability of a server for any given application.
3) It must be able to test the server before the necessary client software has been developed.
4) It must be able to emulate an environment where multiple clients interact with a single server application.
5) It must be able to test an application under the load of tens, hundreds, or even thousands of potential users.
<<<<<< =================== >>>>>>
Q. 3: What are the drawbacks of manual load testing processes?
Load testing of a complete system can be done manually by building an environment where many users work simultaneously on the system. Each user is made to work on his standalone machine and every individual submits input to the system. However due to complexity of such a system, following drawbacks are there
1) Manual testing methods offer only a partial solution to the load testing.
2) Manual testing is expensive & requires large amounts of manpower & equipment.
3) Manual testing is complicated, especially while coordinating and synchronizing multiple testers.
4) Manual testing involves a high degree of organization, especially to record and analyze results meaningfully.
5)The repeatability of the manual tests is limited.
<<<<<< =================== >>>>>>
Q. 4: How LoadRunner takes care of the shortcomings of manual performance testing?
1) LoadRunner reduces manpower requirements by replacing human users with virtual users or Vusers. These Vusers emulate the behavior of real users operating real applications.
2) Since several Vusers can run on a single computer, LoadRunner reduces the amount of hardware required for testing.
3) LoadRunner Controller allows us to easily and effectively control all the Vusers from a single point of control.
4) LoadRunner monitors the application performance online, enabling us to fine-tune the system during test execution.
5) LoadRunner automatically records the performance of the application during a test. We can choose from a wide variety of graphs and reports to view the performance data.
6) LoadRunner checks where performance delays occur: network or client delays, CPU performance, I/O delays, database locking, or other issues at the database server. LoadRunner monitors the network and server resources to help us improve performance.
7) Because LoadRunner tests are fully automated, we can easily repeat them as often as we need.
<<<<<< =================== >>>>>>
Q. 5: What are the process elements of using LoadRunner?
Process elements of LoadRunner are :
1) Scenario: Before using LoadRunner, we divide the application performance testing requirements into various scenarios. A scenario defines the events which occur during each testing session. Thus, 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.
2) Vusers: In the scenario, LoadRunner replaces human users with virtual users or Vusers. When we run a scenario, Vusers emulate the actions of human users working with our application. While a workstation accommodates only a single human user, many Vusers can run concurrently on a single workstation. In fact, a scenario can contain tens, hundreds, or even thousands of Vusers.
3) Vuser Scripts: The actions that a Vuser performs during the scenario are described in a Vuser script. When we run a scenario, each Vuser executes a Vuser script. The Vuser scripts include functions that measure and record the performance of our application’s components.
4) Transactions: To measure the performance of the server, we define transactions. A transaction represents an action or a set of actions that we are interested in measuring. We define transactions within our Vuser script by enclosing the appropriate sections of the script with start and end transaction statements. For example, we can define a transaction that measures the time it takes for the server to process a request to view the balance of an account and for the information to be displayed at the ATM.
5) Rendezvous points: We insert rendezvous points into Vuser scripts to emulate heavy user load on the server. Rendezvous points instruct Vusers to wait during test execution for multiple Vusers to arrive at a certain point, so that they may simultaneously perform a task. For example, to emulate peak load on the bank server, we can insert a rendezvous point instructing 100 Vusers to deposit cash into their accounts at the same time.
6) Controller: We use the LoadRunner Controller to manage and maintain our scenarios. Using the Controller, we control all the Vusers in a scenario from a single workstation.
7) Load Generator: When we execute a scenario, the Controller distributes each Vuser in the scenario to a load generator. The load generator is the machine that executes the Vuser script, enabling the Vuser to emulate the actions of a human user.
8) Performance analysis: Vuser scripts include functions that measure and record system performance during load-testing sessions. During a scenario run, we can monitor the network and server resources. Following a scenario run, we can view performance analysis data in reports and graphs.
<<<<<< =================== >>>>>>
Q. 6: What are our expectations from a scenario load testing an application Server?
The scenario would define the following actions which would be required to be performed on the server during the load test.
1) Emulating the conditions of controlled load on the server.
2) Emulating the conditions of maximum load on the server.
3) Measuring the server performance under load.
4) Check where performance delays occur: network or client delays, CPU performance, I/O delays, database locking, or other issues at the server.
5) Monitoring the network and server resources under load.
<<<<<< =================== >>>>>>
Q. 7: What is the role of Remote Agent Dispatcher in LoadRunner?
The role of Remote Agent Dispatcher is to enable the Controller to start applications on the load generator.
<<<<<< =================== >>>>>>
Q. 8: What is the role of LoadRunner Agent?
1) LoadRunner Agent enables the Controller and the load generator to communicate with each other.
2) When we run a scenario, the Controller instructs the Remote Agent Dispatcher to launch the LoadRunner agent.
3) The agent receives instructions from the Controller to initialize, run, pause, and stop Vusers.
4) The agent relays data on the status of the Vusers back to the Controller.
<<<<<< =================== >>>>>>
Q. 9: What type of actions a Vuser can perform during database server testing?
A Vuser script can perform following actions while testing a database server:
1) Logging in to the Web application.
2) Connecting to the database server.
3) Submitting an SQL query.
4) Retrieving and processing the server response.
5) Disconnecting from the server and the Web.
<<<<<< =================== >>>>>>
Q. 10: What are the broad steps involved in testing process by LoadRunner?
LoadRunner follows a Six–step process for testing the application under the load:
Step - 1: Planning the Test: Involves development of a thorough test plan for the success of the load testing effort.
Step - 2: Creating the Vuser Scripts: Vusers emulate human users interacting with our application. A Vuser script contains the actions which each Vuser performs during scenario execution.
Step - 3: Creating the Scenario: A scenario describes the events that occur during a testing session. A scenario includes a list of machines on which Vusers run, a list of scripts that the Vusers run, and a specified number of Vusers or Vuser groups that run during the scenario. We can create scenarios using the Controller.
Step - 4: Running the Scenario: User load is emulated on the server by instructing multiple Vusers to perform tasks simultaneously. We can set the level of load by increasing and decreasing the number of Vusers that perform tasks at the same time.
Step - 5: Monitoring a Scenario: This can be done by executing scenario monitoring with the help of LoadRunner's set of many resources.
Step - 6: Analyzing Test Results: During scenario execution, LoadRunner records the performance of the application under different loads. We can use LoadRunner’s graphs and reports to analyze the application’s performance.
Q. 11: What are the benefits of a test plan for a successful load testing?
A well-defined test plan is the first essential step to successful testing.
Planning of load testing helps us in:
1) Building test scenarios which accurately emulate our working environment. Load testing means testing our application under typical working conditions, and checking for system performance, reliability, capacity, and so forth.
2) Understanding as to which resources are required for testing. Application testing requires hardware, software, and human resources. Before we begin testing, we need to know which resources are available and decide how to use them effectively.
3) Defining success criteria in measurable terms. Focused testing goals and test criteria ensure successful testing. For example, it’s not enough to define vague objectives like "Check server response time under heavy load." A more focused success criterion would be "Check that 100 customers can check their account balance simultaneously, and that the server response time will not exceed one minute."
<<<<<< =================== >>>>>>
Q. 12: What are the elements of Load Test Planning Process using LoadRunner?
Load test planning is a three-step process:
Step -1: Analyzing the Application: Involves becoming thoroughly familiar with the hardware and software components, the system configuration, and the typical usage model. This step ensures that the testing environment created by us will accurately reflect the environment and configuration of the application under test.
Step -2: Defining Testing Objectives: Before starting the testing process, we need to define exactly what we want to achieve.
Step -3: Planning LoadRunner Implementation: Involves decision making on how to use LoadRunner to achieve our testing goals.
<<<<<< =================== >>>>>>
Q. 13: What factors do we consider while planning the system configuration before its load testing?
We describe the configuration of every system component like client machines, network, middleware, and servers in ample detail giving answers to the following:
1) How many users are anticipated to connect to the system?
2) What is the configuration of application client machine. Configuration includes information on hardware, memory, operating system, software, development tool etc.?
3) What types of database and Web servers are used with the information of hardware, database type, operating system, file server etc.?
4) How does the server communicate with the application client?
5) What is the middleware configuration and application server between the front-end client and back-end server?
6) What other network components are used like modems etc. which may affect response time?
7) What is the throughput of the communications devices & How many concurrent users can each device handle?
<<<<<< =================== >>>>>>
Q. 14: What factors do we consider regarding system usage while planning the load testing?
1) Consideration as to how the system is typically used, and decide which functions are important to test.
2) Consideration as to who uses the system, what are the number of each type of user and what are the common tasks performed by each user.
3) Consideration of any background load which might affect the system response time.
For example, say 500 persons log on to the accounting system every morning, and the same office network has a constant background load of 100 users performing various word processing and printing tasks. We would create a LoadRunner scenario with 600 virtual users signing in to the accounting database, and check the server response time.
<<<<<< =================== >>>>>>
Q. 15: What are the broad objectives before planning load testing?
Before starting testing, we need to define our objectives precisely as to what we want to achieve.
Broad application testing objectives for load testing with LoadRunner can be:
1) Measuring end-user response time: To know how long does it take to complete a business process?
2) Defining optimal hardware configuration: To know which hardware configuration provides the best performance?
3) Checking reliability: To know how hard or long can the system work without errors or failures?
4) Checking hardware or software upgrades: To know how does the upgrade affect performance or reliability?
5) Evaluating new products: To know which server hardware or software should we choose?
6) Measuring system capacity: To know how much load can the system handle without significant performance degradation?
7) Identifying problem areas: To know which element is slowing down the response time?
<<<<<< =================== >>>>>>
Q. 16: Load Testing is applicable during which stages of product life cycle?
Load testing is necessary throughout the product life cycle.
Load Testing activities performed during various stages of product life cycle are:
1) During Planning and Design stage: Evaluation of new products & measurement of response time of every activity.
2) During Product Development stage: Measurement of response time of every activity, checking of optimum hardware configuration, checking of hardware and software upgrades and checking of reliability.
3) During Product Deployment stage: Checking of reliability, measurement of response time of every activity and measurement of system capacity.
4) During Production stage: Measurement of response time of every activity and Identification of various problem areas.
5) During Evolution stage: Checking of hardware and software upgrades and measurement of system capacity.
<<<<<< =================== >>>>>>
Q. 17: At which points we use LoadRunner to measure the response time in our application?
Following type of response times are measured to decide as to where to run the Vusers and which Vusers to run, according to our predefined test objectives:
1) Measurement of end-to-end response time: We can measure the response time which a user experiences by running a GUI Vuser at the front end. GUI Vusers emulate real users by submitting input to and receiving output from the client application.
We can run GUI Vusers at the front end to measure the response time across the entire network, including a terminal emulator or GUI front end, network, and server.
2) Measurement of network and server response times: We can measure network and server response time, excluding response time of the GUI front end, by running Vusers on the client machine. Vusers emulate client calls to the server without the user interface. When we run many Vusers from the client machine, we can measure how the load affects network and server response time.
3) Measurement of GUI response time: We can find out as to how the client application interface affects response time by calculating the difference among the previous two measurements i.e.
GUI response time = (End-to-end response time) - (Network and server response time)
4) Measurement of server response time: We can measure the time it takes for the server to respond to a request without going across the network. When we run Vusers on a machine directly connected to the server, we can measure the server performance.
5) Measurement of middleware-to-server response time: We can measure response time from the server to middleware if we have access to the middleware and its API. We can create Vusers with the middleware API and measure the middleware-server performance.
<<<<<< =================== >>>>>>
Q. 18: What are the broad basis for creating Vuser scripts?
Since Vusers emulate the actions of a typical enduser, the Vuser scripts are created with a consideration of end-user tasks.
Vuser scripts are created based on the following:
1) Analysis of Vuser types: For finding out the number and type of Vusers expected to be created.
2) Activities expected to be performed by the Vusers: For example, for load testing a banking application, we would create a Vuser script which performs typical banking related activities.
3) Test objectives: Form the basis of taking decision on tasks to be measured and defining their transactions.
<<<<<< =================== >>>>>>
Q. 19: What factors do we consider while selecting hardware for using LoadRunner?
For running the desired number of Vusers the hardware and Operating system must be adequately powerful and fast.
Following factors are given due consideration while deciding the number of machines and their configuration:
1) Make a provision of running LoadRunner Controller on a separate machine.
2) Make a provision of a separate Windows-based machine for every GUI Vuser. However one UNIX machine can take care of running of several GUI Vusers.
3) Keep the configuration of GUI Vusers testing machine same like the actual user’s machine.
<<<<<< =================== >>>>>>
Q. 20: How LoadRunner can be helpful in checking the reliability of a hardware system?
LoadRunner can provide good pointers to decision making in following areas pertaining to hardware:
1) Finding out the level of system stability under heavy or continuous work loads, by creating stress on the system.
2) Testing the system by forcing it to handle the extended activity in a compressed time period to simulate the kind of activity a system would normally experience over a period of weeks or months.
Q. 21: How do we measure the system capacity?
We measure system capacity to find out how much excess capacity the system can handle without any degradation in its performance .
For checking the capacity of a system, we compare the performance versus load on the existing system, and find out a point at which significant degradation of response-time starts taking place. Point is known as "knee" when plotted over a response time curve.
<<<<<< =================== >>>>>>
Q. 22: What is the purpose of creating Scenarios in LoadRunner?
For testing a system by using LoadRunner, we need to create a scenario. Scenario is a file containing complete information about the testing session. The scenario is a means of emulating a real-life user.
The scenario contains following information about the mechanism of emulating the real users:
1) Details of groups of virtual users or Vusers.
2) Details of test scripts the Vusers will run.
3) Details of load generators upon which the scripts shall be made to run.
<<<<<< =================== >>>>>>
Q. 23: How many types of scenarios can be created while using Controller of LoadRunner?
We can create any one type of scenario out of the following:
1) Manual Scenario: Scenario is created manually by defining the number of Vuser groups we want to run, and building a schedule for LoadRunner to run these groups. Manual scenario can be created by defining the total number of Vusers to be used in the scenario, or assigning a percentage of the total number of Vusers to each script.
2) Goal-Oriented Scenario: We define the goals that we want to achieve in our test and LoadRunner automatically builds a scenario for us, based upon our goals.
<<<<<< =================== >>>>>>
Q. 24: How can we change the maximum number of scripts displayed in the Available Scripts list?
We can change the maximum number of scripts displayed in the Available Scripts list by modifying the registry key:
HKEY_CURRENT_USER\Software\Mercury Interactive\RecentScripts\max_num_of_scripts
<<<<<< =================== >>>>>>
Q. 25: What is the purpose of Scenario Files?
A scenario provides detailed description of various events taking place during every load testing session.
A scenario is created by using the Design view of Controller in LoadRunner. Once a scenario is created, LoadRunner saves the information in a
scenario file having an extension (*.lrs).
<<<<<< =================== >>>>>>
Q. 26: What methods are available in LoadRunner for building scenarios?
Two methods are available through which we can create scenarios.
1) Manual Scenario creation method: Involves creating groups and specifying the script, the load generator, and the number of Vusers included in each group. We can chose to opt for using Percentage Mode to distribute our Vusers among various scripts.
2) Goal Oriented Scenario creation method: Involves defining the goals we want our test to achieve, and LoadRunner automatically builds a scenario for us, based on these goals.
<<<<<< =================== >>>>>>
Q. 27: How can we change the maximum number of scripts displayed in the Available Scripts list?
We can change the maximum number of scripts displayed in the Available Scripts list by modifying the registry key:
HKEY_CURRENT_USER\Software\Mercury Interactive\RecentScripts\max_num_of_scripts
<<<<<< =================== >>>>>>
Q. 28: What is the purpose of having Vuser groups in scenarios?
A scenario consists of groups of Vusers which simulate the actions of human users on the application under test. When a particular scenario is run, the Vusers generate load on the server, and LoadRunner monitors the server and transaction performance..
Vuser groups are created to organize several Vusers in a scenario into manageable groups. Vuser groups are created by including Vusers having similar characteristics. For example, when many Vusers run the same Vuser script, we can club them into one Vuser group.
<<<<<< =================== >>>>>>
Q. 29: What type of actions can be performed on a Vuser group or scenario?
Following actions can be performed on a Vuser group:
1) Defining the group name, Vuser quantity, load generators, and scripts for the Vuser group.
2) Adding load generators to the Vuser group and configuring the load generators.
3) Adding and configuring scripts to the Vuser group.
4) Enabling or disabling a Vuser group for the scenario.
5) Removing a Vuser group from the scenario.
6) Scheduling the Vuser group execution.
7) Defining service level agreements for the scenario.
8) Running, stopping & resetting the scenario.
9) Configuring the settings of scenario results.
<<<<<< =================== >>>>>>
Q. 30: What is the meaning of pending status for a Vuser?
Pending status for a V user indicates that the Vuser is ready to be initialized and is waiting for an available load generator, or is transferring files to the load generator. The Vuser will run when the conditions set in its scheduling attributes are met.
Q. 31: What is the meaning of rendezvous status for a Vuser?
Rendezvous status for a Vuser indicates that the Vuser has arrived at the rendezvous and is waiting to be released by LoadRunner.
<<<<<< =================== >>>>>>
Q. 32: What is the purpose of Gradual Stop option for the Vusers?
Gradual Stop option Instructs the Controller to complete the current iteration or action before stopping the Vuser. This option is only available when the Vuser is in the RUN state.
<<<<<< =================== >>>>>>
Q. 33: How do we modify the run-time settings of multiple scripts?
We need to chose the method of modifying the run-time settings:
1) Modification method for Shared run-time settings: This method opens one window containing all of the run-time settings in blank mode. In this mode, we set only the options that we want to modify for all selected scripts. All other run-time settings remain unchanged.
Some of the run-time settings cannot be modified in shared mode. These settings do not appear. To modify them, we need to open the run-time settings for each individual script.
2) Modification method for Individual run-time settings: This method opens a separate window for each selected script. In this mode, we modify each script’s settings individually.
<<<<<< =================== >>>>>>
Q. 34: What configuration settings we can define for Load Generators in a scenario?
With the help of Load Generators dialog box, we can set following type of load generator’s attributes:
1) Defining which load generators will run Vusers in the scenario. For example, if a load generator is unavailable for a particular scenario run, we can exclude it temporarily instead of removing it entirely from your list of load generators.
2) Selecting which load generators will take part in the scenario by using the Enable and Disable commands. Disabling a load generator temporarily removes it from the list. Enabling a load generator reinstates it.
<<<<<< =================== >>>>>>
Q. 35: What is the role of controller in LoadRunner?
The Controller monitors a Windows load generator’s CPU usage and automatically stops loading Vusers on a load generator when it becomes overloaded.
We can monitor the status of a machine’s CPU usage. When the CPU usage of a load generator becomes problematic, the icon to the left of the load generator name contains a yellow bar. When the machine becomes overloaded, the icon contains a red bar.
<<<<<< =================== >>>>>>
Q. 36: What are the Terminal Services in LoadRunner?
Terminal services allows centralized management of computing resources for each client connected to the server, and provides each user with their own working environment.
We use LoadRunner’s Terminal Services Manager to remotely manage multiple load generators running in our load testing scenario on a terminal server. With the help of Terminal Services Manager, we can select the number of terminals to be used in our scenario & the maximum number of Vusers which can be run per terminal. The Terminal Services Manager then evenly distributes the number of virtual users among the client sessions.
With the help of Terminal Server Client, we can operate in a server-based computing environment from a remote machine. The terminal server transmits applications over the network and displays them via terminal emulation software. Every user logs on and sees only his individual session, which is managed transparently by the server operating system, independent of any other client session.
<<<<<< =================== >>>>>>
Q. 37: What is the use of Creating a Manual Scenario Using the Percentage Mode?
A manual scenario is created in the Percentage mode by defining the total number of Vusers to be used in the scenario, and assigning load generators and a percentage of the total number of Vusers to each script.
While creating a new scenario, we can access the Percentage Mode directly by selecting the "Use the Percentage Mode to distribute the Vusers among the scripts" in the New Scenario dialog box.
A scenario created in the Vuser Group Mode can be easily converted to the Percentage Mode.
<<<<<< =================== >>>>>>
Q. 38: What are the key considerations while converting a scenario from Vuser Group Mode to Percentage Mode?
1) In case we have defined multiple scripts for a Vuser group, the number of Vuser scripts created in the Percentage Mode will be same as the number of scripts defined for the group.
2) All Load Generators will be assigned to all Vuser scripts created in the Percentage Mode. In case we have defined multiple load generators for a Vuser group, the Vusers we assign to the scripts in the Percentage Mode will be distributed evenly among the load generators previously assigned by us to the group.
3) All Vuser group schedule settings will be lost. All profiles will contain scenario schedule settings only.
<<<<<< =================== >>>>>>
Q. 39: What are the key considerations while converting a scenario from Percentage Mode to Vuser Group Mode?
1) Each script will be converted to a Vuser group.
2) In case we have defined multiple load generators for a Vuser script, the Vuser group which is created when converting the scenario will also contain multiple load generators.
3) All schedule settings will be retained as it is.
<<<<<< =================== >>>>>>
Q. 40: What is the purpose of Scheduling Scenarios?
After creating a scenario, we schedule it to start running at a specified time. We can make a schedule defining the time at which to initialize, start, and stop Vusers during the scenario run, and how long an action should continue running.
We can restrict the execution duration of the scenario or of a Vuser group within the scenario. We can also stipulate how many Vusers to start and stop running within a certain time frame. We can specify whether LoadRunner should start or stop running all Vusers in a scenario simultaneously, or only a certain number of Vusers within a specified amount of time.
Q. 41: What is the effect of Rendezvous points on the running of scenarios as per schedule?
Rendezvous points, if present in a script, interfere with the scheduled scenario run. The scenario will not run as scheduled due to the presence of rendezvous points in the script.
<<<<<< =================== >>>>>>
Q. 42: What are the methods by which we can schedule the enabled Vuser groups in a scenario?
After creating a scenario, we can schedule the enabled Vuser groups to run according to either of the following:
1) As a part of a whole scenario: When we run a scenario, LoadRunner runs all the Vuser groups enabled in the scenario. The schedule defined for running the scenario is applied to all the Vuser groups concurrently, and LoadRunner applies each action proportionately to all the Vusers groups.
2) As per its own schedule: For each enabled Vuser group in a scenario, we can design a separate execution schedule. We can specify when to start running the Vuser group, how many Vusers to start and stop running within given time intervals, and how long the Vuser group should continue running.
<<<<<< =================== >>>>>>
Q. 43: How many modes are available to us for scheduling the running of scenario?
We can schedule a scenario to run in one of the following modes:
1) Real-life schedule: The scenario runs according to a user-defined group of actions that simulate a real-life schedule of events. Vuser groups run according to the iterations defined in their run-time settings, but we can define how many Vusers to run at a time, how long Vusers should continue to run, and how many Vusers to stop running at a time.
2) Classic Schedule: All enabled Vuser groups run together on one schedule, each according to its own run-time settings. We can schedule how many Vusers to start running at a time, how long to run the Vusers, and how many Vusers to stop running at a time.
3) Run until complete: All the Vuser groups in the scenario run according to the iterations defined in their run-time settings. Each Vuser group in the scenario runs its defined course, and when all the Vuser groups have finished running, the scenario run is complete.
<<<<<< =================== >>>>>>
Q. 44: What is the purpose of specifying Service Level Agreements in scenarios?
While creating a load testing scenario, we can specify our goals or service level agreements - SLA's for the performance measurement.
When this scenario is made to run the LoadRunner captures all the performance related data. During analysis phase, Analysis compares this data against the SLAs and determines SLA status for the defined measurements.
<<<<<< =================== >>>>>>
Q. 45: What methods LoadRunner uses to find out the SLA status?
Depending on the measurements being evaluated by us, LoadRunner finds out the SLA status in one of the following ways:
1) As per time interval within the run: Analysis displays SLA statuses at set time intervals in the timeline. For example, every 10 seconds - Analysis checks to see if the measurement’s performance has deviated from the threshold defined in the SLA.
2) As per the whole run: Analysis displays a single SLA status for the whole scenario run. The measurements include - Total Hits, Average Hits, Total Throughput, and Average Throughput.
<<<<<< =================== >>>>>>
Q. 46: How many types of Goal Oriented Scenarios can be created in LoadRunner?
In a goal-oriented scenario, we define the goals required to be achieved through our tests, and LoadRunner automatically builds a scenario for us based on these goals.
When we want to test how many Vusers the application can run simultaneously, it is better to define a type of goal for the Virtual Users.
Following five types of goals can be defined in a goal-oriented scenario:
1) Defined number of virtual users
2) Defined number of hits per second by the Web Vusers.
3) Defined number of transactions per second.
4) Defined number of pages per minute by the Web Vusers.
5) Defined transaction response time we want our scenario to reach.
<<<<<< =================== >>>>>>
Q. 47: Under what circumstances a Pages per Minute or Hits per Second goal-oriented scenario fails?
Pages per Minute or Hits per Second goal-oriented scenario is assigned a "Failed" status in situations like:
1) When the Controller has twice attempted to reach the goal using the maximum number of Vusers specified, and the goal could not be reached.
2) When no pages per minute or hits or transactions per second were registered after the first batch of Vusers was run.
3) When the number of pages per minute or hits or transactions per second did not increase after the Controller ran a certain number of Vuser batches.
4) When all the Vusers that were run failed.
5) When there were no available load generators for the type of Vusers we attempted to run.
<<<<<< =================== >>>>>>
Q. 48: What is Load Balancing process in LoadRunner?
Load balancing is the process, which evenly distributes the load generated by Vusers among the requested load generators, thereby ensuring an accurate load test.
When a Windows load generator’s CPU usage becomes overloaded, the Controller stops loading Vusers on the overloaded load generator, and automatically distributes them among load generators taking part in the scenario.
Load balancing option is available only in goal-oriented scenarios and manually controlled scenarios in the Percentage Mode.
<<<<<< =================== >>>>>>
Q. 49: What policy attributes can be defined for rendezvous points?
Setting the rendezvous policy determines how the Vusers handle a rendezvous point. We can set the following policy attributes for every rendezvous point:
1) Release policy: Defines how many Vusers will be released from a rendezvous point at a time.
2) Timeout policy: Defines how long the Controller shall wait before releasing Vusers from a rendezvous point.
<<<<<< =================== >>>>>>
Q. 50: Can we disable a particular Vusers at Rendezvous Points?
We can disable a rendezvous point for all Vusers in a scenario.
In addition to this we can disable a rendezvous point for a particular Vusers.
By disabling Vusers at a rendezvous point, we temporarily exclude them from participating in the rendezvous. Enabling disabled Vusers returns them back to the rendezvous.
Q. 51: What type of status related Rendezvous Information is available to us during creation of a scenario?
Following Rendezvous Information is available to us for viewing & necessary modifications:
1) Current Status: The number of Vusers that arrived at the rendezvous point out of the total number of Vusers assigned to the rendezvous.
2) Time: The time at which the Vusers at the rendezvous point were released.
3) Reason: The reason the Vusers at the rendezvous point were released. The possible reasons are Timeout or Arrived.
<<<<<< =================== >>>>>>
Q. 52: Out of Individual Load Generator settings & Global Settings, which ones come into effect?
When the global scenario settings differ from those of an individual load generator, the load generator settings override them.
<<<<<< =================== >>>>>>
Q. 53: What is the use of LoadRunner Expert mode?
We can configure additional settings for the LoadRunner agent and other LoadRunner components with the help of LoadRunner Expert mode.
<<<<<< =================== >>>>>>
Q. 54: How LoadRunner takes care of timeout value requirements in case of large number of Vusers?
LoadRunner automatically understands the fact that the number of active Vusers has a significant effect on the timeout values.
For example, 1000 Vusers trying to initialize will take much longer than 10 Vusers. Taking care of this, LoadRunner automatically adds an internal value, based on the number of active Vusers, to the timeout value specified by us.
<<<<<< =================== >>>>>>
Q. 55: While running a scenario, the run-time files are stored at which location by default?
While we run a scenario, by default the run-time files get stored locally on each load generator machine running the Vuser script.
The default location of the files is under the temporary directory specified by the load generator’s environment variables like Windows - TEMP or TMP Directory.
If no environment variable is defined, the files get saved to the /tmp directory.
<<<<<< =================== >>>>>>
Q. 56: What are the various types of Primary Run-time files?
Primary run-time files are of following types:
1) Vuser Script files: When we run a Vuser, the Controller sends a copy of the associated Vuser script to the Vuser load generator. These script files are stored in the load generator’s temporary run-time directory.
2) Result files: While we run a scenario, the participating Vusers write their results to the temporary run-time file directory. After scenario execution, these result files are consolidated and the results from all the load generators are transferred to the results directory.
<<<<<< =================== >>>>>>
Q. 57: How transfer of script files takes place at run time in case Vusers access the scripts at some shared location?
If we specify that all Vusers access their Vuser scripts directly at some shared location, no transfer of script files take place at run time.
<<<<<< =================== >>>>>>
Q. 58: What is Path translation in LoadRunner
Path translation is a mechanism used by LoadRunner to convert remote path names. We need to do path translation, when we specify a shared network drive for run-time file storage.
<<<<<< =================== >>>>>>
Q. 59: What preparatory steps are recommended for running a scenario?
Before running a scenario following are suggested steps:
1) Specify the location of the results.
2) Assign a name to the results.
3) Scheduling of the scenario.
4) Providing scenario summary information.
5) Specification of applications to be invoked at the start of the scenario.
<<<<<< =================== >>>>>>
Q. 60: What is the extension of scenario result file?
The general information about the scenario are stored in a result file with an extension (.eve and .lrr)
Q. 61: How Analysis module of LoadRunner interacts with the results files?
When analysis graphs and reports are generated, the Analysis module of LoadRunner copies all the scenario result files to a database.
Then the Analysis module directly interacts with the database and does not require the individual result files.
<<<<<< =================== >>>>>>
Q. 62: What are the benefits of saving scenarios in a Quality Center Project?
When Controller module of LoadRunner is connected to a Quality Center project, we can create a new scenario in the Controller and save it directly to the Quality Center project.
This helps us in keeping a track of all scenarios created for each subject and allows monitoring the progress of test planning and creation.
<<<<<< =================== >>>>>>
Q. 63: How can we test the functionality of an application under heavy load using LoadRunner?
LoadRunner integrates functional testing scripts created by Functional testing Tools like QTP or WinRunner. These scripts in the form of GUI Vuser scripts integrate into the scenarios of LoadRunner.
<<<<<< =================== >>>>>>
Q. 64: What are the benefits of running functional test scripts in LoadRunner?
1) To see how the functionality of the application gets affected under the heavy load.
2) To measure the end-to-end response time experienced by a typical user on the client side while the application is under load.
3) By including QTP test scripts at specific points in a LoadRunner scenario we can confirm that the functionality of our application does not get affected by the extra load at these sensitive points.
4) When a GUI Vuser script runs on our screen during the LoadRunner scenario, we can watch the actual steps executed by the Vuser in a real time.
<<<<<< =================== >>>>>>
Q. 65: What is a GUI Vuser?
A GUI Vuser emulates the complete environment of a human user. GUI Vusers enable us to measure and monitor end-to-end user response times while our client/server system is under load.
A GUI Vuser can be programmed to read and act on information that appears on its machine’s display. All actions of every GUI Vuser are described in a GUI Vuser script generally created in QTP or WinRunner.
GUI Vusers are monitored and managed through the Controller module of LoadRunner.
<<<<<< =================== >>>>>>
Q. 66: Can we use VuGen module of LoadRunner to run a GUI Vuser script?
We cannot use VuGen to run a GUI Vuser script.
We use the Controller module of LoadRunner to run a GUI Vuser script as part of a scenario. Whereas we use QTP or WinRunner to run a GUI Vuser script in the standalone mode.
<<<<<< =================== >>>>>>
Q. 67: What is End-to-end response time in relation to GUI Vuser Technology?
End-to-end response time means the total time that a user waits for a response after submitting a request. GUI Vusers measure real end-to-end response times. End-to-end response times include GUI response times plus network and server response times.
<<<<<< =================== >>>>>>
Q. 68: What are the special design constraints with QTP Tests while adopting in LoadRunner?
1) Only simple QTP tests should be adopted for use in LoadRunner & should be designed to pinpoint specific operations.
2) LoadRunner cannot run nested action iterations.
3) Do not include references to external actions or other external resources, like an external Data Table file, environment variable file, shared object repositories etc.
4) Include transactions in QTP test since LoadRunner only provides performance information for data that is included within a transaction.
<<<<<< =================== >>>>>>
Q. 69: How do we define transactions within our Vuser script?
Transactions are defined as an action or a set of desired actions to measure the performance of a server.
We define transactions within our Vuser script by enclosing the appropriate sections of the script with start and end transaction statements. For example, we can define a transaction, which measures the time it takes for the server to process a request to view the balance of an account and for the information to be displayed at the ATM.
<<<<<< =================== >>>>>>
Q. 70: For use in LoadRunner, which statements are manually added to basic Vuser script recorded in WinRunner?
Since LoadRunner provides performance-related information only for the data included within a transaction. Hence WinRunner test scripts are manually edited to include transactions needed to be used by LoadRunner. Thus following statements are manually inserted into WinRunner test scripts :
1) Transaction statements to measure the performance of the server.
2) Rendezvous statements to emulate a specific user load.
Q. 71: What are the special considerations while running the LoadRunner scenario integrated with GUI Vuser script created in QTP or WinRunner?
1) Run just the one GUI Vuser concurrently per machine.
2) Ensure that QTP and WinRunner are closed before running the scenario.
3) In the Run-time Settings for script dialog box, only the General categories and sub-categories like General, Iterations, Miscellaneous, Think Time etc. are relevant for QTP and WinRunner tests.
4) The Replay options are not relevant for QTP and WinRunner tests.
<<<<<< =================== >>>>>>
Q. 72: What actions are performed by the LoadRunner during scenario execution?
While executing a scenario, the LoadRunner does the following:
1) Recording of the duration of the transactions you defined in the Vuser scripts
2) Performing the rendezvous included in the Vuser scripts
3) Collecting error, warning, and notification messages generated by the Vusers
During running of scenarios Controller module of LoadRunner performs following actions:
a) Checking the scenario configuration information.
b) Invokes the applications selected by us for running with the scenario.
c) Distributing each Vuser script to its specified load generator. When the Vuser groups become re ready, they start executing their respective scripts.
<<<<<< =================== >>>>>>
Q. 73: Can we activate an additional Vuser while a scenario is running?
With the help of Run / Stop Vusers dialog box, we can activate an additional Vuser while a scenario is running.
The scenario will finally end when all the Vusers have completed their scripts, or when the specified duration finishes out, or when we terminate it.
<<<<<< =================== >>>>>>
Q. 74: What are the brief steps of running a scenario?
Scenario execution by & large follows following basic steps:
Step -1:Opening of an existing scenario or creating a fresh one.
Step -2:Configuring and scheduling the scenario.
Step -3:Setting the results directory.
Step -4:Running and monitoring the scenario.
<<<<<< =================== >>>>>>
Q. 75: How running of individual Vusers differ from running an entire scenario?
We can run all the Vusers and Vuser groups all together in a scenario, alternatively we can chose the specific Vuser groups and Vusers and can run them individually.
The difference in operation lies as under:
1) When We run an entire scenario, LoadRunner does not begin running Vusers until they all reach the Ready state.
2) When we run individual groups or Vusers, LoadRunner runs each Vuser immediately after it reaches the Ready state.
<<<<<< =================== >>>>>>
Q. 76: What do we mean by initialization of Vusers in a group?
By initializing the Vusers, we distribute the Vusers in the group to their specified load generators so that they get ready to execute their script.
The status of the Vuser group changes from Down to Pending to Initializing to Ready. In case a particular Vuser group does not get initialized due to any reason, the status of this Vuser group changes to Error.
By initializing all the Vusers in a group before running them, we can ensure that they all begin executing the scenario at the same time.
<<<<<< =================== >>>>>>
Q. 77: How the addition of new Vusers differ among various modes of running a scenario?
We run a scenario or Vuser in two modes like: 1) Vuser Group Mode 2) Percentage Mode.
1) Vuser Group Mode: Here we control the number of new Vusers that can be added to each Vuser Group, and the load generators on which these additional Vusers will run.
2) Percentage Mode: Here we control the number of new Vusers that can be distributed among the Vuser scripts according to the percentage you define, and the load generators on which these additional Vusers will run.
<<<<<< =================== >>>>>>
Q. 78: What type of Vuser activity can be seen while a scenario is running?
LoadRunner allows us to see the following Vuser activity during a scenario run:
1) On the Controller load generators, we can view the Output window, monitor Vuser performance online, and check the status of Vusers executing the scenario.
2) On remote machines, we can view the Agent summary with information about the active Vusers.
<<<<<< =================== >>>>>>
Q. 79: How connections are established among Controller & Load Generators under fire walled environment?
In a conventional non-firewalled load test scenario, the Controller can directly connect to the LoadRunner agents running on remote machines.
While running Vusers over a firewall, the direct connection between the controller and the Load Generator gets blocked by the firewall. The reason being that the Controller does not have permissions to open the firewall.
LoadRunner addresses this problem by using a communication configuration based on HTTPS or secured TCP/IP.
In such a fire walled environment, a LoadRunner agent is installed on load generators running Vusers, and on Monitor machines which monitor the servers. This agent communicates through port 443 in the firewall.
<<<<<< =================== >>>>>>
Q. 80: What is a MI Listener machine?
The MI Listener machine works as a router between the following:
1) The agent on the load generator machine and the Controller, enabling the Controller to run Vusers over a firewall.
2) The agent on the Monitor over Firewall machine and the Controller, enabling the Controller to monitor the servers that are located over a firewall.
MI Listener components are installed on a dedicated machine.
Q. 81: How the communication takes place across MI Listener machine in a fire-walled environment?
The MI Listener serves the purpose of a router between the Controller and the LoadRunner agent.
When the LoadRunner agent connects to the MI Listener machine, the MI Listener keeps a listing of the connection to the agent using a symbolic name that the agent passed to it.
When the Controller connects to the MI Listener machine, it communicates to the MI Listener through port 50500.
<<<<<< =================== >>>>>>
Q. 82: How many types of online monitors are available for controller machines?
1) Run-Time Monitors: For displaying the number and status of Vusers participating in the scenario, as well as the number and types of errors that the Vusers generate.
2) Transaction Monitors: For displaying the transaction rate and response time during scenario execution.
3) Web Resource Monitors: For providing information about the number of Web connections, throughput volume, HTTP responses, server retries, and pages downloaded to the Web servers during the scenario.
4) System Resource Monitors: For measuring the Windows, UNIX, Tuxedo, SNMP, Antara FlameThrower, and SiteScope resources used during a scenario.
5) Network Delay Monitor: For displaying the information about the network delays on our system.
6) Firewall Monitor: For measuring the statistics of the firewall servers during the scenario.
7) Web Server Resource Monitors: For measuring the statistics of the Apache, Microsoft IIS, iPlanet Web servers during the scenario.
8) Web Application Server Resource Monitors: For measuring the statistics of the Ariba, ATG Dynamo, BroadVision, ColdFusion, Fujitsu INTERSTAGE, iPlanet, Microsoft ASP, Oracle9iAS HTTP, SilverStream, WebLogic and WebSphere application servers during the scenario.
9) Database Server Resource Monitors: For measuring the statistics of the SQL server, Oracle, Sybase, and DB2 databases during the scenario.
10) Streaming Media Monitors: For measuring the statistics of the Windows Media Server and RealPlayer audio/video servers, as well as the RealPlayer and Media Player client during the scenario.
11) ERP/CRM Server Resource Monitors: For measuring the statistics of the SAP Portals, Siebel Servers, and PeopleSoft servers during the scenario.
12) Java Performance Monitor: For measuring the statistics of Java Platforms and Java-based applications using J2EE machines.
13) J2EE & .NET Diagnostics Monitors: For providing information to trace, time, and troubleshoot individual transactions through J2EE & .NET Web, application, and database servers.
14) Application Component Monitor: For measuring the statistics of the Microsoft COM+ server during a scenario run.
15) Application Deployment Solutions Monitor: For measuring the statistics of the Citrix MetaFrame servers during a scenario run.
16) Middleware Performance Monitors: For measuring the statistics of the Tuxedo and IBM Web servers during a scenario run.
17) Infrastructure Resources Monitor: For measuring the statistics of the network client data points during a scenario run.
<<<<<< =================== >>>>>>
Q. 83: What is Merging Graphs in LoadRunner?
LoadRunner allows us to merge the results of two graphs from the same scenario into a single graph.
The merging helps us to compare several different measurements at once. For example, we can make a merged graph to display the Web Throughput and Hits per Second, as a function of the elapsed time.
To merge two graphs, the x-axis of both the graphs must be the same measurement.
<<<<<< =================== >>>>>>
Q. 84: What situations are best suited for performing path translation?
1) When saving run-time result files to a shared drive which has been mapped differently by the Controller and remote load generator.
2) When the remote machine maps the path as another drive letter or path, path translation is necessary to enable the load generator to recognize the script location.
2) Across platforms - to translate Windows-based paths as seen by the Controller into paths recognized by the UNIX Vuser load generator.
<<<<<< =================== >>>>>>
Q. 85: What is the use of Expert mode of Controller module of LoadRunner?
It is basically meant for the support personnel & helps us in getting access to the system information.
When we work in the Expert mode, the Controller dialog boxes contains additional options for fine tuning the Controller operation.
<<<<<< =================== >>>>>>
Q. 86: How to check whether a particular problem lies with a scenario or lies with the Vuser script?
1) Verify that the script runs properly on all remote load generators in stand-alone mode.
2) Test the GUI Vuser scripts on Windows platforms using WinRunner.
3) Test the Vuser scripts on UNIX platforms by running them from the command line.
4) Test all other types of Vuser scripts on Windows platforms by running them from VuGen, or by running a single user from the Controller.
<<<<<< =================== >>>>>>
Q. 87: What to do when a test passes when run in VuGen, but fails when run in Controller?
When a test runs in VuGen, the full browser is used. However when this test is run in Controller, it use the browser basics only.
Hence before running a scenario in the Controller with multiple Vusers, it is a best practice to run a single Vuser in stand-alone mode to ensure that the test is free from bugs.
<<<<<< =================== >>>>>>
Q. 88: What to do when Controller machine fails to connect to the remote load generator machine?
Check the following items:1) Check TCP/IP connectivity: Ensure full TCP/IP connectivity among the Controller and Vuser machines. Use the ping utility from the DOS command line to verify communication with a remote machine.
2) Check Load generator connections: Ensure full connectivity of the load generator with every remote load generators from the Controller’s Load Generators dialog box.
3) Check UNIX shell: For UNIX Vusers, make sure that the Windows Controller can execute a remote shell command.
<<<<<< =================== >>>>>>
Q. 89: What is the use of LoadRunner Agent?
LoadRunner Agent runs on the load generators and enables communication between the Controller, load generators, and MI Listeners under fire-walled environment.
The LoadRunner agent receives instructions from the Controller to initialize, run, pause, and stop Vusers. At the same time, the agent also relays data on the status of the Vusers back to the Controller.
<<<<<< =================== >>>>>>
Q. 90: How can we increase the load during the Load test?
We can increase the load on the application during a running load test by manually adding more Vusers.
Q. 91: What to do in case of a warning message that Controller cannot activate additional Vusers?
This is a hardware related problem. It happens when we use our local machine having limited memory resources, as a load generator.
Hence it is better to use a dedicated machine as a load generator to avoid such problems.
<<<<<< =================== >>>>>>
Q. 92: How to know as to whether my application performed well under the load?
Look at the transaction response time and find out whether the transaction was within an acceptable limit for the customer.
If the transaction response time degrades, we need to look for problems.
<<<<<< =================== >>>>>>
Q. 93: When do we use of goal-oriented scenario in LoadRunner?
Prior to deploying an application, we want to run an acceptance test to make sure that the system will withstand the real-life expected workload.
We have an idea about a rate at which we expect the server should perform say in terms of number of hits or transactions per second.
Using a goal-oriented scenario we define a goal for the number of hits per second, transactions per second, or the transaction response time which we want to generate.
<<<<<< =================== >>>>>>
Q. 94: How many types of goals are provided by LoadRunner in a goal oriented scenario?
LoadRunner provides following five types of goals in a goal oriented scenario:
1) Number of concurrent Vusers.
2) Number of hits per second.
3) Number of transactions per second.
4) Number of pages per minute.
5) Transaction response time which we want the scenario to reach.
<<<<<< =================== >>>>>>
Q. 95: What is the objective of an analysis session after the load test?
The aim of an analysis session is to find out the failures in performance of our system and then to point out the root cause of such failures.
Following questions are asked during the analysis session.
1) Were the test expectations met?
2) What was the transaction response time on the user’s end under load?
3) Did the SLA meet or deviate from its goals?
4) What was the average transaction response time of the transactions?
5) What parts of the system could have contributed to the decline in performance?
6) What was the response time of the network and servers?
7) Can we find a possible cause by correlating the transaction times and backend monitor matrix?
<<<<<< =================== >>>>>>
Q. 96: What to do when a script fails during simple playback, while during recording same actions were successful?
Many applications use dynamic values which change every time we use the application. For example, some servers assign a unique session ID for every new session. When we try to replay a recorded session, the application creates a new session ID which happen to differ from the recorded session ID.
LoadRunner addresses this issue through correlation. Correlation saves the changing values, in this case the session ID, to a parameter. When running the emulation, the Vuser does not use the recorded value and instead of it, it uses the new session ID, assigned to it by the server.
<<<<<< =================== >>>>>>
Q. 97: How to confirm as to whether the desired content is the same as the returned web page?
This can be done through the content check which verifies that the expected information appears on a Web page while the script is running.
We can insert following two types of content checks:
1) Text check: For checking that a text string appears on a Web page.
2) Image check: For checking an image on a Web page.
<<<<<< =================== >>>>>>
Q. 98: What is the use of a Throughput graph?
The Throughput graph shows the amount of data in terms of bytes which the Vusers receive from the server at any given second.
We then compare this graph with the Transaction Response Time graph to see how throughput affects transaction performance.
<<<<<< =================== >>>>>>
Q. 99: How to know that the test has finished running?
When the test finishes its run, the Scenario Status pane shows the Down status. This indicates that the Vusers have stopped running.
We can look in the Vuser dialog box to see the status of each individual Vuser.
<<<<<< =================== >>>>>>
Q. 100: How can we instruct LoadRunner to randomly run only one Vuser in a group?
This can be done by right-clicking the Vuser group and selecting "Run One Vuser Until Complete".
A Vuser script log will open, displaying the run-time information about the Vuser.
*****************************Load Runner Basic**********************
Q. 1: What is the process of manual correlation in LoadRunner?
It is the method adopted for capturing the dynamic data resulting from the server responses & further reusing it in the script. It can be done in two ways like:
1.Manual correlation
2. Auto Correlation
<<<<<< =================== >>>>>>
Q. 2: What is the Load testing process in LoadRunner?
Step 1: Planning the test: Involves development of a clearly defined test plan to ensure that the newly developed test scenarios are able to accomplish the load-testing objectives.
Step 2: Creation of Vusers: Involves creation of Vuser scripts which contain various tasks performed by every Vuser, tasks performed by Vusers as a whole, and tasks measured as transactions.
Step 3: Creation of the scenarios: A scenario describes the events that occur during a testing session. It includes a list of machines, scripts, and Vusers that run during the scenario. Scenarios are created by using LoadRunner Controller. We can create manual scenarios as well as goal-oriented scenarios. In manual scenarios, we define the number of Vusers, the load generator machines, and percentage of Vusers to be assigned to each script. For web tests, we may create a goal-oriented scenario where we define the goal that our test has to achieve. LoadRunner automatically builds a scenario for us.
Step 4: Running the scenario: The load on the server is emulated by instructing multiple Vusers to perform the tasks simultaneously. Before the testing, we set the scenario configuration and scheduling. We can run the entire scenario, Vuser groups, or individual Vusers.
Step 5: Monitoring the scenario: Scenario execution is monitored using the LoadRunner online runtime, transaction, system resource, Web resource, Web server resource, Web application server resource, database server resource, network delay, streaming media resource, firewall server resource, ERP server resource, and Java performance monitors.
Step 6: Analyzing test results: During scenario execution, LoadRunner records the performance of the application under different loads. We use LoadRunner's graphs and reports to analyze the application's performance.
<<<<<< =================== >>>>>>
Q. 3 : When load and performance Testing are done?
Load testing is performed after the completion of interface (GUI) testing.
Single user testing focuses on functionality and user interface of a system component, while application testing focuses on performance and reliability of an entire system.
For example, a typical application-testing scenario might depict 1000 users logging in simultaneously to a system. This gives rise to issues such as what is the response time of the system, does it crash, will it go with different software applications and platforms, can it hold so many hundreds and thousands of users, etc.
<<<<<< =================== >>>>>>
Q. 4: What are the components of LoadRunner?
The components of LoadRunner are The Virtual User Generator, Controller, and the Agent process, LoadRunner Analysis and Monitoring, LoadRunner Books Online.
<<<<<< =================== >>>>>>
Q. 5: What Component of LoadRunner are used for recording a Script?
Virtual User Generator (VuGen) component is used to record a script. It enables you to develop Vuser scripts for a variety of application types and communication protocols.
<<<<<< =================== >>>>>>
Q. 6: What is a rendezvous point LoadRunner?
Rendezvous points are inserted into Vuser scripts to emulate heavy user load on the server.
Rendezvous points instruct Vusers to wait during test execution for multiple Vusers to arrive at a certain point, in order that they may simultaneously perform a task. For example, to emulate peak load on the bank server, you can insert a rendezvous point instructing 100 Vusers to deposit cash into their accounts at the same time.
<<<<<< =================== >>>>>>
Q. 7: What Component of LoadRunner are used to play Back the script in multi user mode?
Controller component is used to playback the script in multi-user mode. This is done during a scenario run where a vuser script is executed by a number of vusers in a group.
<<<<<< =================== >>>>>>
Q. 8: What is a scenario in LoadRunner?
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 to be performed, and the machines on which the virtual users run their emulations.
<<<<<< =================== >>>>>>
Q. 9 : What is the recording mode for web Vuser script in LoadRunner?
We use VuGen to develop a Vuser script by recording a user performing typical business processes on a client application. VuGen creates the script by recording the activity between the client and the server.
For example, in web based applications, VuGen monitors the client end of the database and traces all the requests sent to, and received from, the database server. We use VuGen to: Monitor the communication between the application and the server; Generate the required function calls; and Insert the generated function calls into a Vuser script.
<<<<<< =================== >>>>>>
Q. 10: Why do we create parameters in LoadRunner?
Parameters are like script variables. They are used to vary input to the server and to emulate real users. Different sets of data are sent to the server each time the script is run. Better simulate the usage model for more accurate testing from the Controller; one script can emulate many different users on the system.
Q. 11: What is a correlation in LoadRunner?
Correlation is used to obtain data which are unique for each run of the script and which are generated by nested queries. Correlation provides the value to avoid errors arising out of duplicate values and also optimizing the code (to avoid nested queries).
Corelations are of two types like :
1) Automatic correlation iinvolves setting of some rules for thecorrelation. It can be application server specific. Here values are replaced by data which are created by these rules.
2) Manual correlation, the value we want to correlate is scanned and create correlation is used to correlate.
<<<<<< =================== >>>>>>
Q. 12: How can we find out as to where correlation is required in LoadRunner?
There are two ways to find out the place of use of corelation
1) We can scan for correlations, and see the list of values which can be correlated. From this we can pick a value to be correlated.
2) We can record two scripts and compare them.
<<<<<< =================== >>>>>>
Q. 13: Where can we set automatic correlation options in LoadRunner?
We can set the automatic correlation from web point of view in recording options and correlation tab. Here we can enable correlation for the entire script and choose either issue online messages or offline actions, where we can define rules for that correlation.
Automatic correlation for database can be done using show output window and scan for correlation and picking the correlate query tab and choose which query value we want to correlate. If we know the specific value to be correlated, we just do create correlation for the value and specify how the value to be created.
<<<<<< =================== >>>>>>
Q. 14: What is the function to capture dynamic values in the web Vuser script in LoadRunner?
Web_reg_save_param function saves dynamic data information to a parameter.
<<<<<< =================== >>>>>>
Q. 15: When do you disable log in Virtual User Generator in LoadRunner?
Once we debug our script and verify that it is functional, we can enable logging for errors only. When we add a script to a scenario, logging is automatically disabled.
<<<<<< =================== >>>>>>
Q. 16: When do we use standard and extended logs in LoadRunner?
Standard Log Option: It creates a standard log of functions and messages sent during script execution to use for debugging.
It is suggested to disable this option for large load testing scenarios. When you copy a script to a scenario, logging is automatically disabled.
Extended Log Option: Is selected to create an extended log, including warnings and other messages. We can specify all additional information that needs to be added to the extended log.
<<<<<< =================== >>>>>>
Q. 17: How do we debug a script in LoadRunner?
VuGen contains two options to help debug Vuser scripts-the Run Step by Step command and breakpoints.
The Debug settings in the Options dialog box allow us to determine the extent of the trace to be performed during scenario execution.
The debug information is written to the Output window. We can manually set the message class within our script using the lr_set_debug_message function. This is useful if we want to receive debug information about a small section of the script only.
<<<<<< =================== >>>>>>
Q. 18:How do we write user defined functions in LoadRunner?
Before we create the User Defined functions we need to create the external library (DLL) with the function. We add this library to VuGen bin directory. Once the library is added then we assign user defined function as a parameter.
The function should have the following format: __declspec (dllexport) char* (char*, char). Few examples of user defined functions are GetVersion, GetCurrentTime, GetPltform etc.
<<<<<< =================== >>>>>>
Q. 19: What are the changes possible to be made in run-time settings in LoadRunner?
The Run Time Settings are:
a) Pacing - Has iteration count.
b) Log - Needs to Disable the Logging Standard Log
c) Extended Think Time - In think time there are two options like Ignore think time and Replay think time.
d) General - Under general tab we can set the vusers as process or as multithreading and each step as a transaction.
<<<<<< =================== >>>>>>
Q. 20: Where do we set Iterations for Vuser testing in LoadRunner?
Iterations are set in the Run Time Settings of the VuGen. The navigation for this is Run time settings, Pacing tab, set number of iterations.
Q. 21: How do we perform functional testing under load?
Functionality under load can be tested by running several Vusers concurrently. By increasing the amount of Vusers, we can determine how much load the server can sustain.
<<<<<< =================== >>>>>>
Q. 22: What is Ramp up in LoadRunner?
It is an option is used to gradually increase the amount of Vusers/load on the server. An initial value is set and a value to wait between intervals can be specified. To set Ramp Up, go to 'Scenario Scheduling Options'
<<<<<< =================== >>>>>>
Q. 23: What are the advantages of running the Vuser as thread in LoadRunner?
VuGen provides the facility to use multithreading. This enables more Vusers to be run per generator. If the Vuser is run as a process, the same driver program is loaded into memory for each Vuser, thus taking up a large amount of memory.
This limits the number of Vusers that can be run on a single generator. If the Vuser is run as a thread, only one instance of the driver program is loaded into memory for the given number of Vusers (say 100).
Each thread shares the memory of the parent driver program, thus enabling more Vusers to be run per generator.
<<<<<< =================== >>>>>>
Q. 24: How can we stop the execution of script when an error occurs?
The lr_abort function aborts the execution of a Vuser script. It instructs the Vuser to stop executing the Actions section, executes the vuser_end section and terminates the execution.
This function is useful when you need to manually abort a script execution as a result of a specific error condition. When you terminate a script using this function, the Vuser is assigned the status "Stopped". For this to take effect, we have to first uncheck the "Continue on error" option in Run-Time Settings.
<<<<<< =================== >>>>>>
Q. 25: What is the relation between Response Time and Throughput?
The Throughput graph shows the amount of data in bytes that the Vusers received from the server in a second.
When we compare this with the transaction response time, we will notice that as throughput decreased, the response time also decreased. Similarly, the peak throughput and highest response time would occur approximately at the same time.
<<<<<< =================== >>>>>>
Q. 26: What is the Configuration of systems in relation to the LoadRunner?
The configuration of our systems refers to that of the client machines on which we run the Vusers.
The configuration of any client machine includes its hardware settings, memory, operating system, software applications, development tools, etc.
This system component configuration should match with the overall system configuration that would include the network infrastructure, the web server, the database server, and any other components that go with this larger system so as to achieve the load testing objectives.
<<<<<< =================== >>>>>>
Q. 27: How do we identify the performance bottlenecks in LoadRunner?
Performance Bottlenecks can be detected by using monitors. These monitors might be application server monitors, web server monitors, database server monitors and network monitors. They help in finding out the troubled area in our scenario which causes increased response time.
The measurements made are usually performance response time, throughput, hits/sec, network delay graphs, etc.
<<<<<< =================== >>>>>>
Q. 28: How can we find out the web server related issues?
Using Web resource monitors we can find the performance of web servers. Using these monitors we can analyze throughput on the web server, number of hits per second that occurred during scenario, the number of http responses per second, the number of downloaded pages per second.
<<<<<< =================== >>>>>>
Q. 29: How can we find out the database related issues?
By running "Database" monitor and help of "Data Resource Graph" we can find database related issues.
<<<<<< =================== >>>>>>
Q. 30: How do we plan the Load in LoadRunner?
Load test is planned to decide the number of users, what kind of machines we are going to use and from where they are run. It is based on 2 important documents, Task Distribution Diagram and Transaction profile.
Task Distribution Diagram gives us the information on number of users for a particular transaction and the time of the load. The peak usage and off-usage are decided from this Diagram. Transaction profile gives us the information about the transactions name and their priority levels with regard to the scenario we are deciding.
Q. 31: What is the purpose of vuser_init action in LoadRunner?
Vuser_init action contains details of procedures to login to a server.
<<<<<< =================== >>>>>>
Q. 32: What is the purpose of vuser_end action in LoadRunner?
Vuser_end section contains details of log off procedures.
<<<<<< =================== >>>>>>
Q. 33: What is think time in LoadRunner?
It is the time that a real user waits between two actions.
For example: When a user receives data from a server, he may need to wait for some time may be several seconds to review the data before responding. This time delay is known as the think time.
<<<<<< =================== >>>>>>
Q. 34: What is think time threshold in LoadRunner
Threshold level is the level below which the recorded think time will be ignored. The default value is five (5) seconds. We can change the think time threshold in the Recording options of the Vugen.
<<<<<< =================== >>>>>>
Q. 35: What is the difference between standard log and extended log in LoadRunner?
The standard log sends a subset of functions and messages sent during script execution to a log. The subset depends on the Vuser type.
Extended log sends a detailed script execution messages to the output log. This is mainly used during debugging when we want information about parameter substitution, data returned by the server & advanced trace.
<<<<<< =================== >>>>>>
Q. 36: What is the purpose of lr_debug_message in LoadRunner?
The lr_debug_message function sends a debug message to the output log when the specified message class is set.
<<<<<< =================== >>>>>>
Q. 37: What is the purpose of lr_output_message in LoadRunner?
The lr_output_message function sends notifications to the Controller Output window and the Vuser log file.
<<<<<< =================== >>>>>>
Q. 38: What is the purpose of lr_error_message in LoadRunner?
The lr_error_message function sends an error message to the LoadRunner Output window.
<<<<<< =================== >>>>>>
Q. 39: What is the purpose of lrd_stmt in LoadRunner?
The lrd_stmt function associates a character string (usually a SQL statement) with a cursor. This function sets a SQL statement to be processed.
<<<<<< =================== >>>>>>
Q. 40: What is the purpose of lrd_fetch in LoadRunner?
The lrd_fetch function fetches the next row from the result set.
Q. 41: Waht are the various types of goals in a goal oriented scenario in LoadRunner?
Load Runner provides five different types of goals in a goal oriented scenario:
1) The number of concurrent Vusers
2) The number of hits per second
3) The number of transactions per second
4) The number of pages per minute
5) The transaction response time that you want your scenario
<<<<<< =================== >>>>>>
Q. 42: Where do we set automatic correlation options in LoadRunner?
Automatic correlation from web point of view, can be set in recording options and correlation tab. Here we can enable correlation for the entire script and choose either issue online messages or offline actions, where we can define rules for that correlation.
Automatic correlation for database, can be done using show output window and scan for correlation and picking the correlate query tab and choose which query value we want to correlate. If we know the specific value to be correlated, we just do create correlation for the value and specify how the value to be created.
<<<<<< =================== >>>>>>
Q. 43: How can we capture dynamic values in the web vuser script in LoadRunner?
Web_reg_save_param function saves dynamic data information to a parameter.
<<<<<< =================== >>>>>>
Q. 44: How do we use the recording mode for web Vuser script in LoadRunner?
We use VuGen to develop a Vuser script by recording a user performing typical business processes on a client application. VuGen creates the script by recording the activity between the client and the server.
For example, in web based applications, VuGen monitors the client end of the database and traces all the requests sent to, and received from, the database server. We use VuGen to: Monitor the communication between the application and the server; Generate the required function calls; and Insert the generated function calls into a Vuser script.
<<<<<< =================== >>>>>>
Q. 45: What is the use of parameters in LoadRunner?
Parameters are like script variables. These are used to vary input to the server and to emulate real users.
Different sets of data are sent to the server each time the script is run. It is better to simulate the usage model for more accurate testing from the Controller where one script can emulate many different users on the system.
<<<<<< =================== >>>>>>
Q. 46: For load testing, what you should know in addition to the knowldege of LoadRunner tool?
1) Management aspects of Load Testing especially the Planning.
2) Requirements gathering, Profile/Mix, SLA, Acceptance Criteria....
3) Broad understanding of the protocol we need to work with.
4) Basic knowledge of C programming.
<<<<<< =================== >>>>>>
Q. 47: How many users can we emulate with Load-Runner on a PC?
There is no limit. However it depends on system response. That too inturn depends on various factors like entire system configuration etc.
If system comes across bottle necks during the begining or with minimum no of Vusers, no further addition of vusers should be considered unless & until the previously observed bottleneck are adequately resolved.
<<<<<< =================== >>>>>>
Q. 48: How can we find out memory leak using Load Runner?
Setup the scenario with Available Bytes and Committed Bytes as one of the counters to monitor. Run the load test as per the norms. Observe the pattern of memory usage on the designated server with the ramp up of Vusers and see if they correlate.
When the memory usage goes to its peak, exit the Vusers gradually. If there wasn't any leakage, the Available Bytes should increase and Committed Bytes should decrease in correlation with the existing Vusers. If it doesn't happen, means that the memory usage had been very high, and the Vusers have successfully exited. It may indicate the memory leak had existed in the application and this aspect would need to be resolved at the code-level.
<<<<<< =================== >>>>>>
Q. 49: How can we record a command prompt operation in LoadRunner?
We can't record a command prompt operation in LoadRunner. Because LR works on a environment where Client and server talks with each other. It records only the communication of Client to Server and verifies the reply from Server.
<<<<<< =================== >>>>>>
Q. 50 :How can we run QTP scripts in LoadRunner?
1) Install QTP and Loadrunner in same machines.
2) Open the QTP script.
3) .Open Vugen and click on record then all provide all required information in all fields then click "OK" Button.
4) Click F5 or Replay in QTP script.
