1) LoadRunner provides you with five different types of goals in a goaloriented scenario: the number of

concurrent Vusers, the number of hits per second, the number of transactions per second, the number
of pages per minute, or the transaction response time that you want your scenario to reach.

2 How to record Script in VuGennnnn:

1. Click New Vuser Script in the Scripts tab in the VuGen Start Page. The New
Virtual User dialog box opens, displaying the options for a new single protocol
script. It shows the list of all protocols supported by VuGen. Make sure the
Category type is All Protocols. VuGen displays a list of all of the available protocols
for a single protocol script. Scroll down the list, select Web (HTTP/HTML), and click
OK to create an empty Web script.

2. Choose Vuser > Start Record or click the Start Record button in the Toolbar at
the top of the page.

3. Browse steps which you want test for load testing and click stop button, VuGen
automatically generate the Virtual user Script for You,

To record any application in LoadRunner, firstly you need to select the correct protocol(s) which
client and server use for the communication. The selection of the protocol was a bit easier in
the past with the use of Protocol Advisor which has been discontinued by Micro Focus. Now,
you need to find out the suitable protocol by yourself. For that purpose, you must know the
type and architecture of the application along with the network protocol which they use for the
communication.
Many applications use application-level protocol along with network protocol. In that case, you
need to select the corresponding protocol to record the application. Sometimes you have to
select a combination of the protocol to capture all the requests.
Key points to select the LoadRunner protocol for scripting:
1. Type of application: You must know the type of application whether it is standalone,
web, mobile or IoT application. Once you get the application access and run it manually
then you can easily understand the type.
2. Architecture: You can get the architecture details from the application architecture or
development team. They can provide you whether the application has tier-1, tier-2, tier-
3 or multi-tier architecture. Most of the applications have tier-3 or multi-tier
architecture which supports Web HTTP/HTML protocol.
3. Network/Application level Protocol: You need to collect the information whether the
application sends request over TCP/IP or use any higher-level protocol.
 4. Platform: It refers to the build platform of the application like Java, .net, Flex, Web
Service etc.

For web application: If you partially get the above information then you can select Web
HTTP/HTML protocol from the list and try to record the flow. If you face the recording issue
then check the relative solution in LoadRunner community. You can also use the multi-protocol
option in order to manage the recording.
For web service: If you have XML or web service URL then you can directly load it and create
the script. Web service does not need explicit recording.
For Mobile and IoT application: LoadRunner supports mobile and IoT application recording and
has some dedicated protocols. You can simply use these protocols for recording purpose and
create the script.

5
There are three types of recording mode/levels in LoadRunner. GUI-based, HTML based and
URL based. For the uninitiated, recording levels tells you the amount of and what information is
recorded during the recording process. As the title says, for this post we will keep focus on
HTML based and URL based recording levels only and will touch upon GUI based mode, in a
later post.

5. HTML based mode, records script for every user action that is performed during
recording (hmmm…sounds like QTP) while URL based mode records each and every
 browser request to the server and resources received from the server. Confused? ok,
HTML based mode does recording as you perform clicks and doesn’t give you inside
information like what is happening behind the recording while URL based mode records
each and every step and emulate Javascript code.
6. From the point1) above you can guess, HTML mode would have less correlation to do
while URL mode has much more complex correlation requirements.
7. HTML mode is smaller and is more intuitive to read as the statements are inside the
functions corresponding to the user action performed. In the case of URL based, all
statements gets recorded into web_url()
8. HTML mode is recommended for browser applications while URL mode is
recommended for non-browser applications.
9. Lastly, don’t get the impression that I am advocating for HTML mode :). URL mode can
be of real help when you want to have control over the resources that need to be or need
not to be downloaded, since you have each and every statement in-front of you (point 1)

7
Correlation. I would recommend you to understand each and every aspect around this topic.
If you simply record and playback a script in VuGen, you might encounter errors in your
playback. Often, those errors are related to the session values which are sent by the server to the
client to identify that particular session.
Why error? Well, session values will change with every playback of the script.
To overcome this we need a way which can capture these dynamically generated session values
and pass it subsequently to any part of the script, wherever required. This method to identify
and set the dynamic generated value is known as correlation.
If your new to loadtesting, don’t confuse this term with parameter which you might have used in
tools like QTP to pass varying values. Parameter is not a dynamic value captured from
server response but it is something for which the user has predefined data values
available.
LoadRunner use three functions to correlate scripts:

10. Web_reg_save_param
11. Web_create_html_param
12. Web_create_html_param_ex
The last two are just used for backward compatibility. The first function is used often.
web_reg_save_param function explained
As explained in one of my previous posts, web_reg_save_param is THE most important
function when you are working with LoadRunner. We will start with the syntax and then touch
upon some examples to get a clear idea.
int web_reg_save_param (const char *mpszParamName, <List of
Attributes>,LAST);
Find below the available attributes [<List Of Attributes>]. Note that the attribute value strings
(e.g. Search=all) are not case sensitive.
NotFound The handling method when a boundary is not found and an empty string is
generated. “ERROR,” the default, indicates that VuGen should issue an error when a boundary
is not found. When set to “EMPTY,” no error message is issued and script execution continues.
Note that if Continue on Error is enabled for the script, then even when NOTFOUND is set to
“ERROR,” the script continues when the boundary is not found, but it writes an error message
to the Extended log file.
LB The left boundary of the parameter or the dynamic data. This parameter must be a non-
empty, null-terminated character string. Boundary parameters are case sensitive; to ignore the
case, add “/IC” after the boundary. Specify “/BIN” after the boundary to specify binary data.
RB The right boundary of the parameter or the dynamic data. This parameter must be a non-
empty, null-terminated character string. Boundary parameters are case sensitive; to ignore the
case, add “/IC” after the boundary. Specify “/BIN” after the boundary to specify binary data.
RelFrameID The hierarchy level of the HTML page relative to the requested URL.
Search The scope of the search—where to search for the delimited data. The possible values are
Headers (search only the headers), Body (search only Body data, not headers), or ALL (search
Body and headers). The default value is ALL.

ORD This optional parameter indicates the ordinal or occurrence number of the match. The
default ordinal is 1. If you specify “All,” it saves the parameter values in an array.

SaveOffset The offset of a sub-string of the found value, to save to the parameter. The default is
0. The offset value must be non-negative.
Savelen The length of a sub-string of the found value, from the specified offset, to save to the
parameter. The default is -1, indicating until the end of the string.
Convert The conversion method to apply to the data:
HTML_TO_URL: convert HTML-encoded data to a URL-encoded data format
HTML_TO_TEXT: convert HTML-encoded data to plain text format

Examples:
The examples below are taken from the LoadRunner tutorial to give clarity on topic. We will see
more examples in the coming posts.
Sample Correlation for Web Vusers
Suppose the script contains a dynamic session ID:
web_url(“FirstTimeVisitors”,”URL=/exec/obidos/subst/help/first-time-
visitors.html/002-8481703-4784428>Buy books for a penny “,
“TargetFrame=”,”RecContentType=text/html”,”SupportFrames=0″,LAST);
The dynamic id here is 002-8481703-4784428
You insert a web_reg_save_param statement before the above statement:
web_req_save_param (“user_access_number”,
“NOTFOUND=ERROR”,”LB=first-time-visitors.html/”,”RB=>Buy books for a
penny”, “ORD=6”,LAST);
ORD=6 saves the sixth occurrence of the value in user_access_number. I think everything else
is self explanatory
After implementing correlated statements, the modified script looks like this, where
user_access_number is the name of the parameter representing the dynamic data.
web_url(“FirstTImeVisitors”,”URL=/exec/obidos/subst/help/first-
time-”“visitors.html/{user_access_number}Buy books for a penny “,
“TargetFrame=”,”RecContentType=text/html”,”SupportFrames=0″,LAST);
Note: Each correlation function retrieves dynamic data once, for the subsequent HTTP request.
If another HTTP request at a later point in the script generates new dynamic data, you must
insert another correlation function.
Also as I wrote in my last post don’t confuse correlation with parameter which you might have
used in tools like QTP to pass varying values. Parameter is not a dynamic value captured
from server response but it is something for which the user has predefined data
values available.
Tips to identify the dynamic string boundaries:

 Always analyze the location of the dynamic data within the HTML code itself, and not in
the recorded script.
 Identify the string that is immediately to the left of the dynamic data. This string defines
the left boundary of the dynamic data.
 Identify the string that is immediately to the right of the dynamic data. This string
defines the right boundary of the dynamic data.
 web_reg_save_param looks for the characters between (but not including) the specified
