À quoi correspond un test de charge ? Il s’agit de mesurer les réponses d’un système soumis à un volume d’utilisateurs accru pour en vérifier la capacité à soutenir le trafic attendu. Pour tester le comportement et la fonctionnalité de votre système, vous utilisez diverses mesures et paramètres comme le temps de réponse, le débit, l’état et la stabilité des serveurs.
Mais qu’est-ce qu’une « charge utilisateur accrue » ? Bien sûr, la définition de cette notion dépendra beaucoup de l’application et du contexte particulier. Google peut s’attendre à des millions d’utilisateurs effectuant des recherches de données en parallèle, et peut fixer pour son système des temps de retour de résultats inférieurs à la demi-seconde. Par contre, une petite agence bancaire locale ne tablera certainement que sur un millier d’utilisateurs simultanés, avec un temps de connexion cible de 3 secondes. Et encore, un site de commerce en ligne aura des exigences différentes pour la gestion des procédures de commande de milliers d’utilisateurs.
En bref, les cibles d’un test de charge (qui sont souvent survolées) dépendront du contexte et du secteur d’activité spécifiques.
Tester la charge revient-il à tester la performance ?
Ces deux termes sont encore trop souvent source de confusion. Les tests de performance couvrent un contexte plus étendu, et peuvent inclure différentes variables autres que la charge. Par exemple, vous pouvez exécuter un test de performance sous la forme d’un seul utilisateur depuis votre ordinateur de bureau, ou en exécuter un autre sous la forme d’un service depuis le nuage.
Le test de charge est une ramification spécifique du test de performance, qui simule un grand volume d’activités pour vérifier le comportement du système.
Différents types de test de charge
Il existe plusieurs types de test de charge, ayant chacun pour objectif de tester différents aspects ou conditions:
Le test de charge « classique » qui sert en général à vérifier que le système peut tenir des temps de réponse cible pour un volume d’utilisateurs donné.
Le test de résistance au stress – qui s’intéresse au comportement du système face à des conditions extrêmes après avoir atteint une exigence cible, telle que définie par le test de charge. Parmi ce qui peut constituer des conditions extrêmes : des machines avec une capacité mémoire inférieure aux prévisions, un afflux d’utilisateurs non prévu, des puissances CPU variables, ou toute autre configuration.
Le test de capacité – La capacité est un type spécifique de test de résistance au stress, qui aide à identifier le nombre maximal d’utilisateurs gérable par le système.
Le test d’endurance – qui examine le comportement du système lors d’une exécution sur la durée (par exemple, sur plusieurs jours) après avoir atteint ses exigences cibles, telles que définies par le test de charge.
Le processus d’exécution d’un test de charge
Même si de nombreux livres ont été consacrés au processus et à la méthodologie des tests de charge, voici en quelques étapes simples une description de ce processus.
1 – Définir les cibles
C’est la première étape, souvent éludée, lors d’un test de charge. Contrairement au test fonctionnel ou de régression, où les résultats réussite/échec sont finis, les résultats d’un test de charge sont beaucoup plus fluctuants et ouverts à interprétation quant à leur nocivité sur le système.
Les cibles d’un test de charge peuvent inclure diverses mesures analytiques, telles que le temps de réponse attendu, le nombre d’utilisateurs pris en charge par chaque activité, le comportement en période de pointe, le nombre d’utilisateurs mobiles supportés, etc.
2 – Configurer un environnement de test de charge
Une part importante de l’exécution d’un test de charge est de bâtir un environnement de test robuste et capable de reproduire l’environnement de production réel. Sont inclus les facteurs comme les profils et configurations machines, l’architecture réseau, les équilibreurs de charge, le pare-feu, les bases de données, etc. Pour plus de renseignements sur ce sujet, vous pouvez lire nos astuces pour bâtir un environnement de test de charge.
3 – Créer des scénarios de test
Bâtir des scénarios de charge peut se faire soit en enregistrant l’activité utilisateur, soit en la scénarisant, soit les deux (la solution la plus fréquente). Les scénarios de test de charge incluront tous les points de validation, les transactions et les mesures.
4 – Exécuter des tests
Une fois les scénarios de test configurés, vous les exécutez en utilisant différentes conditions afin de simuler une situation réaliste, qui sera fonction de vos cibles. Par exemple, exécuter des scénarios avec différents nombres d’utilisateurs, situés à différents emplacements ou utilisant différents navigateurs.
5 – Analyser les résultats
L’analyse des résultats implique d’interpréter les données recueillies pendant l’exécution des tests. Sont incluses les données liées aux transactions, aux erreurs, aux clics, au temps de réponse des transactions, aux pages, aux composants, et aux mesures de performance des serveurs.
Le volume de données collectées complique d’autant l’analyse des résultats. Le processus d’analyse est généralement itératif, c’est-à-dire que vous modifiez plusieurs paramètres de test puis réexécutez les scénarios afin de mieux cerner les problèmes et d’en identifier les origines. Un processus méthodologique et bien documenté, conçu et basé sur des cibles prédéfinies, peut vous faire gagner beaucoup de temps.
Quand effectuer un test de charge ?
En général, on effectue un test de charge à la fin du développement d’une version, juste avant de lancer le logiciel en phase de production réelle. Ces dernières années, dans le cadre des processus de développement agile, plusieurs entreprises ont procédé à leurs tests de charge beaucoup plus précocement. Cela permet d’identifier et de réparer les problèmes au plus tôt, et donc de réduire les frais de correction et d’éviter les retards de dernière minute.
Récapitulatif
Le test de charge est une discipline entre la science et l’art. Les ingénieurs de performance impliqués doivent posséder une bonne compréhension du système et du réseau, une expérience pointue avec l’application testée, et de bonnes connaissances sur les serveurs – mais aussi les compétences nécessaires pour dénicher les problèmes, les isoler, puis les résoudre de manière méthodique et organisée.
Par David BUCH, Directeur innovation de Radview
