Qu'est-ce que le Volume Testing ?

Qu'est-ce que le volume testing ?

Le volume testing (test de volumétrie) est un test de performance où le système est soumis à de grands volumes de données, la taille des données étant la variable que vous modifiez. Le nombre d'utilisateurs reste réaliste pendant que les bases de données, les stockages de fichiers et les files grossissent, pour observer l'effet sur le temps de réponse, la mémoire et le disque. On parle parfois de flood testing.

C'est une discipline du chemin des données, pas de la concurrence. Un seul utilisateur qui exporte cinq ans de commandes constitue déjà un test de volume.

Pour un exemple détaillé, les outils et la lecture de la courbe, voir volume testing in software testing sur le blog LoadFocus (en anglais).

Volume testing et test de charge

Les deux sont des tests de performance, mais ils font varier des choses différentes. Un test de charge fixe les données et fait monter la concurrence : que se passe-t-il quand 5 000 utilisateurs arrivent sur un système de taille normale ? Un test de volume fixe la concurrence et fait monter les données : que se passe-t-il quand le même système contient cent fois plus de lignes ? Réussir l'un en dit peu sur l'autre. Un système peut passer tous les tests de charge sur une petite base de préproduction et échouer en production, où les tables sont bien plus grosses.

Deux voisins se confondent facilement avec lui. Le test de capacité cherche la charge maximale supportée, et le test de scalabilité demande comment le système se comporte quand on ajoute des ressources ou du trafic. Le test de volume garde l'infrastructure et le trafic fixes et ne fait croître que les données.

Comment se déroule un test de volume

1. Construire des données réalistes à plusieurs tailles. Restaurez une sauvegarde récente sur une copie de test, ou générez des enregistrements bien répartis (nombreux clients, dates et statuts). Retirez d'abord les données personnelles.
2. Rejouer la même charge à chaque taille. Un nombre fixe d'utilisateurs virtuels, les mêmes opérations.
3. Comparer les courbes. Tracez le temps de réponse p95, la mémoire et le disque en fonction de la taille des données. Une valeur qui croît plus vite que les données est le résultat.

Exemple (chiffres hypothétiques) : une boutique en ligne compte 50 000 commandes et en attend 2 millions d'ici deux ans. On teste avec 50 000, 2 millions et 10 millions de commandes. À chaque taille, on rejoue le même mélange d'historiques de commandes, de recherches d'administration et de nouvelles commandes, et on compare le p95 de chaque opération. Si la recherche d'administration reste plate jusqu'à 2 millions puis saute, vous avez trouvé la taille à partir de laquelle sa requête n'utilise plus d'index.

Ce qui casse avec de gros volumes de données

• Index manquants ou inutilisés. Une requête instantanée à 10 000 lignes peut parcourir toute la table à 10 millions, et les plans d'exécution peuvent changer quand les tables grossissent.
• Résultats non bornés. Du code qui charge une table entière pour la filtrer ou la compter en mémoire.
• Pagination et comptage. "Page 1 sur N" oblige à compter les lignes, et les décalages profonds ralentissent à chaque page.
• Exports, rapports et migrations. Souvent écrits sur un jeu de données de développement et jamais revus.
• Files d'attente. Un gros retard ou un seul message défectueux peut bloquer des consommateurs qui n'ont jamais vu plus de quelques éléments.
• Sauvegardes, restaurations et reconstruction d'index. Leur durée croît avec les données et ne se découvre souvent que pendant un incident.

Erreurs fréquentes

• Tester une seule taille. Un point ne montre pas une courbe. Utilisez au moins trois tailles.
• Données irréalistes. Des millions de lignes identiques sollicitent le cache et l'index tout autrement que des données réelles.
• Ignorer l'avenir. Testez la taille attendue dans un à deux ans, pas seulement l'actuelle.
• Seulement le cas nominal. Testez les chemins lents : rapports, exports, imports en masse, tâches de fond.
• Utiliser des données de production non masquées. Masquez les données personnelles dans toute copie.

Volume testing, supervision et LoadFocus

LoadFocus fournit le trafic, pas les données : vous préparez le gros jeu de données dans votre environnement de test, puis lancez dessus un test de charge de taille fixe avec k6 ou JMeter et comparez les percentiles de temps de réponse d'une exécution à l'autre. Gardez le même nombre d'utilisateurs pour que seules les données changent. Le volume testing se distingue du soak testing, qui maintient la charge pendant des heures pour trouver des fuites : voir endurance et soak testing (en anglais). Après la mise en production, la supervision d'API montre si les endpoints testés restent rapides à mesure que les données réelles grossissent.

Questions fréquentes

Quelle différence entre volume testing et test de charge ?

Le volume testing augmente la quantité de données à nombre d'utilisateurs constant. Le test de charge augmente le nombre d'utilisateurs simultanés à données constantes.

Le volume testing est-il la même chose que le test de stress ?

Non. Le test de stress pousse la charge utilisateur au-delà de la limite pour trouver le point de rupture. Le volume testing pousse la taille des données, et les défaillances sont autres : requêtes lentes, pression mémoire, traitements longs.

Avec quel volume de données tester ?

Prenez la taille actuelle de production comme point bas, la taille attendue dans un à deux ans comme point médian et un chiffre supérieur comme marge. Comparez les résultats entre tailles plutôt que de juger une seule exécution.

Peut-on faire un test de volume en production ?

C'est plus sûr sur une copie aux données de taille réelle, avec les données personnelles masquées. Remplir la production de données de test met en danger les enregistrements et rapports réels.