Was ist Volume Testing?

Was ist Volume Testing?

Volume Testing (Volumentest) ist ein Performance-Test, bei dem das System sehr großen Datenmengen ausgesetzt wird. Die Datenmenge ist die Variable, die Sie verändern. Die Nutzerzahl bleibt realistisch, während Datenbanken, Dateispeicher und Warteschlangen wachsen, sodass Sie sehen, was mit Antwortzeit, Speicher und Festplatte passiert. Manchmal heißt er auch Flood Testing.

Es geht um den Datenpfad, nicht um Gleichzeitigkeit. Ein einzelner Nutzer, der fünf Jahre Bestellungen exportiert, ist bereits ein Volumentest.

Ein ausgearbeitetes Beispiel, Werkzeuge und die Auswertung der Messkurve finden Sie im Blogartikel Volume Testing in Software Testing (auf Englisch).

Volume Testing und Lasttest im Vergleich

Beide sind Performance-Tests, variieren aber Verschiedenes. Ein Lasttest hält die Daten fest und skaliert die Gleichzeitigkeit: Was passiert, wenn 5.000 Nutzer auf ein normal großes System treffen? Ein Volumentest hält die Gleichzeitigkeit fest und skaliert die Daten: Was passiert, wenn dasselbe System hundertmal so viele Zeilen enthält? Das Bestehen des einen sagt wenig über das andere. Ein System kann jeden Lasttest gegen eine kleine Staging-Datenbank bestehen und in Produktion mit viel größeren Tabellen trotzdem scheitern.

Zwei Nachbarn werden leicht verwechselt. Der Kapazitätstest sucht die maximale tragbare Last, und der Skalierbarkeitstest fragt, wie sich das System bei mehr Ressourcen oder Traffic verhält. Beim Volumentest bleiben Infrastruktur und Traffic fest, nur die Daten wachsen.

So läuft ein Volumentest ab

1. Realistische Daten in mehreren Größen aufbauen. Ein aktuelles Backup in eine Testkopie einspielen oder Datensätze mit realistischer Streuung erzeugen (viele Kunden, Daten, Status). Personenbezogene Daten vorher entfernen.
2. Bei jeder Größe dieselbe Last fahren. Feste Zahl virtueller Nutzer, dieselben Abläufe.
3. Kurven vergleichen. p95-Antwortzeit, Speicher- und Plattenverbrauch über der Datenmenge auftragen. Ein Wert, der schneller wächst als die Daten, ist der Befund.

Beispiel (hypothetische Zahlen): Ein Onlineshop hat 50.000 Bestellungen und erwartet in zwei Jahren 2 Millionen. Getestet wird mit 50.000, 2 Millionen und 10 Millionen Bestellungen. Bei jeder Größe läuft derselbe Mix aus Bestellhistorie, Admin-Suche und neuen Bestellungen, und das p95 jeder Operation wird verglichen. Bleibt die Admin-Suche bis 2 Millionen flach und springt dann, haben Sie die Größe gefunden, ab der ihre Abfrage keinen Index mehr nutzt.

Was bei großen Datenmengen kaputtgeht

• Fehlende oder ungenutzte Indizes. Eine Abfrage, die bei 10.000 Zeilen sofort antwortet, kann bei 10 Millionen die ganze Tabelle lesen, und Abfragepläne können sich mit wachsenden Tabellen ändern.
• Unbegrenzte Ergebnismengen. Code, der eine ganze Tabelle lädt, um sie im Speicher zu filtern oder zu zählen.
• Paginierung und Zählen. "Seite 1 von N" erfordert das Zählen aller Zeilen, und tiefe Offsets werden mit jeder Seite langsamer.
• Exporte, Berichte und Migrationen. Meist gegen einen Entwicklungsdatensatz geschrieben und nie überprüft.
• Warteschlangen. Ein großer Rückstau oder eine einzige fehlerhafte Nachricht kann Consumer blockieren, die nie mehr als wenige Einträge gesehen haben.
• Backups, Wiederherstellung und Index-Neuaufbau. Ihre Dauer wächst mit den Daten und fällt oft erst im Störfall auf.

Häufige Fehler

• Nur eine Größe testen. Ein Messpunkt zeigt keine Kurve. Nutzen Sie mindestens drei Größen.
• Unrealistische Daten. Millionen identischer Zeilen belasten Cache und Index ganz anders als echte Daten.
• Die Zukunft ignorieren. Testen Sie die Größe, die Sie in ein bis zwei Jahren erwarten, nicht nur die heutige.
• Nur der Normalfall. Testen Sie die langsamen Pfade: Berichte, Exporte, Masseneinträge, Hintergrundjobs.
• Produktionsdaten ungeschützt verwenden. Maskieren Sie personenbezogene Daten in jeder Kopie.

Volume Testing, Monitoring und LoadFocus

LoadFocus liefert den Traffic, nicht die Daten: Sie bereiten den großen Datenbestand in Ihrer Testumgebung vor, fahren dagegen einen Lasttest fester Größe mit k6 oder JMeter und vergleichen die Antwortzeit-Perzentile zwischen den Läufen. Halten Sie die Nutzerzahl konstant, damit sich nur die Daten ändern. Vom Volumentest zu trennen ist der Soak-Test, der Last über Stunden hält, um Lecks zu finden: siehe Endurance- und Soak-Testing (englisch). Nach dem Release zeigt API-Monitoring, ob die getesteten Endpunkte mit wachsenden Echtdaten schnell bleiben.

Häufige Fragen

Was ist der Unterschied zwischen Volume Testing und Lasttest?

Volume Testing vergrößert die Datenmenge bei konstanter Nutzerzahl. Der Lasttest vergrößert die Zahl gleichzeitiger Nutzer bei konstanter Datenmenge.

Ist Volume Testing dasselbe wie Stresstest?

Nein. Ein Stresstest treibt die Nutzerlast über die Grenze, um die Bruchstelle zu finden. Volume Testing treibt die Datenmenge, und die Fehlerbilder sind andere: langsame Abfragen, Speicherdruck, lange Jobs.

Mit wie vielen Daten sollte ich testen?

Nehmen Sie die heutige Produktionsgröße als unteren Punkt, die erwartete Größe in ein bis zwei Jahren als mittleren und einen größeren Wert als Reserve. Vergleichen Sie die Ergebnisse über die Größen hinweg, statt einen einzelnen Lauf zu bewerten.

Kann ich einen Volumentest in Produktion fahren?

Sicherer ist eine Kopie mit Daten in Produktionsgröße und maskierten personenbezogenen Daten. Testdaten in der Produktion riskieren echte Datensätze und Berichte.