boundaries and saves the information beginning one byte after the left boundary and
ending one byte before the right boundary. web_reg_save_param does not support
embedded boundary characters.
For example, if the input buffer is {a{b{c} and “{” is specified as a left boundary,
and “}” as a right boundary, the first instance is c and there are no further
instances—it found the right and left boundaries but it does not allow embedded
boundaries, so “c” is the only valid match. By default, the maximum length of
any boundary string is 256 characters.
Include a web_set_max_html_param_len function in your script to increase the
maximum permitted length. For example, the following function increases the
maximum length to 1024 characters: web_set_max_html_param_len(“1024”);

What is Parameterization?
Parameterization is passing different values for each virtual user or iteration. When you
record an application in Loadrunner, during recording the script contains values such as
username, password, account number etc. Suppose if you want to pass different username,
password and account numbers for each iteration that login into the application, then you
can use parameterization.

How to do Parameterization in Loadrunner:


a. Right click on the value that you want to do parameterization.
b. Click on replace with parameter.
c. Create new parameter
d.

Parameterization in Loadrunner 1
e. Give the parameter Name as shown in the image
f. Click on OK
g.

Parameterization in Loadrunner 2

h. It will ask “Do you want to replace all occurrences of the string with
parameter?” Click on Yes
i.

Parameterization in Loadrunner 3

j. Now click on parameters as shown in the image or Press CTRL+L

k.

Parameterization in Loadrunner 4
 l. You will see the parameter value that is created.

Parameterization in Loadrunner 5

Types of parameters in Loadrunner with Examples

Following are the different types of Parameters in Loadrunner
13. Custom
14. Date/Time
15. File
16. Group Name
17. Iteration Number
18. Load Generator Name
19. Random Number
 20. Table
21. Unique Number
22. User Defined Function
23. Vuser ID
24. XML
1.Custom
Customer Parameter is used to store a single value that you want to pass and it will take
that value. I don’t see much use of this parameter.
2.Date/Time
You will use this very frequently in your scripting as you need to pass different dates, like
current date, future date, Unix Time Stamp etc.
You will come across this function in many of the regular scripting and you need to practice
this option multiple times. Such as how to set the data forward by 10 days etc.
3.File
File Parameter is used to pass values like username and password and you can use rows and
columns in the file.
4.Group Name
Group name is used to define the groups for the scripts
5.Iteration Number
Iteration Number is used to track iteration number and pass in the script when it is required
and you can define the format like 0001 or 01 etc.
6.Load Generator Name
You can use this parameter to define the load generator name.
7.Random Number
Random number is one of the important parameter to pass random numbers in the scripts.
8.Table
Table is similar to file Type parameter, you can pass multiple values.
9.Unique Number
The title itself explains that this will help in passing the unique number in each iteration.
10.User Defined Function
Using this parameter you can use the function in your script and define the DLL path.
11.Vuser ID
Vuser ID is used to track the users in the test and print different logs and track the errors in
the test.
12.XML
Using this parameter you can pass the xml and its respective values.

Parameterization in Loadrunner interview questions

You will be asked at least two to three questions during your interview. It’s always tricky to
answer the questions in Parameterization.
Question:I have 10 Virtual users and each users run 2 iterations and I set Unique each
iteration in the script, how the values are passed for each user.
Answer: See the screenshot below, the first user picks first two values and the second user
picks third and fourth value and soon.

Question: I have 10 Virtual users and each users run 2 iterations and I set Sequential for
each iteration in the script, how the values are passed for each user.
Answer: See the screenshot below, the first user picks the first value and second value and
soon. All the users repeat the same.

Sequential Each Iteration

Question:How do you pass date + one day in the script?
Question:How do you pass UNIX timestamp in the script?
Question:What is offset parameter by?

Error Handling
You can specify how to handle errors during script execution. By default, when
the script detects an error, it exits. To continue script execution, even when errors
occur, select the Continue on Error check box in VuGen's General runtime
settings.
To control error handling for a specific segment of the script, insert an
lr_continue_on_error statement before and after the desired segment. The new
setting is used until the end of the script execution or until another
lr_continue_on_error statement is issued.
For example, if you enable the Continue on Error runtime setting and an error is
encounteredduring replay of the following segment, execution.
lrd_stmt(Csr1, "select..."...);
lrd_exec(...);
To continue on error for the entire script except for one segment, enable the
Continue on Error setting, and then enclose the segment with
lr_continue_on_error statements.
lr_continue_on_error (0);
lrd_stmt(Csr1, "select..."...);
lrd_exec(...);
lr_continue_on_error(1);
In addition to the lr_continue_on_error statements, you can control error
handling using Error Severity Levels.
lr_continue_on_error statements detect all types of errors—database related,
invalid parameters, etc. If you want to terminate execution only when a database
operation error occurs (Error Code 2009), you can set a function's severity level.
All functions that perform a database operation use severity levels, indicated by
the function's final parameter, miDBErrorSeverity.
Note: When you enable the Runtime setting: Continue on Error, it overrides the
"0" severity level parameter. However, if you clear the Continue on Error check
box but you specify a severity level of "1", script execution continues when a
database error occurs.

10

 Why use Checkpoints : Sometimes the script may not have performed or followed the flow you have
recorded , but it still make the replay PASS , so its better to have Checkpoint after response is got , to
make sure your script is on right page.
  Why does the script passed , without following actual recorded flow ? Because VuGen sees response
code 200 for pass criteria and incorrect flow may also have produced the 200 code
 Two Types
o Text Checkpoint
o Image Checkpoint
 How to see response in HTML page view
o Right click on function and Snapshot->Page View(tab)
o You can view both Recording and Replay screen
 How to add Text Checkpoint
o In Snapshot -> Page View right click on required text and click "Add Text Check Setup"
o Below will be added to your code
o web_reg_find should always be placed before the request on which you want to verify
content
o web_reg_find will give count of Web Tours found on page, but you may not find that
number of Web Tours on HTML page, the count is coming from how many time the Web
Tours is in View Source/Body/Header depending on where you asked it to find.

web_reg_find("Search=Body",
"Text=Web Tours",
LAST);

Or (if you want to find on whole page)

web_reg_find("Text=Web Tours",
LAST);

Or (if you want to ignore case)

web_reg_find("Text/IC=Web Tours",
LAST);

o You can add by putting function manually

 Automatically generate web_reg_find
o Go to Recording Options -> Advanced ( under HTTP Properties) and select checkbox for
"Generate web_reg_find functions for page titles" and optionally "Generate web_reg_find
functions for sub-frames"
 Using web_reg_count for finding how many times searched text is present and storing in LR
Parameter
web_reg_find("SaveCount=CountOfWelcome",
"Text=Welcome",
LAST);

Image Checkpoints

 Very rarely used

 Their code is placed after web request
 Function name is web_image_check
 Enable Image Check from Run Time Setting -> Preferences : Check "Enable image and text checks"
 How to add this checkpoint
o Manually add function
o Or right click anywhere in script -> Insert -> New Step . Steps Toolbox will come. Search for
web_image_check and click it
 You can select ALT or SRC attribute
 To find value of ALT or SRC attribute, use Developer Tool and get alt or src attribute
value and paste it in this
 Below code will be inserted

web_image_check("web_image_check",
"Alt=<alt attribute value>",
LAST);

Or

web_image_check("web_image_check",
"Src=<alt attribute value>",
LAST);

11

 You can invoke Runtime setting from Replay -> Runtime Settings Or Runtime Settings is available in
the Solution Explorer for each Script
 Important Point : How you sequence Action in Runtime Settings only matters. The sequence of
Actions under Actions ( in solution Explorer) does not matter.
 Runtime Settings -> Run Logic can be used for controlling iterations and sequence of Actions or list
of Actions to be executed.
 Iteration setting is not applied on vuser_init and vuser_end Actions.
 Scenario : You have 4 Actions , but want to iterate twice only for selected actions
o Solution : Use Insert Block and put selected Actions in it, and increase iteration on the block
  Think Time Options : Runtime Settings -> Think Time (under general) can be used to set Ignore think
time Or Replay think time
o Widely used Option is Use random percentage of recorded think time ( Min 50 and Max
150)
 How to Run to different browser than on what it has been recorded
o Runtime Settings -> Browser Emulation -> Change to required browser
o Info Purpose : User-Agent String controls what has been sent to Server
o If you desired version is not coming , search for User-Agent String and choose Use custom
and enter that User-Agent String
o Note : Whatever Browser Type you choose ( with Use browser Option) , your User-Agent
String will always start with Mozilla
 Adjust for Client Internet Speed : Runtime Settings -> Speed Simulation

12)

Think time basically the time taken by user to navigate from one page to another. And while recording it
will be reflected. And pacing is the time duration provided to put delay between the two iterations.

For convenience we use delay after each transaction as think time and delay at the end of script as
pacing in Jmeter. In load runner we put think time using the function lr_think_time(6) here think time is
6 sec. And for pacing we have pacing option in runtime settings of loadrunner there we can define the
duration and the way it will be used.

LoadRunner: PACING Calculation

How to calculate Pacing in LoadRunner?

D = Duration of the test (test window/time frame)

B = Baseline time (total time taken by 1 Vuser to complete 1 whole iteration)

T = Total amount of Think time in the script

I = Expected/Target iteration

R = Residual time of the test window.

R = (D - (T + B)*I)

P = Pacing interval

Dividing the residual time by target iteration gives pacing interval

Hence: P = R/I

D is pacing time.

(T + B)*I represent the duration of a scenario and P is the waiting time before the next scenario

Calculating Pacing Time/Think Time to achieve 50 TPS with an average

response time of 0.5 seconds with total of 100 Users
Let us start with calculating total number of transactions in an hour.

1 sec = 50 transactions

Transactions per hour by 100 users =50 TPS *3600 sec = 180000 Transactions

We have total number of users given as 100. Let us see how to calculate how many transactions each
user will perform.

Total Number of Users = 100

Each User will perform 180000/100=1800 transactions/hour

Since, every transaction is taking on an average 0.5 seconds, let us see how much time is required to
complete the each user transactions.

To complete 1800 transactions, it will take 1800*0.5 = 15 minutes

So now, let us see how much think-time is required to complete the required number transactions per
User in an hour.

1800 transactions will complete in 15 minutes

Hence, 45 minutes of think time is required in between 1800 transactions (i.e. 45*60 = 2700 seconds
of think time required in between 1800 transactions (per user))

2700 seconds required for 1800 transactions

x = 1.5 seconds think time need to include

Let us see how much time is required to complete each iteration.

Total time required to complete each Iteration = x + 0.5 seconds = 1.5 + 0.5 = 2 seconds

Verification: Let us verify if our above calculation is correct.

Total time = 1800 * 2 = 3600 seconds = 1 Hr

So, Each User will perform 1800 transactions where we will provide 2 seconds for each Iteration to
complete.

Performance testing can sometimes be misunderstood as hammering the server with high
throughput of request, but concepts like think time, pacing and delays helps us to achieve the
real user patterns happening over production. Designing the performance test scenario as close
to realistic user patterns is very crucial to achieve results which find genuine issues and
bottlenecks in applications. In the same context, think time and pacing have significant
importance while developing load test scenarios. In this article, we will cover think time, pacing
and delays, along with their meaning, best practices and how we can set up these metrics as
part of our test scenario using LoadView. Let’s first understand what think time and pacing in
load tests means when it comes to load testing.
What is Think Time?
Think time in load testing is the time difference between each action of a single user. A user
while browsing the application spends some amount of time (think time) before doing some
action on the website. For example, on an e-commerce web application, a user clicks on a
product tile, goes to its product display page, and then waits there to consume and read the
content over this page before clicking on the Add to Cart button. The time spent from clicking
on the product tile to clicking on Add to Cart is called think time. The value of think time varies
from user to user, but for our test scenario, we can take the average of think time.

What is Pacing?
Pacing is used during load tests to make sure we are running the test with desired transaction
per second. It’s the time difference between each complete iteration of business flow. It helps
us to control the count of requests sent to the server per second. As we have mentioned, load
testing is not about hitting the server with as many requests as possible with no delay, the test
plan with desired throughput can be achieved by finding the correct value of pacing.

Why it’s Important to Introduce Delays in Load Testing Scenarios

Load testing the application before full stage roll-out saves us from a potential bad experience
faced by end users with issues, like timeouts, slow page responses, and downtime. In order to
get close to realistic load test results and find issues, if any, we would need to bring our test
scenario to be as realistic as possible. Consideration of think time and pacing in our test
scenario design helps us to test how server’s queuing management, thread utilization, and
memory management is behaving under heavy load. For example, if we try adding think time in
between each concurrent user action, during this delay the server tends to pick other pending
tasks from the queue, executes the next task and then picks the old task again. This step is
exactly what happens over production with real users. Adding think time also increases the
time spent by the user on the application, which identifies issues related to concurrent user
handling capacity of the server.

How to Calculate Delays for Applications

The number of concurrent virtual users, delays, nad transaction per second (TPS) varies for each
application. So, to calculate what should be the delays for our application, we can use below
formulas.
Load test duration (in seconds) * (TPS + Delays) * Concurrent Users Count = Total Transactions
Let’s say for an example, we would like to generate 100,000 transactions, each transaction has
a response time of 5 seconds and we would be running the test for 10 minutes (600 seconds).
Let’s calculate how many concurrent users required assuming if we have 3 seconds of think
time in delays. Using the above formula, we can calculate concurrent users count required. In
our case it would be 100,000/(8*10*60) which comes out to be around 21 users. This way we
can find the delays and numbers required for load tests.

Best Practices Before Running a Load Test

To get the best and most accurate results out of performance testing, we should consider
answering below question which focus on best practices during load test.

Number of Concurrent Users

We would need to understand at what expected concurrent users we want to benchmark our
application.

Simulating Real User Test Scenarios

Designing the test scenario keeping in mind the real user journey, think times spent by the user
and delays between each test.

Geo-distributed Virtual Loads

Load injectors generating loads should be separated based on specific geo-locations, if our
application is expected to receive traffic from all over the globe.

Setting Ramp Up Period

Setting the ramp up time period also helps in increasing the scale at application gradually and
makes our test scenario realistic to application behavior.

Test Duration
The time duration of a test is important to understand how the server behaves when it is put
under continuous straight line load.
Adding Delays with LoadView
LoadView includes the EveryStep Web Recorder, which provides ease of creating test scenarios
by recording the actions performed by us in a browser. It mimics the exact steps and behavior
performed by the user, collects all data points, like selectors, actions and delays. While creating
our test scenario, we would be required to mimic the real user journey with think time delays.
Once we have stopped the recording, it creates a script which can be rerun with desired
concurrent users. As you can see from the image below, we can also modify the script and
update delays for individual steps, as needed for the test. Learn more about editing EveryStep
Web Recorder scripts.

The developed script with real user interaction with application and user journey is considered
as the best approach which can help us achieve accurate results out of load test.

User Behavior Profile

Additionally, you have the option to modify user behavior from the LoadView platform. As you
can see in the image below, you can choose from Normal Delay or choose Custom Delay to set
specific user behavior and delays for your applications. Learn more about Adjusting User
Behavior.
Parting Thoughts: Load Testing: Think Time, Pacing, and
Delays
Performance testing an application is a critical aspect before we send it into production. It can
only help us find those accurate performance related issues if best practices are followed and
test scenarios are developed which cover real user journeys on the application. In this article,
we took a look at how keeping in mind think time and pacing delays during creation of test
scenario design can help in finding the underneath issues of the system. It helps us find issues
like page timeouts, slow page response, response time and server errors well in advance at high
load. These strategies can help us to move towards responsive and reliable application. Try the
EveryStep Web Recorder now and see how quickly you can create scripts for your applications.
Get started with LoadView today!

Blog Home
13

Why Performance Testing

 Availability: The amount of time an application is available to the end user.

Lack of availability is significant because many applications will have a
substantial business cost for even a small outage. In performance testing
terms, this would mean the complete inability of an end user to make
effective use of the application.
 Response Time:The amount of time it takes for the application to respond
to a user request. For performance testing, one normally measures system
response time, which is the time between the user’s requesting a response
from the application and a complete reply arriving at the user’s workstation.
 Throughput:The rate at which application-oriented events occur. A good
example would be the number of hits on a web page within a given period of
time.
 UtilizationThe percentage of the theoretical capacity of a resource that is
being used. Examples include how much network bandwidth is being
consumed by application traffic and the amount of memory used on a server
when a thousand visitors are active.

Performance Testing Key Objectives

 Test the application’s response time under user load.

 Analyze the configuration at which user load and system configuration
application will give the best performance.
 Test reliability or stability of the system under heavy work load.
 Analyze the point at which the performance degrades and the cause.
 Test system stability in the production environment.

Types of Performance Testing

 Load Testing:This is the classic performance test, where the application is

loaded up to the target vartual user but usually no further. The aim is to
meet performance targets for availability, concurrency or throughput, and
response time. Load testing is the closest approximation of real application
use, and it normally includes a simulation of the effects of user interaction
with the application client. These include the delays and pauses experienced
during data entry as well as (human) responses to information returned from
the application servers.
 Stress Testing:This has quite a different aim from a load test. A stress test
causes the application or some part of the supporting infrastructure to fail.
The purpose is to determine the upper limits or sizing of the infrastructure.
Thus, a stress test continues until something breaks: no more users can log
in, response time exceeds the value you defined as acceptable, or the
 application becomes unavailable. The rationale for stress testing is that if our
target concurrency is 1,000 users but the infrastructure fails at only 1,005
users, then this is worth knowing because it clearly demonstrates that there
is very little extra capacity available. The results of stress testing measure
capacity as much as performance. It’s important to know your upper limits,
particularly if future growth of application traffic is hard to predict. For
example, the scenario just described would be disastrous for something like
an airport air traffic control system, where downtime is not an option.
 Volume Testing:It is done to test the stability of the system by processing
huge amount of data.
 Soak Testing: The soak test is intended to identify problems that may
appear only after an extended period of time. A classic example would be a
slowly developing memory leak or some unforeseen limitation in the number
of times that a transaction can be executed. This sort of test cannot be
carried out effectively unless appropriate server monitoring is in place.
Problems of this sort will typically manifest themselves either as a gradual
slowdown in response time or as a sudden loss of availability of the
application. Correlation of data from the users and servers at the point of
failure or perceived slowdown is vital to ensure accurate diagnosis.

Performance Testing Tools:

 ANTS (Advanced .Net testing System)

 LoadRunner
 SilkPerformer
 JMeter

What is performance testing?

It is the most important part of non-functional testing.

Checking the behavior of an application by applying some load is known as performance

testing.
Generally, this testing defines how quickly the server responds to the user's request.

While doing performance testing on the application, we will concentrate on the various
factors like Response time, Load, and Stability of the application.

Response time: Response time is the time taken by the server to respond to the
client's request.

Load: Here, Load means that when N-number of users using the application
simultaneously or sending the request to the server at a time.

Stability: For the stability factor, we can say that, when N-number of users using the
application simultaneously for a particular time.
When we use performance testing?
We will do performance testing once the software is stable and moved to the
production, and it may be accessed by the multiple users concurrently, due to this
reason, some performance issues may occur. To avoid these performance issues, the
tester performs one round of performance testing.

Since it is non-functional testing which doesn't mean that we always use performance
testing, we only go for performance testing when the application is functionally stable.

Note: Performance testing cannot be done manually since its costly and accurate result can't be
maintained.

Types of Performance Testing

Following are the types of performance testing:

 Load testing
 Stress testing
 Scalability testing
 Stability testing

Let us discuss one by one to give you a complete understanding of Load, Stress,
Scalability, and Stability performance testing.

Load testing
The load testing is used to check the performance of an application by applying some
load which is either less than or equal to the desired load is known as load testing.
For example: In the below image, 1000 users are the desired load, which is given
by the customer, and 3/second is the goal which we want to achieve while performing
a load testing.

Stress Testing
The stress testing is testing, which checks the behavior of an application by applying
load greater than the desired load.

For example: If we took the above example and increased the desired load 1000 to
1100 users, and the goal is 4/second. While performing the stress testing in this
scenario, it will pass because the load is greater (100 up) than the actual desired load.

Scalability Testing
Checking the performance of an application by increasing or decreasing the load in
particular scales (no of a user) is known as scalability testing. Upward scalability and
downward scalability testing are called scalability testing.

Scalability testing is divided into two parts which are as follows:

 Upward scalability testing

 Downward scalability testing
Upward scalability testing

It is testing where we increase the number of users on a particular scale until we

get a crash point. We will use upward scalability testing to find the maximum capacity
of an application.

Downward scalability testing

The downward scalability testing is used when the load testing is not passed, then start
decreasing the no. of users in a particular interval until the goal is achieved. So
that it is easy to identify the bottleneck (bug).

Stability Testing
Checking the performance of an application by applying the load for a particular
duration of time is known as Stability Testing.

Performance testing example

Let us take one example where we will test the behavior of an application where
the desired load is either less than 1000 or equal to 1000 users.

In the below image, we can see that the 100 up users are increased continuously to
check the maximum load, which is also called upward scalability testing.

 Scenario1: When we have the 1000 users as desired load, and the 2.7/sec is
goal time, these scenarios will pass while performing the load test because in
load testing, we will concentrate on the no. of users, and as per the requirement
it is equal to 1000 user.
 Scenario2: In the next scenario, we will increase the desired load by 100 users,
and goal time will go up to 3.5\sec. This scenario will pass if we perform stress
testing because here, the actual load is greater than (1100) the desired load
(1000).
 Scenario3: In this, if we increase the desired load three times as
1200 → 3.5\sec: [it is not less than or equal to the desired load that's why it will
Fail]
1300 → 4\sec: [it is not less than or equal to the desired load. i.e., Fail]
1400 → Crashed
Note1: Volume and soak testing is a type of testing but not performance testing.
Volume testing

Volume testing is testing, which helps us to check the behavior of an application by

inserting a massive volume of the load in terms of data is known as volume testing, and
here, we will concentrate on the number of data rates than the number of users.

Note2:
Volume is a capacity while Load is a quantity, i.e., load testing means no. of users, and volume testing
means amount of data.
Soak testing

In this type of testing, we will check the behavior of an application on the environment,
which is unsupportive for a long duration of time is known as soak testing.

Generally, soak testing is a negative type of testing since we already know that the
server or environment is not supportive.

Performance testing process

The performance testing cannot be done manually since:

 We need a lot of resources, and it became a costlier approach.

 And the accuracy cannot maintain when we track response time manually.
The Performance testing process will be completed in the following steps:

 Identify performance scenarios

 Plan and design performance test script
 Configure the test environment & distribute the load
 Execute test scripts
 Result
 Analysis result
 Identify the Bottleneck
 Re-run test

If we perform a positive flow of the performance testing process, it could follow the
below process:

Identify performance scenarios

Firstly, we will identify the performance scenarios based on these below factors:

Most commonly scenarios: It means that we can find the performance scenarios
based on the scenarios, which commonly used like in the Gmail application; we will
perform login, inbox, send items, and compose a mail and logout.
Most critical scenarios: Critical scenarios mean regularly used and important for the
business-like in Gmail application login, compose, inbox, and logout.

Huge data transaction: If we have huge data means that n-number of the users
using the application at the same time.

Once we identify the performance scenarios, we will move to the next step.

Plan and design performance test script

In this step, we will install the tools in the Test Engineer Machine and access the test
server and then we write some script according to the test scenarios and run the tool.

Once we are done with writing the script, we will go to the next step.

Configure the test environment & distribute the load

After writing the test scripts, we will arrange the testing environment before the
execution. And also, manage the tools, other resources and distribute the load
according to the "Usage Pattern" or mention the duration and stability.

Execute test scripts

Once we are done with distributing the load, we will execute, validate, and monitor the
test scripts.

Result
After executing the test scripts, we will get the test result. And check that the result
meeting the goal in the given response time or not, and the response time could be
maximum, average, and minimum.

If the response is not meeting the required time response, then we will go for the
negative flow where will perform the below steps:

Analysis result
First, we will analyze the test result whether it meets with the response time or not.

Identify the Bottleneck

After that, we will identify the bottleneck (bug or performance issue). And the
bottleneck could occur because of these aspects like the problem in code, hardware
issue (hard disk, RAM Processor), network issues, and the software issue
(operating system). And after finding the bottleneck, we will perform tuning (fix or
adjustment) to resolve this bottleneck.

Re-run test
Once we fix the bottlenecks, re-run the test scripts and checks the result whether it
meets the required goal or not.

The problem occurs in performance testing

While performing performance testing on the application, some problems may occur,
and these problems are also called the performance issue.

The performance issues are as follows:

  Response time issue
 Scalability issue
 Bottleneck
 Speed issue

Response time issue

The response time means how quickly the server respond to the client's request. If the
user's request does not complete in the given response time, it might have possible
that the user may be lost his/her interest in the particular software or application.
That's why the application or software should have a perfect response time for
responding user's request quickly.

Scalability issue
The scalability issues occur when the application cannot take the n-numbers of users
and expected user requests at the same time. That's why we will do upward
scalability testing (check the maximum capacity of the application) and downward
scalability testing (when expected time is not matched with the actual time).

Bottleneck
The Bottleneck is the informal name of bug, which occurs when the application is
limited by a single component and creates a bad impact on the system performance.

The main causes of bottlenecking are software issues (issue related to the
operating system), hardware issues (issues related to the hard disk, RAM and
the processor), and coding issue, etc.

Following are the most common performance bottlenecks:

 Memory utilization
 Disk usage
 CPU utilization
 Operating System limitations
 Network utilization

Speed issues
When we perform performance testing on the application, the application should be
faster in speed to get the user's interest and attention because if the application's
speed is slow, it may lose the user interest in the application.

Performance test tools

We have various types of performance testing tools available in the market, where
some are commercial tools and open-source tool.

Commercial tools: LoadRunner[HP], WebLOAD, NeoLoad

Open-source tool: JMeter

LoadRunner
It is one of the most powerful tools of performance testing, which is used to support the
performance testing for the extensive range of protocols, number of technologies, and
application environments.

It quickly identifies the most common causes of performance issues. And also
accurately predict the application scalability and capacity.

JMeter
The Apache JMeter software is an open- source tool, which is an entirely a Java
application designed to load the functional test behavior and measure the performance.

Generally, it was designed for testing the Web Applications but now expanded to other
test functions also.

Apache JMeter is used to test performance for both static and dynamic resources and
dynamic web applications.
It can be used to reproduce the heavy load on a server, network or object, group of
servers to test its strength or to analyze overall performance under different load types.

WebLOAD
WebLOAD testing tool used to test the load testing, performance testing, and stress
test web applications.

The WebLOAD tool combines performance, scalability, and integrity as a single process
for the verification of web and mobile applications.

NeoLoad
Neotys develop a testing tool which is called NeoLoad. The NeoLoad is used to test the
performance test scenarios. With the help of NeoLoad, we can find the bottleneck areas
in the web and the mobile app development process.

The NeoLoad testing tool is faster as compared to traditional tools.

Apart from them, some other tools are Electric load, web stress tool, LoadUI Pro,
StresStimulus, LoadView, LoadNinja, and RedLine13, which helps to test the
performance of the software or an application.

14 Work Load Modeling

 For a starter lets assume client provided following Workload Related Data
o For client mail application
 Login - 6 Transactions/Hours
 Check Mail - 5 Transactions/Hours
 Delete Mail - 4 Transactions/Hours
 Compose Email - 3 Transactions/Hours
  Note : This data is provided for Peak Hours
 Lets do Workload Modeling , lets take Login Transaction Only
o Performance Test will create Login Script which would have below components
 Launch Transaction ( for launching Application
 Think Time
 Login Transaction
 Think Time
 Log Off Transaction
o Assume this whole process of Login takes 10 min
o Since Client has given 6 Transactions per hour so our load testing should run for 1 hour for
Login process
o To perform above load
 Approach 1 : Get 6 Virtual user start Login at start of hour (which will take 10 min) ,
and than sit idle for 50 minutes
 Approach 2: Get 1 Virtual User to initiate 6 login transactions sequentially , every 10
min, which will finish at the end of hour.
 Which approach should be followed ? In general Approach 2 is followed
o Lets assume now that Login Transaction work load is 3 Transactions/Hour
 Since PT should run for 1 hour , so we have to create Model for 1 hour
 Approach 1 : Let 1 Virtual user run 3 transaction sequentially and complete all of
them in 30 minutes , and sit idle for next 30 min
 Approach 2 : Let 1 Virtual user run 3 transaction sequentially with Gap or Pacing
time of 10 minutes between each iteration , now the 3 iterations will be over in 1
Hour
 Here Approach 2 is best
o Lets assume now that Login Transaction work load is 12 Transaction/Hour
 Approach : Let 2 Virtual User run 6 transaction each (sequentially) , and completing
them in 1 Hour
o Lets assume client gives work load as 6 Login Transactions per Hour with 2 Concurrent
Users
 Approach : Let 2 Virtual user run 3 transaction each( sequentially ) with 10 min of
Pacing
o Lets assume client gives work load as 1025 Login Transactions per Hour with 289
concurrent user
 For this situation we will use Little's Law
 Formula is N = X * (Rt + Zt )
 N : Concurrent Users
 X : Throughput or Transactions Per Second
 Rt : Response Time
 Zt : Think Time ( Industry standard is 5-10 Second)
 For Performance Testing formula would be
 N = X * (Rt + Zt + Pacing) Note Rt + Zt is SET already
 Lets fit formula for 6 Login Transactions per Hour with 2 Concurrent Users
 N=2
 Rt + Zt = 10 min = 600 Sec
 X(TPS) = 6/3600
  Now in formula 2 = (6/3600) * (600 + Pacing )
 Pacing = 600 , which is correct i.e 10 min
 Example of some banking application and resulting Work Load Model

16

What is memory leak?

A memory leak is a particular type of unintentional memory consumption by a
computer program where the program fails to release memory when no longer
needed. This condition is normally the result of a bug in a program that prevents
it from freeing up memory that it no longer needs.This term has the potential to
be confusing, since memory is not physically lost from the computer. Rather,
memory is allocated to a program, and that program subsequently loses the
ability to access it due to program logic flaws.

What is a page fault?

An interrupt that occurs when a program requests data that is not currently in
real memory. The interrupt triggers the operating system to fetch the data from
a virtual memory and load it into RAM.
An invalid page fault or page fault error occurs when the operating system
cannot find the data in virtual memory. This usually happens when the virtual
memory area, or the table that maps virtual addresses to real addresses,
becomes corrupt.
Now the most important question comes up, how do they affect LoadRunner functioning?
As you might guess, memory leak, if left unattended and not corrected, could prove to be fatal.
Memory leaks can be found out by running tests for long duration (say about an hour) and
continuously checking memory usage.
Issues caused by memory leaks are essentially based on two variables for a standalone windows
application 1) Frequency of usage 2) Size of memory leak. If either one or both are very high, the
computer might come to a point when no memory is available for other applications. This could
lead to a computer crash. If it is a network based application then you will also have to consider
network traffic. If each network transaction causes a memory leak, then a high volume of
network transactions could also prove dangerous.
General questions
#1) LoadRunner interview questions can be categorized into 3 main types – Scripting,
Execution, and Analysis. It is important for beginners to focus more on the scripting part.
#2) Http/HTML is mostly used Protocol, for a start try to perfect this protocol.
#3) Be sure to know the exact version of LoadRunner that you worked on. In case of work
experience with a previous version, try to keep yourself updated with the features that are part
of the newer/current versions.
#4) Performance Testing interviews are more practical than they used to be. Scenario
oriented questions are common rather than straightforward ones. Some companies, even make
scripting tests a part of the interview process. So, be prepared for the same.
#5) Even in scripting, it is preferred that you be able to customize code, instead of just
record and replay.
#6) Expect questions on – think time, transactions, comments, recording options,
runtime settings, etc. – these are to test your knowledge of scripting best practices.
The following are some of the Performance Testing interview questions that will need
some experience to answer. Try to keep these questions in mind while working on your
performance test projects, so the interview preparation activity becomes a continuous process.

