Skip to content

Load-Testing

The basics of Simple Performance Testing

You don’t have to performance test if you are not bothered about the performance of your application; this is the only reason, if you are bothered and you want to make sure your customers get the best possible experience then it is wise to do some.

You have probably experienced poor application performance if you do any form of online shopping, many web sites are unable to handle the volumes of load and concurrency they see on their eCommerce platforms at peak times sure as Black Friday or Christmas.

Some even have to introduce a queuing system to throttle the load on their systems which leads to customer complaints and a poor reputation.

In this Blog Post we are going to look at some of the things you can do, that are not overly complicated, to reduce the risk of poor performance on your applications; basically, the simplest approach to performance testing we can think of.

Clearly, we would always recommend you invest a fair proportion of your QA effort to performance testing but if that is not something you wish to do then these simple things could be the difference between an application that can cope with high seasonal demands and one that does not.

This is therefore our guide to a simple performance test.

Performance Regression Testing

Regression Testing, as all Quality Assurance professionals know, is ensuring that previously developed and tested software continues to operate after a change.

Performance Regression being a subset of regression testing as a discipline is therefore ensuring that previously developed and tested continues to meet its performance criteria after a change.

There are subtle differences in the way that performance regression testing is approached when compared with functional regression testing, and we will look to explore these in this Blog Post.

A suitable performance regression strategy can provide huge benefits to your organisation, and we will look that these benefits as well as how to accomplish them.

Once you have a performance regression test suite it is important that it constantly evolves and is not left to become outdated and eventually obsolete, it must be maintained as we will discuss this also, but the benefits of a well-maintained regression pack will exceed the effort required to maintain them.

Gatling: Post requests and modular scripts

This article is the fourth part of a series of tutorials dedicated to Gatling Load Testing.

We will focus on POST requests and script modularization:

In the previous blog post we created a realistic Virtual User that browses the store without buying anything. On the contrary, here we are going to simulate the behavior of a user that connects to the web store, searches for items, adds some to his cart and proceeds to the checkout. Then we will combine both Virtual Users to simulate a diverse load on the PetStore.

POST Requests

Most actions to simulate a user that connects to the store are done via POST HTTP requests. But what exactly is an HTTP POST request?

Gatling: Loops, Conditions and Pauses

This blog post is a guide to help you write Gatling scripts in order to load test web applications efficiently. It follows our second Gatling Simulation scripts parameterization article.

We will continue to load test a fake e-commerce, and so we are going to improve our Virtual User to make it browse the store in a more humanly way. To do it we will cover several topics:

  • Loops to make it browse several articles of each category,
  • Conditions to change its behavior depending on dynamic parameters,
  • Pauses to simulate a real user think-time.

We start where the previous blog post ended, with a simulation script that uses a CSV feeder and a Regular Expression extractor to visit dynamic pages of the pet store: Download Sample Script.

Documentation and Agile Performance Testing

Once upon a time documentation was one of the most important aspects of Quality Assurance and this was not limited to the functional test efforts but the non-functional testing as well.

We spent days, weeks, months even creating Performance Test Strategies, Approaches, Plans, Test Case, Completion Reports etc.

Most of these documents were required before any automation could be written and before a sensible performance testing framework could be considered.

It was expected before performance testing began, during the performance test cycles and after the tests completed it was a constant cycles of documentation creation, review, update, review and sign-off.

With a bit of Performance Testing in the middle.

Surely many of us remember the difficulty in getting some of these significant and lengthy documents approved by many, many stakeholders.

Before I go on to tell you why documentation is overrated I want to caveat it with the fact that for some organisations it is a necessity as they are following the wishes of their customers and clients, and for some organisations they still follow a strict waterfall approach to software development and their way of working delivers for their organisation.

This is all fine, this post is more about Documentation for Performance Testing in Agile Delivery and this is an important distinction.