Explore topic-wise InterviewSolutions in .

The lr_abort function aborts the execution of a Vuser SCRIPT. It instructs the Vuser to stop executing the Actions SECTION, execute the vuser_end section and end 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 end 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.

The lr_abort function aborts the execution of a Vuser script. It instructs the Vuser to stop executing the Actions section, execute the vuser_end section and end 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 end 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.

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.

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.

This 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’.

This 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’.

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.

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.

We SET Iterations in the RUN Time SETTINGS of the VuGen. The navigation for this is Run time settings, Pacing tab, and set NUMBER of iterations.

We set Iterations in the Run Time Settings of the VuGen. The navigation for this is Run time settings, Pacing tab, and set number of iterations.

The Run Time Settings that we make are: a) Pacing - It has iteration count. b) Log - Under this we have Disable Logging Standard Log and C) Extended Think Time - In think time we have 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 whether each step as a transaction.

The Run Time Settings that we make are: a) Pacing - It has iteration count. b) Log - Under this we have Disable Logging Standard Log and c) Extended Think Time - In think time we have 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 whether each step as a transaction.

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* <function name> (char*, char*) Examples of user defined functions are as follows: GetVersion, GetCurrentTime, GetPltform are some of the user defined functions used in my earlier project.

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* <function name> (char*, char*) Examples of user defined functions are as follows: GetVersion, GetCurrentTime, GetPltform are some of the user defined functions used in my earlier project.

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 your 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.

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 your 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.

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. Standard Log Option: When you select Standard log, it creates a standard log of FUNCTIONS and messages sent during script execution to use for debugging. Disable this option for large load testing SCENARIOS. When you copy a script to a scenario, logging is automatically disabled Extended Log Option: Select extended log to create an extended log, including warnings and other messages. Disable this option for large load testing scenarios. When you copy a script to a scenario, logging is automatically disabled. We can SPECIFY which additional information should be added to the extended log using the extended log options.

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. Standard Log Option: When you select Standard log, it creates a standard log of functions and messages sent during script execution to use for debugging. Disable this option for large load testing scenarios. When you copy a script to a scenario, logging is automatically disabled Extended Log Option: Select extended log to create an extended log, including warnings and other messages. Disable this option for large load testing scenarios. When you copy a script to a scenario, logging is automatically disabled. We can specify which additional information should be added to the extended log using the extended log options.

Web_reg_save_param FUNCTION SAVES dynamic data information to a PARAMETER.

Web_reg_save_param function saves dynamic data information to a parameter.

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.

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.

Two ways: First 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. Secondly, we can record two scripts and compare them. We can look up the DIFFERENCE file to see for the values which needed to be correlated. In my project, there was a unique id developed for each customer, it was nothing but Insurance Number, it was GENERATED automatically and it was sequential and this value was unique. I had to correlate this value, in order to avoid errors while running my script. I did using scan for correlation.

Two ways: First 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. Secondly, we can record two scripts and compare them. We can look up the difference file to see for the values which needed to be correlated. In my project, there was a unique id developed for each customer, it was nothing but Insurance Number, it was generated automatically and it was sequential and this value was unique. I had to correlate this value, in order to avoid errors while running my script. I did using scan for correlation.

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). AUTOMATIC correlation is where we set some rules for correlation. It can be application server specific. Here values are replaced by data which are created by these rules. In manual correlation, the value we WANT to correlate is scanned and create correlation is used to correlate.

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). Automatic correlation is where we set some rules for correlation. It can be application server specific. Here values are replaced by data which are created by these rules. In manual correlation, the value we want to correlate is scanned and create correlation is used to correlate.

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.

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.

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.

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.

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.

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.

You 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, 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.

You 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, 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.

The 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.

The 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.

The 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.

The 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.

The COMPONENTS of LoadRunner are the Virtual USER Generator, CONTROLLER, and the Agent PROCESS, LoadRunner Analysis and MONITORING.

The components of LoadRunner are the Virtual User Generator, Controller, and the Agent process, LoadRunner Analysis and Monitoring.

We perform load testing once we are DONE with interface (GUI) testing. Modern system architectures are large and complex. Whereas single user testing primarily on functionality and user interface of a system component, 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. This is when we set do load and performance testing.

We perform load testing once we are done with interface (GUI) testing. Modern system architectures are large and complex. Whereas single user testing primarily on functionality and user interface of a system component, 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. This is when we set do load and performance testing.

Step 1: Planning the test. Here, we develop a clearly defined test plan to ensure the test scenarios we develop will accomplish load-testing objectives.

Step 2: Creating Vusers. Here, we create Vuser scripts that contain tasks performed by each Vuser, tasks performed by Vusers as a whole, and tasks measured as transactions.

Step 3: Creating the scenario. 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. We create scenarios 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. We emulate load on the server by instructing multiple Vusers to perform 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. We monitor scenario execution 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.

Step 1: Planning the test. Here, we develop a clearly defined test plan to ensure the test scenarios we develop will accomplish load-testing objectives.

Step 2: Creating Vusers. Here, we create Vuser scripts that contain tasks performed by each Vuser, tasks performed by Vusers as a whole, and tasks measured as transactions.

Step 3: Creating the scenario. 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. We create scenarios 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. We emulate load on the server by instructing multiple Vusers to perform 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. We monitor scenario execution 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.

YES. VERSION 7.2.

Yes. Version 7.2.

Timing for both read and update transactions should be GATHERED to determine whether system functions are being performed in an acceptable timeframe. This should be done STANDALONE and then in a multi USER environment to determine the EFFECT of multiple transactions on the timing of a SINGLE transaction.

