Tests de charge VS tests de performance. Quelles différences ?

Publié le : 1 janvier 2024

La question pourrait paraître évidente, mais pas tant que ça au regard du nombre de cas ou d’articles abordant les deux sujets sans aucune distinction. Bien trop souvent confondus, les tests de performance et les tests de charge sont des tests complètement différents avec chacun leurs objectifs. On fait le tour de la question dans cet article : test de performance et tests de charge, quelles différences ?

Pour ceux qui maitrisent le glossaire CFTL/ISTQB, vous pourriez être offusqués, car il classe le test de charge comme une sous-partie des tests de performance. Et pourtant au quotidien, fortes des 10 années de retour d’expérience, les entreprises interlocutrices de CloudNetCare distinguent ces deux notions.

Définition ISTQB :

Test de performance : Tests pour déterminer la performance d’un produit logiciel.

Performance : La mesure selon laquelle une composante ou un système utilise le temps, les ressources et la capacité dans l’accomplissement de ses fonctions assignées. Synonymes : Comportement dans le temps, Efficience de la performance. Ref : D’après ISO 25010

Test de charge : le test de charge est une déclinaison du test de performance effectué pour évaluer le comportement d’un composant ou d’un système sous des charges variables, habituellement entre des conditions prévues d’utilisation faible, typique et de pointe. Voir aussi : Tests de performance, tests de stress Ref : ISO 29119

Les tests de performance

À chacune des modifications et nouvelles versions mises en ligne sur votre site internet ou votre application, il est essentiel de vérifier que cela n’a pas nui à la performance (qualité du ressenti de l’utilisateur) : est-ce que les utilisateurs accèdent à mon site dans les mêmes conditions ? Pour faire plus simple « est-ce que mon logiciel est aussi, moins ou plus performant ? ».

Pour répondre à cette question, on réalise plusieurs tests de performance :

1. Un premier test avant la mise en production de la nouvelle version qui va servir de référence (s’il n’y a pas de performance de référence récente).
2. Un deuxième après la mise en production dont les résultats seront comparés aux tests n°1.

Il faut construire un scénario de performance le plus représentatif possible pour que les tests soient pertinents. Ce type de scénario sera exécuté avec un internaute virtuel et selon une fréquence programmée (ex : toutes les deux heures sur une période de 48 heures). L’exécution des tests va permettre de remonter un ensemble de métriques que l’on pourra comparer avec les tests précédents.

Toutes les requêtes exécutées sont analysées pour déterminer, le cas échéant, les points de ralentissement. Ces informations pourront être transmises aux équipes de développement pour qu’elles puissent apporter les correctifs nécessaires.

Les tests de performance ne sont là que pour mesurer la qualité du ressenti d’un utilisateur après une mise en production. Ils répondent à la question : est-ce que mon site est toujours aussi performant ?

Le test de charge : qu’est-ce que c’est ?

L’objectif d’un site internet est souvent corrélé au nombre d’utilisateurs connectés, le fameux “trafic”. On mesure la popularité d’un site par son trafic et dans de nombreux cas on le monétise. Un raccourci rapide : plus j’ai de visiteurs et plus mon site fonctionne ! Il convient donc d’associer non seulement les infrastructures nécessaires pour absorber l’affluence désirée, mais plus encore la qualité des développements (IHM et base de données).

Avant une campagne commerciale ou des périodes clés d’une année marketing, il importe donc d’anticiper la capacité du site/application et de l’infrastructure à absorber les pics d’utilisateurs. Pour cela, il existe les stress tests.

Il est important de faire la différence entre le test de charge et les stress tests. Pour simplifier :

• Stress test : indique la capacité ou non d’une infrastructure à absorber un trafic donné. Ex: est-ce que mon site peut supporter 150 requêtes simultanées et dans quelles conditions techniques : % d’utilisation de la RAM, des I/O, charge du réseau, des frontaux, …
• Test de charge : permet de mesurer la qualité du ressenti de l’internaute derrière son écran ! Ex : combien de secondes mettront les internautes (par palier : 50/100/500/1000…) pour acheter un produit, sachant qu’au-delà de 15s (par exemple dans le tunnel d’achat) je perdrai le client ?

Pour ceux qui veulent aller plus loin et qui souhaitent identifier le moment où leur site internet ou application n’est plus accessible dans des conditions d’utilisation minimum suffisantes (selon des critères préalablement définis), il n’y a qu’une solution : le test de charge (rappel sur la différence entre tests de montée en charge Vs Stress Test ici).

Les réactions d’un site web face à l’affluence de visiteurs

Bien souvent, la montée en charge sur un site internet est progressive. Les cas de figure où un site passe du jour au lendemain de 10 à 150 visiteurs simultanés restent relativement rares. Dans la (très) grande majorité des cas, l’infrastructure évolue parallèlement au trafic et l’expérience utilisateur se dégrade éventuellement, au fur et à mesure du temps, par des connexions simultanées.

Là où le problème se pose, c’est lors d’une montée en charge rapide corrélée à un événement particulier par exemple une campagne publicitaire : passage TV, Black Friday, mise en vente de billet … Autant de circonstances où l’infrastructure est sursollicitée et où il devient compliqué, voire impossible, de naviguer sur un site.

Et cela peut, dans certains cas, anéantir tous les efforts consentis pour une opération commerciale avec l’impact ultime : le tunnel de vente inaccessible.

Les enjeux liés à ces moments “clés” de la vie d’un site sont cruciaux et représentent vite des sommes non négligeables :

• Coût des développements
• Coût des campagnes publicitaires (spots, bannières, relais presse, influenceurs …)
• Captation de l’attention des internautes
• Perte sèche du CA
• …

