It is used to obtain dynamic data that is unique for every run of the test. These values are not hard coded but are extracted from the run-time to avoid failures during the replay of the script.
Example: SessionId, CSRF tokens.

Throughput is the amount of data received for the server in bytes per second. In comparison, when response times increases the throughput also increases and vice-versa.

Think time is the time the user waits between the transactions, i.e the user may have to wait for validating the page before it loads completely or review the data before continuing to next steps.
Threshold value is the value below which the think time is not recognized or ignored, this threshold value can be changed in the recording options.

Loadrunner is to simulate the real user actions and load the server to measure the responsiveness/ stability of the application. Multiple versions rea available in the market to make it compatible with new technologies.
Loadrunner uses ANSI C as default programming language.

There are three components in Loadrunner:
Virtual User Generator – We emulate the end-user actions using VUgen, here we record and enhance the scripts.
Controller – We run the scripts generated from VUgen and this controls the multiple load generators and scenarios associated with it.
Analysis – This gives the detailed results and presents then using reports, charts and graphs.

There are five types of goals in the goal oriented scenario:
1.Number of concurrent users
2.Number of hits per second
3.Number of transactions per second
4.Number of pages per minute
5.Transaction response time

There are two types of correlation.
Automatic correlation – We set the rules in the recording options which depends on the application. As soon as the recording is complete the data can be replaced with parameters for which the rules are set.
Manual correlation – We will have to find the values to be correlated manually and replaced with the parameter name.

Web_reg_save_param_ex is the function used for capturing the dynamic values.

Setting we can change are
Pacing, logging, think time, No of iterations, Browser emulation, speed simulation, proxy, preferences, download filters, streaming.

Load test: to diagnose the performance of application under normal load conditions
Stress test: to find the breakpoint of an application
Endurance testing: to find the behavior of application for the prolonged duration and to find the memory leakages.
Volume test: to find the processing capacity of the server.

Step1: Plan the load test
Step2: Create the Vuser script
Step3: Create the scenario
Step4: Running the scenario
Step5: Monitor the scenario and Analyze test results

Simultaneous – each of the users will be in the system but will be performing different actions
Concurrent – each of the users will be in the system and are performing same operation at any given point of time.

This law states that the average number of users in the system, is equal to product of arrival rate and average time spent in the system.
N=X.R
N is the number of users
X is the arrival rate
R is the time in the system

We will measure response time, 90th percentile, hits/sec, throughput, failures occurred during the test and the types of errors such as 500 errors, 404 errors, proxy errors. Also, performance counters such as CPU utilization, memory utilization, processor queue length, % disk utilization, page faults etc.

Ramp up is the increasing the number of Vusers into the system which is nothing but loading the server gradually. Scenario scheduling options in the controller is the place we can set ramp up.

Monitors are helpful in detecting the performance bottlenecks. There are multiple types of monitors such as application server monitors, web server monitors, database monitors and network monitors.
Metrics measured are response time, 90th percentile, hits/sec, throughput, failures occurred during the test and the types of errors such as 500 errors, 404 errors, proxy errors. Also, performance counters such as CPU utilization, memory utilization, processor queue length, % disk utilization, page faults etc.

Checkpoints helps in verifying the content on the returned page from the server.
There are two types of checkpoints:
Image Checkpoint – checks of an image on a web page
Text Checkpoint – checks for the text on the web page.

Application values are changing in the application and process of testing the application with different data is called parametrization.
There are multiple parameter types – File, date time, Vuserid, random number etc.

Parametrization, Correlation, Validations, inserting transactions, custom coding, variable declarations, rendezvous point etc.

It instructs Vusers to wait at same point, once all Vusers reaches the point it executes resulting in performing the task concurrently and heavily loading the server.

• It is used to test applications, measuring system behavior and performance under different real-time simulated load conditions.
• VU Gen, Controller, Load Generator, Analyser.
• 61 is the latest version of Load Runner.

VU Gen is also called as Virtual User Generator. This will be used to design the script through which Load can be emulated at later stages of Performance Testing.

We can use HTTP, .Net, SAP Web/GUI, React Native, Mobile Web, Web Services, SOAP Requests, Oracle etc., for emulating the load. Sometimes, based on the requirements, we can use multiple protocols in the same script.

Steps Toolbox is functionality in VU Gen which lists all the Commands that can be used during scripting. Even if some commands are not listed, when we search for a new command in the search bar it will suggest the commands.

Debug Layout, Default Layout, Replay Layout, Record Layout, and Snapshot Layout.

A user generally waits after performing a transaction either for the page to load or for deciding to perform another transaction. So the time taken by the user for proceeding to the next action is called think time.

During script recording, we can set the threshold value in the ‘recording options’ so that below that range, the think time can be ignored.

Think Time can be changed in two ways.

• After script recording, we can change the think time in the ‘Run-Time Setting’ in ‘Solution Explorer’ where we can set a fixed think time or even ignore it basing on the test requirements.
• We can search in the script for think time for every transaction and can change the value there itself.

For running multiple iterations within the script, we can use Run Logic.

When an iteration is complete, pacing will decide how often the next iteration can start.

Protocol Advisor will be used in determining the appropriate call for recording a Vuser Script.

The way of capturing dynamic values in a script and generalizing it is called correlation.

It can be done in two ways.

• Manual Correlation
• Automatic Correlation.

‘Web_reg_save_param_ex’ from Step Toolbox can be used to Correlate Manually. We need to set the boundary values for the date to be extracted.

When script recording is completed, we will get the Design Studio pop up for Automatic Correlation. It lists all the potential values needs to be correlated. We can select our choices and can save them as a rule so that it can be used for other scripts.

