Effectuer des tests de performance et de stress avec Apache JMeter

Aujourd’hui nous allons parler d’une partie importante du développement d’une application qui est souvent négligée au même titre que les tests unitaires ou les tests d’intégration : les tests de charge et les stress test.

Pour cela nous allons voir un exemple avec un outil de test éprouvé et reconnu car il n’en existe pas beaucoup sur le marché qui fassent un aussi bon travail : Apache JMeter.

Sur le site de Microsoft, il y en a plusieurs qui sont recommandés mais personnellement j’ai toujours utilisé JMeter : https://docs.microsoft.com/fr-fr/aspnet/core/test/load-tests?view=aspnetcore-5.0

il n’y a rien de pire que d’arriver sur un environnement préproduction ou intégration avec une base de données qui contient plus de données et ou il y a plus d’utilisateurs , ce qui pourra avoir comme résultat de mettre en lumière des performances beaucoup moins bonnes que prévu.

Pour cela il est existe 2 types de tests :

• Tests de charge: Testez si l’application peut gérer une charge d’utilisateurs spécifiée pour un certain scénario tout en répondant toujours à l’objectif de réponse. L’application est exécutée dans des conditions normales.

• Tests de stress: stabilité de l’application de test lors de l’exécution dans des conditions extrêmes, souvent pendant une longue période de temps. Les tests mettent en place une charge utilisateur élevée, des pics ou une augmentation progressive de la charge, sur l’application, ou ils limitent les ressources informatiques de l’application.

Pour vérifier cela, nous allons utiliser JMeter.

Pour commencer, allons télécharger l’exécutable à cette adresse.

Dézippez l’archive à l’endroit de votre choix, puis exécutez « jmeter.bat » :

Vous devriez avoir un écran qui ressemble à celui-ci :

Pour les besoins de l’article j’ai utilisé cette api sur mon repository GitHub.

Commençons par configurer le comportement par défaut de nos appels lors des tests en ajoutant (via clic droit sur le projet) un Http Request Defaults :

Nous allons configurer les paramètres d’appel par défaut en restant sur une utilisation basique.

Maintenant créons un thread group qui va nous servir à paramétrer la montée en charge de nos appels.

La configuration donne ceci :

Nous avons donc un thread par utilisateur qui augmente toutes les 1 secondes jusqu’à atteindre 5000 utilisateurs.

Maintenant nous allons arriver à nos appels.

Rajoutons un appel à un endpoint de notre API , clic droit sur le thread group puis rajoutez une http request :

Comme vous pouvez le remarquer, nous n’avons saisi que le path car nous avons un Http Request Defaults qui sera automatiquement repris.

Nous n’avons pas de mécanisme d’authentification mais si jamais vous en avez un, il faudra l’exécuter en premier puis récupérer le token si vous voulez le réutiliser dans vos appels suivants.

Donc la request :

Rajoutez-y un json extractor pour récupérer votre token :

Vous pourrez ensuite le réutiliser dans vos appels comme suit en rajoutant à nos autres appels ,qui nécessitent le token, un http request header manager :

Puis en rajoutant notre variable précedente :

Vous avez maintenant la base, pour pouvoir tester vos API avec une montée en charge forte ou nominale.

Il existe malgré tout des composants à connaitre.

CSV Config

Si vous souhaitez passer des données en entrée, via un fichier CSV que vous aura fourni votre QA testeur(quand il existe 🤣) , c’est possible ! Il faut rajouter un CSV Data Set Config

Il reprendra les données de votre CSV et le nom de la variable sera le nom de la colonne en header:

Response assertion

Ce composant sert uniquement à faire des tests sur les réponses de vos endpoints comme suit :

Les listeners

Ils servent à écouter ,comme leur nom l’indique, les réponses à vos appels à vos API et à créer des reports principalement.

summary report :

Result tree

Voila ! Vous n’avez plus d’excuses si vos API ne sont pas au niveau de performance demandé par le client car vous auriez du les tester en amont 😉

Je vous ai donné un avant-gout de ce que peut faire JMeter mais c’est un outil extrêment puissant qui va vous permettre de voir réellement vos performances avec un environnement extrême. Il vous permettra de voir vos micro coupures sur les requêtes , les performances via des graphiques etc

Il ne vous reste plus qu’à l’exploiter 😎

Happy coding !