Skip to content

JMeter

  • in JMeter
  • 4 min read

Producing JMeter Tests from OpenAPI

Swagger in conjunction with OpenAPI is a way for REST API’s to be build, documented and consumed. It is defined in either YAML or JSON. OpenAPI and Swagger are both open source, and their use is commonplace amongst development teams and can make the life of a performance tester a lot easier as it allows us to build JMeter tests directly from the definition of the endpoints.

The object of this post is to look at how we can produce JMeter tests directly from a Swagger definition. If you are unfamiliar with Swagger it is worth spending some time reading the online overview as it will provide a good understanding of how the specification works.

Now clearly in order for you to leverage the benefits of building performance tests from Swagger definitions you are going to need to have your development teams use it to describe the API contract for service they are producing, but for the purposes of this post we will use a test definition called Swagger Petstore.

  • in JMeter
  • 5 min read

Soap Requests in JMeter

We are going to look at how to test SOAP Services using JMeter and some of the issues that you can face when testing these services.

We are going to provide some basic principles of SOAP in this post and while some requests can be complex in their definition and structure testing them is relatively straightforward.

The best approach to performance testing SOAP Requests is to discuss what the structure of the message is with your development teams or 3rd parties should the service be hosted external to your organisation. Fundamentally it is no different to any other HTTP Request in that you need:

  • URL of the service,
  • Payload,
  • Request Header (including any authorisation).
  • in JMeter
  • 13 min read

JMeter: test as code solutions

The rise of the CI/CD methodologies and frameworks have shaped the daily work of application developers and testers. It allowed for the creation of the DevOps model. DevOps culture demanding "everything as code", modern infrastructure tooling has grown to drive the management and configuration of infrastructure components "as code" alike.

From a load testing point of view, we already detailed how to Shift left with JMeter in this blog: Moving the JMeter testing to an earlier stage in the project lifecycle can be done by running load tests saved in a GIT repository from Jenkins. At OctoPerf we think that JMeter is one of the best tools to implement an Agile and Push to Production strategy. We explained how this approach can be useful how in a Load Test Driven Development process.

To sum up, JMeter load testing can efficiently be executed on automation servers but:

  • The JMX format is not VCS friendly, making it hard to work on as a team,
  • Using an external graphical application might be a barrier for programmers.

Application developers know that code and associated configuration files can easily be shared, versioned and reused. It's about time we **take "testing as code" seriously and bridge the gaps between development and load testing activities and teams.

The aim of this blog post is to do an overview of available solutions to do "Jmeter as code" using an existing JMX File.

  • in JMeter
  • 8 min read

Scalability Testing

We are going to look at scalability testing in this Blog Post. On paper scalability testing is simple because all you are doing is increasing the load, but there are some common pitfalls that can be easily avoided. So you need to really understand what you are trying to achieve before you start.

Basic Principles

Let’s start with the basic principles: A scalability test is the process of systematically increasing load on your application under test until

  • You reach your goal in terms of desired load,
  • The system starts to become unresponsive.

If you want to get a clear picture of whether your application does scale then it is important to run your scalability test on an environment that is consistent with production, or how you expect production to be.

Clearly one of the objectives of a scalability test is to size the environment so you must also have the flexibility to increase the resources in the environment in which you are running this test.

  • in JMeter
  • 9 min read

Chaotic Performance Tests with JMeter

Building performance tests that conform to a very specific level of load and concurrency is a standard approach to performance testing.

You determine your peak levels of load and concurrency, and you build a test that meets this.

You build soak test and scalability tests that conform to pre-determined levels of load and concurrency, and you execute these alongside the other scenarios you build to meet your performance requirements.

This is the correct approach and conforms to most organisations approach to performance testing and something you should always do; but in addition its also a good idea to build performance tests that change on each execution and put your application under a random ever changing load profile as it is not uncommon for application usage to change when new features are added or if migrating to a new solution therefore randomising your performance testing can provide you useful information on how your application will react to conditions that do not conform to your standard approach.

This blog post will look at how you can make your JMeter tests more chaotic using a variety of samplers, timers and a beanshell server.