Tips for developing effective Performance Test Scripts

The Test scripts are generated to mimic the user behavior during the performance tests. The test
scripts enable the performance tester to simulate the real time user behavior by providing the
configuration options. The Test scripts needs to be modeled in such a way that it exactly
simulates the user actions & user think times.

The Test scripts should have the transaction names or browser requests identified for which the
response time & throughput metrics needs to be collected. These requests should be named with
proper naming convention so that it becomes easy to refer to a specific transaction by its unique
name.

Running the script containing the right set of transactions alone doesn’t mimic the real time user
behavior. Each transaction should be always coupled with another important metric called as
think time, which is the time taken by the user to think and to navigate between various pages.
This wait time which is placed between each transaction determines the accuracy of the scripts
simulating the user behavior. Analyzing the think time between each transaction is very critical
as it determines the load on the server at any point of time. By conducting discussions or surveys
with business analysts & end users of the application, the think time for each transaction can be
identified. Say, you have 2 transactions in your script, Login transaction followed by the think
time of about 10 seconds followed by the Logout transaction. If the think time is changed to 5
seconds, then the frequency of the login & logout requests send to the server increases, hence the
load (requests/sec) on the server increases. If the think time is changed to 20 seconds, then the
server load (requests/sec) decreases as the requests are sent in 20 seconds interval.

The test data parameterization is another important activity which needs to be taken care in the
scripts. Care should be taken so that enough test data is provided in the script so that each test
data is not used more than once when the tests are run. For example, the user login credentials
needs to be parameterized in the script. If the test is planned to run for 100 users, then the script
should have 100 login credentials available in the script. If more than 1 user is allowed to use the
same test data, then the response time would be varying as it might be caching the web pages or
the session might get reused. It’s always recommended to make sure that the script is supplied
with enough test data to be used uniquely for each user. By using parameterization, we can make
sure that the correct formatted unique data is sent from the client-side for each user during the
course of the test run. From the server side, there might be some dynamic data generated for each
user which may be unique for each user. For example the session id of each user would be
unique. If the server passes the session id of the user while returning the response for a specific
client side request, then this part of the script cannot replay correctly if it is run for a different
user id from the parameterized test data.

This kind of server-side dynamic data needs to be handled in the script as well. Sometimes the
recorded script cannot replay because of some specific dynamic values which are generated by
the server. This kind of dynamic values needs to be first studied whether it’s unique with respect
to each logged in user or unique for each run even for the same user. Sometimes the user action
gets completed even if the dynamic values are not handled. Hence, first analyze the logic under
which there is a dynamic value getting generated from the server end & accordingly handle the
dynamic value. Most of the time the dynamic value is handled by identifying the corresponding
left & right boundary & capturing the dynamic value, then the captured value can be substituted
against the variable which is holding the dynamic value.

Last but not least, make sure the script is very realistic in terms of the user actions. Try to have a
single script which covers all the flows of the application & use random number generator
function to distribute the user load across various functional flows. Sometimes it’s good to have
multiple scripts as long as the distribution of the load across scripts is handled separately.
Happy Scripting!!

1. Do you experience problems with performance in production?

2. What is the cost of downtime, including monetary, man hours, and intangibles such as
customer satisfaction, reputation, and opportunity cost?
3. Does your application scale with an increase of users?
4. Do you have a method for obtaining real performance metrics?
5. How do you repeat/reproduce a performance problem?

6. How does the server’s response time change if you increase or decrease the number of
users?
7. How many users can simultaneously work with the web server without a perceptible
slowdown?
8. What load can crash the server application?
9. How do hardware and software changes affect the server performance?

QALoad Product Detail

Advantages

• Scalable Testing
• Streamlined Test Script Development
• Comprehensive Analysis
• Integrated View of System Resources
• Supported Technologies

Scalable Testing

Using QALoad, you can emulate the load generated by hundreds or thousands of users on your
application—without requiring the involvement of the end users or their equipment. You can
easily repeat load tests with varied system configurations to achieve optimum performance.
From the Conductor module in QALoad, you set up a load testing scenario to control the
conditions for the test, create the virtual users you need to simulate the load, initiate and monitor
test and report the results. A Player module simulates the roles of users performing multiple
functions using testing scripts that represent your application

Streamlined Test Script Development

QALoad's Script Development Workbench provides customized modules that facilitate the
development of testing scripts. These modules, called EasyScripts, allow testers to record the
traffic an application generates and convert it into a testing script.

The resulting scripts directly reflect the actual traffic generated by the application and measure
the time taken to perform these transactions to ensure that the system under test will perform to
specifications under load.

Comprehensive Performance Analysis

QALoad provides users with a comprehensive set of performance statistics that can be viewed
both during and after QALoad test session. QALoad enables testers to insert checkpoints into
scripts to identify and review specific areas of system performance for a test. QALoad
automatically presents test results in a variety of easy to understand reports, graphs and charts.
The data from a testing session can also be automatically exported to a variety of different
formats enabling the testing team to quickly communicate findings.

Integrated Analysis of Key Performance Metrics

QALoad enables users to understand the root cause of performance issues by providing an in-
depth view of metrics for the application, operating system, database and network components.
The integrated monitoring allows you to rapidly pinpoint bottlenecks that impact application
performance while you generate a realistic load on your system.

Supported Technologies

Database: ODBC
Distributed: Winsock, Java, .Net, Citrix, TestPartner, Uniface
ERP: Oracle Forms, Server/Ebusiness Suite, SAP R/3
E-commerce: HTTP, SSL, SOAP, XML, Streaming Media