Real-World Scripting Considerations In QA Load Testing

In Quality Assurance by Terrence MarcozziLeave a Comment

Reading Time: 3 minutes

In the realm of website/application QA load testing, there are many considerations which should be addressed in preparing a script for executing the load test in real-time.

The simplicities of an application or page(s) can often be misleading as these simplicities do not necessarily mean that writing and executing the initial pre-tests will be successful the first time around. Scripting time and pre-test time usually increase due to these instances.

The following are a few examples of what to expect when creating a simple load test script and the steps and challenges that come with it. This example is based on an simple application that contains several text entry fields and a Submit button:

1. First, a test environment must be created to run the load tests against. A load test is never run against a live production site or application.

2. If using a script recording tool (i.e. Selenium IDE), the script is often easy to initially create. Point and click, entering appropritate content into the fields and clicking the Submit button should usually give the scripter something to work with in the form of a functioning script.

3. If the application/webpage programmer has used unconventional naming methods to identify the elements in the application, executing the test will fail as the script will not recognize the unconventional naming method (script recorders are smart, but not always smart enough). Then, the load test scripter will need to do the following:

a. Open the application or page in question.

b. Start Firebug to enable the element(s) to be insepected. In this example, we’ll use the “itemFields” div class and element ID of “123″.
(The full version of Firebug is available for the Firefox browser and a version called Firebug Lite is available for other browsers such as Chrome, Safari and IE.)

c. In Firebug, find what “div class/id” you want to change. In this case, you are wanting to change something in the “div”. So copy the word “itemFields”, open any text editor that can do a “search all” within a folder. This word search should lead you to the correct field you are looking for (in this case “123″). Let’s say that we’ve found the element and it is actually named “first”. You would then edit the script to replace and access the name “first” instead of the unrecognized ID “123″ that the script recorder sees.

3. Now that the script is edited, a single load test can be executed to determine if it runs correctly from start to finish. When this is successful, the next script detail can be addressed.

4. Exclusions: If there are any links on the page which automatically and invisibly access a third-party site such as a counter, ads, or animations, these may be excluded in the script by a special blocking line of code which will prevent the script from accessing these links. This is especially crucial for counters which if included in a real load test, would create thousands of false hits and provide incorrect metrics related to the webpage/application access.

5. Regarding the test environment, some servers are not accessible through normal internet access and your test computer’s IP address (and if using a third-party test service), both IPs must be supplied to the test server’s admin in order to gain access to that protected test server environment.

6. Wait statements: In executing the pre-tests, your load test script may be hitting the test server with such speed and quantity of requests that the error logs are showing many errors related to being unable to resolve the requests to the test server. In this case, the problem is usually resolved in the script with the addition of WAIT clauses after each request. This will give the server time to resolve the request before moving on the the next request.

7. In some situations, especially with large amounts of requests via URLs that must be accessed in a load test, the IP addresses are often managed by one single master IP address which will divert the test requests to the test environment without the server admin having to create a new IP for each individual URL’s domain as many will reside in single separate domains. This can be done in a statement(s) included in your load test script.

8. Another consideration is caching. Your load test script cannot turn caching on/off on the server side. This must be done by the server admin whenever the test calls for server caching to be on/off.

9. Pre-tests with server admin: This should be carried out before the formal execution of the load testing. There may be issues that the server admin sees on the server side which may need adjustment before the real load test gets underway.

These are the basics of what should be considered in writing a test script, pre-tests and adjustments made to ensure a successful and meaningful load test. In a simple application or webpage mentioned at the beginning of this article, it may seems extremely simple to write the script. However, the 9 points made here as to the preparation of the script and the test environment needs careful scrutiny, which often evolves into more hours of scripting edits, pre-testing and environment validations.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.