Agile Performance Testing - Testing Experience

HTTP-level tools record HTTP requests on the HTTP protocol level.
They usually provide functionality for basic parsing of HTTP responses
and building of new HTTP requests. Such tools may also
offer parsing and extraction of HTML forms for easier access to
form parameters, automatic replacement of session IDs by placeholders,
automatic cookie handling, functions to parse and construct
URLs, automatic image URL detection and image loading,
and so on. Extraction of data and validation are often done with
the help of string operations and regular expressions, operating
on plain HTTP response data. Even if HTTP-level tools address
many load testing needs, writing load test scripts using them can
be difficult.
Challenges with HTTP-Level Scripting
Challenge 1: Continual Application Changes
Many of you probably know this situation: A load test needs to
be prepared and executed during the final stage of software development.
There is a certain time pressure, because the go-live
date of the application is in the near future. Unfortunately, there
are still some ongoing changes in the application, because software
development and web page design are not completed yet.
Your only chance is to start scripting soon, but you find yourself
struggling to keep up with application changes and adjusting the
scripts. Some typical cases are described below.
• The protocol changes for a subset of URLs, for example, from
HTTP to HTTPS. This could happen because a server certificate
becomes available and the registration and checkout process
of a web shop, as well as the corresponding static image
URLs, are switched to HTTPS.
• The URL path changes due to renamed or added path components.
• The URL query string changes by renaming, adding or removing
URL parameters.
• The host name changes for a subset of URLs. For example,
additional host names may be introduced for a new group
of servers that delivers static images or for the separation of
content management URLs and application server URLs that
deliver dynamically generated pages.
• HTML form parameter names or values are changed or form
parameters are added or removed.
• Frames are introduced or the frame structure is changed.
© iStockphoto.com/brinkstock
Load Testing Web Applications –
Do it on the DOM Level!
by Ronny Vogel
• JavaScript code is changed, which leads to new or different
HTTP requests, to different AJAX calls, or to a new DOM (Document
Object Model) structure.
In most of these cases, HTTP-level load test scripts need to be adjusted.
There is even a high risk that testers do not notice certain
application changes, and although the scripts do not report any
errors, they do not behave like the real application. This may have
side effects that are hard to track down.
Challenge 2: Dynamic Data
Even if the application under test is stable and does not undergo
further changes, there can be serious scripting challenges due
to dynamic form data. This means that form field names and values
can change with each request. One motivation to use such
mechanisms is to prevent the web browser from recalling filledin
form values when the same form is loaded again. Instead of
„creditcard_number“, for example, the form field might have a
generated name like „cc_number_9827387189479843“, where the
numeric part is changed every time the page is requested. Modern
web applications also use dynamic form fields for protection
against cross-site scripting attacks or to carry security-related tokens.
Another problem can be data that is dynamically changing, because
it is maintained and updated as part of the daily business.
If, for example, the application under test is an online store that
uses search-engine-friendly URLs containing catalog and product
names, these URLs can change quite often. Even worse, sometimes
the URLs contain search-friendly catalog and product names,
while embedded HTML form fields use internal IDs, so that there
is no longer an obvious relation between them.
Session IDs in URLs or in form fields may also need special handling
in HTTP-level scripts. The use of placeholders for session IDs
is well supported by most load test tools. However, special script
code might be needed, if the application not only passes these
IDs in an unmodified form, but also uses client-side operations on
them or inserts them into other form values.
To handle the above-mentioned cases, HTTP-level scripts need
manually coded, and thus unfortunately also error-prone, logic.
Challenge 3: Modeling Client-Side Activity
In modern web applications, JavaScript is often used to assemble
URLs, to process data, or to trigger requests. The resulting
requests may also be recorded by HTTP-level tools, but if their
20 The Magazine for Professional Testers www.testingexperience.com