JMeter : retour d’expérience

Une application sans bug ça n’existe pas, c’est pourquoi pour limiter les dégats on fait des tests.
Il en existe deux sorte :
- Les tests manuels, qui se basent le plus souvent sur un cahier de recette
- Les tests automatiques

Traditionnellement, les tests automatiques sont utilisés pour la partie métier (service).
C’est quelque chose de relativement simple de mettre en œuvre, et que tout bon développeur fera de lui-même avant de mettre en gestion de conf son œuvre.
En Java, on utilise JUnit pour se faire, et pour mesurer la non régression et faire de l’intégration continue on utilise des plateforme comme Hudson.

Coté utilisateur/client, on teste ce qu’on voit, c'est-à-dire la partie IHM. Les tests automatiques sont souvent lourds à mettre en place, et pénibles à maintenir. En effet, si le métier évolue au cours d’un projet, l’IHM elle est très sujette au changement (ergonomie, navigation, couleur, forme, position).
Pour automatiser cette partie, c’est donc difficile. Il faut se concentrer sur le fond et non sur la forme qui est trop instable. C’est là que JMeter entre en action.

Dans une cadre d’un gros projet, j’ai utilisé JMeter pour automatiser des tests IHM entre autres.
Pour une application web, JMeter s’utilise comme un proxy pour enregistrer un scénario (requêtes http). Une fois le scénario enregistré, il suffit de modifier les entrées (un fichier CSV par exemple), et voilà. Il existe même un plugin maven !

Mais la force de JMeter par rapport à d’autres outils est de pouvoir jouer en scénario en boucle, et même de simuler plusieurs utilisateurs (en même temps ou pas). Vous voyez mieux l’utilité ?
J’ai donc utilisé JMeter pour des tests de charge, des tests mémoire, etc …
En suite à partir d’exigence de performances connus, on peut jauger au niveau de la production combien de cluster il faut.

Bref, j’ai adoré cet outil, même si la prise en main avec un projet webflow est un peu complexe (gestion des paramètres comme les flowId et flowExecutionKey).