Solutions > Performance Testing

Performance Testing

Performance testing or software performance testing is becoming the accepted term to cover all forms of volume related non functional testing for software applications. Other terms that may be used to describe very similar activity are: Load Testing, Stress Testing, Volume Testing, Capacity Testing and others.

What is Performance Testing?

Performance testing is an essential part of the software development process and provides an evaluation of the application under test while it is under realistic, accurate & relevant load. The output from a performance test will definitively state:

• Page response: The response time a user can expect to see, that is how long a user / customer will wait to see the screen they requested load on their screen.
• Concurrent virtual users: The number of virtual users the application was able to deal with. This will either be the number of users specified at the beginning of the test, or a number lower than that if the application was not able to handle load. In load testing terms users are talked about as concurrent users i.e. users that are using the application simultaneously, these users may be downloading a screen / page or simulating the reading / digestion of a screen or page.
• Transaction rate: The number of transactions the application was able to process in a given period. For example if an insurance company expects to sell 100 insurance policies in its busiest hour then the site needs to be able to support that.

The transaction rate and page response times are a product of the number of users on the site and the speed at which those users using the site.

Recommended Performance Testing Methodology

Quotium recommend a structured methodology for performance testing that can be described as follows:

Phase 1: Test plan development

This phase is crucial to ensure that the test adheres to the business requirements. It should contain all information necessary for the proper conduct of the project including scope and objectives. It must answer who, what, when, how and where.
It should also document in detail the transactions to be simulated which should be those which pose the highest risk to the business in the event of failure and the most commonly used transactions.
Typically 5-10 transactions are pinpointed for performance testing.

Phase 2: Preparation

All elements necessary to achieve the objectives should be prepared at this point.
This includes:

• Installation and configuration of the test environment in line with the objectives

• Installation and preparation of testing tools

• Preparation of data on the test system

• Preparation of test data files that will be required by the transactions

• Configuration of any monitoring parameters and permissions

Phase 3: Scenario and Script Creation

Capture of business transactions as scripts to simulate real user activity is done with the performance testing tool. Once captured these scripts should be verified and parameterised to use data files and dynamic parameters to enable them to accurately simulate multiple unique users performing multiple unique transactions against the system under test.

Scenarios should be set up reflecting the load models defined in the test plan; each scenario will contain one or many scripts.

Phase 4: Execution

Execution should take place at a defined time in line with the project plan, all phases before this phase must be complete before this phase can take place.
As execution will potentially be generating large amounts of load it may best to perform this phase out of hours unless a dedicated test system is available.
Once complete it may be necessary to regenerate or rewind databases on the test system and their complimenting data sets for use by the test tool to enable further runs of the test execution.

Phase 5: Results Analysis

Detailed analysis of results is required with the aim of highlighting (where seen) the cause of possible points of contention on the target architecture (test system) and to validate whether the system conforms quality of service requirements in terms of performance and availability.
This phase can be cyclical to enable a study of the efficacy of the optimisations made.
When the testing project is complete results should be made available in a report and a presentation of results should be made to key players in the project.

Other sources of information can be found on Wikipedia : http://en.wikipedia.org/wiki/Software_performance_testing