18 Oct 2016

Grâce aux tests de perfs jMeter, Tester c’est s’assurer !

Bon je vous l’accorde, peut-être que le jeu de mots du titre n’est pas au plus haut de mes performances mais quand même, il y a une grosse part de vérité là dedans.

Aujourd’hui j’ai décidé de vous faire un retour des plus banals mais pas des moindres. Quand on est développeur, nous le savons tous, tester n’est pas toujours simple, ce n’est pas toujours motivant et avouons également que nous aimons trouver des excuses pour ne pas faire ce travail !

Mais pourtant ce n’est plus à prouver, les tests jouent sur la qualité et la fiabilité du livrable. Si je décide d’enfoncer le clou sur ce sujet c’est que récemment j’ai travaillé sur un projet qui nous a donné du fil à retordre. Sans trop dévoiler le projet, résumons en disant que c’est une simple application qui fait de la redirection en GET.

Durant la production du code nous avons appliqué la méthodologie TDD, tout s’est passé pour le mieux, une couverture de code avoisinant les 98,5% avant de livrer (Et comme le dit Mr DX : quoi seulement ça ??!! ), pas moins de 150 tests pour tester une simple redirection, bref une application de rêve, bien ficelée !

Et pourtant, même avec ceinture et bretelles nous avons rencontré des problèmes. Je suis un adepte des tests mais jusque là il y a certains tests que je ne faisais pas systématiquement que je compte bien ajouter à la fin de tous mes devs. Ce sont les tests de charge ou dit “stress test”.

En effet nous nous sommes rendus compte que l’application ne tenait pas la charge et que des optimisations avaient besoins d’être mis en place pour corriger ces soucis de performances dû à une forte charge.

test-de-charge

Alors, quelques jours durant, je me suis plongé dans le monde du test pour faire le “bourrin” et assassiner mon application comme je le pouvais. J’ai installé un outil fortement connu qui s’appelle jMeter et qui permet de jouer des scénarios avec des paliers de charge : parfait ! Si vous souhaitez également mettre en place ce genre de tests, ce que je vous recommande fortement, voici la marche à suivre pour utiliser jMeter (basiquement)

1– Installez jMeter (oui quand même c’est un minimum…), moi perso j’utilise le jmeter.bat mais nous verrons pourquoi plus tard.

2– Une fois lancé vous avez devant vous sur le panel de gauche, deux sections, “plan de test” et “plan de travail”. Le plan de test c’est votre projet, là où seront lancés vos tests, alors que le plan de travail c’est un espace temporaire utilisé par JMeter. A la fin de vos tests, cette zone sera nettoyée par jMeter.

Bon dans la vrai vie, n’étant pas un expert de jMeter, j’avoue que je ne l’utilise que très peu. En effet, il y a sans doutes une utilisation bien précise de ce plan de travail que je ne maîtrise pas!

3– Du coup vous l’aurez compris nous allons nous positionner sur le plan de test et ajouter un groupe d’unités (Clic droit sur plan de test>Ajouter>Moteurs d’utilisateurs>Groupe d’unités). Il sera possible de lancer les tests sur le groupe d’unités que vous souhaitez ou alors exécuter tous les tests d’un coup.

Dans le projet nous avons créé un groupe d’unités par environnement et nous avons choisi de ne lancer que le groupe sur lequel on souhaite faire nos tests, de là à vous dire si c’est une bonne pratique…

Quand votre groupe d’unités est créé vous pouvez lui donner un petit nom mais surtout vous pouvez régler le nombre d’utilisateurs que vous voulez sur la durée de montée en charge que vous souhaitez avec un nombre d’itérations allant de 1 à l’infini et au delà… pardon

Si j’ai un conseil à vous donner c’est de ne pas être aussi bourrin que moi, commencez par laisser “1” partout pour vérifier vos cas de tests puis montez progressivement, inutile de faire exploser votre machine de dev 😉

