Qu'est-ce que le test de volume ? Apprendre avec des exemples

Par : Thomas Hamilton Thomas Hamilton
Hours Le kit de préparation mis à jour

⚡ Résumé intelligent

Les tests de charge consistent à soumettre une application à une très grande quantité de données afin d'observer le comportement du stockage, des requêtes et des temps de réponse à mesure que la base de données s'agrandit. Également appelés tests de saturation, ils mettent à l'échelle le volume de données plutôt que le nombre d'utilisateurs.

  • (I.e. Définition principale : Le volume de données augmente tandis que la charge utilisateur reste normale.
  • 🔍 Contrôles primaires : Perte de données, écrasement silencieux, précision du stockage et temps de réponse avec un grand ensemble de données.
  • 📈 Point de dégradation : Le test permet de déterminer le volume à partir duquel la stabilité et les performances commencent à se dégrader.
  • ️ Test de charge non effectué : Le volume mesure la taille des lignes et des fichiers ; la charge mesure le nombre d’utilisateurs simultanés. Ces deux mesures détectent des défauts différents.
  • 🧪 Réalisme des données : Les données générées doivent respecter les clés et l'intégrité relationnelle, ce qui constitue la partie la plus difficile du test.
  • ???? Business case: Les limites de capacité déterminées avant la mise sur le marché coûtent beaucoup moins cher que les mêmes limites constatées en production.
En savoir plus

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

Qu’est-ce que le test de volume ?

Tests de volume est un type de test de logiciel, dans lequel le logiciel est soumis à un énorme volume de données. On l'appelle également tests d'inondation. Des tests de volume sont effectués pour analyser les performances du système en augmentant le volume de données dans la base de données.

Grâce aux tests de volume, l'impact sur le temps de réponse et le comportement du système peut être étudié lorsqu'il est exposé à un volume élevé de données.

Par exemple, un service de streaming musical pourrait être testé avec un catalogue de 50 millions de titres. tracks et une table d'historique d'écoute contenant des milliards de lignes, pour voir si les requêtes de recherche et de recommandation renvoient toujours un résultat dans un délai acceptable.

Notez la distinction : Les tests en volume augmentent le quantité de données le système tient bon. Augmenter le nombre d'utilisateurs simultanés Il s'agit d'un test de charge, qui est un test différent avec un objectif différent.

Avantages des tests de volume

  • Identifier les problèmes de capacité au plus tôt permet d'éviter les coûts bien plus élevés liés à leur résolution en production.
  • Cela permet un démarrage plus rapide des plans d’évolutivité
  • Identification précoce des goulots d'étranglement
  • Il garantit que votre système est désormais capable d'être utilisé dans le monde réel

Pourquoi effectuer des tests de volume ?

L'objectif de la réalisation des tests de volume est de

  • Vérifiez les performances du système avec des volumes croissants de données dans la base de données
  • Identifiez les problèmes susceptibles d'apparaître lorsque l'ensemble de données deviendra volumineux.
  • Comprendre le point auquel la stabilité du système se dégrade
  • Les tests de volume aideront à identifier la capacité du système ou de l’application – volume normal et important

Comment effectuer des tests de volume

Lors des tests en volume, les éléments suivants doivent être testés

  • Testez pour vérifier s'il y a une perte de données
  • Vérifiez le temps de réponse du système
  • Vérifiez si les données sont stockées correctement ou non
  • Vérifiez si les données sont écrasées sans aucune notification
  • Vérifiez que les avertissements et les messages d'erreur s'affichent effectivement lorsqu'une limite de volume est atteinte.
  • Vérifiez si un volume élevé de données affecte la vitesse de traitement
  • Vérifiez que le système dispose des ressources de mémoire et de stockage requises par le volume.
  • Vérifiez que le test de volume couvre l'ensemble du système et non un seul composant.
  • Y a-t-il un risque si le volume de données est supérieur à celui spécifié
  • Vérifier s'il existe une garantie que le volume de données ne dépassera pas le maximum spécifié.

Meilleures pratiques pour les tests à volume élevé

Plusieurs des pratiques ci-dessous sont communes aux tests de charge, car les deux sont généralement exécutés dans le même environnement. Les pratiques spécifiques aux volumes concernent l'ensemble de données lui-même :

  • Arrêtez tous les serveurs et vérifiez tous les journaux
  • Avant le test de charge, exécutez manuellement le scénario d'application
  • Pour obtenir des résultats plus utiles, échelonnez le nombre d’utilisateurs
  • Pour surmonter les contraintes de licence, équilibrez le temps de réflexion
  • Soyez prudent avec la nouvelle construction
  • Analyser le cas d'utilisation à améliorer une fois qu'une référence a été établie
  • La répétition de parties particulières des tests de volume devient inévitable en cas de goulot d'étranglement en termes de performances.

ARTICLES LIÉS

Tests de volume vs tests de charge

Tests de volume test de charge
  • Les tests de volume vérifient le comportement d'une application lorsque la base de données contient une très grande quantité de données.
  • Lors des tests de charge, l'application est soumise à un certain niveau de charge pour analyser le comportement de l'application.
  • Les tests de volume vérifient que le système répond toujours correctement à un volume de données donné. Ils consistent généralement à augmenter la taille des fichiers et des tables.
  • Les tests de charge vérifient les performances lorsque le nombre d'utilisateurs simultanés augmente. Ils augmentent généralement le nombre de requêtes simultanées.

Défis liés aux tests de volume

  • Fragmentation de la mémoire difficile à générer
  • Génération dynamique de clés
  • Relationnel Integrity de données générées

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.

Comment générer des données de test pour les tests de volume

La section consacrée aux défis souligne que la génération de données réalistes constitue la partie la plus complexe des tests de volume. Quatre approches sont utilisées en pratique, chacune impliquant un compromis.

Approche Le réalisme Inconvénient principal
Copie des données de production Le plus élevé Exposition à la confidentialité et à la conformité
Copie de production masquée Haute Le masquage peut rompre l'intégrité référentielle
génération synthétique Moyenne Les distributions peuvent ne pas correspondre à la réalité
Trafic de production rejoué Haute Nécessite une infrastructure de capture

Quel que soit le chemin emprunté, trois propriétés doivent être vérifiées, sinon le test ne mesure rien d'utile.

  • Intégrité référentielle. Chaque clé étrangère doit être résolue. Un million de lignes orphelines sollicitent le moteur de stockage, mais n'affectent jamais les chemins de jointure réellement utilisés par l'application.
  • Cardinalité réaliste. Si la table de production comporte dix millions de lignes réparties sur deux cents clients, la génération de dix millions de lignes réparties sur dix millions de clients produit des plans de requêtes complètement différents.
  • Distribution réaliste. Les données réelles sont asymétriques. Des données aléatoires uniformes masquent les partitions surchargées et les conflits d'index qui provoquent des incidents de production.

Un avertissement pratique concernant la protection de la vie privée. La copie de données de production dans un environnement de test est la cause la plus fréquente de fuite de données lors des tests. Il est impératif de masquer les champs personnels avant que la copie ne quitte l'environnement de production, et non après.

FAQ

Les tests de volume augmentent la quantité de données dans le système tandis que la charge utilisateur reste normale. Les tests de charge augmentent le nombre d'utilisateurs simultanés tandis que le volume de données reste constant. Ils révèlent différents goulots d'étranglement ; les deux sont donc nécessaires.

Partez du volume de données projeté à la fin de l'horizon de capacité prévu, généralement deux à trois ans de croissance, puis effectuez des tests à ce chiffre et à son double pour déterminer à partir de quel point la dégradation commence.

Index manquants ou inefficaces, requêtes dont la taille évolue de manière non linéaire, saturation du stockage, troncature silencieuse des champs et traitements par lots dont la durée d'exécution dépasse la fenêtre disponible.

Les modèles d'IA apprennent la distribution statistique et les relations des données de production, puis génèrent des enregistrements synthétiques qui préservent ces propriétés sans exposer aucun enregistrement client réel.

Oui, dans une certaine mesure. Les modèles ajustés aux courbes de dégradation mesurées extrapolent le point de défaillance, mais la projection doit être confirmée par un essai réel avant de servir de base à une décision concernant la capacité.

Résumez cet article avec :