Qu'est-ce que le Volume Testing ?

Qu'est-ce que le volume testing ?

Le volume testing mesure comment un système se comporte quand les données qu'il gère sont très grandes : une table de base de données avec 500 millions de rows, un upload de fichier de 5 GB, une queue avec 10 millions de messages en backlog, un index de recherche de 50 millions de documents. Le but est de trouver le failure mode qui apparaît seulement à l'échelle des données : une query qui utilise un index à 1 million de rows mais un sequential scan à 100 millions ; un endpoint streaming qui bufferise le payload entier en mémoire ; un queue consumer qui bloque sur un seul poison message à depth 8 millions.

Le volume testing est une discipline data-path, pas une discipline de concurrence. Un seul utilisateur uploadant un fichier de 10 GB ou lançant un rapport sur 5 ans de données est un volume test même si la concurrence est 1.

Volume testing vs load testing

Les deux stressent le système mais selon des axes différents :

• Volume testing : fixer la concurrence, scaler la taille des données. Demande "que se passe-t-il quand la table fait 1 milliard de rows ou le message body fait 100 MB ?"
• Load testing : fixer la taille des données, scaler la concurrence. Demande "que se passe-t-il quand 10 000 utilisateurs hit un request normal simultanément ?" Voir load testing.

Tu as besoin des deux. Un système peut passer les load tests avec un petit dataset staging et collapser immédiatement en production où la table customers est 100x plus grande. Le failure classique : un developer écrit une query ORM qui produit un execution plan propre sur 10 000 rows, et en production elle fait un full table scan qui lock la table pendant 4 minutes. Les volume tests attrapent ça ; les load tests non.

Quand lancer des volume tests

• Avant une migration de données : staging a 1 GB de données, production a 1 TB. Le script de migration qui tourne en 30 secondes sur staging peut tourner 8 heures sur production.
• Avant d'ajouter bulk import ou export : CSV upload, bulk API, export data warehouse. L'endpoint qui gère 1 000 rows peut OOM à 100 000.
• Avant qu'une feature reporting ne shippe : une query qui agrège sur 5 ans de transactions à full row count se comporte différemment de la même query sur un dataset test.
• Quand les données client grandissent substantiellement : le premier client enterprise s'onboarde avec 200x le dataset de n'importe quel client précédent.
• En upgradant les versions de base de données : les query planners Postgres ou MySQL peuvent changer de comportement à row counts élevés. Volume test l'upgrade contre une copie.
• Avant de changer de storage backend : S3 vers disque local, single-region vers multi-region, primary-replica vers sharded. Les volume tests font remonter les hypothèses de data plane qui se sont cassées.

Volume failure modes à chercher

1. Flips de query plan : la base de données arrête d'utiliser un index au-dessus d'un certain row threshold et commence à scanner. Attraper avec EXPLAIN ANALYZE à row counts de production.
2. Pression mémoire sur des code paths streaming : code qui devrait streamer une réponse bufferise en fait le result set complet en mémoire.
3. Escalation de locks : un row-level lock qui escalate vers un table lock à row counts élevés.
4. Collapse de pagination : pagination basée sur OFFSET qui coûte O(N) par page, devient inutilisable passé page 10 000.
5. Starvation de queue consumer : un poison message à queue depth 8 millions bloque chaque consumer derrière.
6. Fenêtre de backup explosée : un backup nightly qui finit en 20 minutes sur staging prend 12 heures sur les données de production.
7. Temps de rebuild d'index : drop et recreate d'un index sur une table est instantané à 100k rows, lock la table pendant 6 heures à 100 millions.

Comment lancer les volume tests

Construire un dataset à taille production (un backup récent restauré sur une copie staging est le chemin le plus facile ; redact PII d'abord). Lancer le workload ciblé : un seul utilisateur hit l'endpoint de bulk import, le batch job nightly, la query reporting, le queue consumer avec un vrai backlog. Mesurer temps d'exécution, peak mémoire, durée de locks et erreurs.

Le volume testing complémente le load testing, le soak testing et le capacity testing. Chacun attrape une classe différente de failures : load tests attrapent les bugs de concurrence, soak tests attrapent les memory leaks dans le temps, volume tests attrapent les bugs de data scale.

Pour les workloads qui ont besoin de données full-production-shape plus charge concurrente (le cas réaliste), LoadFocus propose des services de load testing où des ingénieurs conçoivent la matrice de test combinant volume de données et charge concurrente.