Skip to content

JMeter

Using custom JAR files in JMeter

JMeter has many plug-ins and downloadable JAR Files you can use to support your testing, it is also possible to write your own custom Jar files and use these as well.

Why would you want to do that, you may say, well whilst it is unlikely that you would need to create anything too complicated.

You may feel the need to create utilities to support your own in-house performance testing or just something to make your testing process easier.

We could easily write a custom Jar file to push the results of test run to any reporting tools your organisation uses, if they expose their API's, at the end of the test execution cycle.

Alternatively, you could write something that sends your results to a mail server or web server for the purposes of results distribution.

For the purposes of this post lets imagine a situation where your company has a dashboard technology that displays the status of development builds or testing progress through a series of APIs, there are many examples of these type of status boards and they are common in many technology departments.

And let’s write a JAR file to output our JMeter test results in the form of JSON which can be sent to this imaginary endpoint we will then use the Custom Class we create in a JMeter test script.

Let’s get started!

Asynchronous API Performance Testing with JMeter

The principles behind performance testing API’s does not differ from the principles behind the performance testing of any application.

Many API’s however are Asynchronous and a valid response from the API does not necessarily mean the transaction is complete which can cause a problem when measuring the performance of API’s.

There are however ways around this and we will explore these in this post.

Sample JMX and DB files for this blog post are available for download:

Simple Way to Create Complex JMeter Scenarios

Creating complex performance testing scenarios in JMeter can be a complicated but necessary problem you will encounter as you build tests to mirror real user behaviour in your testing.

There are many add-ins that can support you in the creation of these scenarios. Which is good if they do what you want them to do. But if you want the flexibility to build tests without the limitations of 3rd party add-ins then there are several techniques you can use which come with the standard JMeter install.

All you require is a bit of imagination, a basic understanding of Groovy and the JMeter Switch Controller.

The resulting JMX script can be downloaded here.

JMeter Beanshell Server

The Beanshell Interpreter in JMeter can act as a server which as stated in the JMeter documentation is accessible by telnet or http.

So what, I hear you say, well this can be useful and we will explore some of these uses in this Blog Post.

Before we move on the definition of a Beanshell can be found on the official Web Site.

But at a high level:

You can use BeanShell interactively for Java experimentation and debugging as well as to extend your applications in new ways. Scripting Java lends itself to a wide variety of applications including rapid prototyping, user scripting extension, rules engines, configuration, testing, dynamic deployment, embedded systems, and even Java education.

In short, BeanShell is dynamically interpreted Java, plus a scripting language and flexible environment all rolled into one clean package.

So effectively the Beanshell can dynamically change properties or variables while the test is running.

Managing data during performance testing

We are going to talk about data in this blog post, predominately test data required for performance testing.

This is something that makes the life of a performance tester extremely difficult and awkward as because of the huge quantities required, in the right state, that match the criteria required for your test to run.

We often have to approach the use of large quantities data for the purpose of performance testing in a number of ways:

  • Use a small subset,
  • Ask business users or functional test teams for a set of data, that may become redundant after an execution of your testing because you may alter the state during testing making this data short lived and therefore requests to the business become frequent,
  • Restore your database after each test iteration, this may not be possible if the database is shared and is certainly not agile,
  • Create your own data before the tests start, this can be long-winded and may require multiple legacy system interaction or overnight batch processes to get the data in the right state.

Fear not, help is at hand from your friends at OctoPerf.

As we have seen above there are a number of valid ways to get data but the one we are going to explore and the one that make our tests reusable and agile is to query the database of the application under test, or any supporting application databases, to retrieve usable data using SQL this way we avoid our defined pitfalls above by:

  • Taking as much data as we need from our databases,
  • Not needing to ask the business because we have the relevant SQL at our disposal,
  • Not needing to restore the database as we just take more of the data we need from our data-sources
  • Avoid creating your own data using the user interface.

Ok, we need to caveat this if you have a performance test environment that does not contain a copy of production data, or artificially constructed representative data volumes then this approach will not work but you could argue that performance testing on a system that does not have production quantities of data is not representative so lets assume you do, because I think most will.

Before moving on there is obviously the ability, in JMeter, to create random data that conform to any number of rules (Dates, Random Strings or Integers, Values from Arrays, a value from any number of the JMeter native, or 3rd party, function libraries.

But if you need data that exists in your application under test to either use, update or delete then you need to know the values before testing starts and this is what we are looking at in this post.