Je vais vous présenter le principe et le fonctionnement des tests de charge. Cette présentation se fera sur plusieurs articles, vous permettant d’appréhender pas à pas cette notion.
Qu’est ce qu’un test de charge ?
Je vous entends déjà dire « Voici encore du charabia d’informaticien ».
Et pourtant il s’agit là d’une notion simple à appréhender. Un test de charge est un test au cours duquel on va simuler la connexion simultanée d’un nombre d’utilisateurs dits « virtuels », afin de valider l’application pour une charge attendue d’utilisateurs. On va donc simuler le comportement des utilisateurs « réels ». Ce type de test permet de mettre en évidence les points sensibles et critiques de l’architecture technique. Il permet en outre de mesurer le dimensionnement des serveurs, de la bande passante nécessaire sur le réseau, etc. Il ne s’agit en aucun cas d’une estimation hasardeuse, mais bien de simuler un comportement le plus proche possible de la réalité.
Pour quoi faire ?
Savez-vous combien d’utilisateurs peuvent utiliser votre site web en même temps ? Vos infrastructures tiendront-elles le coup lors de soldes ou de campagnes de pub ?
Certains sites ou applications web sont amenés à connaitre un fort trafic, ou encore générer une lourde charge pour l’architecture technique. L’exemple le plus parlant est celui de la boutique en ligne vendant des billets de spectacles ou du matériel informatique. Ce type de site marchand peut engendrer des milliers de connexions à l’heure. Ces pics de connexions peuvent également concerner des sites évènementiels (concerts, Roland Garros) .
Dans ces cas de figure, les tests de montée en charge poursuivent des objectifs critiques, dont voici une liste non exhaustive:
S’assurer du bon fonctionnement des applications avant la mise en production ou la mise en ligne : il s’agit d’établir des scenarii de test pour vérifier que l’application ou le site réagira comme prévu aux sollicitations des utilisateurs évitant ainsi toutes indisponibilités
Simuler des utilisateurs et analyser le comportement de l’infrastructure : les applications ou les sites internet s’appuient sur des briques techniques (serveurs web, bases de données). Il s’agit de déterminer grâce à la simulation, la capacité maximale de l’infrastructure (par exemple 1000 connexions simultanées). C’est un point crucial pour un site marchand : chaque connexion refusée ou échouée se traduit par du chiffre d’affaire en moins.
Valider les temps de réponse pour les métiers : des temps de réponse courts sont une condition sine qua non pour conserver des internautes sur un site marchand. Lorsqu’il s’agit d’une application métier, des temps de réponses trop longs peuvent impacter de manière grave l’activité (péage d’autoroute, guichet, etc…)
Méthodologie
Et maintenant la pratique !
Les tests de performance doivent être implémentés et réalisés tout au long du cycle de développement, et ce le plus tôt possible. Un résultat plus ou moins précis maintenant vaut mieux qu’un résultat très précis plus tard.
- Tester de façon large, puis de façon approfondie
- Tester dans un environnement contrôlé
- L’environnement de test doit être dans la mesure du possible identique à l’environnement de production, à défaut à une échelle étalonnée reconnue fiable
Étape 1 : Analyse de Référence (l’analyse préliminaire consiste en l’enregistrement d’un ou de plusieurs scénarios pour mieux comprendre l’application et l’étendue du test).
- Définir le système à tester, les processus métier, et les objectifs (métiers, techniques, économiques)
- Définir les scénarios, par rapport à une analyse complète des risques métiers et techniques
- Définir le modèle de charge, par rapport au modèle d’usage de l’application
- Caractériser les données pour chaque scénario
- Enregistrer les scénarios
Étape 2 : Tests sur Environnement de Recette
- Mettre en œuvre des moyens et définir la plate-forme de test
- Exécuter les tests de charge.
- Analyser les résultats.
Étape 3 : Test sur Environnement de Production
- Mettre en œuvre des moyens et définir la plate-forme de test
- Exécuter les tests de charge
- Analyser les résultats
- Optimiser le système
Résultats attendus
Alors maintenant que je sais lancer un test, on fait quoi ??
Le Bilan des Tests, livrable obligatoire et essentiel du processus de test, donne les résultats obtenus lors des tests effectués, éventuellement un avis de mise en production, mais aussi des préconisations applicatives ou systèmes pour résoudre les problèmes de performance. Corrélé au Plan de Test, il permet de valider que les résultats obtenus sont conformes au objectifs attendus, dans un contexte technique précis (production, préproduction, dédié, modélisé, …), éventuellement optimisé, avec des hypothèses de charge clairement identifiées et définies.
À ce titre, il restitue des résultats selon trois vues:
- Vue Métier : nombre de clients de l’application connectés, nombre de processus métier réalisés.
- Vue Utilisateur : Temps de réponse des transactions, taux d’erreur.
- Vue Technique : Consommations des ressources systèmes (CPU, Mémoire, I/O), consommations applicatives (métriques applicatives telles que sessions, attentes dans les pools threads/connexions, etc…).
L’ensemble des données restituées dans le bilan donne donc un niveau de qualité de service de l’application, en charge, qui est à rapprocher des attendus prédéfinis dans le Plan de Test. Il doit permettre aux équipes de production d’anticiper les ressources à mettre à disposition, ainsi que les paramétrages à mettre en œuvre.
Les différents scénarios de tests
Il existe une multitude de tests, tous ayant des objectifs particuliers. Donc qu’on ne m’accuse pas de ne pas vous informer !
Test de performance : proche du Test de Charge, il s’agit d’un test au cours duquel on va mesurer les performances de l’application soumise à une charge d’utilisateurs. Les informations recueillies concernent les temps de réponse utilisateurs, les temps de réponse réseau et les temps de traitement d’une requête sur le(s) serveur(s). La nuance avec le type précédent réside dans le fait qu’on ne cherche pas ici à valider les performances pour la charge attendue en production, mais plutôt vérifier les performances intrinsèques à différents niveaux de charge d’utilisateurs.
Test de dégradations des transactions : il s’agit d’un test technique primordial au cours duquel on ne va simuler que l’activité transactionnelle d’un seul scénario fonctionnel parmi tous les scénarios du périmètre des tests, de manière à déterminer quelle charge le système est capable de supporter pour chaque scénario fonctionnel et d’isoler éventuellement les transactions qui dégradent le plus l’ensemble du système. Ce test peut tenir compte ou non de la cadence des itérations, la représentativité en termes d’utilisateurs simultanés vs. sessions simultanées n’étant pas ici un objectif obligatoire, s’agissant ici plutôt de déterminer les points de contention générés par chaque scénario fonctionnel. La démarche utilisée est d’effectuer une montée en charge linéaire jusqu’au premier point de blocage ou d’inflexion. Pour dépasser celui-ci, il faut paramétrer méthodiquement les composants systèmes ou applicatifs afin d’identifier les paramètres pertinents, ce jusqu’à obtention des résultats satisfaisants. Méthodologiquement, ce test est effectué avant les autres types de tests tels que performance, robustesse, etc. où tous les scénarios fonctionnels sont impliqués.
Test de stress : il s’agit d’un test au cours duquel on va simuler l’activité maximale attendue tous scénarios fonctionnels confondus en heures de pointe de l’application, pour voir comment le système réagit au maximum de l’activité attendue des utilisateurs. La durée du palier en pleine charge, en général de 2 heures, doit tenir compte du remplissage des différents caches applicatifs et clients, ainsi que de la stabilisation de la plateforme de test suite à l’éventuel effet de pic-rebond consécutif à la montée en charge. Dans le cadre de ces tests, il est possible de pousser le stress jusqu’à simuler des défaillances systèmes ou applicatives afin d’effectuer des tests de récupération sur incident (Fail-over) ou pour vérifier le niveau de service en cas de défaillance.
Test de robustesse, d’endurance, de fiabilité: il s’agit de tests au cours duquel on va simuler une charge importante d’utilisateurs sur une durée relativement longue, pour voir si le système testé est capable de supporter une activité intense sur une longue période sans dégradations des performances et des ressources applicatives ou système. Le résultat est satisfaisant lorsque l’application a supporté une charge supérieure à la moitié de la capacité maximale du système, ou lorsque l’application a supporté l’activité d’une journée ou plusieurs jours/mois/années, pendant 8 à 10 heures, sans dégradation de performance (temps, erreurs), ni perte de ressources systèmes.
Test de capacité, test de montée en charge : il s’agit d’un test au cours duquel on va simuler un nombre d’utilisateurs sans cesse croissant de manière à déterminer quelle charge limite le système est capable de supporter. Éventuellement, des paramétrages peuvent être effectués, dans la même logique que lors des tests de dégradation, l’objectif du test étant néanmoins ici de déterminer la capacité maximale de l’ensemble système-applicatif dans une optique prévisionnelle (cf. Capacity planning, Gestion de la capacité en français).
Test aux limites : il s’agit d’un test au cours duquel on va simuler en général une activité bien supérieure à l’activité normale, pour voir comment le système réagit aux limites du modèle d’usage de l’application. Proche du test de capacité, il ne recouvre pas seulement l’augmentation d’un nombre d’utilisateurs simultanés qui se limite ici à un pourcentage en principe prédéfini, mais aussi les possibilités d’augmentation du nombre de processus métier réalisés dans une plage de temps ou en simultané, en jouant sur les cadences d’exécutions, les temps d’attente, mais aussi les configurations de la plateforme de test dans le cadre d’architectures redondées (Crash Tests).
Il existe d’autre types de tests, plus ciblés et fonction des objectifs à atteindre dans la campagne de tests : Test de Benchmark (comparaisons de logiciel, matériels, architectures,…), Tests de non-régression des performances, Tests de Composants, Tests de Volumétrie des données, etc. Étant entendu qu’en principe un type de test correspond à un type d’objectif, et que dans une matrice de couverture des tests les résultats se recoupent obligatoirement, il est rare (et coûteux) de réaliser l’ensemble de ces tests pour une application donnée.
Outils nécessaires
Et le plus beau c’est que des outils font le travail pour vous !
- être capable d’enchaîner des actions sur le système selon des scénarios qui ont du sens pour les objectifs de test
- valoriser ces actions sur des données qui sont pertinentes à la fois vis-à-vis des scénarios et de l’état du système au moment où l’on exécute ces tests
Prenons par exemple le cas du test de performance d’un portail eCommerce dans lequel on va adresser plus particulièrement la fonction de constitution d’un panier d’achat. Il faut disposer d’un mécanisme d’automatisation des actions de sélection d’article, de validation de commande, etc. Mais il faut également valoriser ces actions en donnant les articles qui seront effectivement commandés par les utilisateurs virtuels (simulés) dans le cadre du test de performance. Or, la nature et le nombre de ces articles peuvent varier en fonction du contenu de la base de données d’articles de l’application, du profil de consommateur de l’utilisateur simulé, ou encore de la période de l’année que l’on simule dans le test.
Les solutions de tests de performances Web vont permettre de simplifier et d’automatiser ces tests : création plus ou moins automatisée des scénarios de tests, configuration des scénarios avec ou sans script, simulation d’utilisateurs virtuels avec collecte des mesures (et génération automatique de rapports), etc.
Les outils que nous utilisons
Les cordonniers ne sont pas toujours les plus mal chaussés !

Ces 2 logiciels sont édités « SmartBear » (http://smartbear.com/).
Source SOAP UI: SOAP UI en version 4.5.1 est disponible à cette adresse: http://sourceforge.net/projects/soapui/files/soapui/4.5.1/soapUI-x32-4.5.1.exe/download
Sources LOAD UI: LOAD UI en version 2.1.1 est disponible à cette adresse: http://sourceforge.net/projects/loadui/files/2.1.1/loadUI-2.1.1.exe/download
Voila vous ne pourrez plus dire maintenant que vous ignorez si votre site tiendra la charge lors des prochaines soldes ou lors de votre prochaine campagne de pub. Et le plus beau dans l’histoire, c’est que tout est à portée de main pour réussir simplement et facilement vos tests de charge