Pour éviter tout cela, il faut être capable d’absorber les pics d’affluence et cela commence par connaître non seulement les limites de son infrastructure, mais plus encore de son application web. Le test de charge est alors la solution.

Le test de charge, pour s’assurer qu’un site peut absorber les pics de fréquentation

Un test de charge permet de contextualiser la qualité du ressenti de l’internaute et ne se contente pas de métriques techniques. On parle de contexte, car il ne s’agit pas seulement de savoir si 50 utilisateurs peuvent se connecter simultanément sur votre site, mais surtout si ces 50 utilisateurs vont pouvoir utiliser votre site dans de bonnes conditions. Et la nuance a toute son importance en matière de test de charge !

Un utilisateur qui peut se connecter et qui met 10 secondes à charger la moindre page et un utilisateur qui se voit renvoyer une erreur 503 ont la même incidence sur votre business : perte des commandes potentielles, pertes en matière de transaction et d’achat sur le marché.

L’idéal, pour tout site Internet, serait de pouvoir reproduire (et non simuler) puis observer comment la qualité de la navigation est impactée en fonction du nombre d’utilisateurs. Cela permettrait de déterminer précisément le moment et surtout pourquoi, les conditions ne sont plus réunies pour une expérience utilisateur optimale. C’est justement à cela que sert une campagne de tests de charge !

Un cas d’usage

Il est possible de construire des scénarios de montée en charge pour observer la réaction de l’infrastructure et de l’application au fur et à mesure de l’augmentation du nombre d’utilisateurs.

Ex : Une montée progressive des connexions simultanées jusqu’à 800 internautes virtuels (courbe orange) pendant 15 minutes (axe des abscisses).

Une campagne de montée en charge va permettre de reproduire à l’identique un utilisateur et ses actions via un navigateur. Le but est de mesurer les temps de réaction du serveur, des JS et des services tiers au fur et à mesure du temps et de l’augmentation progressive du nombre d’utilisateurs. En bref, la performance de charge.

On obtiendra ce type de graphique représentant bien le temps de réponse du serveur en fonction du nombre d’utilisateurs simultanés. Et c’est avec ce rapport de campagne de tests, ainsi qu’avec l’analyse qui en sera faite, qu’il sera possible de déterminer le moment où la qualité de navigation des utilisateurs n’est plus suffisante.

Ce moment où les conditions ne sont plus réunies pour permettre une expérience optimale impose de rediriger les utilisateurs vers une page de débordement.

Dans notre exemple et très nettement à partir de la 6ème minute du test de charge, avec 250 internautes virtuels simultanés, on constate que l’infrastructure ne réussit plus à absorber la charge (courbe bleue). Par effet de bord, le temps d’accès à l’application (courbe verte) passe de 10 s à 30 s (axe des ordonnées) le tout générant des erreurs d’accès (courbe rouge en pointillée).

Il doit être possible de rentrer dans le détail des requêtes gérées par le navigateur pour comprendre ce qui provoque cet effondrement des temps de réponse et les erreurs.

Uniquement à la vue de ce graphe on peut conclure :

C1 – Le premier problème, qui en cache peut-être d’autres, vient de l’infrastructure

C2 – Cette application répond dans :

• De très bonnes conditions d’utilisations jusqu’à 150 internautes < 5 s (temps incluant les mesures)
• De bonnes conditions d’utilisations jusqu’à 250 (Temps < 10s (temps incluant les mesures)

Actions à réaliser :

A1 – Comprendre la cause : frontaux, load balancer, réseau saturé…

A2 – Réaliser les correctifs.

A3 – Réaliser le TIR de puissance à ISO pour vérifier l’impact des correctifs.

A 4 – Réitérer le processus par paliers (1000/1500) jusqu’à la cible maximale envisagée (par exemple 2000 internautes ?)

Et c’est grâce à l’interprétation des résultats du test de charge qu’il est possible de déterminer comment absorber un pic d’affluence sur son application web :

• Travailler à la diminution du nombre de requêtes par utilisateur (commencer par-là !)
• Mettre en place une page de débordement
• Augmenter la capacité de l’infrastructure
• Revoir la qualité du développement (IHM, Base de données)

Pour voir tout ce qu’il est possible de faire avec un plan de campagne basé sur le test de charge, nous ne pouvons que vous conseiller notre article détaillé sur le sujet.

Les tests de charge permettent de déterminer précisément la réaction de son infrastructure/site ou application, face à des pics d’affluence. Il permet de répondre à la question : à partir de combien d’utilisateurs simultanés mon site ne permet plus de proposer des conditions de navigation optimale ?

Pour conclure.

Le Graal est que 100% des utilisateurs puissent accéder au site dans de bonnes conditions, mais cela n’est accessible que pour les “géants” du web. Il ne faut pas non plus oublier que, eux aussi, sont passés par là et que leurs applications et l’infrastructure nécessaire ont évolué conjointement avec leur trafic.

En 2020 les temps de chargement d’une page sont critiques et nous nous battons tous pour les réduire ou, a minima, ne pas les augmenter. Les tests de non régression permettent d’améliorer la qualité de vos livrables, mais ne tiennent pas compte des temps de chargement. C’est là où les tests de performance sont primordiaux. L’augmentation du temps de chargement d’une URL est une régression.

De son côté, le test de charge permet d’anticiper des pics d’affluence et d’identifier le moment où les conditions ne sont plus réunies pour continuer d’accueillir des nouveaux visiteurs sur son infrastructure.

Nous avons bien deux tests répondant à deux besoins différents. Attention donc à ne pas les confondre ;).