Skip to content


Volume Testing

In this post we are going to look at the importance of volume testing. We are going to consider how this type of non-functional test can have a significant impact on your size and scale your production environment based on evidence this test provides. We are going to look at some real-world examples of how getting your volume testing correct will ensure that your environments are not oversized or undersized. Both these scenarios have a cost which is both financial and potentially reputational.

Definition of volume testing

From Wikipedia.

Volume testing belongs to the group of non-functional tests, which are a group of tests often misunderstood and/or used interchangeably. Volume testing refers to testing a software application with a certain amount of data to assert the system performance with a certain amount of data in the database. Volume testing is regarded by some as a type of capacity testing, and is often deemed necessary as other types of tests normally don't use large amounts of data, but rather typically use small amounts of data.

We use this test to understand the impact of large data volumes on your application under test. Larger data volumes in the database can:

  • Increase the query time of your SQL statement which impact response times,
  • Impact the amount of CPU or memory your database uses and therefore you can use this test to size this component,
  • Impact the size of responses to end user and API requests, with search requests being an example, this impacts application CPU and Memory.

A volume test looks to not only understand performance of the SQL with an indicative sized database. But also looks to understand how much CPU and Memory is required across you full stack to support peak volumes of load and concurrency. The results you gather from this type of non-functional testing is important in determining how you application needs to be sized in production to support future data volumes.

From Performance Tests to Sanity Tests with JMeter

In this blog post we are going to look at how we can use our performance tests to act as Sanity Test. We have touched upon the subject in one of our blog posts on the hidden benefits or performance testing.

This post will however look to provide more detail on the subject and provide guidance on how you can accomplish this.

Aim of this post

We are not suggesting that you write a set of JMeter tests to act as sanity tests for our application under test as that would not be that beneficial. There are much better ways to write sanity tests for applications in the form of Unit Tests in code or by using a functional testing tool such as Playwright.

What we are going to investigate is how you could use already existing JMeter tests to also support Sanity testing. If you have a set of performance tests or are in the process of creating a set of performance tests for a particular project or programme, then to build them in such a way that they can double as Sanity tests would be beneficial.

We will look at how when building a test, you could also add some additional logic to give your performance tests the capability of supporting an application Sanity test. If you have a set of tests already that you have built, then by following this post will show you how these existing assets can be updated to support Sanity testing.

All tests will be written in JMeter.

Defining and Maintaining Performance Test Coverage

In this post we are going to look at performance test coverage. What functionality to performance test can range from very little to most of the application under test and both are valid under the right circumstances. We have talked about what to performance test in other posts available in the OctoPerf Blog but as part of a wider post about performance testing rather than as the subject of the post. This is an important topic and deserves a post devoted to it.

We are going to discuss the performance coverage topic through a series of questions which we will explore in detail. These questions are:

Postman Collection to JMeter

In this blog post we are going to look at how we take a postman request or collection and translate these into JMeter tests. When web services are being build it is common for Postman to be used to test the endpoints. This is done by:

  • Development teams
  • Wider Quality Assurance community
  • Business users
  • Product owners

the list goes on.

What naturally happens during programmes where web services are part of the design is that postman requests and collections are built and grow to support all manner of requirements. Using these collections to quickly build your performance tests can save you a significant amount of time and effort when it comes to understanding the web service you are testing along with the payload that the web service expects.

You will find that in some cases you can inherit a fully functioning set of web service requests that support all your requirements from a performance testing perspective.

Build your own JMeter Docker Image and execute your Performance Test

If you'd like to run load tests in a simple way, and possibly share them, while benefiting from a simplified configuration, with a focus on writing your test plan, and its test typology, this article is for you!

Docker offers virtualization services that simplify the replication of working environments.

Furthermore, each virtualized service is isolated from unrelated services on other containers or the host machine, ensuring portability across host machines and the network.

Using JMeter within a Docker container offers several advantages :

Portability :

Docker enables the creation of lightweight and portable containers that can run on any Docker-compatible system, whether it's Linux, macOS, or Windows. This simplifies the deployment and management of JMeter, avoiding compatibility issues related to different system configurations.

Isolation :

Docker containers provide an isolated environment for running applications, meaning JMeter's dependencies and runtime environment are encapsulated within the container. This reduces potential conflicts with other applications or system components.

Ease of deployment :

With Docker, distributing and deploying JMeter across multiple machines or environments is straightforward.

You can create a Docker image containing JMeter and distribute it to your team or various test environments, streamlining the deployment process.

Version management :

By using Docker, you can version your Docker images containing JMeter, facilitating the management of different versions of JMeter used in your tests. You can also share these images via public or private Docker registries