25. What are the different scripting issues you faced so far?
26. What are the performance bottlenecks that you found in the projects you were working
on? What are the recommendations made to overcome those issues?
27. Have you applied Little’s law to your project? If so, how?
28. What is your approach for analysis?
29. What do you monitor while execution?
30. How to extract server data for test execution and how to analyze that?
31. How to identify performance bottlenecks?
Key question areas are:

 Challenges that you face during scripting

 Correlation function
 Error handling
 Different recording modes for Web HTTP/HTML protocol.
 Scenario creation
 Challenges during execution
 Analysis
Below we have provided a few common LoadRunner interview questions and answers to them.
However, please note that the best results can be achieved by providing answers based
on your exposure, expertise, and interpretation of the concepts. Learning just the
answers to questions is not always optimum. Practice, Learn and Expert – this should be
your approach for Performance Testing interview preparation.
LoadRunner Interview Questions And Best Answers
Q #1) What is the difference between Performance Testing and Performance
engineering?

Answer: In Performance Testing, testing cycle includes requirement gathering, scripting,

execution, result sharing, and report generation. Performance Engineering is a step ahead of
Performance Testing where after execution; results are analyzed with the aim to find the
performance bottlenecks and the solution is provided to resolve the identified issues.
Q #2) Explain Performance Testing Life Cycle.