4– Nous allons ajouter l’adresse de base que tous les tests utiliseront, pour cela sur votre groupe d’unités faites clique droit>Ajouter>Configurations>Paramètres HTTP par défaut et dans le champ nom ou adresse IP, saisissez l’url ou l’ip de votre serveur web (suivi du nom de votre application si vous utilisez IIS comme nous)

5– Au besoin ajoutez des cookies, pour cela faites clic droit sur vous groupe d’unités puis Ajouter>Configurations>Gestionnaire de Cookies HTTP. Cliquez ensuite sur Ajouter (en bas de l’écran) puis saisissez vos valeurs de cookies ! Pour vous aider à récupérer des cookies, si vous ne connaissez pas d’astuces de sioux, vous pouvez utiliser Postman et son plugin Chrome qui va examiner toutes les requêtes que vous faites, ensuite il ne vous reste plus qu’à les éplucher et récupérer ce dont vous avez besoin.

6-ça y est on entre dans le vif du sujet, l’url à appeler ! Sur votre groupe d’unités faites un clique droit>Ajouter>Échantillon>Requête HTTP. Ajouter lui un joli petit nom puis remplissez le champ “chemin” avec l’url que vous souhaitez tester. Autre conseil, vous avez l’option “Suivre les redirect.” qui est cochée par défaut, Si vous ne voulez pas vous faire démonter par le responsable de l’application sur laquelle vous faites vos redirections, décochez cette option, surtout en cas de forte, que dis-je, très forte sollicitation 🙂

Pour ajouter une assertion à cette url vous pouvez faire clic droit dessus>Ajouter>Assertions>”Celle que vous voulez” moi j’ai fait des “Assertion Réponse”. Dans cette assertion ajoutez-y tout ce que vous vous attendez à recevoir en réponse. Vous pouvez y mettre des RegEx, des contains, et plein d’autres trucs géniaux!

7-La dernière étape avant de jouer vos tests c’est d’ajouter des “Récepteurs” qui vont vous permettre d’interpréter les résultats (temps de réponse, réponse http obtenue, graphique, …)

Pour cela sur votre plan de test cette fois, faites clique droit>Ajouter>Récepteurs>”Celui que vous souhaitez”.

Ceux que nous avons utilisé sont:

  • Rapport consolidé
  • Arbre de résultats
  • Graphique agrégé
  • Graphique de résultats
  • Graphique évolution temps de réponses

jmeter

Voilà ! il ne vous reste plus qu’à jouer vos tests, soit Ctrl+R qui équivaut à la petite flèche verte pour tout lancer, soit clique droit sur le groupe d’unités>Lancer. Let’s go, vos tests se lancent et normalement tout est OK. Très bien, maintenant sur votre groupe d’unités augmentez progressivement votre nombre d’utilisateurs, le temps de montée en charge et le nombre d’itérations, vous aurez un beau test de performances dans vos mains. Pensez bien évidemment à sauvegarder votre projet et entre chaque test il vous faudra surement nettoyer les résultats afin de ne pas polluer vos stats 😉

Exemple d’un avant/après des temps de réponses de notre application (900 requêtes/seconde)

jMeter avant les corrections (Temps de réponse moyen 34 secondes en charge):

resultatbefore

jMeter après les corrections (Temps de réponse moyen 37 millisecondes en charge):

resultatafter

 

Notez que ces tests peuvent faire office de tests de non régressions et donc ils sont indispensables lorsque vous aurez une modifications à effectuer sur l’application.
Il y a un dernier point que j’aimerai aborder sur jMeter et le fait de l’utiliser avec son .bat, il est possible de jouer vos tests en ligne de commande et là ça devient intéressant car qui dit ligne de commande dit possibilité de faire des trucs de fous dans une PIC par exemple ! Je ne manquerai pas de vous faire un retour là dessus dès que ce processus sera en place mais je vous laisse imaginer la couverture fonctionnelle ainsi qu’un déploiement continu robuste que vous pouvez avoir en combinant tout cela. C’est donc là dessus que je vous quitte en vous recommandant fortement de mettre en place tous les tests que vous pouvez pour écarter au maximum les problèmes sur votre application et faciliter le travail pour de la livraison en un clic, le rêve de tous!

Share