Load testing is evolving as a discipline and it has discovered most of its business in the Internet economy. This paper examines various types of load testing and provides a detailed discussion on the load testing process. All load testing tools simulate realistic volumes of users to measure, define, validate, and maintain optimal application performance. There are many tools available on the market that can help in load testing, but this paper presents a brief overview of Web Application Stress Tool (WAST) that can serve the purpose.
Load Testing
Introduction
Load Testing is creation of a simulated load on a real computer system by using virtual users who submit work as real users would do at real client workstations and thus testing the systems ability to support such workload. –Watson, Rational inc.,
Testing of critical web applications during its development and before its de-ployment should include functional testing to confirm to the specifications, per-formance testing to check if it offers an acceptable response time and load testing to see what hardware or software configuration will be required to provide acceptable response time and handle the load that will created by the real users of the system
Why is load testing important?
Load Testing increases the uptime for critical web applications by helping you spot the bottlenecks in the system under large user stress scenarios before they happen in a production environment
When should load testing be done?
Load testing should be done when the probable cost of the load test is likely less than the cost of a failed application deployment.
Thus a load testing is accomplished by stressing the real application under simu-lated load provided by virtual users.
Load Testing Process
System Analysis
This is the first step when the project decides on load testing for its system. Evaluation of the requirements and needs of a system, prior to load testing will provide more realistic test conditions. For this one should know all key performance goals and objectives like number of concurrent connections, hits per second etc.,
Another important analysis of the system would also include the appropriate strat-egy for testing applications. It can be load testing or stress testing or capacity test-ing.
Load Testing is used to test the application against a requested number of users. The objective is to determine whether the site can sustain a requested number of users with acceptable response times. Stress testing is nothing but load testing over extended periods of time to validate an application’s stability and reliability. Similarly capacity testing is used to determine the maximum number of concurrent users that an application can manage. Hence for businesses capacity testing would be the benchmark to say that the maximum loads of concurrent users the site can sustain before the system fails.
Finally it should also be taken into consideration of the test tool which supports load testing by determining its multithreading capabilities and the creation of number of virtual users with minimal resource consumption and maximal virtual user count.
User Scripts
Once the analysis of the system is done the next step would be the creation of user scripts. A script recorder can be used to capture all the business processes into test scripts and this more often referred as virtual users or virtual user scripts. A virtual user is nothing but an emulated real user who drives the real application as client.
All the business process should be recorded end to end so that these transactions will assist in breakdown of all actions and the time it takes to measure the per-formance of business process.
Settings
Run time settings should be defined the way the scripts should be run in order to accurately emulate real users. Settings can configure the number of concurrent connections, test run time, follow HTTP redirects etc., System response times also can vary based on the connection speed. Hence throttling bandwidth can emulate dial up connections at varying modem speeds (28.8 Kbps or 56.6 Kbps or T1 (1.54M) etc.
Performance Monitoring
Every component of the system needs monitoring :the clients, the network, the webs server, the application server, the database etc., This will result in instantly identifying the performance bottle necks during load testing. But if the tools sup-port real time monitoring then testers would be able to view the application per-formance at any time during the test.
Thus running the load test scenario and monitoring the performance would accel-erate the test process thereby producing a more stable application
Analyzing Results
The last but most important step in load testing is collecting and processing the data to resolve performance bottlenecks. The reports generated can be anything ranging from Number of hits, number of test clients, requests per second, socket errors etc.,
Hence analyzing the results will isolate bottle necks and determine which changes are needed to improve the system performance. After these changes are made the tests must re run the load test scenarios to verify adjustments.
Load Testing with WAST
Web Application Stress is a tool to simulate large number of users with a relatively small number of client machines. Performance data on an web application can be gathered by stressing the website and measuring the maximum requests per second that the web server can handle. The next step is to determine which re-source prevents the requests per second from going higher, such as CPU, memory, or backend dependencies. This section will give the basics and most easiest way of performing load testing using WAST.
Creating a Test Script
You can create test scripts using Web Application stress for load testing of your web application in the following ways,
- Manually
- By recording with a browser
- From an IIS log
- From the web site content
For ease let us discuss how can Test scripts can be created by recording with a browser.
The first step involved would be to create a database which will hold your scripts i.e., you need to create a web application stress database. This database will con-tain all the scripts that are generated as a result of your recording on various actions that were performed on the web application. It would be advisable to create a separate database for separate projects.
Once a database is created remove the sample script provided by the default. You can create one!! Choose the menu options to create a script by recording. This would prompt the user to choose the following
- Record delay between records
- Record browser cookies
- Record the host header
User can select anything depending upon their needs. Once this is finished the user will be prompted to enter the web address in the address bar of the browser. The user should enter the URL for the web application which is under test. Stop recording after finishing all your actions. Once recording is stopped the user will be able to see the details of the pages that the user has browsed.
Now you can change your settings to configure how the WAST should stress you application. Web Application Stress allows you to specify the Stress level (threads) and Stress multiplier (sockets per thread) for greater control of a test run. Stress level is the total number of Windows NT threads that are created across all of the clients. Each thread can create multiple sockets and each socket is a concurrent request. The following formula explains this relationship:
Total Concurrent Requests = Stress level x Stress multiplier = Total Number Sockets
The test run time can be varied depending upon how much time the script needs to be run. For example giving the test run time as 1 minute would run the script for a minute and would stop the execution of the scripts.
Once the test is run with the expected number of users the reports will be gener-ated. Selecting a report would in general give the details like number of test clients, number of hits per second, requests per second etc. The result codes will highlight if the system is susceptible to use by recording the results. Hence the user would be able to get useful data on the test run.
Conclusion
Load testing is the measure of an entire Web application's ability to sustain a number of simultaneous users and transactions, while maintaining adequate re-sponse times. It is the only way to accurately test the end-to-end performance of a Web site prior to going live.
Two common methods for implementing this load testing process are manual and automated testing. Manual testing would involve
- Coordination of the operations of users
- Measure response times
- Repeat tests in a consistent way
- Compare results
As load testing is iterative in nature, the performance problems must be identified so that system can be tuned and retested to check for bottlenecks. For this reason, manual testing is not a very practical option.
Today, automated load testing is the preferred choice for load testing a Web application. The testing tools typically use three major components to execute a test:
- A console, which organizes, drives and manages the load
- Virtual users, performing a business process on a client application
- Load servers, which are used to run the virtual users
With automated load testing tools, tests can be easily rerun any number of times and the results can be reported automatically. In this way, automated testing tools provide a more cost-effective and efficient solution than their manual counterparts. Plus, they minimize the risk of human error during testing.
