Skip to content

Load-Testing

Risk Assessment In Performance Testing

Performance Testing coverage needs to be defined from the application under tests functional requirements and this does not change regardless of whether you are following an Agile or a more Planned approach.

The Risk Assessment process defines what performance testing needs to be executed and the order in which this should be approached, the reason we use the functional test requirements for definition of coverage as these functional requirements define what the system does whereas the non-functional requirements are what you use to measure your tests against when you execute them.

As discussed the Risk Assessment is a way of identifying where your performance testing effort should be focussed and prioritising the order in which your performance tests are written and therefore executed so you ensure that you are focussing on the riskiest, from a performance perspective, aspects of the system first; we will expand on what we mean by riskiest later in this post.

A Risks Assessment should be done as early in the project or sprint, if you are working in an Agile methodology, as is possible to maximise its benefits.

The first thing we will discuss is the differences between Agile and Non-Agile Risk Assessment as this is an important concept but only as far as what is assessed and when, the principles of how and why we carry out a risk assessment will become clear as you read this post and remain the same regardless of your approach to development.

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.