Answer:

 Step 1: System Analysis (Identification of critical transaction)

Virtual User Generator
 Step 2: Creating Virtual User Scripts (Recording)
 Step 3: Defining Users Behavior (Runtime setting)
LoadRunner Controller
 Step 4: Creating Load Test Scenarios
 Step 5: Running the Load Test Scenarios and Monitoring the Performance
LoadRunner Analysis
 Step 6: Analyzing the Results
Refer Performance Testing Tutorial #2 for more details.
Q #3) What is Performance Testing?

Answer: Performance Testing is done to evaluate the application’s performance under load and
stress conditions. It is generally measured in terms of the response time of the user’s action on
an application.
Q #4) What is Load Testing?

Answer: Load Testing is to determine if an application can work well with the heavy usage
resulting from a large number of users using it simultaneously. The load is increased to
simulates the peak load that the servers are going to take during maximum usage periods.
Q #5) What are the different components of LoadRunner?

Answer:
The major components of LoadRunner are:

 VUGen: Records Vuser scripts that emulate the actions of real users.
  Controller: Administrative center for creating, maintaining and executing load test
scenarios. Assigns scenarios to Vusers and load generators, starts and stops loading
tests.
 Load Generator: An agent through which we can generate load
 Analysis: Provides graphs and reports that summarize the system performance
