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).
|