Qu’est-ce que le test de charge ? (Exemples)

⚡ Résumé intelligent

Les tests de charge mesurent le comportement d'une application logicielle lorsqu'un grand nombre d'utilisateurs y accèdent simultanément, jusqu'au pic de charge prévu. Ils permettent d'identifier la capacité opérationnelle maximale, les goulots d'étranglement qui la limitent et de déterminer si l'infrastructure actuelle est suffisante.

  • 👥 Définition principale : Un test non fonctionnel qui applique la charge utilisateur maximale attendue et mesure la réponse.
  • ️ Indicateur principal : Le délai de réponse doit être quantitatif, pertinent, réaliste, atteignable et mesurable.
  • ???? Ce qu'il découvre : Capacité maximale, lacunes d'infrastructure, limites de la base de données et problèmes de configuration.
  • (I.e. Charge vs contrainte : La charge s'arrête au pic prévu ; la contrainte la dépasse délibérément pour trouver le point de rupture.
  • ️ Options d'outillage : JMeterGatling et k6 sont des logiciels libres ; LoadRunner est la solution commerciale établie.
  • 📋 Condition préalable: Ne l'exécutez que lorsque l'application est fonctionnellement stable, sinon les défauts masquent les résultats de performance.

Qu'est-ce qu'un test de charge ?

Qu'est-ce que le test de charge ?

test de charge est un processus de test logiciel non fonctionnel dans lequel les performances d'une application logicielle sont testées sous une charge attendue spécifique. Il détermine le comportement de l'application logicielle lorsqu'elle est accessible simultanément par plusieurs utilisateurs. L’objectif des tests de charge est d’améliorer les goulots d’étranglement des performances et de garantir la stabilité et le bon fonctionnement de l’application logicielle avant le déploiement.

Ce test identifie généralement –

  • La capacité opérationnelle maximale d’une application
  • Déterminer si l'infrastructure actuelle est suffisante pour exécuter l'application
  • Durabilité de l’application par rapport à la charge maximale d’utilisateurs
  • Nombre d'utilisateurs simultanés qu'une application peut prendre en charge et évolutivité pour permettre à davantage d'utilisateurs d'y accéder.

C'est un type de test non fonctionnel. En génie logiciel, les tests de charge sont couramment utilisés pour les applications Web client/serveur – à la fois sur Intranet et sur Internet.

test de charge

Pourquoi les tests de charge sont-ils nécessaires ?

Certains sites extrêmement populaires ont subi de graves temps d’arrêt lorsqu’ils reçoivent des volumes de trafic massifs. Les sites de commerce électronique investissent massivement dans les campagnes publicitaires, mais pas dans les tests de charge pour garantir des performances optimales du système, lorsque ce marketing génère du trafic.

Exemples de tests de charge

  • Toysrus.com n'a pas pu gérer le trafic généré par sa propre campagne publicitaire, perdant ainsi à la fois les dépenses marketing et les ventes escomptées.
  • Le site Web d'une compagnie aérienne n'était pas en mesure de gérer plus de 10000 utilisateurs lors d'une offre de festival.
  • L'Encyclopedia Britannica a déclaré l'accès gratuit à sa base de données en ligne comme une offre promotionnelle. Ils n’ont pas pu suivre le trafic pendant des semaines.

De nombreux sites subissent des temps de chargement retardés lorsqu’ils rencontrent un trafic important. Quelques faits –

  • L'abandon augmente fortement au-delà d'environ 3 secondes de temps de chargement de la page, et cet effet est encore plus marqué sur les connexions mobiles.
  • Les pages lentes coûtent aux sites de commerce électronique des revenus mesurables à chaque visite, c'est pourquoi la performance est considérée comme un indicateur commercial plutôt que technique.

Pourquoi des tests de charge ?

  • Les tests de charge donnent confiance dans le système, sa fiabilité et ses performances.
  • Les tests de charge aident à identifier les goulots d'étranglement dans le système dans des scénarios de stress utilisateur intense avant qu'ils ne se produisent dans un environnement de production.
  • Les tests de charge offrent une excellente protection contre les mauvaises performances et s'adaptent à des stratégies complémentaires de gestion des performances et de surveillance d'un environnement de production.

Objectifs des tests de charge

Les tests de chargement identifient les problèmes suivants avant de déplacer l'application vers le marché ou la production :

  • Temps de réponse pour chaque transaction
  • Performances des composants du système sous diverses charges
  • Performances des composants de base de données sous différentes charges
  • Délai réseau entre le client et le serveur
  • Problèmes de conception de logiciels
  • Problèmes de configuration du serveur comme un serveur Web, un serveur d'applications, un serveur de base de données, etc.
  • Problèmes de limitation matérielle tels que la maximisation du processeur, les limitations de mémoire, les goulots d'étranglement du réseau, etc.

Les tests de charge détermineront si le système doit être ajusté ou si une modification du matériel et des logiciels est nécessaire pour améliorer les performances. Pour effectuer efficacement des tests de charge, vous pouvez utiliser divers outils de test de performances disponibles pour vous aider à identifier les domaines à améliorer.

Prérequis des tests de charge

La principale mesure des tests de charge est le temps de réponse. Avant de commencer les tests de charge, vous devez déterminer :

  • Si le temps de réponse est déjà mesuré et comparé – Quantitatif
  • Si le temps de réponse est applicable au processus métier – Pertinent
  • Si le temps de réponse est justifiable – Réaliste
  • Si le temps de réponse est réalisable – Réalisable
  • Si le temps de réponse est mesurable à l’aide d’un outil ou d’un chronomètre – Mesurable

Configuration de l'environnement avant les tests de charge

Plate-forme matérielle Configuration logicielle
  • Machines serveur
  • Processeurs
  • Mémoire
  • Stockage sur disque
  • Configuration des machines de chargement
  • Configuration du réseau
  • Operating système
  • Logiciel serveur

Stratégies de test de charge

Il existe de nombreuses façons d’effectuer des tests de charge. Voici quelques stratégies de tests de charge :

Stratégies de tests de charge

  • Test de charge manuel: Il s'agit de l'une des stratégies permettant d'exécuter des tests de charge, mais elle ne produit pas de résultats reproductibles, ne peut pas fournir des niveaux de stress mesurables sur une application et constitue un processus impossible à coordonner.
  • Outils de test de charge développés en interne: Une organisation qui réalise l'importance des tests de charge peut créer ses propres outils pour exécuter des tests de charge.
  • Outils de test de charge open source: Il existe plusieurs outils de test de charge disponibles en open source et gratuits. Ils ne sont peut-être pas aussi sophistiqués que leurs homologues payants, mais si vous avez un budget limité, ils constituent le meilleur choix.
  • Outils de test de charge de classe entreprise: Ils sont généralement livrés avec une fonction de capture/lecture. Ils prennent en charge un grand nombre de protocoles. Ils peuvent simuler un nombre exceptionnellement grand d’utilisateurs.

Comment faire des tests de charge

Le processus de test de charge peut être brièvement décrit comme ci-dessous :

  1. Créer un espace dédié Environnement de test pour les tests de charge
  2. Définir les scénarios de test de charge
  3. Déterminer les transactions de test de charge pour une application
    • Préparer les données pour chaque transaction
    • Le nombre d'utilisateurs accédant au système doit être prédit
    • Déterminez les vitesses de connexion. Certains utilisateurs peuvent être connectés via des lignes louées tandis que d'autres peuvent utiliser une connexion commutée.
    • Déterminer les différents navigateurs et systèmes d'exploitation utilisés par les utilisateurs 
    • Une configuration de tous les serveurs comme les serveurs Web, d'applications et DB
  4. Exécution et suivi des scénarios de tests. Collecte de diverses métriques
  5. Analysez les résultats. Faire des recommendations
  6. Affiner le système
  7. Re-tester

Directives pour les tests de charge

Lignes directrices pour les tests de charge

  1. Les tests de charge doivent être planifiés une fois que l'application devient fonctionnellement stable.
  2. Un grand nombre de données uniques doivent être prêtes dans le pool de données
  3. Le nombre d'utilisateurs doit être décidé pour chaque scénario ou script
  4. Évitez la création de journaux détaillés pour conserver l'espace d'E/S disque
  5. Essayez d'éviter le téléchargement d'images sur le site
  6. Lors du processus d'exécution des cas de test de test de charge, la cohérence du temps de réponse sur la période écoulée doit être enregistrée et celle-ci doit être comparée avec diverses exécutions de tests.

Différence entre les tests de charge et de contrainte

test de charge Test de stress
Les tests de charge identifient les goulots d'étranglement dans le système sous diverses charges de travail et vérifient comment le système réagit lorsque la charge augmente progressivement. Test de stress détermine le point de rupture du système pour révéler le point maximum après lequel il se casse.
Pour reconnaître la limite supérieure du système, définissez le SLA de l'application et vérifiez comment le système peut gérer une charge importante. Pour vérifier comment le système se comporte sous des charges extrêmes et comment il se remet d'une panne.
Générer une charge accrue sur une application Web est l'objectif principal des tests de charge. Les tests de stress visent à garantir que sous une charge soudaine et élevée pendant une durée considérable, les serveurs ne tombent pas en panne.
Les attributs vérifiés lors d'un test de charge sont les performances maximales, la quantité de serveurs et le temps de réponse. Ce type de test vérifie le temps de réponse de stabilité, etc.
Lors des tests de charge, la limite de charge est un seuil de rupture. Lors des tests de résistance, la limite de charge est supérieure au seuil de rupture.

Différence entre les tests fonctionnels et de charge

Essais fonctionnels test de charge
Les résultats des tests fonctionnels sont facilement prévisibles car nous avons défini les étapes et les conditions préalables appropriées. Les résultats des tests de charge sont imprévisibles
Les résultats des tests fonctionnels varient légèrement Les résultats des tests de charge varient considérablement
Fréquence d'exécution Essais fonctionnels sera élevé La fréquence d'exécution des tests de charge sera faible
Les résultats des tests fonctionnels dépendent des données de test Les tests de charge dépendent du nombre d'utilisateurs.

Outils de test de charge

LoadRunner

LoadRunner, initialement développé par HP et faisant désormais partie de OpenText Suite à l'acquisition par Micro Focus, ce système teste les applications en conditions de charge normale et de pointe. Il génère une charge via des utilisateurs virtuels qui simulent le trafic réseau réel et présente les résultats sous forme graphique.

Lire la suite dans le Tutoriel LoadRunner.

Apache JMeter

Un open source Java Cet outil est l'option gratuite la plus utilisée. Il prend en charge HTTP, JDBC, JMS, FTP et bien plus encore, stocke les plans de test au format XML et s'intègre aux pipelines d'intégration continue. Voir la documentation. JMeter tutoriel pour une visite guidée.

Gatling

Un outil open-source dont les tests sont écrits sous forme de code en Scala ou JavaIl gère une forte concurrence sur du matériel modeste et produit des rapports HTML détaillés, ce qui convient aux équipes qui préfèrent les scripts de test versionnés.

k6

Un outil open-source avec des tests écrits en JavaScript conçu pour les tests de performance gérés par les développeurs au sein d'un pipeline CI plutôt que comme une activité d'assurance qualité distincte.

Choisir un outil

Choisissez JMeter Pour une couverture de protocoles la plus large possible sans frais, Gatling ou k6 lorsque l'équipe souhaite que les tests soient conservés dans le contrôle de version avec l'application, et un outil commercial tel que LoadRunner lorsque la prise en charge des protocoles d'entreprise et l'assistance du fournisseur justifient la licence.

Avantages et inconvénients des essais de charge

Voici les avantages des tests de charge :

  • Identification des goulots d’étranglement des performances avant la production
  • Améliore l’évolutivité du système
  • Minimiser les risques liés aux temps d’arrêt du système
  • Coûts d’échec réduits
  • Augmenter la satisfaction client

Inconvénients des tests de charge :

  • La plupart des outils nécessitent des connaissances en programmation pour élaborer des scénarios réalistes.
  • Les outils peuvent être coûteux car le prix dépend du nombre d'utilisateurs virtuels pris en charge.

Indicateurs clés à mesurer lors d'un test de charge

La section relative aux prérequis établit le temps de réponse comme principal indicateur. En pratique, un rapport de test de charge doit comporter six chiffres, car le temps de réponse seul ne permet pas d'expliquer un ralentissement du système.

Métrique Ce que ça te dit Panneau d'avertissement
Temps de réponse moyen L'expérience utilisateur typique Augmente avec la charge
temps de réponse au 95e percentile L'expérience des utilisateurs les plus lents Bien au-dessus de la moyenne
Cadence de production Requêtes traitées avec succès par seconde S'aplatir ou s'affaisser tandis que la charge augmente
Taux d'erreur Part des requêtes ayant échoué ou expiré Toute augmentation au-delà du seuil convenu
Utilisateurs concurrents Nombre réel de sessions simultanées réalisées Inférieur au scénario prévu
Utilisation des ressources du serveur marge de manœuvre du processeur, de la mémoire, du disque et du réseau Toute ressource supérieure à environ 80 %

Lisez le débit conjointement au temps de réponse. L'augmentation du temps de réponse avec l'augmentation du débit signifie simplement que le système est plus sollicité. L'augmentation du temps de réponse avec chute Un débit anormalement bas signifie que le système a dépassé sa capacité et qu'il perd désormais du travail ; c'est précisément ce que le test vise à détecter.

Ne jamais présenter uniquement la moyenne. Une moyenne de 900 ms, avec un 95e centile de 1.1 seconde, caractérise un système stable. En revanche, une moyenne identique, avec un 95e centile de 11 secondes, signifie qu'un utilisateur sur vingt rencontre une expérience inacceptable, ce que la moyenne masque.

Comment ce test se compare-t-il aux autres tests de performance ?

Les tests de performance constituent une famille de tests qui diffèrent par la forme de la charge appliquée, ce qui explique pourquoi ils sont si facilement confondus.

Type de test Qu'est-ce qui est augmenté ? Question à laquelle il répond
Test de charge Nombre d'utilisateurs simultanés, jusqu'au pic prévu Atteint-il ses objectifs en conditions de trafic de pointe normales ?
Tests de volume Données contenues dans la base de données Est-il capable de gérer l'augmentation de la taille de l'ensemble de données ?
Tests de résistance Surcharge au-delà de la capacité, jusqu'à défaillance Où se casse-t-elle, et comment ?
Test de pointe Chargement instantané et extrêmement rapide Peut-il survivre et se remettre d'un choc ?
Essais d'endurance Durée, à charge normale Les performances se dégradent-elles avec le temps ?
Test de trempage Durée, ressources de visionnage Existe-t-il des fuites de mémoire ou de descripteurs ?
Test de stabilité Conditions variables Reste-t-il fiable lorsque les conditions changent ?

La distinction qui compte le plus ici : Les tests de volume permettent de dimensionner les données, les tests de charge permettent de dimensionner les utilisateurs. Un rapport qui s'exécute en deux secondes pour dix mille lignes et en deux minutes pour dix millions de lignes présente un problème de volume, et non un problème de charge, et aucune augmentation de la capacité du serveur ne pourra le résoudre.

FAQ

Les tests de charge appliquent la charge de pointe prévue et vérifient que les objectifs sont atteints. Les tests de résistance dépassent délibérément la capacité pour identifier le point de rupture et confirmer que le système tombe en panne et se rétablit correctement.

Une fois l'application fonctionnellement stable, et suffisamment tôt pour qu'un goulot d'étranglement détecté puisse encore être corrigé. L'exécuter durant la dernière semaine ne laisse aucun temps pour agir sur les problèmes identifiés.

JMeterParce qu'il est gratuit, prend en charge un large éventail de protocoles et possède la documentation la plus complète. Passez à Gatling ou k6 si l'équipe préfère des tests écrits sous forme de code versionné.

L'IA déduit des profils de charge réalistes à partir des journaux de trafic de production, détecte automatiquement les anomalies dans les résultats et prédit quelles modifications de code sont susceptibles de dégrader les performances avant la planification d'une exécution.

Oui. Les outils d'IA convertissent les parcours utilisateurs enregistrés ou les spécifications d'API en scripts exécutables. Vérifiez les temps de réflexion générés et la paramétrisation des données, car des valeurs irréalistes produisent des résultats trompeurs.

Résumez cet article avec :