Performance in a Web application is of utmost importance. This paper discusses the various types of testing that should be performed while measuring the performance of a Web application, the different workload models, and the ways of measuring response times using automated tools. A good performance tool aids the testing process and can be the smartest way of measuring performance in a project. End-to-end performance is the last stage of the project in a typical Web development iteration cycle. This paper also talks about some crucial design factors that improve the performance of a system.
1. What Is the Difference between Load and Stress Testing?
A load test is a simulation of real-life use of a Web application, performed to assess how the application will work under actual conditions of use. The test is performed under expected conditions both prior to application deployment and during the life cycle of the application. A stress test is designed to determine how heavy a load the Web application can handle. A huge load is generated as quickly as possible to stress the application to its limit. To guarantee a realistic simulation of the workload created by actual users, the test environment must be as close to the real environment as possible. A good load test should generate different types of traffic expected, using actual computer software and hardware.
2. What Is a Workload?
A workload is the total burden of activity placed on the Web application to be tested. This burden consists of a certain number of virtual users who process a defined set of transactions in a specified time period. Assigning a proper workload is at the crux of performance testing.
3. Typical Workload Models :
- A steady state workload is the simplest workload model used in load testing. A constant number of virtual users are run against the Web application for the duration of the test.
- An increasing workload model helps testers to find the limit of a Web application's work capacity. At the beginning of the load test, only a small number of virtual users are run. Virtual users are then added to the workload step by step.
- In a dynamic workload model, you can change the number of virtual users in the test while it is being run and no simulation time is fixed.
- In a queuing workload model, transactions are scheduled following a prescribed arrival rate. This rate is a random value based on an average interval calculated from the simulation time and the number of transactions specified.
4. Understanding the Architecture and Test Environment
Before choosing the right model for performance tests, it is important for us to understand the architecture. Testing in an environment that does not mimic production provides wrong results. It's crucial to know the specifications of the Web server, databases, or any other external dependencies the application might have. Building the test environment as close to production as possible makes the testing effort a lot easier and is the key to providing accurate results.
5. Writing Automated Scripts
In any tool, record and playback is a common feature. But automated testers should realize that recording and playing back the Web traffic that you recorded from the application won't help you simulate the workload. Once have your basic recorded script, you have to: parameterize the script by declaring variables and creating data files associated with the script; call functions to parse through the data files; store the values; and input them to the script. A good example to consider would be to simulate multiple logins in an application. In this case you might want to store the user names and passwords in a comma-separated value file or some other format. It's also a good idea to randomize certain data wherever possible to ensure complete coverage of data. You can also add think times to the script while performing a stress test. Verifying the headers and HTML or XML content returned from the server involves writing additional functions in the automated script. Once the basic framework for the script is complete, the next step would be to structure the script based on the scenarios that you want to include in