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.
When performance testing you need a set of requirements to measure your response times against. When defining these you should do so with your end users or business teams.
It is relatively easy to predict volumes, load and users that will use your application as you will no doubt have some data based on your current systems. It is a lot harder to agree on what the response times of your application should be. Without this critical measure we really cannot say for certain that an application or service performs. The reason being that we are not measuring the response time under load against a value that has been agreed upfront.
We need to be able to answer these questions:
At what point does a response time become unacceptable?
How can response times be defined in the requirements gathering stage?
How can we ensure there is a measure to test against?
We are going to look in this post at how we might categorise response times based on the interaction model with the end-user. And use these metrics to build response time requirements as part of your wider non-functional requirements.
We've recently been working with folks at Inflectra to develop an integration between Spira and OctoPerf. If you don't know about Inflectra and Spira they offer a very cool test management solution (among other things), you should check it out.
In this blog post we will highlight all the steps to follow in order to setup this integration. This way you'll be able to see the benefits of working with both tools in your organization.
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.
