Im Test funktioniert alles, die Fachabteilung hat abgenommen – und am ersten Tag nach dem Go-live wird das neue Kundenportal unerträglich langsam. Funktional war die Software korrekt, unter echter Last aber nicht belastbar. Lasttests schließen genau diese Lücke. Dieser Artikel zeigt, wie Sie Lasttests so planen und auswerten, dass sie verlässliche Aussagen liefern statt beeindruckender, aber nutzloser Diagramme.
Ein Lasttest untersucht, wie sich ein System bei einer definierten, realistischen Anzahl gleichzeitiger Nutzer oder Transaktionen verhält. Gemessen werden vor allem Antwortzeiten, Durchsatz, Fehlerraten und die Auslastung von Ressourcen wie CPU, Arbeitsspeicher, Datenbankverbindungen oder Netzwerk. Die zentrale Frage lautet: Erfüllt die Anwendung ihre Anforderungen auch dann, wenn so viele Menschen gleichzeitig arbeiten wie im echten Betrieb erwartet?
Lasttests gehören zu den Performancetests und damit zu den nicht-funktionalen Tests. Sie ersetzen keine fachlichen Tests, sondern ergänzen sie: Eine Funktion, die bei einem Nutzer korrekt rechnet, kann bei hundert gleichzeitigen Anfragen durch Sperren in der Datenbank, erschöpfte Verbindungspools oder ungünstige Abfragen ausbremsen.
Im Projektalltag werden die Begriffe oft vermischt. Für die Planung lohnt sich eine klare Unterscheidung, weil jede Variante eine andere Frage beantwortet:
Nicht jedes Projekt braucht alle Varianten. Ein internes Fachverfahren mit planbarer Nutzerzahl kommt oft mit Last- und Dauertest aus; ein Online-Shop mit Aktionen braucht zusätzlich Spike- und Stresstests.
Der häufigste Grund für wertlose Lasttests ist ein fehlendes Ziel. „Das System soll schnell sein“ lässt sich nicht testen. Formulieren Sie Performance-Anforderungen deshalb so konkret wie fachliche Anforderungen: welche Transaktion, bei welcher Last, mit welcher maximalen Antwortzeit und welcher zulässigen Fehlerrate. Statt Durchschnittswerten sollten Perzentile verwendet werden – etwa „95 Prozent aller Suchanfragen werden unter einer festgelegten Zeit beantwortet“ –, weil ein guter Mittelwert lange Wartezeiten einzelner Nutzer verdecken kann.
Die Zahlen dafür kommen nicht aus dem Bauch, sondern vom Fachbereich und aus vorhandenen Daten: Zugriffsstatistiken des Altsystems, erwartete Nutzerzahlen, saisonale Spitzen, vertragliche Service-Level. Wer Anforderungen sauber erhebt, vermeidet später Diskussionen darüber, ob ein Testergebnis „gut genug“ ist. Wie das grundsätzlich gelingt, beschreibt unser Artikel Der unterschätzte Erfolgsfaktor: saubere Anforderungen.
Ein Lasttest ist nur so aussagekräftig wie das Nutzungsverhalten, das er nachbildet. Tausend Nutzer, die gleichzeitig dieselbe Startseite aufrufen, sagen wenig über den Betrieb aus. Ein gutes Lastprofil beschreibt:
Konzentrieren Sie sich auf die Abläufe, die geschäftskritisch sind oder viel Last erzeugen. Eine Handvoll gut gewählter Szenarien liefert mehr Erkenntnis als ein Skript für jede Maske der Anwendung.
Ergebnisse aus einer Umgebung, die deutlich kleiner ist als die Produktion, lassen sich nur eingeschränkt übertragen. Idealerweise entspricht die Lasttestumgebung der Produktion in Architektur, Konfiguration und Größenordnung. Wo das nicht möglich ist, sollten die Unterschiede dokumentiert und bei der Bewertung berücksichtigt werden.
Ebenso wichtig sind die Testdaten. Eine Datenbank mit wenigen hundert Datensätzen verhält sich anders als eine mit dem Datenbestand mehrerer Jahre. Planen Sie realistische Datenmengen ein und achten Sie darauf, dass personenbezogene Daten anonymisiert oder synthetisch erzeugt werden. Klären Sie außerdem früh, wie externe Schnittstellen behandelt werden: Echte Drittsysteme dürfen in der Regel nicht unter Last gesetzt werden und werden deshalb durch Simulationen ersetzt.
Werkzeuge wie JMeter, Gatling, k6 oder Locust erzeugen die Last, entscheidend ist aber, was parallel gemessen wird. Ohne Monitoring auf Server-, Datenbank- und Anwendungsebene sehen Sie nur, dass Antwortzeiten steigen, nicht warum. Bewährt hat sich folgendes Vorgehen:
Ein Lasttest liefert Messwerte, keine Lösungen. Die eigentliche Arbeit beginnt bei der Analyse: Steigen die Antwortzeiten gleichmäßig oder ab einem bestimmten Punkt sprunghaft? Welche Ressource ist zu diesem Zeitpunkt ausgelastet? Häufige Ursachen sind ineffiziente Datenbankabfragen, fehlende Indizes, zu kleine Verbindungspools, fehlendes Caching, synchrone Aufrufe langsamer Schnittstellen oder Sperrkonflikte bei gleichzeitigen Schreibzugriffen.
Die Auswertung sollte gemeinsam mit Entwicklung und Betrieb erfolgen. Am Ende steht ein Bericht, der klar beantwortet: Welche Anforderungen sind erfüllt, welche nicht, welche Risiken bestehen für den Go-live, und welche Maßnahmen werden empfohlen? Diese Aussage ist die Grundlage für die Freigabeentscheidung von Projektleitung und Fachbereich.
Wer Lasttests erst wenige Tage vor dem Go-live durchführt, hat kaum noch Zeit, grundlegende Architekturprobleme zu beheben. In agilen Projekten sollten Performance-Anforderungen deshalb Teil des Backlogs und der Definition of Done sein. Kleinere, automatisierte Performancetests einzelner Schnittstellen lassen sich in die CI/CD-Pipeline integrieren und machen Verschlechterungen sichtbar, sobald sie entstehen. Der umfassende Lasttest mit realistischem Lastprofil bleibt zusätzlich ein fester Termin vor größeren Releases. Wie sich Qualitätssicherung grundsätzlich in Sprints einbinden lässt, beschreibt unser Beitrag zu Regressionstests.
Lasttests sind kein Pflichtprogramm für das Projektende, sondern ein Werkzeug, um Risiken früh sichtbar zu machen. Mit messbaren Performance-Anforderungen, einem realistischen Lastprofil, einer belastbaren Testumgebung und einer gemeinsamen Auswertung liefern sie eine klare Grundlage für die Go-live-Entscheidung. Welche Rolle strukturierte Qualitätssicherung insgesamt für den Projekterfolg spielt, lesen Sie in Warum Qualitätssicherung über den Projekterfolg entscheidet.
Der Lasttest prüft, ob ein System bei erwarteter Normal- und Spitzenlast die vereinbarten Antwortzeiten einhält. Der Stresstest steigert die Last bewusst darüber hinaus, um die Belastungsgrenze zu finden und zu prüfen, ob sich das System dort kontrolliert verhält.
Vor dem Go-live einer neuen Anwendung, vor erwarteten Lastspitzen sowie nach größeren Änderungen an Architektur, Infrastruktur oder Datenbank. In agilen Projekten ergänzen kleinere automatisierte Performancetests in der CI/CD-Pipeline die großen Lasttests.
Verbreitet sind unter anderem JMeter, Gatling, k6 und Locust. Wichtiger als das Werkzeug sind ein realistisches Lastprofil, eine produktionsnahe Testumgebung und ein begleitendes Monitoring, das Engpässe sichtbar macht.
30 Minuten Erstgespräch — kostenlos und unverbindlich. Wir schauen gemeinsam auf Ihre Performance-Anforderungen und zeigen, wie ein aussagekräftiger Lasttest für Ihr System aussieht.
Jetzt Erstgespräch vereinbarenMehr zu unserer Leistung: Software-Qualitätssicherung in Hamburg →
Passend dazu: Testautomatisierung einführen in 6 Schritten →