Print Page | Close Window

Performance Testing for Web Applications

Printed From: One Stop Testing
Category: Types Of Software Testing @ OneStopTesting
Forum Name: Performance & Load Testing @ OneStopTesting
Forum Discription: Discuss All that is need to be known about Performance & Load Testing and its Tools.
URL: http://forum.onestoptesting.com/forum_posts.asp?TID=2875
Printed Date: 17Nov2024 at 7:50am


Topic: Performance Testing for Web Applications
Posted By: tanushree
Subject: Performance Testing for Web Applications
Date Posted: 15Oct2007 at 4:40am
Performance Testing for Web Applications   

The most realistic strategy for rolling out a Web application is to do so in phases. Performance testing must be an integral part of designing, building, and maintaining Web applications.

•Automated testing tools play a critical role in measuring, predicting, and controlling application performance. There is a paragraph on automated tools available for testing Web Applications at the end of this document.

In the most basic terms, the final goal for any Web application set for high-volume use is for users to consistently have

•continuous availability
•consistent response times—even during peak usage times.

Performance testing has five manageable phases:

•architecture validation
•performance benchmarking
•performance regression
•performance tuning and acceptance
•and the continuous performance monitoring necessary to control performance and manage growth (see Figure2).
                                 
 
A.Architecture Validation:
In designing the architecture for a transaction-based Web application, scaling volume has to be fixed. Then use performance tests to validate that the software architecture will deliver the necessary performance—and that it will scale linearly as hardware is added to accommodate future growth. Testing the scalability of the architecture must happen at the start of development, after a prototype of the application has been created and is able to generate transactions to touch all tiers of the application.

Walkthrough of the logic of the front-end of the application must be done to ensure that it’s easy to navigate. There should be provision for enough memory and processors for these layers of the architecture to handle the expected user volumes. If the application requires custom components, the scalability of the core technologies involved should be tested.

B.Performance Benchmarking:
Carefully considering and defining the types of performance tests needed—and then creating, running, and analysing the first round of performance tests against the initial version of the application—provides a set of performance metrics commonly referred to as performance benchmarks. In considering the types of performance tests to create, it’s important to start by defining all of the possible types of transactions user audience can initiate.

C.Performance Regression Testing:

 Performance regression testing is the process by which the Web application is continuously re-tested and measured against the established benchmark tests to ensure that application performance hasn’t been degraded because of the changes made. These tests should be performed when architectural modifications have been made during the development of the application.

D.Performance Tuning and Acceptance:
This is the final load-testing phase prior to the acceptance testing. In this step, all of the different pieces of the Web application (including the hardware and all load-balancing and software components) are integrated, and performance is validated. Different transaction scenarios of real-life usage are emulated, and the scalability of the final configuration is validated. Testers should ensure that server-clustering techniques provide adequate failover and bandwidth to handle the amount of concurrent users planned. Results from this level of tests will illustrate actual user experience for page response times, error rates, etc.

E.Continuous Performance Monitoring:
24/7 Performance testing must continue even after the application is deployed. Typical thresholds for returned requests range anywhere between six and ten seconds. Anything outside the response time range should trigger some type of alert. The application should be scalable on multiple application servers which is managed by load balancers. Scalability of a web application can be also in terms of having components on various application servers (if COM technology is used).



Print Page | Close Window