Q #6) What is the Rendezvous point?

Answer: Rendezvous point helps in emulating heavy user load (request) on the server. This
instructs Vusers to act simultaneously. When the Vuser reaches the Rendezvous point, it waits
for all Vusers with Rendezvous point. Once designated numbers of Vusers reaches it, the Vusers
are released. Function lr_rendezvous is used to create the Rendezvous point. This can be
inserted by:

 Rendezvous button on the floating Recording toolbar while recording.

 After recording Rendezvous point is inserted through Insert> Rendezvous.
Q #7) What are the different sections of the script? In what sequence do these
sections run?

Answer: LoadRunner script has three sections Vuser_init, Action, and Vuser_end.

 Vuser_init has requests/actions to login to the application/server.

 Action has actual code to test the functionality of the application. This can be played
many times in iterations.
 Vuser_end has requests/actions to login out of the application/server.
The sequence in which these sections get executed is Vuser_init is at the very beginning and
Vuser_end at the very end. The action is executed in between the two.
Q #8) How do you identify which protocol to use for any application?

Answer: Previously Performance tester had to depend much on the development team to know
about the protocol that the application is using to interact with the server. Sometimes, it also
used to be speculative.
However, LoadRunner provides great help in the form of Protocol Advisor from version 9.5
onwards. Protocol advisor detects the protocols that the application uses and suggests to us the
possible protocols in which script can be created to simulate the real user.
Q #9) What is a Correlation? Explain the difference between Automatic
Correlation and Manual Correlation?

Answer: Correlation is used to handle the dynamic values in a script. The dynamic value could
change for each user action (value changes when action is replayed by the same user) or for
different users (value changes when action is replayed with a different user). In both cases,
correlation takes care of these values and prevents them from failing during execution.
Manual Correlation involves identifying the dynamic value, finding the first occurrence of
dynamic value, identifying the unique boundaries of capturing the dynamic value, writing
correlation function web_reg_save_param before the request having the first occurrence of a
dynamic value in its response.
Automated correlation works on predefined correlation rules. The script is played back and
scanned for autocorrelation on failing. Vugen identifies the place wherever the correlation rules
work and correlate the value on approval.
Refer to this tutorial for more details.
Q #10) How to identify what to correlate and what to parameterize?

Answer: Any value in the script that changes on each iteration or with the different users while
replaying needs correlation. Any user input while recording should be parametrized.
Q #11) What is Parameterization & why is Parameterization necessary in the
script?
Answer: Replacing hard-coded values within the script with a parameter is called
Parameterization. This helps a single virtual user (Vuser) to use different data on each run. This
simulates real-life usage of an application as it avoids server from caching results.
Refer to this tutorial for more details.
Q #12) How you identify Performance test use cases of any application?

Answer: Test cases/Uses cases for Performance tests are almost the same as any
Manual/Functional testing test cases where each and every step performed by the user is
written. The only difference is that all Manual test cases can’t be Performance Testing use cases
as there are few criteria for the selection as:

 The user activity should be related to the critical and most important functionality of the
application.
 The user activity should be having a good amount of database activity such as search,
delete or insert.
 The user activity should be having good user volume. The functionality of having less
user activity is generally omitted from the Performance testing point of view. For
Example, admin account activity.
Any of the Manual test cases that fulfill the above criteria can be used as a Performance Testing
use case/test case. If manual test cases are not written step by step, the Performance team
should create dedicated documents for them.
Q #13) While scripting you created correlation rules for Automatic Correlation. If
you want to share the correlation rules with your team members working on the
same application so that he/she can use the same on his workstation, how will you
do that?
Answer: Correlation rules can be exported through the .cor file and the same file can be
imported through VuGen.
Q #14) What are different types of Vuser logs that can be used while scripting and
execution? What is the difference between these logs? When you disable logging?