The process of replacing the input data in the script so that we can use it multiple times for different users through external files is called Parameterization.

Syntax: ‘web_reg_save_param(“ParamName”, “LB=__”, “RB=__”, LAST);

Checkpoint is functionality we use for deciding whether a Transaction is passed or failed. It si of two types.

• Text Checkpoint
  • Checks for a text on the Webpage
  • Web_reg_find(“Text to check”) is used for Text Checkpoint.
• Image Checkpoint.
  • Checks for an image on the Webpage
  • Web_img_check(“Image to check”) is used for Image Checkpoint.

It is a new feature introduced in V12.56 in Virtual User Generator. It includes the Recording Summary Report, providing various statistics for your web protocol recording.

It lists out the response codes we get in a response in the form of a pie chart, the time taken for recording, all essential details like requests and connections in a single place.

It gives a pictorial representation of how the load will be pushed during the Load Test.

Runtime Graphs, Transaction Graphs, Web Resources Graphs, System Resource Graphs, Network Graphs, Database Graphs etc.

We can see all the graphs that can be used in the ‘Run’ section of Load Controller.

Through the Load Generators, we can assign the calls to run under the Local Host during the load test. If the load is too much, UNIX or Windows Load Generators can be included through the Load Generators option in Design Section.

When the test is completed, Auto Collate Result will process the messages related to the test in all the set Load Generators and prepare a complete test result which can be viewed in the Analyser component.

A load generator is a typical UNIX or Windows machine whose purpose is to offer space for the VUsers during Load Test, store the requests and responses.

The controller is a Loadrunner Component used for creating the Scenarios for Load Tests. It is the most important part of Performance Testing as we can set the behavior of the calls, the VUsers to be run for a particular call, the duration of the test etc.,.

The analyser is an essential component of LoadRunner Package which is used for reporting purposes. It tabulates the response time, transaction count for the Load Test Scenario.

It captures different types of response times, Throughput, Transaction Count, Different graphs related to the Load Test and so on.

It is a normal filter that gives the filtered result basing on our criteria and values.

Usually, we will use it to filter the response of a particular call for a particular time, response of a particular VUser etc,

Scenario Elapsed time is the time passed since the start of the current event.     In Analyser, we can filter the results basing on Elapsed Time as well.

We can’t generalize the exact number of VUsers that a Load Generator can accommodate as it is purely based on the Size of the Load Generator and the size of one VUser Script.

Using web_get_init_property we can hey the HTTP status info..

Using additional attributes we can edit it in runtime settings.

Web protocol simulates user behavior using HTTP request.

Tru client simulates using objects. Every options in a page will be detected as Objects.

We need to parametrize the values which are being entered by the end user. So that we can simulate real world scenario with different types of data.

Sequential: passes the data one by one as per the order present in the parameter file.

Random: Randomize the values from the parameter file and pass a random value every iteration.

Unique:  It passes a unique value to each user in every iteration.

Yes, we can use random parameter type and choose a range (ex: 1 to 100) to generate a random number every iteration.

• These are multiple actions available in Vugen.
• Init is used for login hits of any application.
• The action is used for navigational steps of any scenario.
• Vuser_End is used to place log out steps of any application.

Yes ,it is possible using run logic option under run times settings.

Yes , we can distribute sequentially or randomly.

We have an option in runtime settings to simulate the speed..

It is the duration of pause between every user action. It is used to simulate end user behaviour. End user will wait for a few seconds between every action.

Pacing is a pause duration between every iterations. It is used to achieve TPS in any Performance tests.

• As soon an iteration starts.
• Wait for some duration after an iterations ends
• Start a new iteration at some fixed or random intervals.

Yes , there will be a change in response time if we disable it. Non HTML RESOURCES are the CSS ,JavaScript files  and images etc.

Using web_convert_param we can convert a parameter from HTML to URL and vice versa.

To capture the values generate at server side. Ex: session I’d.

If a request requires ha eader ,w e can pass it through web_add_header.

If the consecutive request require the same header, we can use web_add_auto_header, it passes the header value in all the consecutive requests

It is used to pass the SSL version of the application. Ex: SSL, TLS.

It is used to increase the parameter length . If you have to correlate many parameters you will have to increase the parameter length .

Once we recorded the scenario ,we must add web_reg_find function to check the response of it. We should choose an unique text for each requests.

Endurance test is executed to check the application behaviour for a longer duration. Also, we can find any memory leak in the application.

It is identified by monitoring the available memory of the servers. If the memory remains high even after the test has completed. We can identify there a problem with the memory. Memory leak happens when the objects created during the test, still keep the reference alive.

Manual scenario is used to schedule the test duration as per the time we require i.e rate of ramp up and steady state and ramp down.

Goal oriented scenario will run for the duration as per the goal defined.

Ex. Number of hits and throughout to be achieved.

Wininet uses the Microsoft interface to interact with the network card.

Socket mode uses it’s own interface to interact.

These modes can be switched based on applications.

It is used to hit the application with more number of users at the same time. It is used to create a spike testing scenario.

We must enter the rendezvous point at the beginning of any request which it requires.

Yes we can add additional users to a running script but before adding make sure you have enough data has been placed.

Yes we can add any number for scripts/ groups to a running scenario.

It’s the time that vuser should wait before aborting a step.

In runtime settings, we have download filters option to Include/Exclude.

It’s is used to get the machine name from which the script is being executed.

The timestamp is always unique. In parameter, we have date/time type.

It is used to register the number of occurrences of the text present in the response.