Systems | Development | Analytics | API | Testing

This article is the last 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 analysis.

In this blog post we are going to look at some of the uncommon performance tests. By this we mean those scenarios that are not what we believe are commonly executed but those that are run periodically at best. These uncommon scenarios should not necessarily take priority over the more common performance scenarios. They do add value by stressing parts of your application under test that may be missed by the more conventional tests.

We have spoken in a previous blog post about documentation about how we believe that if you are building performance tests that support either Continuous Integration or Continuous Delivery then having to produce performance testing documentation before and after each test does not fit with this methodology.

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.

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.

In this Blog Post we are going to discuss performance testing in production. Now before you think we have gone mad and lost our minds completely this is not as crazy as it sounds. Production is an environment that: All the things you spend a significant amount of time getting right in your performance testing environment and that can be difficult to achieve. Therefore, it seems like the perfect environment to performance test in.

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.

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.