Answer: There are two types of Vuser logs available –Standard log and Extended log. Logs are
key for debugging the script. Once a script is up and running, logging is enabled for errors only.
Standard log creates a log of functions and messages sent to the server during script execution
whereas the Extended log contains additional warnings and other messages. Logging is used
during debugging and disabled while execution. Logging can be enabled for errors in that case.
Q #15) What is the Modular approach of scripting?

Answer: In Modular approach, a function is created for each request (For Example, login,
logout, save, delete, etc.) and these functions are called wherever required. This approach gives
more freedom to reuse the request and saves time. With this approach, it is recommended to
work with web custom requests.
Q #16) What are the different types of goals in Goal-Oriented Scenario?

Answer: LoadRunner has five different types of goals in Goal-Oriented Scenario. These are:

32. The number of concurrent Vusers

33. The number of hits per second
34. The number of transactions per second
35. The number of pages per minute
36. The transaction response time
Q #17) How is each step validated in the script?

Answer: Each step in the script is validated with the content on the returned page. A content
check verifies whether specific content is present on the web page or not. There are two types
of a content check which can be used in LoadRunner:

 Text Check: This checks for a text/string on the web page.

 Image Check: This checks for an image on a web page.
Q #18) How is the VuGen script modified after recording?

Answer: Once the script is recorded, it can be modified with the following process:

 Transaction
 Parameterization
 Correlation
 Variable declarations
  Rendezvous Point
 Validations/Checkpoint
Q #19) What are Ramp-up and Ramp Down?

Answer:

 Ramp-up: Rate at which virtual users add to the load test.

 Ramp Down: Rate at which virtual users exit from the load test.
Q #20) What is the advantage of running the Vuser as the thread?

Answer: Running Vusers as thread helps generate more virtual users from any machine due to
the small memory print of the Vuser running a thread.
Q #21) What is wasted time in the VuGen Replay log?

Answer: Waste time is never performed by any browser user and just the time spent on the
activities which support the test analysis. These activities are related to logging, keeping record
and custom analysis.
Q #22) How do you enable text and image checks in VuGen?

Answer: This can be done by using functions web_find (for text check) and web_image_check
(for image check) and enabling image and text check from runtime setting.
Run Time Setting–>Preference–>Enable the Image and text checkbox.
Q #23) What is the difference between web_reg_find and web_find?

Answer: web_reg_find function is processed before the request sent and is placed before the
request in the VuGen script whereas a web_find function is processed after the response of the
request comes and is placed after the request in VuGen script.
Q #24) What are the challenges that you will face to script the step “Select All” and
then “Delete” for any mail account?

Answer: In this case, the post for “Select All” and “Delete” will change every time depending on
the number of mails available. For this the recorded request for the two should be replaced with
the custom request and string building is required to build the post. (Note– This question needs
practical knowledge. So please this practically and formulate your answer).
Q #25) What is a difference between pacing and think time?

Answer: Pacing is the wait time between the action iterations whereas thinking the time is a
wait time between the transactions.
Q #26) What is the number of graphs you can monitor using Controller at a time?
What is the max of them?

Answer: One, two, four and eight graphs can be seen at a time. The maximum number of
graphs that can be monitored at a time is 8.
Q #27) You have an application that shows the exam results of the student.
Corresponding to the name of each student its mentioned whether he passed or
failed the exam with the label of “Pass” and “Fail”. How will you identify the
number of passed and failed students in the VuGen script?

Answer: For this text check is used for the web page for the text “Pass and “Fail”. Through the
function web_reg_find, we can capture the number of texts found on the web page with the help
of “SaveCount”. SaveCount stored the number of matches found. For example-

web_reg_find("Text=Pass",
"SaveCount=Pass_Student",
LAST);
web_reg_find("Text=Fail",
"SaveCount=Fail_Student",
LAST);
Q #28) During the load test, what is the optimum setting for Logs?

Answer: For the load test log level is set to minimal. This can be achieved by setting the log
level to the standard log and selecting the radio button “Send a message only when an error
occurs”.
Q #29) How will you handle the situation in scripting were for your mailbox you
have to select any one mail randomly to read?

Answer: For this, we will record the script for reading the first mail. Try to find what is being
posted in the request to read the first mail such as mail ids or row no.
From the post where a list of emails is reflecting, we will try to capture all the email ids row no
with correlation function and keeping Ordinal as All i.e. ORD=All. Replace the requested email
id in the read post with any of the randomly selected email id from the list of captured email ids.
Refer to this Scripting Tutorial.
Q #30) What is the Think Time? What is the Threshold level for think time and
how can be this changed?

Answer: Think time is the wait time inserted intentionally between the actions in the script to
emulate real user`s wait time while performing an activity on the application. The Threshold
level for Think time in the level below which recorded think time will be ignored. This can be
changed from Recorded options->Script->Generate think time greater than the
threshold.
Q #31) How is the Automated Correlation configured?

Answer: Any setting related to Automated Correlation can be done by General Options-
>Correlation. Correlation rules are set from Recording options->Correlations.
Q #32) How do you decide the number of load generator machines required to run
a test?

Answer: The number of load generators required totally depends on the protocol used to create
the script and configuration of the load generator machine. Each protocol has a different
memory print and this decides how many virtual users can be generated from the give
configuration of the machine (load generator).
Q #33) What are the capabilities exactly you look for while selecting the
performance testing tool?

Answer: Performance testing tool should capable of:-

 Testing an application built using multiple technologies and hardware platforms.

 Determine the suitability of a server for testing the application
 Testing an application with a load of tens, thousand and even thousands of virtual users.
Q #34) How are concurrent users differing from simultaneous users?

Answer: All simultaneous users are concurrent users but vice versa is not true.
All the Vusers in the running scenario are Concurrent users as they are using the same
application at the same time but maybe or may not be doing the same tasks. Simultaneous users
perform the same task at the same time. Concurrent users are made Simultaneous users through
rendezvous points.
Rendezvous points instruct the system to wait until a certain number of Vusers arrive so that
they all can do a particular task simultaneously.
Q #35) How do you identify which values need to be correlated in the script? Give
an example.

Answer: This can be done in ways:

 Record the two scripts with similar steps and compare them using WDiff utility. (See
tutorial Correlation).
 Replay the recorded script and scan for correlation. This gives a list of values that can be
correlated.
Session-Id is a good example of this. When two scripts are recorded and compared using WDiff
utility. Session ids in the two scripts should be different and WDiff highlights these values.
Q #36) How does caching affect Performance Testing results?

Answer: When data is cached in the server’s memory, the server needs not to fetch the result
and no server activity triggered. The test result does not reflect the same performance of real
users using the application with different data.
Q #37) How will you stop the execution of a script on error?

Answer: This can be achieved through lr_abort function. The function instructs the Vuser to
stop executing the Action section and end the execution by executing the vuser_end section.
This function is helpful in handling a specific error.
This can also be used to handle a situation rather than error where execution is not possible. The
function assigned “Stopped” status to the Vuser which stopped due to lr_abort function. In the
Run-Time setting, “Continue on error” should be unchecked.

The following are some of the performance testing interview questions that will need
some experience to answer. Try to keep these questions in mind while working on your
performance test projects, so the interview preparation activity becomes a continuous process.

37. What are the different scripting issues you faced so far?
38. What are the performance bottlenecks that you found in projects you were working?
What are the recommendations made to overcome those issues?
39. Have you applied Little’s law in your project? If so, how?
40. What is your approach for analysis?
41. What do you monitor while execution?
42. How to extract server data for test execution and how to analyze that?
43. How to identify performance bottlenecks?
Key question areas are:

 Challenges that you face during scripting

 Correlation function
 Error handling
 Different recording modes for Web HTTP/HTML protocol.
 Scenario creation
 Challenges during execution
 Analysis
Below we provided few common LoadRunner interview questions and answers to them.
However, please note that the best results can be achieved by providing answers based
on your exposure, expertise and interpretation of the concepts. Learning just the
answers to questions is not always optimum. Practice, Learn and Expert – this should be
your approach for performance testing interview preparation.
Q 1. What is the difference between Performance testing and Performance
engineering?

Ans: In Performance testing, testing cycle includes requirement gathering, scripting, execution,
result sharing and report generation. Performance Engineering is a step ahead of Performance
testing where after execution; results are analyzed with the aim to find the performance
bottlenecks and the solution is provided to resolve the identified issues.
Q2. Which components have you used in LoadRunner ?
Ans: Vuser generator – For generating Scripts
Controller – For creating and executing scenarios
Analyzer – To analyze results
Q3. What is load runner Agent.
Ans: Agent is interface between host machine and controller
Q4. What is the process for developing a Vuser Script ?
Ans: There are 4 steps for developing a vuser script.
1) Record the Vuser Script .
2) Playback / Enhance the recorded vuser script.
3) Define the various run-time settings & check
4) Incorporate the script in a LoadRunner scenario
Q5. Explain Performance Testing Life Cycle.
Ans: Step 1: System Analysis (Identification of critical transaction)
Virtual User Generator
Step 2: Creating Virtual User Scripts (Recording)
Step 3: Defining Users Behavior (Runtime setting)
LoadRunner Controller
Step 4: Creating Load Test Scenarios
Step 5: Running the Load Test Scenarios and Monitoring the Performance
LoadRunner Analysis
Step 6: Analyzing the Results
For More Software QA Tutorials and Interview preparations please visit:
www.tonmoyelearn.com
Q6. What is Performance testing?
Ans: Performance testing is done to evaluate application`s performance under load and stress
conditions. It is generally measured in terms of response time of user’s action on application.
Q7. What is Load testing?
Ans: Load testing is to determine if an application can work well with the heavy usage resulting
from a large number of users using it simultaneously. Load is increased to to simulates the peak
load that the servers are going to take during maximum usage periods.
Q8. What are the different components of LoadRunner?
Ans: The major components of LoadRunner are:
VUGen- Records Vuser scripts that emulate the actions of real users.
Controller – Administrative center for creating, maintaining and executing load test scenarios.
Assigns scenarios to Vusers and load generators, starts and stops loading tests.
Load Generator – An agent through which we can generate load
Analysis – Provides graphs and reports that summarize the system performance
Q9. What is the Rendezvous point?
Ans: Rendezvous point helps in emulating heavy user load (request) on the server. This
instructs Vusers to act simultaneously. When the vuser reaches the Rendezvous point, it waits
for all Vusers with Rendezvous point. Once designated numbers of Vusers reaches it, the Vusers
are released. Function lr_rendezvous is used to create the Rendezvous point. This can be
inserted by:

