|
|
3.
Determining the transaction
mix
In any real world scenario,
not all users will do the
same transaction. In order
to simulate the same, the
Performance Analyst must
determine the mix of
transactions/mix of browsers
for every test that needs to
be conducted.
|
For ex: Some of your clients
may be using IE and some may
be using Mozilla
You need to have the data of
% of usage. [Which you
should collect during
Requirement Collection]
|
Type Of Browser |
Transaction Name |
%
Of User |
|
Mozilla |
Search |
20 |
| IE |
Search |
50 |
|
Opera |
Search |
30 |
Similarly,
the transactions itself can
be divided based on the
Percentage of usage of that
application
|
Transaction Name |
%
Of Users |
|
Login Search |
60 |
|
Login Add Users |
20 |
|
Login Delete Users |
20 |
4.
Methodology for Tool
selection
There are a number of
Performance testing tools
available in the market .The
following are some of the
considerations for selecting
a Performance testing tool
- Look
at the budget for the
tool
- Look
for the types of
possible licensing
available
-
Understand the
technologies that are
used by your Client in
the Application under
test and the Protocols
that you need the tool
to support. Also look
for future usage
-
Evaluate the tools that
support the protocols
desired
- Check
for ease of scripting,
reporting features,
Monitors, root level
diagnosis abilities etc.
This will help you
estimate the time
required for the tests
and for reporting.
5.
Considerations while
scripting those transactions
When our performance test
design calls for a replay of
thousand’s or million’s of
users, it is very likely
that the data should be
random or diversified across
the different simulated
transactions. It should be
easy to assume that all the
users in the world don’t
exchange the same data. We
are all unique, different
and dynamic. Thus, for our
load testing to simulate the
real-world, the scripts must
support the dynamic and
varied parameterization of
data values in the script
and not just use hard-coded
values.
Let’s talk about the two
known ways of making the
data random/dynamic
-
Parameterization
-
Correlation
Parameterization: It is
automatic replacement of
hard coded data query values
in a test script, so that
different scripts can use
different data. For instance
if multiple virtual users
login with the same ID, it
does not simulate a real
world scenario. So, we
parameterize the ‘Login ID
‘with different values for
every iteration.
For ex:
|
Iteration |
Virtual User |
Login ID |
| 1 |
1 |
Dave |
| 2 |
2 |
Smith |
| 3 |
3 |
Nancy |
Correlation: Correlation
is reuse of data values as a
test script is executed. For
ex: –Consider a User goes to
an online shopping center
opens the product search
page and does a query for
the colors of Shirts
available in a particular
brand (‘Brand1Shirts’) The
value of ‘Brand1 Shirts’ is
assigned to the parameter
searchStr, and posted: “query.aspx?
str=searchStr”
Query returns 3 different
brands of Shirts that user
can choose the results of
the query are saved into a
parameter table:
|
Colour |
Product ID |
| Sky
Blue |
12349 |
|
Peach |
12560 |
|
Light Pink |
12785 |
User
chooses a Color randomly
from the list of items
returned. The value (say)
‘12560’ is selected from the
product table and saved in
the productID
parameter.
Now when 1000 users run the
same transaction, you cannot
have the same value for the
ProductID. Also for
different brands of shirts
that the user searches there
could number of ProductID’s
on the screen. In these
situations we should
correlate the data
dynamically.
Why should we be using
dynamic data while
scripting? How does it
matter?
There is a technical root
reason that your load
testing should include
dynamic data values. When a
system retrieves data from
the database, copies of that
data are saved in memory on
different components
throughout the system.
This can happen at many
layers within the
architecture of the system,
from individual hard drives,
storage controllers, in the
operating system kernel and
in the various buffer
managers in the
application’s software. If
you don’t use dynamic data
to continuously query for
new data, the load test will
not accurately flush the
cache buffers throughout the
system; and thus the system
may seem to respond with
faster than in the real
world.
What next? …
My upcoming articles will
talk about
-
Creating test
environments for
different types of
Performance tests
- How
to Conduct different
types of performance
tests
- Some
Common terminologies
used while conducting
Performance testing
- Some
specific tools in
Performance testing and
their capabilities
-
Analyzing different
bottlenecks
Performance Test Types
|