Timing for both read and update transactions should be gathered to determine whether system functions are being performed in an acceptable timeframe. This should be done standalone and then in a multi user environment to determine the effect of multiple transactions on the timing of a single transaction.

Manual & Automatic Co-relation

Manual correlation - Correlation is used to obtain data which are unique for each RUN of the script and which are generated by NESTED queries.

Automatic correlation is where we set some rules for correlation. It can be application server SPECIFIC. Here values are replaced by data, which are CREATED by these rules.

Manual & Automatic Co-relation

Manual correlation - Correlation is used to obtain data which are unique for each run of the script and which are generated by nested queries.

Automatic correlation is where we set some rules for correlation. It can be application server specific. Here values are replaced by data, which are created by these rules.

DISPLAY the average time TAKEN to perform transaction during each SECOND of the scenario RUN.

Display the average time taken to perform transaction during each second of the scenario run.

The percentage of transaction that were PERFORMED WITHIN a GIVEN time range.

The percentage of transaction that were performed within a given time range.

It DISPLAY the NUMBER of complited , successful transaction perform during each SECOND of scenario RUN.

It display the number of complited , successful transaction perform during each second of scenario run.

It indicate when VUSER were released from rendezvous POINT and how many vuser are released from each point.it HELP the transaction PERFORMANCE TIME .

It indicate when vuser were released from rendezvous point and how many vuser are released from each point.it help the transaction performance time .

It display general SCENARIO information and it CONTAIN the information like (title, scenario, result START time, end time and DURATION).

It display general scenario information and it contain the information like (title, scenario, result start time, end time and duration).

Each REPORT VIEWER CONTAIN the report header and report viewer tool bar.

Each report viewer contain the report header and report viewer tool bar.

It displays the NUMBER of the vuser that execute vuser script during each SECOND of the SCENARIO RUN. Only running and rendez state are INCLUDE.(loading, ready and pause are not displayed).

It displays the number of the vuser that execute vuser script during each second of the scenario run. Only running and rendez state are include.(loading, ready and pause are not displayed).

It CHANGES the STATUS of the VUSER from RUNNING TO PAUSE.

It changes the status of the vuser from RUNNING TO PAUSE.

The vuser status change from DOWN to PENDING to INITILIZAING to READY. If vuser FAILS to INITIALIZE , the vuser status changes to ERROR.

The vuser status change from DOWN to PENDING to INITILIZAING to READY. If vuser fails to initialize , the vuser status changes to ERROR.

OPEN an existing scenario .
CONFIGURE the scenario.
Set the RESULT directory.
Run the scenario.

Open an existing scenario .
Configure the scenario.
Set the result directory.
Run the scenario.

1-The controller check the SCENARIO configuration information.
2-then next it INVOKE the application that you select to run with the scenario .
3- then transform each script to its related hosts, when the vuser are ready they START EXECUTION.

1-The controller check the scenario configuration information.
2-then next it invoke the application that you select to run with the scenario .
3- then transform each script to its related hosts, when the vuser are ready they start execution.

If a MULTIPLE VUSER to PERFORM a tasks at EXACTLY the same time.

If a multiple vuser to perform a tasks at exactly the same time.

To CHECK the RESPONSE TIME of the client/server SYSTEM under LOAD.

To check the response time of the client/server system under load.

Using VUSER script INFORMATION DIALOG BOX.

Using vuser script information dialog box.

1-name of the VUSER SCRIPT .
2-the TYPE of the vuser.
3-the location(PATH).
4-command LINE option.

1-name of the vuser script .
2-the type of the vuser.
3-the location(path).
4-command line option.

It CONTAIN all the VUSER SCRIPT that vuser can RUN.

It contain all the vuser script that vuser can run.

In TEMPORALLY in the LOCAL DRIVE of each HOST.

In temporally in the local drive of each host.

USE WinRunner CONFIGURATION FILE that is in a specific LOCATION on the network.

Use WinRunner configuration file that is in a specific location on the network.

Instruct the VUSER to use HOSTS WinRunner CONFIGURATION FILE.

Instruct the vuser to use hosts WinRunner configuration file.

Instruct the vuser to USE the WINRUNNER CONFIGURATION file.

Instruct the vuser to use the WinRunner configuration file.

Capabilities of the HOST that at a TIME how many VUSER Are initialize .

Capabilities of the host that at a time how many vuser Are initialize .

We can MODIFY the maximum NUMBER of vuser according to the (available RESOURCE , the needs of your SCENARIO, LOADRUNNER license agreements).

We can modify the maximum number of vuser according to the (available resource , the needs of your scenario, LoadRunner license agreements).

1-the MAXIMUM number of vuser that host can run.
2-the initialization QUOTA .
3-the LOCATION of the WinRunner configuration FILE.
4. the location of the file during run-time.

1-the maximum number of vuser that host can run.
2-the initialization quota .
3-the location of the WinRunner configuration file.
4. the location of the file during run-time.

1-install remote COMMAND luncher on every MACHINE.
2-add the NAME of the host to the host lists.
3-set attributes for each host.
4-select which HOSTS will take part in the SCENARIO.

1-install remote command luncher on every machine.
2-add the name of the host to the host lists.
3-set attributes for each host.
4-select which hosts will take part in the scenario.

1-the STATUS of the HOST.
2-the PLATFORM TYPE of the host(windows/unix).
3-details of the SCENARIO.

1-the status of the host.
2-the platform type of the host(windows/unix).
3-details of the scenario.