When building performance tests, we all understand the value of using properties or variables to store static values outside of our tests.
This ensures that any changes to these values need only be made in one place rather than having to make these changes in many tests.
Sometime though you may have inherited a suite of JMeter tests, or you were **
under pressure to develop these tests** and in order to do so you hardcoded values in your tests. This means that if
anything changes, an endpoint or the server-name or even the payload of a sampler then you need to make changes to these
static values in your tests.
We are going to discuss how we can test the Lightweight Directory Access Protocol (LDAP) using JMeter, the principles of LDAP can be quite complicated as their origins come from the X500 specification which documents a suite of protocols developed by the International Telecommunication Union in the 1980’s.
It is likely that you have heard of LDAP as the directory protocol used to underpin Active Directory (AD) which is a directory service for Microsoft and normally is used by many organisations to support user authentication and role profiles for company networks.
It is important to understand that LDAP is not exclusive to Microsoft but does allow users to query AD and authenticate access to it.
In order to demonstrate how we can test LDAP using JMeter we are going to use an Online Test Server provided by Forumsystems which means that should you wish to follow this tutorial but don’t have access to a LDAP server you can. If you need to look at the solution, the JMeter project can be found here.
A limitation of using this online LDAP test server is that we only have read-only access meaning we can only test the following functions:
Bind
Unbind
Search
Compare
But JMeter also offers the ability to:
Rename
Add
Delete
Modify
The LDAP entries which we will be unable to demonstrate using this service but nonetheless we will provide some examples of these test types.
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.
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:
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.
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.