Performance Testing Tutorial

What is Performance Testing?

Performance Testing is a software testing process used for testing the speed, response time, stability, reliability, scalability, and resource usage of a software application under a particular workload. The main purpose of performance testing is to identify and eliminate the performance bottlenecks in the software application. It is a subset of performance engineering and is also known as “Perf Testing”.

The focus of Performance Testing is checking a software program’s:

• Speed – Determines whether the application responds quickly
• Scalability – Determines the maximum user load the software application can handle
• Stability – Determines if the application is stable under varying loads

Why is Performance Testing Important?

Features and functionality supported by a software system are not the only concern. A software application’s performance, like its response time, reliability, resource usage, and scalability, do matter. The goal of Performance Testing is not to find bugs but to eliminate performance bottlenecks.

Performance Testing is done to provide stakeholders with information about their application regarding speed, stability, and scalability. More importantly, Performance Testing uncovers what needs to be improved before the product goes to market. Without Performance Testing, the software is likely to suffer from issues such as running slow while several users use it simultaneously, inconsistencies across different operating systems, and poor usability.

Performance testing determines whether software meets speed, scalability, and stability requirements under expected workloads. Applications sent to market with poor performance metrics due to nonexistent or poor performance testing are likely to gain a bad reputation and fail to meet expected sales goals.

Also, mission-critical applications like space launch programs or life-saving medical equipment should be performance tested to ensure that they run for a long period without deviations.

According to Dunn & Bradstreet, 59% of Fortune 500 companies experience an estimated 1.6 hours of downtime every week. Considering the average Fortune 500 company with a minimum of 10,000 employees is paying $56 per hour, the labor part of downtime costs for such an organization would be $896,000 weekly, translating into more than $46 million per year.

Only a 5-minute downtime of Google.com (19-Aug-13) is estimated to cost the search giant as much as $545,000.

It is estimated that companies lost sales worth $1100 per second due to a recent Amazon Web Service Outage.

Hence, performance testing is important. To help you with this process, check out this list of performance testing tools.

Types of Performance Testing

There are primarily six types of performance testing in software testing, which are explained below.

• Load testing – checks the application’s ability to perform under anticipated user loads. The objective is to identify performance bottlenecks before the software application goes live.
• Stress testing – involves testing an application under extreme workloads to see how it handles high traffic or data processing. The objective is to identify the breaking point of an application.
• Endurance testing – is done to make sure the software can handle the expected load over a long period of time. It helps detect issues like memory leaks and resource depletion that only surface during sustained operation.
• Spike testing – tests the software’s reaction to sudden large spikes in the load generated by users. Unlike stress testing, spike testing focuses specifically on how the system handles and recovers from sharp, short-lived traffic surges.
• Volume testing – involves populating a database with a large volume of data and monitoring the overall software system’s behavior. The objective is to check the software application’s performance under varying database volumes.
• Scalability testing – determines the software application’s effectiveness in “scaling up” to support an increase in user load. It helps plan capacity addition to your software system.

Common Performance Problems

Most performance problems revolve around speed, response time, load time, and poor scalability. Speed is often one of the most important attributes of an application. A slow-running application will lose potential users. Performance testing ensures an application runs fast enough to keep a user’s attention and interest. The following are common performance problems where speed is a recurring factor:

• Long load time – Load time is normally the initial time it takes an application to start. This should generally be kept to a minimum. While some applications are impossible to make load in under a minute, load time should be kept under a few seconds if possible.
• Poor response time – Response time is the time it takes from when a user inputs data into the application until the application outputs a response to that input. Generally, this should be very quick. If a user has to wait too long, they lose interest.
• Poor scalability – A software product suffers from poor scalability when it cannot handle the expected number of users or when it does not accommodate a wide enough range of users. Load Testing should be done to be certain the application can handle the anticipated number of users.
• Bottlenecking – Bottlenecks are obstructions in a system that degrade overall system performance. Bottlenecking is when either coding errors or hardware issues cause a decrease in throughput under certain loads. Bottlenecking is often caused by one faulty section of code. The key to fixing a bottlenecking issue is finding the section of code causing the slowdown and trying to fix it there. Bottlenecking is generally fixed by either fixing poor-running processes or adding additional hardware. Some common performance bottlenecks are:
  • CPU utilization
  • Memory utilization
  • Network utilization
  • Operating System limitations
  • Disk usage

How to Do Performance Testing

The methodology adopted for performance testing can vary widely, but the objective for performance tests remains the same. It can help demonstrate that your software system meets certain pre-defined performance criteria. Or it can help compare the performance of two software systems. It can also help identify parts of your software system which degrade its performance.

Below is a generic process on how to perform performance testing.

Step 1) Identify Your Testing Environment

Know your physical test environment, production environment, and what testing tools are available. Understand details of the hardware, software, and network configurations used during testing before you begin the testing process. It will help testers create more efficient tests. It will also help identify possible challenges that testers may encounter during the performance testing procedures.

Step 2) Identify the Performance Acceptance Criteria

This includes goals and constraints for throughput, response times, and resource allocation. It is also necessary to identify project success criteria outside of these goals and constraints. Testers should be empowered to set performance criteria and goals because often the project specifications will not include a wide enough variety of performance benchmarks. Sometimes there may be none at all. When possible, finding a similar application to compare to is a good way to set performance goals.

Step 3) Plan & Design Performance Tests

Determine how usage is likely to vary amongst end users and identify key scenarios to test for all possible use cases. It is necessary to simulate a variety of end users, plan performance test data, and outline what metrics will be gathered.

