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.
In this post we are going to look at performance testing on large scale programmes. A few the posts we write define techniques and approaches based on a single application under test but sometimes you are faced with the prospect of performance testing: Now, especially in the case of migration of services, performance is key, and you cannot afford to see a degradation in performance as the business users will have already become accustomed to the software and how it performs.
When using a testing tool, it is only logical to trust its results. And the more well-known the tool is, the more trust we put in it. Furthermore, how could we know it is wrong? After all, who is in a position to judge the judge? This phenomenon is particularly true in the load testing community, since the field is still something of a niche among the testing world. Finding deep-dive studies about the actual technical aspect of load testing is difficult.
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.
This article is the third in a series of overviews of our new UI. You can find the others here: This time we will dive into the changes we’ve made in the runtime phase.
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.
This article is the second in a series of overviews of our new UI. You can find the first one here. This time we will dive into the changes we’ve made in the design phase. We’ve addressed many pain points from the old UI that we want to detail here: This will make the design in OctoPerf even faster, so that you can focus more time on your tests and analyzing them.
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.
There are many articles on the huge benefits of performance testing integrated into the development process and the concept of shift-left performance testing. We have also discussed the concepts of Load Test Driven Development which involves the creation of performance testing in parallel with the code development and sits alongside Test Driven Development. We are going to consider in this post how involving performance testing resources in the application design process can be a benefit.
Our new UI has been available for everyone since a few weeks now. It is a major project for us that has taken several years to get to this stage. It’s been a lot of effort but we’re confident that it will be worth it when you see all the new possibilities. That being said, we thought it would be helpful to ease you into it by going through some of the key features together. The goal is to talk about the major UI changes that impact most if not all the new screens.
