Performance testing is a whole other animal in the world of good development.
Read on for a brief journey to the wild side of testing.
In functional testing, detailed requirements are needed that allow you to consider whether the issue found is a bug or a feature. However, in performance testing, it varies as one cannot specify “pass” or “fail”. You simply gather as much information as possible and provide it to the customer.
Bottom line-> the main goal of performance testing is gathering information about system performance and providing it to the customer.
So, performance testers must obtain as much information as possible. And for this purpose there are several types of performance testing.
Load testing is the process of applying demands on a system or device and measuring its response. Load testing is performed to find out a system’s behavior under both normal and peak load conditions.
It helps to specify the extreme operating volume of an application as well as any bottlenecks in order to segregate the component causing degradation.
In other words. Find the troublemaker.
When a load placed on the system is raised beyond standard usage patterns in order to check the system's reaction at unusually extreme or top loads, this is stress testing. The load is usually so great that error conditions are the expected result, although no clear boundary exists when an activity ceases to be a load test and becomes a stress test.
Stress testing is a type of testing that is used to discover the stability of a given system or object. It involves testing beyond customary operational capacity, often to a breaking full stop, in order to examine the results.
When conducting stress tests take note of:
- How the system recovers after ending a period of stress load. Generally, after a short period of time that the system is given peak load, and after that – normal load. As you remember, determination of peak load is the purpose of load testing. After the stress load is over, the system should return to normal state. It means that we should see normal response time again.
- How long the system is able to work under the allocated stress load. It's important to determine the capacity or amount of stress that causes the system to fail.
Note,the stress load is not the load under which system fails. This is the load under which system is still working. But, if we increase the load for some value – it fails.
The purpose of volume testing is to determine system performance while increasing data volume in a database.
Here we’re interested in the same parameters, e.g. in general – time of operation execution depending on quantity of users, but in this case, we execute tests with huge volumes of data. Imagine a system that generates financial reports. Works great managing data over a 6 month period. However, the system works at a lower capacity when managing data of a 12 month period and fails managing the vast data of a 24 month period.
Always pay attention to any locations where vast volumes of data are queried or where complex SQL queries are executed. To find these places you can take modules where a lot of data is printed to screen or talk to developers to determine where larger SQL requests reside.
Information needed for volume testing:
- Determine locations where complex SQL queries are executed
- Place a huge amount of data onto the database
- Execute load testing
- Execute stress testing, if needed
The purpose of stability testing is the assessment of performance during a prolonged load. In this scenario, a normal load should be applied to the system Response time in stability testing is less important We give it a 2 rating (out of 2).
The goal is to determine memory leaks or other problems that will not permit a stable work flow for a long period of time.
Although times of responses may also be useful for analyzing results, they can also show the degree of degradation of the system.
In tthe scenario that the system is still going strong after running extremelly long test runs, but the response time constantly increased during the test, you have got problems. Bug ones, like, huge problems.
Your test was too short to view a complete fail of the system. Then you must increase the testing time.
Failing, in this scenario= success!
Join the first JMeter Meetup! Wednesday, May 9, 2012, in the Bay Area,CA. RSVP today to save your spot!