Let's take a look at the six most popular types of performance tests that answer these questions and others.

Performance Testing 101

Performance tests measure how a system behaves in various scenarios, including its responsiveness, stability, reliability, speed and resource-usage levels. By measuring these attributes, development teams can be confident they're deploying reliable code that delivers the intended user experience.

Waterfall development projects usually run performance tests before each release, but many Agile projects find it better to integrate performance tests into their process to they can quickly identify problems. For example, LoadNinja makes it easy to integrate with Jenkins and build load tests into continuous integration builds.

Load tests are the most popular performance test, but there are many tests designed to provide different data and insights.

Load Testing

Load tests apply an ordinary amount of stress to an application to see how it performs. For example, you may load test an ecommerce application using traffic levels that you've seen during Black Friday or other peak holidays. The goal is to identify any bottlenecks that might arise and address them before new code is deployed.

In the DevOps process, load tests are often run alongside functional tests in a continuous integration and deployment pipeline to catch any issues early. 

Stress Testing

Stress tests are designed to break the application rather than address bottlenecks. It helps you understand its limits by applying unrealistic or unlikely load scenarios. By deliberately inducing failures, you can analyze the risks involved at various break points and adjust the application to make it break more gracefully at key junctures.

These tests are usually run on a periodic basis rather than within a DevOps pipeline. For example, you may run a stress test after implementing performance improvements.

Spike Testing

Spike tests apply a sudden change in load to identify weaknesses within the application and underlying infrastructure. These tests are often extreme increments or decrements rather than a build-up in load. The goal is to see if all aspects of the system, including server and database, can handle sudden bursts in demand.

These tests are usually run prior to big events. For instance, an ecommerce website might run a spike test before Black Friday.

Endurance Testing

Endurance tests, also known as soak tests, keep an application under load over an extended period of time to see how it degrades. Oftentimes, an application might handle a short-term increase in load, but memory leaks or other issues could degrade performance over time. The goal is to identify and address these bottlenecks before they reach production.

These tests may be run parallel to a continuous integration pipeline, but their lengthy runtimes mean they may not be run as frequently as load tests.

Scalability Testing

Scalability tests measure an application's performance when certain elements are scaled up or down. For example, an e-commerce application might test what happens when the number of new customer sign-ups increases or how a decrease in new orders could impact resource usage. They might run at the hardware, software or database level.

These tests tend to run less frequently since they’re designed to diagnose specific issues rather than broadly help identify bottlenecks within the entire application.

Volume Testing

Also known as flood tests, measure how well an application responds to large volumes of data in the database. In addition to simulating network requests, a database is vastly expanded to see if there's an impact with database queries or accessibility with an increase in network requests. Basically it tries to uncover difficult-to-spot bottlenecks.

These tests are usually run before an application expects to see an increase in database size. For instance, an ecommerce application might run the test before adding new products.

LoadNinja Makes These Tests Easy

Most performance tests involve recording HTTP/S protocol traffic and maintaining massive scripts that are difficult to read and update. If you're testing dynamic data, you may need to capture and store dynamic values from the server to use in later requests. The entire process quickly becomes too time-consuming and brittle to use within an Agile environment.

LoadNinja makes it easy to record and playback browser-based tests within minutes with no coding or correlation. Unlike protocol-based tests, these tests run on tens of thousands of real browsers in the cloud to provide realistic data that incorporates HTML/CSS rendering and JavaScript execution time, rather than just server response times.

LoadNinja’s Recorder Eliminates the Need to Create Scripts – Source: LoadNinja

Navigation timings and other data are sourced from real browsers to make debugging a lot faster. For instance, test engineers or developers can dive into a specific virtual user that experienced an issue and debug directly from the DOM, providing much greater insights than protocol-based tests. This can speed up the entire development process.

LoadNinja also makes it easy to integrate with common DevOps tools, such as Jenkins and Zephyr for Jira. That way, you can ensure that load tests become a natural part of the development lifecycle while making it easier for everyone to access the insights.

The Bottom Line

Performance tests are designed to help you understand how your application responds when it’s most needed. While load tests are the most popular performance tests, you may need to use other tests to answer key questions and incorporate them into your development lifecycle. Fortunately, LoadNinja makes that process easy.