Step 4) Configure the Test Environment

Prepare the testing environment before execution. Also, arrange tools and other resources. Mirror the production environment as closely as possible to ensure test results are realistic and actionable.

Step 5) Implement Test Design

Create the performance tests according to your test design.

Step 6) Run the Tests

Execute and monitor the tests.

Step 7) Analyze, Tune, and Retest

Consolidate, analyze, and share test results. Then fine-tune and test again to see if there is an improvement or decrease in performance. Since improvements generally grow smaller with each retest, stop when bottlenecking is caused by the CPU. Then you may have to consider the option of increasing CPU power.

Performance Testing Metrics: Parameters Monitored

The basic parameters monitored during performance testing include:

• Processor Usage – the amount of time the processor spends executing non-idle threads.
• Memory use – the amount of physical memory available to processes on a computer.
• Disk time – the amount of time the disk is busy executing a read or write request.
• Bandwidth – shows the bits per second used by a network interface.
• Private bytes – the number of bytes a process has allocated that cannot be shared amongst other processes. These are used to measure memory leaks and usage.
• Committed memory – the amount of virtual memory used.
• Memory pages/second – the number of pages written to or read from the disk in order to resolve hard page faults. Hard page faults occur when code not from the current working set is called up from elsewhere and retrieved from a disk.
• Page faults/second – the overall rate at which fault pages are processed by the processor. This occurs when a process requires code from outside its working set.
• CPU interrupts per second – the average number of hardware interrupts a processor is receiving and processing each second.
• Disk queue length – the average number of read and write requests queued for the selected disk during a sample interval.
• Network output queue length – the length of the output packet queue in packets. Anything more than two means a delay, and bottlenecking needs to be stopped.
• Network bytes total per second – the rate at which bytes are sent and received on the interface including framing characters.
• Response time – the time from when a user enters a request until the first character of the response is received.
• Throughput – the rate at which a computer or network receives requests per second.
• Amount of connection pooling – the number of user requests that are met by pooled connections. The more requests met by connections in the pool, the better the performance will be.
• Maximum active sessions – the maximum number of sessions that can be active at once.
• Hit ratios – this relates to the number of SQL statements that are handled by cached data instead of expensive I/O operations. This is a good place to start for solving bottlenecking issues.
• Hits per second – the number of hits on a web server during each second of a load test.
• Rollback segment – the amount of data that can rollback at any point in time.
• Database locks – locking of tables and databases needs to be monitored and carefully tuned.
• Top waits – monitored to determine what wait times can be cut down when dealing with how fast data is retrieved from memory.
• Thread counts – an application’s health can be measured by the number of threads that are running and currently active.
• Garbage collection – involves returning unused memory back to the system. Garbage collection needs to be monitored for efficiency.

Performance Testing Test Cases Example

Below are sample performance testing test cases:

• Test Case 01: Verify response time is not more than 4 seconds when 1000 users access the website simultaneously.
• Test Case 02: Verify response time of the Application Under Load is within an acceptable range when the network connectivity is slow.
• Test Case 03: Check the maximum number of users that the application can handle before it crashes.
• Test Case 04: Check database execution time when 500 records are read/written simultaneously.
• Test Case 05: Check CPU and memory usage of the application and the database server under peak load conditions.
• Test Case 06: Verify the response time of the application under low, normal, moderate, and heavy load conditions.

During the actual performance test execution, vague terms like acceptable range, heavy load, etc. are replaced by concrete numbers. Performance engineers set these numbers as per business requirements and the technical landscape of the application.

Performance Testing Best Practices

Following established best practices ensures that performance testing delivers reliable results. These guidelines help teams avoid common pitfalls.

• Mirror the production environment – Configure your test setup to reflect production as closely as possible. Differences in hardware or software versions can produce misleading results.
• Design realistic test scenarios – Create test cases that simulate actual user behavior, including think times and concurrent transaction mixes.
• Use percentile-based metrics – Rely on 90th and 95th percentile response times rather than averages alone. Percentiles expose tail-end latency that averages can hide.
• Test early and continuously – Integrate performance testing into the CI/CD pipeline rather than treating it as a final-stage activity.
• Document and baseline results – Record results from every test run. Comparing new results against baselines makes it easy to detect regressions across releases.

How AI is Transforming Performance Testing

Artificial intelligence is reshaping performance testing by automating complex analysis tasks and enabling predictive capabilities. AI-driven tools analyze historical data, detect patterns, and provide actionable recommendations without requiring human intervention at every step.

• Predictive anomaly detection – AI algorithms analyze performance metrics in real time during load tests and flag deviations before they escalate into critical failures.
• Automated root cause analysis – AI-powered tools correlate data across distributed systems to pinpoint the exact components causing performance degradation.
• Intelligent test optimization – Machine learning models identify redundant test scenarios and suggest optimal configurations, reducing execution time while maintaining coverage.
• Self-healing test scripts – AI adapts test scripts when application interfaces change, reducing maintenance overhead for performance test suites.

Performance Testing Tools

There are a wide variety of performance testing tools available in the market. The tool you choose for testing will depend on many factors such as types of the protocol supported, license cost, hardware requirements, and platform support. Below is a list of popularly used testing tools.

• HP LoadRunner – is one of the most popular performance testing tools on the market. This tool is capable of simulating hundreds of thousands of users, putting applications under real-life loads to determine their behavior under expected loads. LoadRunner features a virtual user generator which simulates the actions of live human users.
• JMeter – one of the leading open-source tools used for load testing of web and application servers. It supports multiple protocols and provides extensive reporting capabilities.

FAQs