44. Rendezvous button on the floating Recording toolbar while recording.

45. After recording Rendezvous point is inserted through Insert> Rendezvous.
Q 10. What are the different sections of the script? In what sequence does these
section runs?
Ans: LoadRunner script has three sections vuser_init, Action and vuser_end.
vuser_init has requests/actions to login to the application/server.
Action has actual code to test the functionality of the application. This can be played many times
in iterations.
Vuser_end has requests/actions to login out the application/server.
The sequence in which these sections get executed is vuser_init is at the very beginning and
vuser_end at the very end. Action is executed in between the two.
Q11. How do you identify which protocol to use for any application?
Ans: Previously Performance tester had to depend much on the development team to know
about the protocol that application is using to interact with the server. Sometimes, it also used to
be speculative.
However, LoadRunner provides a great help in form of Protocol Advisor from version 9.5
onwards. Protocol advisor detects the protocols that application uses and suggest us the possible
protocols in which script can be created to simulate the real user.
Q12. What is correlation? Explain the difference between automatic correlation
and manual correlation?
Ans: Correlation is used to handle the dynamic values in a script. The dynamic value could
change for each user action (value changes when action is replayed by the same user) or for
different users (value changes when action is replayed with different user). In both the cases
correlation takes care of these values and prevents them from failing during execution.
Manual Correlation involves identifying the dynamic value, finding the first occurrence of
dynamic value, identifying the unique boundaries of capturing the dynamic value, writing
correlation function web_reg_save_param before the request having the first occurrence of
dynamic value in its response.
Automated correlation works on predefined correlation rules. The script is played back and
scanned for auto correlation on failing. Vugen identifies the place wherever the correlation rules
work and correlate the value on approval.
Q13. How to identify what to correlate and what to parameterize?
Ans: Any value in the script that changes on each iteration or with different user while replaying
needs correlation. Any user input while recording should be parametrized.
Q14. How many VUsers are required for load testing ?
This is essentially a trick question.
Ans: The number of VUsers required depends on your system under test , network
configurations , hardware settings, memory, operating system, software applications objective of
performance test. There can not be any generic value for Vuser.
Q15. What is the difference in running the Vuser as a process and as a thread?
Which is more advantageous way of running Vuser?
Ans: When Vuser is run as a process the same driver program is loaded into memory for each
Vuser. This will take a large amount of memory and will limit the number of Vusers you can run
on a single generator
When Vuser is run as a thread, only one instance of driver program is shared by given number of
Vusers. You can run more number of Vusers on a single generator using the multi-threading
mode.
Q16. What is the significance of “Vuser-init “?
Ans: Vuser-init records the pre-operations also called the initialization operations before the
actual application is run.
Q17. What is extended log?
Ans: An extended log will store information such as data returned by server and advanced
trace, parameter substitution and much other information depending on the options you select
in run-time settings.
Q18. Why do you create parameter?
Ans: To create a parameter you will replace the hard coded value within the script and replace it
with a parameter. This allows a single Vuser to be run many times, and to use different data on
each run. It helps in stimulating more real life server demand as it prevents server from caching
results.
Q19. What is parameterization & why is parameterization necessary in the script?
Ans: Replacing hard coded values within the script with a parameter is called Parameterization.
This helps a single virtual user (vuser) to use different data on each run. This simulates real life
usage of application as it avoids server from caching results.
Q20. How you identify Performance test use cases of any application?
Ans: Test cases/Uses cases for Performance test are almost same as any manual/functional
testing test cases where each and every step performed by the user is written. The only
difference is that all manual test cases can’t be Performance testing use cases as there are few
criteria for the selection as:
A) The user activity should be related to critical and most important functionality of the
application.
B)The user activity should be having good amount of database activity such as search, delete or
insert.
C)The user activity should be having good user volume. The functionality having less user
activity is generally omitted from Performance testing point of view. e.g admin account activity.
Any of the manual test cases that fulfill the above criteria can be used as performance testing use
case/test case. If manual test cases are not written step by step , Performance team should
create dedicated documents for them.
Q21. While scripting you created correlation rules for automatic correlation. If you
want to share the correlation rules with your team member working on the same
application so that he/she can use the same on his workstation, how will you do
that?
Ans: Correlation rules can be exported through .cor file and the same file can be imported
through VuGen.
Q22. How will you divide your script into multiple Actions? Why?
Ans: I will divide the script into Actions based on the functionality. For example, Once Action
for Logining into Application, another Action for booking and so on.
Actions increase code reusability, reduce maintenance time and hence, decrease costs.
Q23. How can you set the number of Vusers in LoadRunner ?
Ans: You can set the number of Vusers in the controller section while creating your scenarios.
Many other advanced options like ramp-up, ramp-down of Vusers are also available in the
Controller section.
Q24. What are monitors?
Ans: Monitors are used to “monitor” performance bottlenecks. They are used in Controller
section of Load Runner
Q25. What are the types of check points is available in LoadRunner?
Ans: LoadRunner provides two types of check points
a) Image Checkpoints : This checkpoint will verify the presence of an image on a page during
run-time
b) Text Checkpoint : This checkpoint will verify the presence of a text-string on a page during
run-time
Both of the above checkpoints can be added in Vugen.
Q25.1 What kind of problem we can face regarding hardware, software, network
and memory bottleneck during the performance test?
Ans: The possible issues amongst others could be –
1. Lack of Hardware
2. Memory Leakage
3. Network related issues.
4. Application/Software error
Q26. What would be your recommendation to improve performance measure?
Ans: Fine Tuning of network, database, and app and web server is recommended.
At the network level try to optimize the latency and bandwidth.
At database level, verify all indexes and sequences by running profilers. You may also optimize
your database queries.
At the App server level, run profilers for finding the memory leaks in the application
At the web server level you can use monitors and optimize the throughput and other related
metrics of the server.
Q27. What is Rendezvous point?
Ans: Rendezvous point is Synchronization/Wait point . 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.
The significance of this is to emulate some heavy load only to particular portion of the scenario
and test the behavior of the application.
Q28. What is Correlation?
Ans: Correlation is used to obtain data which is unique for each run of your test script (ex:
session ids). While recording, these dynamic values are hard-coded in your script causing the
script to fail during playback. Correlation is a technique where dynamic values are not hard-
coded in your script but are extracted at run-time to avoid failure.
Q29. What is Manual Correlation?
Ans: Its correlation technique which uses function Web_reg_save_param() to identify dynamic
values in your script. It is important that your playback your script to verify that correlation is
done successfully.
Q30. How do you identify the performance bottlenecks? –
Ans: 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
Q31. What are different types of vuser logs which can be used while scripting and
execution? What is the difference between these logs? When you disable logging?
Ans: There are two types of Vuser logs available –Standard log and Extended log. Logs are key
for debugging the script. Once a script is up and running, logging is enabled for errors only.
Standard log creates a log of functions and messages sent to the server during script execution
whereas Extended log contains additional of warnings and other messages. Logging is used
during debugging and disabled while execution. Logging can be enabled for errors in that case.
Q32. What is Modular approach of scripting?
Ans: In Modular approach, a function is created for each request (e.g. login, logout, save, delete,
etc.) and these functions are called wherever required. This approach gives more freedom to
reuse the request and saves time. With this approach it is recommended to work with web
custom request.
Q33. What are the different types goals in Goal-Oriented Scenario?
Ans: LoadRunner has five different types of goals in Goal-Oriented Scenario. These are:

 The number of concurrent Vusers

 The number of hits per second
 The number of transactions per second
 The number of pages per minute
 The transaction response time
