Performance testing is a form of software testing that focuses on how a system running the system performs under a particular load. This type of test is not about finding software bugs or defects. Different performance testing types measures according to benchmarks and standards. Performance testing gives developers the diagnostic information they need to eliminate bottlenecks.
In this article you will learn about:
- Types of performance testing
- Steps on how to run performance testing
- Performance testing metrics
- And software testing best practices
Types of Performance Testing for Software
First, it’s important to understand how software performs on users’ systems. There are different types of performance tests that can be applied during software testing. This is non-functional testing, which is designed to determine the readiness of a system. Functional testing focuses on individual functions of software.)
Load Testing
Load testing measures system performance as the workload increases. That workload could mean concurrent users or transactions. The system is monitored to measure response time and system staying power as workloads increase and test whether workload parameters fall within normal working conditions.
Stress Testing
Unlike load testing, stress testing — also known as fatigue testing — is meant to measure system performance outside of the parameters of normal working conditions. The software is given more users or transactions that can be handled. The goal of stress testing is to measure the software stability. At what point does software fail, and how does the software recover from failure?
Spike Testing
Spike testing is a type of stress testing that evaluates software performance when workloads are substantially increased quickly and repeatedly. The workload is beyond normal expectations for short amounts of time.
Endurance Testing
Endurance testing — also known as soak testing — is an evaluation of how the software performs with a normal workload over an extended amount of time. The goal of endurance testing is to check for system problems such as memory leaks. A memory leak occurs when a system fails to release discarded memory. The memory leak can impair system performance or cause it to fail.
Scalability Testing
Scalability testing is used to determine if software is effectively handling increasing workloads by gradually adding to the user load or data volume while monitoring system performance. Also, the workload may stay at the same level while resources such as CPUs and memory are changed.
Volume Testing
Volume testing determines how efficiently software performs with large projected amounts of data. Also known as flood testing, volume tests flood the system with data.
Throttle Testing
Throttle testing focuses on scenarios where users with poor connection speed might interact with the software to see how the software would respond. A common way to test this is to limit the connection speed of users and have them use the software.
Most Common Problems Observed in Performance Testing
During software performance testing, developers look for performance symptoms and issues. Speed issues — slow responses and long load times for example — often are observed and addressed. Other performance problems can be observed:
- Bottlenecking — This occurs when data flow is interrupted or halted because there is not enough capacity to handle the workload.
- Poor scalability — If software cannot handle the desired number of concurrent tasks, results could be delayed, errors could increase, or other unexpected behavior could happen that affects:
- Disk usage
- CPU usage
- Memory leaks
- Operating system limitations
- Poor network configuration
- Software configuration issues — Often settings are not set at a sufficient level to handle the workload.
- Insufficient hardware resources — Performance testing may reveal physical memory constraints or low-performing CPUs.
Seven Performance Testing Steps
Image credit Gateway TestLabs
Also known as the test bed, a testing environment is where software, hardware, and networks are set up to execute performance tests. To use a testing environment for performance testing, developers can use these seven steps:
1. Identify the Testing Environment.
Identifying the hardware, software, network configurations, and tools available allows the testing team to design the test and identify performance testing challenges early on. Performance testing environment options include:
- Subsets of production systems with fewer servers of lower specification
- Subsets of production systems with fewer servers of the same specification
- Replicas of production systems
- Actual production systems
2. Identify Performance Metrics.
In addition to identifying metrics such as response time, throughput, and constraints, identify what are the success criteria for performance testing.
3. Plan and Design Performance Tests.
Identify performance test scenarios that take into account user variability, test data, and target metrics. This will create one or two models.
4. Configure the Test Environment.
Prepare the elements of the test environment and instruments needed to monitor resources.
5. Implement Your Test Design.
Prepare the tests for execution.
6. Execute Tests.
In addition to running the performance tests, monitor and capture the data generated.
7. Analyze, Report, Retest.
Analyze the data and share the findings. Run the performance tests again using the same parameters and different parameters.
What Performance Testing Metrics are Measured
Metrics are needed to understand the quality and effectiveness of performance testing. Improvements cannot be made unless there are measurements. Two definitions that need to be explained:
- Measurements — The data being collected such as the seconds it takes to respond to a request.
- Metrics — A calculation that uses measurements to define the quality of results such as average response time (total response time/requests).
There are many ways to measure speed, scalability, and stability but each round of performance testing cannot be expected to use all of them. Among the metrics used in performance testing, the following are used most often:
Response Time
Total time to send a request and get a response.
Wait Time
Also known as average latency, this tells developers how long it takes to receive the first byte after a request is sent.
Average Load Time
The average amount of time it takes to deliver every request is a major indicator of quality from a user’s perspective.
Peak Response Time
This is the measurement of the longest amount of time it takes to fulfill a request. A peak response time that is significantly longer than average may indicate an anomaly that will create problems.
Error Rate 
This calculation is a percentage of requests resulting in errors compared to all requests. These errors usually occur when the load exceeds capacity.
Concurrent Users
This is the most common measure of load — how many active users at any point. Also known as load size.
Requests Per Second
The number of requests handled.
Transactions Passed/Failed
A measurement of the total number of successful or unsuccessful requests.
Throughput
Measured by kilobytes per second, throughput shows the amount of bandwidth used during the test.
CPU Utilization
The amount of time the CPU needs to process requests.
Memory Utilization
The amount of memory needed to process the request.
Performance Testing Best Practices
Perhaps the most important tip for performance testing is testing early, and testing often. A single test will not tell developers all they need to know. Successful performance testing is a collection of repeated, smaller tests:
- Test as early as possible in development. Do not wait and rush performance testing as the project winds down.
- Performance testing isn’t just for completed projects. There is value in testing individual units or modules.
- Conduct multiple performance tests to ensure consistent findings and determine metric averages.
- Applications often involve multiple systems such as databases, servers, and services. Test the individual units separately as well as together.
Image credit Varun Kapaganty
In addition to repeated testing, performance testing will be more successful by following a series of performance testing best practices:
- Involve developers, IT, and testers in creating performance testing environments.
- Real people use the software that is undergoing performance testing. Determine how the results will affect users not just test environment servers.
- Go beyond performance test parameters. Develop a model by planning a test environment that takes into account as much user activity as possible.
- Baseline measurements provide a starting point for determining success or failure.
- Performance tests are best conducted in test environments that are as close to the production systems as possible.
- Isolate the performance test environment from the environment used for quality assurance testing.
- No performance testing tool will do everything needed. And limited resources may restrict choice even further. Research performance testing tools for the right fit.
- Keep the test environment as consistent as possible.
- Calculating averages will deliver actionable metrics. There is value in tracking outliers also. Those extreme measurements could reveal possible failures.
- Consider the audience when preparing reports that share performance testing findings. Also, include any system and software changes in reports.
Five Common Performance Testing Mistakes
Some mistakes can lead to less-than-reliable results when performance testing:
- Not enough time for testing.
- Not involving developers.
- Not using a QA system similar to the production system.
- Not sufficiently tuning software.
- Lack of or poor troubleshooting plan.
10 Performance Testing Missteps to Avoid
Performance Testing is the Last Step in Development.
As mentioned in the section on performance testing best practices, anticipating and solving performance issues should be an early part of software development. Implementing solutions early will be more cost effective than major fixes at the end of software development.
More Hardware Can Fix Performance Issues.
Adding processors, servers or memory simply adds to the cost without solving any problems. More efficient software will run better and avoid potential problems that can occur even when hardware is increased or upgraded.
The Testing Environment is Close Enough.
Conducting performance testing in a test environment that is similar to the production environment is a performance testing best practice for a reason. The differences between the elements can significantly affect system performance. It may not be possible to conduct performance testing in the exact production environment, but try to match:
- Hardware components
- Operating system and settings
- Other applications used on the system
- Databases
What Works Now, Works Across the Board.
Be careful about extrapolating results. Don’t take the small set of performance testing results and assume that they will be the same when elements change. Also, the same is true in the opposite direction. Do not infer minimum performance and requirements based on load testing. All assumptions should be verified through performance testing.
One Performance Testing Scenario is Enough.
Not every performance problem can be detected in one performance testing scenario. However, resources do limit the amount of testing that can happen. In the middle are a series of performance tests that target the riskiest situations and have the greatest impact on performance. Also, problems can arise outside of well-planned and well-designed performance testing. Monitoring the production environment also can detect performance issues.
Testing Each Part Equals Testing the Whole System.
While it is important to isolate functions for performance testing, the individual component test results do not add up to a system-wide assessment. However, it may not be feasible to test all the functionalities of a system. A complete-as-possible performance test must be designed using the resources available. But be aware of what has not been tested.
What Works for Them, Works for Us.
If a given set of users does experience complications or performance issues, do not consider that a performance test for all users. Use performance testing to make sure the platform and configurations work as expected for as many user scenarios as possible.
Software Developers are Too Experienced to Need Performance Testing.
Lack of experience is not the only reason behind performance issues. Mistakes are made, even by developers who have created issue-free software in the past. Many more variables come into play when applications hit production and multiple concurrent users are in the system.
A Full Load Test Tells Everything.
It’s tempting to just run a test at the total load to find all the performance issues. Unfortunately, that kind of test tends to reveal so many performance issues that it’s hard to focus on individual solutions. Starting at a lower load and scaling up incrementally may seem like an unnecessarily slow process, but it produces results across a variety of scenarios that are more efficient to troubleshoot. Tools such as LoadView make scaling load testing simpler, and on-demand.
Test Scripts are Actual Users.
Make sure the test automation is using the software in ways that real users would. This is especially important when performance test parameters are changed.
Performance Testing and Software Testing With Stackify
Performance and software testing can make or break your software. Before launching your application, make sure that it is fool-proof. However, no system is ever perfect, but flaws and mistakes can be prevented.
Testing is an efficient way of preventing your software from failing. Now that you’ve learned the different types of performance testing, steps, and best practices for proper testing, all you need now is a testing tool to help you achieve optimal application performance.
Stackify Retrace helps developers proactively improve the applications they create and monitor. Retrace aids developers in identifying bottlenecks of the system and constantly observes the application while in the production environment. This way, you can constantly monitor how the system runs while improving application performance. Start your free Stackify Retrace trial today and see how a full life-cycle APM solution improves performance testing and the end user experience.
Additional Resources on Performance Testing
- Performance Testing Guidance for Web Applications (Microsoft)
- Performance Testing Checklist Packet (SmartBear PDF)
- “Perfect Software and Other Illusions About Testing” (Book by Jerry Weinberg)
- The Tester (Special Interest Group In Software Testing (SIGIST) newsletter)
- Performance Testing – Software Testing (Geeks for Geeks)
