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 <strong>Testing</strong> 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
XLT Xceptance LoadTest Functional & Load <strong>Testing</strong> • JavaScript & Ajax Pure Java • Recorder • Cloud Service For more information please visit our website at www.xceptance.com/xlt © 2005 – 2010 Copyright Xceptance Software Technologies GmbH. XLT and Xceptance are registered trademarks, all rights reserved.
Change language