Q34. How is each step validated in the script?
Ans: Each step in the script is validated with the content on the returned page. A content check
verifies whether specific content is present on the web page or not. There are two types of
content check which can be used in LoadRunner:
Text Check- This checks for a text/string on the web page
Image Check- This checks for an image on a web page.
Q35. How is VuGen script modified after recording?
Ans: Once the script is recorded, it can be modified with the following process:
Transaction
Parameterization
Correlation
Variable declarations
Rendezvous Point
Validations/Check point
Q36. What is Ramp up and Ramp Down?
Ans: Ramp up- Rate at which virtual users add to the load test
Ramp Down- Rate at which virtual users exit from the load test.
Q37. What is the advantage of running the Vuser as thread?
Ans: Running vusers as thread helps generate more virtual users from any machine due to
small memory print of the vuser running as thread.
Q38. Which function is used to end a nested transaction ?
Ans: The function is – lr_end_sub_transaction
Q39. What is the difference between transaction and transaction instance in
loadRunner ?
Ans: A transaction is used to measure time between executions of certain statements. A
transaction instance is used for performance analysis
Q40. While the script is running we find some values that may be need to be
correlated? Is it possible to do manual correlation for those values?
Ans: NO. Its not possible to do correlation when script is running but you can make changes
once script has stopped.
Q41. What is Elapsed Time in Load Runner?
Ans: Elapsed time designates how much time has passed since the launch of the current event
and is measured differently for different screens as given below –
In Scenario Status Window – Elapsed time is measured from the moment you hit “Start
Scenario” or ” Initialize/Run Vuser?” button.
In “Vuser” window elapsed time is measured form the moment Vuser enters “running” state.
Q42. Does caching have a negative effect on your load testing results ?
Ans: Yes. Caching has a negative effect. Cache is temporary memory which stores your
browsing history. When you visit a page for the SECOND time , the time required to load the
page will be less than that required to load the page for your first visit since much of the
information required to load the page is grabbed from the cache instead of the server. This will
effect the response times in your test. Hence, it is recommended to turn-off caching.
Q43. What is the difference between Overlay graph and Correlate graph?
Ans: Overlay Graph: It will overlay the content of two graphs that shares a common x-axis
Correlate Graph: It will Plot the Y-axis of two graphs against each other.
Q44. What is the difference between lr_error_message and lr_debug _message?
Ans: lr_error_message – Sends a error message to the LoadRunner Controller’s Output
window
lr_debug _message – Sends a debug message to the LoadRunner Controller’s Output window
Q45. What is the difference between load , performance testing ?
Ans: The objective of performance testing is to check whether an application loads/updates
within stipulate time limit (say 2 seconds). It uses metrics like response time , Requests per
second. It is carried out under production – like load conditions.
The objective of load testing is to check scalability of the system. For example, finding out the
maximum number of users supported by the system within certain specifications.
Q46. You have created several Auto Correlation rules. A new tester on your team
is preparing to record a group of scripts on the same application on his
workstation. What can you do to provide the tester with the correlation rules?
Ans: I would export the Auto Correlation rules to a .cor file, and then have the new team
member import the .cor file into his Auto Correlation rules
Q47. You want to emulate a call center for an airline. All representatives login in
the morning, perform their business processes, and log out at night. In one day, a
representative will Create 40 flight reservations, Modify 10 flight reservations, and
Search for 20 flight reservations. A representative cannot perform a Modify
without performing a Search first. How would you design the run logic ?
Ans: Create – 67% Search – 16% Block0 – 17% Search Modify
Q48. Where should you add a web_reg_save_param function to a script?
Ans: Before the step that retrieves the dynamic value
Q49. What is wasted time in VuGen Replay log?
Ans: Waste time is never performed by any browser user and just the time spent on the
activities which support the test analysis. These activities are related to logging, keeping record
and custom analysis.
Q50. How do you enable text and image checks in VuGen?
Ans. This can be done by using functions web_find (for text check) and web_image_check (for
image check) and enabling image and text check from run time setting.
Run Time Setting–>Preference–>Enable the Image and text check box.
Q51. What is the difference between web_reg_find and web_find?
Ans: web_reg_find function is processed before the request sent and is placed before the
request in the VuGen script whereas web_find function is processed after the response of the
request come and is placed after the request in VuGen script.
Q52. What are the challenges that you will face to script the step “Select All” and
then “Delete” for any mail account?
Ans: In this case the post for “Select All” and “Delete” will change every time depending on the
number mails available. For this the recorded request for the two should be replaced with
custom request and string building is required to build the post. (Note- This question needs
practical knowledge. So please this practically and formulate your answer).
Q53. What is difference between pacing and think time?
Ans: Pacing is wait time between the action iterations whereas think time is wait time between
the transactions.
Q54. What are the number of graphs you can monitor using Controller at a time?
What is the max of them?
Ans: One, two, four and eight graphs can be seen at a time. The maximum number of graphs
can be monitored in at a time is 8.
Q55. You have an application which shows the exam results of the student.
Corresponding to name of each student its mentioned whether he passed or failed
the exam with the label of “Pass” and “Fail”. How will you identify the number of
passed and failed student in VuGen script?
Ans: For this text check is used for the web page for the text “Pass and “Fail”. Through the
function web_reg_find, we can capture the number of texts found on the web page with the help
of “SaveCount”. SaveCount stored the number of matches found. For example-

1 web_reg_find("Text=Pass",
2 "SaveCount=Pass_Student",
3 LAST);
4 web_reg_find("Text=Fail",
5 "SaveCount=Fail_Student",
6 LAST);
Q56. Which protocols are supported by Loadrunner ?
Ans: As of Loadrunner 12 following protocols are supported. The interviewer is not looking for
you to name all but a few (say 5-7 protocols).
Application Deployment Solution: For the Citrix protocol.
Client/Server: For DB2 CLI, DNS, MS SQL, ODBC, Oracle (2-tier), Sybase
Ctlib, Sybase Dblib, and Windows Sockets protocols.
Custom: For C templates, Visual Basic templates, Java templates,
Javascript and VBscript type scripts.
Distributed Components: For COM/DCOM, Corba-Java, and Rmi -Java protocols.
E-business: For FTP, LDAP, Palm, Web (HTTP/HTML), Web Services, and the dual
Web/Winsocket protocols.
Enterprise Java Beans: For EJB Testing and Rmi-Java protocols.
ERP/CRM: For Baan, Oracle NCA, Peoplesoft-Tuxedo, Peoplesoft 8,
SAPGUI, SAP-Web, and Siebel (Siebel-DB2CLI, Siebel-MSSQL, Siebel-Web, and Siebel-Oracle)
protocols.
Legacy: For Terminal Emulation (RTE).
Mailing Services: Internet Messaging (IMAP), MS Exchange (MAPI), POP3, and SMTP.
Middleware: Jacada and Tuxedo (6, 7) protocols.
Streaming: For MediaPlayer and RealPlayer protocols.
Q57. During the load test what is the optimum setting for Logs?
Ans: For the load test log level is set to minimal. This can be achieved with setting the log level
to the standard log and selecting the radio button “Send message only when an error occurs”.
Q58. How will you handle the situation in scripting where for your mailbox you
have to select any one mail randomly to read?
Ans: For this we will record the script for reading the first mail. Try to find what is being posted
in the request to read the first mail such as mail ids or row no. From the post where a list of
mails is reflecting, we will try to capture all the email ids row no with correlation function and
keeping Ordinal as All i.e. ORD=All . Replace the requested email id in the read post with any of
the randomly selected email id from the list of captured email ids.
Q59. What is the Think Time? What is the Threshold level for think time and how
can be this changed?
Ans: Think time is the wait time inserted intentionally between the actions in the script to
emulate real user`s wait time while performing activity on the application. The Threshold level
for Think time in the level below which recorded think time will be ignored. This can be changed
from Recorded options->Script->Generate think time greater than threshold.
Q60. How is Automated Correlation configured?
Ans: Any setting related to Automated Correlation can be done by General Options-
>Correlation. Correlation rules are set from Recording options->Correlations.
Q61. How you decide the number of load generator machine required to run a test?
Ans: Number of load generator required totally depends on the protocol used to create the
script and configuration of the load generator machine. Each protocol has different memory
print and this decides how many virtual users can be generated from the give configuration of
the machine (load generator).
Q62. What are the capabilities exactly you look for while selecting the performance
testing tool?
Ans: Performance testing tool should capable of:-

 Testing an application built using multiple technologies and hardware platforms.

 Determine the suitability of a server for testing the application
 Testing an application with load of tens, thousand and even thousands virtual users.
Q63. How concurrent users are differing from simultaneous users?
Ans: All simultaneous users are concurrent users but vice versa is not true.
All the vusers in the running scenario are Concurrent users as they are using the same
application at the same time but may be or may not be doing the same tasks. Simultaneous users
perform the same task at the same time. Concurrent users are made Simultaneous users through
rendezvous points. Rendezvous points instruct the system to wait till a certain number of vusers
arrive so that they all can do a particular task simultaneously.
Q64. How do you identify which values need to be correlated in the script? Give an
example.
Ans: This can be done in ways:
a) Record the two scripts with similar steps and compare them using WDiff utility.
b) Replay the recorded script and scan for correlation. This gives a list of values that can be
correlated.
Session Id is a good example of this. When two scripts are recorded and compared using WDiff
utility. Session ids in the two scripts should be different and WDiff highlight these values.
Q65. How does caching affect performance testing results?
Ans: When data is cached in server`s memory, the server need not fetch the result and no
server activity triggered. Test result does not reflect the same performance of real user using the
application with different data.
Q66. How will you stop the execution of script on error?
Ans: This can be achieved through lr_abort function. The function instructs the vuser to stop
executing Action section and end the execution by executing the vuser_end section. This
function is helpful in handling a specific error. This can also be used to handle a situation rather
than error where execution is not possible. The function assigned “Stopped” status to the vuser
which stopped due to lr_abort function. In Run-Time setting, “Continue on error” should be
unchecked.
Q67. You want to have each step in your script measured as a transaction in the
Controller and not shown in the Replay Log in VuGen. How can you accomplish
this?
Ans: This can be done by enabling the automatic transaction in the Run-time settings
Q68. Which web protocol recording level generates the web_submit_form
function?
Ans: The URL protocol generates this function.