The Blog is a series of articles about performance/Load/Stress testing It covers all the phases of a performance testing cycle starting from requirement gathering to bottleneck identification and Performance Re-engineering. We will also try to cover multiple tools (Jmeter, LR, RPT, VSTS, SOAP UI etc) and technologies (Like SOA, .net, Java etc) Some more Posts will be uploaded soon :)

Total Pageviews

Powered by Blogger.

Follow by Email

Recent

Comment

Search This Blog

Followers

Friday, April 4, 2014

Types of Performance Testing




Types Of Performance Testing
Types of Performance Testing

Performance testing basically revolves around three "S"  Speed, Stability and Scalability

Speed : Speed can be simply termed as how fast is my application performing.
To test speed we perform  Load test, Volume Test and Spike Tests 

Stability: An application is said to be stable if
a) The application performance does not degrade with time and
b) In case of breakdown (happen exceptionally) the data should not be lost and application should easily recover to its original state, without any code changes.
To test stability we perform Endurance (soak) test and Stress Test

Scalability: Scalability is termed as the load handling capacity of the application at an increased user load.

Scalability tests will give you answer to this question
Will my application be able to handle the increased user load after say 5 years or 10 years?
Scalability tests provide us the statistics that would help us in projecting the server hardware that would be required in future to handle the increased user load.

To check scalability Capacity Tests are performed.


========================================================================

Now we will talk about the various terms mentioned above.

Load Test:  The load tests are performed at the normal (expected* user load) load to get a clear picture of the application performance when the application will be made available to the target audiences.

* Normal or expected user load is the load projected by the business team ( should be realistic)

Volume Tests: Volume tests are related to the volume of data (i.e no of records fetched, displayed or processed etc).

  Below are some of the situations where Volume tests should be performed:
  • Batch process testing: the results for a batch process could be something like, the daily batch takes 15 minutes to process 10,000 records and 1 hour to process 30,000 records. (Here the decrease in the rate of record processing can be due to some performance bottleneck and may require a root cause analysis)
  • Generating/Displaying a Report: the statistics to be captured would be something like How much time the application/process takes to download/display the report with 1000 records, 5000 records etc (based on the expected volume of records).
  • Database Synch Process:Consider a component that fetches data from a front end system's DB and inserts it into corresponding fields into the back-end database.
           How often this sych should be performed (?) can be answered based on statistics like how much time            it would take to Synchronize say 100, 500, 1000, 5000 records.


Spike Tests: The spike tests are performed to check the application performance under short spikes of user load increased beyond the expected values.
These tests make sure that application will be able to handle sudden burst of users.


Endurance (Soak) Tests: When the load tests are run at for a long duration (the duration can be 5 hours to 100 hours or more ) the tests are called as soak tests.
Once the application goes live it is expected to perform consistently for many months or years hence Soak tests becomes important as these tests provide us statistics to say that the application performance will degrade with time or not.


Stress Test: the stress tests are performed to test the application performance at user loads much beyond  the expected user load. These tests provide us the statistics about the breakpoint of the application and how application performance degrades under exceptionally high user load.
The expectation from the application is to degrade gracefully even at very high user loads.

The best case for the application is that even during exceptionally high user load rather than crashing, the application should give proper error messages (e.g currently we are experiencing high load so please try after some time) and should keep responding to some minimum users. 


Capacity test: The dictionary meaning of capacity is "the maximum amount that something can contain"
Hence capacity tests are aimed at assessing the load handling capacity of the current hardware and capturing the resource consumption statistics in such a way that the hardware requirements for an increased user load can be projected.

We will take one example how hardware requirements can be projected.

Assuming that the current server's hard disk is specified to handle 400 IOps and the application consumes 200 IOps when 100 transaction are performed per second, Implying 2 IOps per transaction
This leads us to a conclusion that for sustaining 400 transaction/sec we would require one more hard disk with the same capacity i.e. 400 IOps.


Bibliography


Performance Testing Guidance for Web Applications

J.D. Meier, Carlos Farre, Prashant Bansode, Scott Barber, and Dennis Rea
Microsoft Corporation


User Experience, Not Metrics

R. Scott Barber


1 comment: