Blog Zenika

#CodeTheWorld

Web

Performance testing : A What, How, When… blog article.

Imagine this situation, you have just finished developing your application, you are literally on cloud nine and you can’t wait to provide it to your 10 users… I mean 50 users.. or 100 users.. 1000 maybe? Wait, why your application is not available anymore?

So let’s face it, your application was not ready to have that number of simultaneous users.

How could you anticipate such a thing? One answer : performance testing.

What is performance testing? 

Performance testing is a type of non-functional testing designed to test the performance of your application under certain conditions and observe its behavior.

In easy words, it determines how much load your system can handle before it breaks or starts giving errors.

When To ?

In most cases we start performance testing when the project is completed or almost. And this is may not be the best way to do the task, for two reasons :

  • We could end up finding a huge number of bugs which will demand a huge time fixing them. Probably not a great news for “completed projects”
  • Finding the origin of the errors wouldn’t be the easiest task to do especially for complex architecture applications.

The alternative way is to test as early as possible. In fact involving testing in your development process, running them on a periodic basis will certainly help you detect some issues faster and fixing them will be a lot easier.

How To ? 

The How to part will include some tools that you should use and an explanation of the performance testing life cycle.

Before starting performance testing you should collect some quantitative information about your target audience: how many users in total per day? How many simultaneously?

Then, following those steps

  1. Prepare the test environment: it is important to have an iso-prod test environment and make sure to have the same architectural configurations.
  2. Choose your tools, make a comparative study of the existing tools (Apache Jmeter, Gatling, Grinder ..) many parameters should be taken into consideration: the time that will be devoted to the task, the technical skills of the person or the team who will develop the test. 
  3. Aim your metrics and prepare your monitoring tools: what part of the application are you going to monitor? And what tools you will be using to do so? Remember your test, and your monitoring tools should enable you to visualise the bahavior of as many components of your app as possible.
  4. Prepare the tests: writing performance tests could be done in two ways: writing them from scratch, or using a recording tool then reconfigure them (test recordes) 
  5. Make sure to make your tests as dynamic as possible (use global variables for number of users, action durations, users credentials ) so they can be reused with different parameters and maintining them would be easier.
  6. Save the results, analyze them: it is important to have the history of your tests executions.

Bests practices

1. Integrate performance testing on the development phase: example, running performance test before and after developing a feature/bug fix that may impact performance and compare metrics. If the metrics changed for example requests time raised you should review your code.

2. Integrate performance testing on your release phases: a periodic performance testing for the whole scenario: keep track of the results, compare them with the last ones, in case of performance downgraded you should review the code written between the two tests. The shorter the interval between tests the easier we identify bugs. Performance tests should be part of a global test strategy as long as unit tests, integration tests and E2E tests.

3. Run performance tests before and after dependencies upgrades in order to identify the impacts.

4. Write reports after each test to keep track of your performance evaluation: it helps you understand what happened and when.

5. Make sure that the tests reflect real human behaviors: the thinking time and the scenarios mix. Because users don’t click all buttons in 2 seconds, so consider adding a pause time between actions. Also run different scenarios at the same time, because the real user consults different interfaces while using the app.

6. Test all resources; CPU, RAM and databases in order to detect your system dificiency origins.

FINALLY..

Performance testing was always seen as “to do last operation”, and doing that at the end of your product life cycle could be a time/money consuming operation. So establishing a performance testing culture is very important.

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

En savoir plus sur Blog Zenika

Abonnez-vous pour poursuivre la lecture et avoir accès à l’ensemble des archives.

Continue reading