Qu'est-ce qu'un test d'évolutivité ? Apprendre avec l'exemple
Thomas Hamilton
⚡ Résumé intelligent
Les tests de scalabilité mesurent le comportement d'une application lorsque la charge utilisateur, le volume de données ou le taux de transactions augmentent ou diminuent, révélant le point précis où les performances cessent d'évoluer et identifiant le goulot d'étranglement responsable.
Qu'est-ce que les tests d'évolutivité ?
Tests d'évolutivité Les tests de scalabilité sont une méthode de test non fonctionnelle qui mesure les performances d'un système ou d'un réseau lorsque le nombre de requêtes utilisateur augmente ou diminue. Leur objectif est de garantir que le système peut gérer une augmentation prévue du trafic utilisateur, du volume de données et de la fréquence des transactions. Ils testent la capacité du système à répondre à une demande croissante.
Les tests de scalabilité sont un sous-type de Test de performanceElle se concentre donc sur le comportement d'une application lorsqu'elle est déployée sur un système plus vaste ou soumise à une charge excessive. Génie logicielLes tests de scalabilité mesurent le point auquel une application cesse de s'adapter et identifient la raison de ce phénomène.
Pourquoi effectuer des tests de scalabilité ?
Les problèmes de capacité apparaissent rarement lors des tests fonctionnels. Ils surgissent généralement lors des journées de forte activité, au lancement d'une campagne marketing ou lorsqu'un ensemble de données, dont la croissance a été discrète pendant deux ans, finit par ralentir chaque requête. Les tests de scalabilité permettent d'identifier ces limites dans un environnement contrôlé. Concrètement, ils vous aident à :
- Déterminez comment l'application évolue à mesure que la charge de travail augmente, et à quel moment cette courbe s'aplatit.
- Déterminez la limite d'utilisateurs simultanés pour l'application Web avant que les temps de réponse ne deviennent inacceptables.
- Déterminer la dégradation côté client et l'expérience de l'utilisateur final sous charge, comme par exemple un rendu d'écran lent.
- Déterminer la robustesse et la dégradation côté serveur, notamment la saturation du processeur, les fuites de mémoire et l'épuisement du pool de connexions.
La relation se représente plus facilement sous forme de courbe : le débit augmente avec la charge jusqu’à saturation des ressources, après quoi les utilisateurs supplémentaires ne font qu’allonger la file d’attente.
Types de tests d'évolutivité
La scalabilité n'est pas une propriété unique ; un plan de test couvre donc généralement plusieurs dimensions. Les quatre types ci-dessous sont ceux que la plupart des équipes mesurent, et les deux premiers déterminent la structure même de l'environnement de test.
| Type | Qu'est-ce qui est mis à l'échelle | Ce que prouve le test |
|---|---|---|
| Évolutivité verticale (montée en gamme) | Ajout de processeur, de mémoire ou de stockage à un seul serveur | Quelle quantité de charge supplémentaire une machine mise à niveau absorbe-t-elle, et où se situe la limite de performance d'un nœud unique ? |
| Évolutivité horizontale (mise à l'échelle) | Serveurs, conteneurs ou nœuds supplémentaires derrière un équilibreur de charge | Que le débit augmente à peu près proportionnellement au nombre de nœuds ajoutés, ou que les ressources partagées le plafonnent, |
| Évolutivité fonctionnelle | Nouvelles fonctionnalités, modules ou services | La possibilité d'intégrer les fonctionnalités supplémentaires sans dégrader les transactions existantes |
| Évolutivité administrative | Utilisateurs, locataires, équipes ou environnements à gérer | La question est de savoir si l'intégration, les autorisations et le suivi restent adaptés à mesure que l'organisation se développe. |
La mise à l'échelle verticale est plus simple car l'architecture évolue rarement, mais une machine unique a toujours ses limites. La mise à l'échelle horizontale lève ces limites et améliore la tolérance aux pannes, au prix d'une latence réseau, d'une incohérence des données et d'une surcharge de coordination — autant d'éléments que le test doit mesurer et non supposer.
Que tester lors des tests de scalabilité ?
La scalabilité s'évalue par des mesures, non par des impressions. Enregistrez les attributs suivants à chaque étape de chargement afin de visualiser la tendance, et pas seulement le résultat final.
| Attribut | Ce que ça te dit |
|---|---|
| Le temps de réponse | Délai entre une requête utilisateur et la réponse du système ; ce délai doit rester constant malgré l’augmentation du nombre de requêtes simultanées. |
| Transition d'écran | La rapidité avec laquelle une page ou une vue cède la place à la suivante sous charge |
| Cadence de production | Volume de requêtes traitées par unité de temps ; un plateau marque la limite de scalabilité |
| Mesures du temps | Durée de la session, temps de redémarrage, temps d'impression, temps de transaction et temps d'exécution de la tâche |
| Performances par rapport au nombre d'utilisateurs | Comment chaque indicateur évolue-t-il lorsque des utilisateurs simultanés sont ajoutés par incréments ? |
| tarifs de demande | Requêtes par seconde, transactions par seconde et accès par seconde |
| Utilisation du réseau | Bande passante consommée et latence des paquets entre les niveaux |
| Utilisation du processeur et de la mémoire | Coût des ressources par transaction ; un chiffre en constante augmentation signale souvent une fuite. |
| Compteurs de serveur Web | Requêtes et réponses par seconde, profondeur de la file d'attente et connexions rejetées |
| Performances sous charge | Comportement combiné une fois que toutes les métriques sont lues ensemble au pic |
Stratégie de test pour les tests de scalabilité
La stratégie de test pour les tests de scalabilité diffère selon le type d'application testée. Si une application accède à un base de donnéesLes paramètres de test incluront notamment la taille de la base de données par rapport au nombre d'utilisateurs.
Conditions préalables aux tests d'évolutivité
- Capacité de répartition de la charge — Vérifiez si l'outil de test de charge permet de générer la charge à partir de plusieurs machines et de la contrôler à partir d'un point central.
- Operating système — Vérifier ce systèmes d'exploitation les agents de génération de charge et le maître de test de charge s'exécutent sous.
- Processeur — Vérifiez le type de processeur requis pour l'agent utilisateur virtuel et le maître de test de charge.
- Mémoire — Vérifiez la quantité de mémoire nécessaire pour l'agent utilisateur virtuel et le serveur maître de test de charge.
- Environnement de test — Vérifiez que le environnement de test reflète suffisamment fidèlement la production pour que les résultats soient transposables.
Comment faire des tests d'évolutivité
- Définir un processus reproductible pour l'exécution des tests de scalabilité tout au long du cycle de vie de l'application
- Déterminer les critères d’évolutivité
- Présélectionnez les outils logiciels requis pour exécuter le test de charge
- Définir l'environnement de test et configurer le matériel requis pour exécuter les tests d'évolutivité
- Planifiez les scénarios de test ainsi que les tests de mise à l'échelle
- Créer et vérifier le script de l'utilisateur virtuel
- Créer et vérifier les scénarios de tests de charge
- Exécuter les tests
- Évaluer les résultats
- Générez les rapports requis
Plan de test d'évolutivité
Avant de créer les tests proprement dits, élaborez un plan de test détaillé. Cette étape est essentielle pour garantir la conformité des tests aux exigences de l'application.
Voici les attributs permettant de créer un Plan de test pour les tests d’évolutivité.
- Étapes pour les scriptsLe script de test doit comporter des étapes détaillées qui déterminent les actions exactes qu'un utilisateur effectuerait.
- Données d'exécutionLe plan de test doit déterminer toutes les données d'exécution nécessaires à l'interaction avec l'application.
- Tests basés sur les donnéesSi les scripts nécessitent des données variables lors de l'exécution, vous devez comprendre tous les champs qui requièrent ces données.
Exemple de test de scalabilité
Prenons l'exemple d'une boutique en ligne qui prévoit 2 000 clients simultanés pendant une période de soldes. L'équipe définit d'abord un critère de réussite : la transaction de paiement doit être finalisée en moins de trois secondes pour 95 % des utilisateurs, avec un taux d'erreur inférieur à 1 %.
Le test exécute ensuite le même script de navigation, de recherche, d'ajout au panier et de paiement avec 250, 500, 1 000, 1 500 et 2 000 utilisateurs virtuels. Le temps de réponse se maintient autour de deux secondes jusqu'à 1 000 utilisateurs, passe à 2.8 secondes à 1 500 utilisateurs et atteint neuf secondes à 2 000 utilisateurs, tandis que l'utilisation du processeur de la base de données se situe à 98 %. La limite de scalabilité est donc d'environ 1 500 utilisateurs, et le goulot d'étranglement se situe au niveau de la base de données, et non au niveau des serveurs d'application que l'équipe avait prévu d'ajouter.
Outils de test de scalabilité
Les tests de montée en charge nécessitent un outil capable de générer une charge à partir de plusieurs machines simultanément et de centraliser les résultats. Le choix de cet outil dépend généralement du langage principal de l'équipe et des protocoles testés.
| Outil | Scripting | Meilleur adapté à |
|---|---|---|
| Apache JMeter | Plans de test GUI et XML, Java basé | Large couverture des protocoles, notamment JDBC, JMS, LDAP et SOAP |
| Grafana k6 | JavaScénario ou TypeScript | Tests d'API et de microservices intégrés dans un pipeline CI/CD |
| Gatling | Java, DSL Kotlin ou Scala | Nombre élevé d'utilisateurs virtuels par injecteur avec des rapports HTML détaillés |
| Criquet | nature Python | Python les équipes qui ont besoin d'étendre le client au-delà du HTTP |
| LoadRunner | Scripts de type C enregistrés dans VuGen | Parcs d'applications d'entreprise de grande envergure avec des applications héritées et des progiciels. |
Les runners hébergés dans le cloud, tels que BlazeMeterLoadView et Gatling Enterprise s'appuient sur plusieurs de ces moteurs et méritent d'être envisagés lorsqu'un test nécessite des dizaines de milliers d'utilisateurs virtuels ou du trafic provenant de plusieurs régions géographiques. Un aperçu plus complet de cette catégorie est disponible dans le guide. outils de test de performances.
Défis et bonnes pratiques en matière de tests de scalabilité
Résultats de mise à l'échelle très décevants tracNous revenons à la configuration de test plutôt qu'à l'application. Ce sont là les problèmes récurrents et les habitudes qui permettent de les éviter.
Défis communs
- environnements sous-dimensionnés — Un banc d'essai doté de la moitié de la mémoire de production signale un goulot d'étranglement qui n'existe pas en production.
- Modèles de charge de travail irréalistes — Les scripts sans temps de réflexion ni variation de données accèdent à des caches que les vrais utilisateurs ne remarqueraient pas.
- Résultats bruyants — La mise à l'échelle automatique, le nettoyage de la mémoire et le matériel cloud partagé peuvent expliquer les différences entre deux exécutions identiques.
- observabilité mince — Sans indicateurs côté serveur, un résultat lent indique qu'il y a eu un problème, mais pas lequel.
- Prix — Générer une très forte concurrence nécessite sa propre flotte de générateurs de charge, qu'il est facile de sous-estimer dans le budget.
Meilleures pratiques
- Définissez les critères de réussite, tels qu'un percentile de temps de réponse et un plafond de taux d'erreur, avant le premier essai.
- Augmentez la charge par étapes planifiées et maintenez chaque étape suffisamment longtemps pour que le système se stabilise.
- Variez les données de test pour chaque utilisateur virtuel afin que la mise en cache n'influence pas les résultats.
- Collectez les indicateurs de performance des applications, des bases de données et de l'infrastructure, ainsi que les données côté client.
- Stockez les scripts de test dans un système de contrôle de version et effectuez un court test de scalabilité à chaque compilation, puis un test complet avant la mise en production.
- Comparer les tendances entre les différentes versions plutôt que de juger un seul rapport isolément.
Tests de montée en charge vs tests de charge
Ces deux tests sont souvent confondus car ils appliquent tous deux une charge. La différence réside dans la question à laquelle chacun répond : les tests de scalabilité s’intéressent à la capacité de croissance du système, tandis que les tests de scalabilité déterminent jusqu’où le système peut évoluer. test de charge demande s'il peut supporter la charge déjà prévue.
| Base | Tests d'évolutivité | test de charge |
|---|---|---|
| Focus | Elle se concentre sur les performances de vos sites web, logiciels, matériels et applications lorsque des modifications sont apportées à la taille ou au volume du système pour répondre à un besoin croissant. | Les tests de charge consistent à tester une application sous de fortes charges, afin de déterminer à quel moment le temps de réponse du système devient insuffisant. |
| Modèle de charge | La charge est augmentée par paliers, et des ressources peuvent être ajoutées entre les paliers. | La charge est maintenue à un niveau de pointe prévu pendant une durée fixe. |
| Réponse à la question | Jusqu'où ce système peut-il se développer, et quelles sont ses limites ? | Ce système atteint-il aujourd'hui les objectifs convenus ? |
| Sortie typique | Une limite d'évolutivité, un goulot d'étranglement et un plan de capacité | Réussite ou échec par rapport aux objectifs de temps de réponse et de débit |
Tous deux sont assis sous le tests non fonctionnels parapluie à côté tests de stress, tests de pointe, essais d'endurance et tests de volumeet une stratégie de performance mature consiste généralement à exécuter plusieurs de ces scripts sur les mêmes scripts.
