Leistungstests

Übersicht Leistungstest

Ein Leistungstest platziert eine definierte Anzahl gleichzeitiger Benutzer oder Anfragen auf einer Website, Webanwendung oder API, erhöht diese Last entlang einer geplanten Kurve und zeichnet auf, was sich ändert: Antwortzeiten, Durchsatz, Fehlerrate und wie viel Server-, Datenbank- und Netzwerkkapazität das System zur Aufrechterhaltung benötigt. Das Ergebnis ist eine Zahlenreihe, die mit einem Zielwert verglichen wird, und kein Eindruck davon, wie schnell sich die Seite anfühlt.

Das Ziel kann eine öffentliche Seite, ein authentifizierter Ablauf durch ein Portal oder eine SaaS-Anwendung, eine Folge von API-Aufrufen oder eine interne Webanwendung hinter einer Firewall sein.

Das Ziel ist nicht, eine Webseite generell schnell zu machen. Es geht darum zu bestätigen, dass ihre wichtigsten Seiten, Workflows und API-Aufrufe definierte Anforderungen bei erwarteten Verkehrsniveaus erfüllen. Ein Checkout kann für einen Benutzer normal funktionieren, aber verlangsamen oder timeouten, wenn Hunderte von Kunden gleichzeitig Bestellungen aufgeben.

Funktionstests bestätigen, dass eine Seite oder Transaktion korrekt funktioniert. Leistungstests messen, ob sie schnell, stabil und zuverlässig bleibt, wenn der Verkehr zunimmt.

Was können Sie leistungsseitig testen?

Leistungstests decken üblicherweise vier HTTP/S-Ziele ab: Websites, Webanwendungen, APIs und interne Webanwendungen. Jedes benötigt unterschiedliche Skripte und Messungen.

Warum Leistungstest wichtig ist

Der Wert eines Leistungstests liegt in einer präzisen Antwort, die vor Benutzern auf das Problem aufmerksam macht:

• Engpässe tauchen vor der Veröffentlichung auf. Eine langsame Abfrage oder ein unterdimensionierter Verbindungspool erscheint im Testbericht statt in der Supportwarteschlange.
• Kapazitäts- und Skalierungspläne werden verifiziert. Auto-Skalierungsregeln, CDN-Cache-Einstellungen und Instanzgrößen sind Annahmen, bis der Verkehr sie bestätigt.
• Die umsatzrelevanten Abläufe bleiben geschützt. Login, Suche, Checkout, Datei-Upload und die dahinter liegenden API-Aufrufe sind zuerst zu testen.
• Spitzenereignisse führen zu weniger Verzögerungen, Fehlern und Ausfällen. Produktstarts, Kampagnen, Anmeldefenster und saisonale Verkäufe haben oft vorhersehbare Verkehrsmuster, die vorher getestet werden können.
• Regressionen werden erkannt. Änderungen an Code, API, Datenbank, Infrastruktur und externen Diensten beeinflussen die Performance leicht, und die Drift summiert sich über Releases.
• Freigabeentscheidungen und Service-Level-Ziele erhalten Belege. Eine p95-Metrik gegenüber eines Ziels ist handlungsorientierter als die Meinung, die Seite “fühle sich langsam an”.

Arten von Leistungstests

Jede Art wendet Verkehr in unterschiedlicher Form an, um eine andere Frage zu beantworten. Die meisten Programme kombinieren mehrere.

Dauertests und Soak-Tests sind zwei Begriffe für denselben Test, nicht zwei Typen. Die Grenze zwischen Last- und Stresstest ist die, die Teams am häufigsten verwischen, weshalb sie eine eigene Seite hat: Lasttest vs. Stresstest.

Leistungstest ist die Oberkategorie. Jeder untergeordnete Typ ändert, wie viel Verkehr ankommt, wie schnell und wie lange.

Leistungstest vs. Lasttest

Leistungstest ist die breitere Praxis, Geschwindigkeit, Stabilität, Skalierbarkeit und Ressourcennutzung unter verschiedenen Bedingungen zu bewerten. Lasttest ist eine Form des Leistungstests, der sich auf erwarteten und Spitzenverkehr konzentriert.

Die Begriffe werden oft synonym verwendet, weil der Lasttest häufig der erste Leistungstest ist, den Teams durchführen. Andere Testtypen sind nötig, um Ausfallpunkte, langfristige Verschlechterungen oder Skalierungsprobleme zu finden.

Für einen Vergleich, der auch Stresstests einschließt, lesen Sie Leistungstest vs. Stresstest vs. Lasttest.

Wie man Leistungstests durchführt

Die folgenden Schritte gelten für eine Landingpage, einen Checkout-Prozess oder eine authentifizierte API-Sequenz.

1. Ziel und Akzeptanzkriterien definieren

Formulieren Sie, was der Test beweisen muss, in Zahlen. Beispiele: p95-Antwortzeit unter 2 Sekunden für Checkout bei 1.500 gleichzeitigen Benutzern; Fehlerrate unter 0,5 %; die Bestell-API bewältigt 400 Transaktionen pro Sekunde. Ein Test ohne Bestehen/Nichtbestehen-Kriterien liefert Daten, aber keine Entscheidung.

2. Modellieren Sie den Website-, Anwendungs- oder API-Verkehr

Nutzen Sie Web-Analytics, Zugriffsprotokolle, APM-Daten und Geschäftsvorhersagen. Identifizieren Sie die kritischen Seiten oder Abläufe, wie sich der Verkehr aufteilt, Spitzenkonkurrenz, Anfragefrequenzen, Denkzeit zwischen Schritten, geografische Verteilung und API-Aufrufe pro Sitzung. Seitenaufrufe sind nicht gleich gleichzeitige Benutzer: 100.000 tägliche Seitenaufrufe können eine Spitze von einigen Hundert gleichzeitigen Sitzungen bedeuten; das Modell sollte angeben, welche.

3. Erstellen Sie eine repräsentative Testumgebung

Spiegeln Sie den Produktiv-Webstack, die Anwendungsversion, Datenbankgröße, CDN- und Cache-Verhalten, API-Abhängigkeiten, Integrationen und Skalierungsregeln möglichst genau nach. Verwenden Sie sichere Testkonten und Zahlungssandboxes. Wo Unterschiede nötig sind, dokumentieren Sie diese, damit das Ergebnis nicht als Produktionsgarantie fehlinterpretiert wird.

4. Wählen Sie Testtyp und Testmethode

Wählen Sie Last-, Stress-, Spike-, Dauer-, Volumen-, Skalierbarkeits- oder einen Kombinationstest basierend auf der Frage aus Schritt 1. Entscheiden Sie dann, wie Sie den Verkehr erzeugen. HTTP/S-Tests senden Anfragen direkt und sind effizient bei hohem Volumen gegen Seiten und APIs. Echtbrowser-Tests führen JavaScript aus und simulieren mehrstufiges Benutzerverhalten, messen also, wie lange eine Person wartet. Viele Teams kombinieren Protokolltests für Skalierung und eine kleinere Gruppe Echtbrowser-Tests für Benutzererfahrung.

5. Basislinie festlegen

Führen Sie einen kontrollierten Test mit moderater Last vor Änderungen durch. Das bestätigt, dass das Skript vollständig läuft, die Testdaten gültig sind, und die Lastgeneratoren nicht der Engpass sind. Speichern Sie Ergebnis und Testbedingungen, denn Unterschiede bei Cache, Testdaten oder Umgebung können spätere Vergleiche unzuverlässig machen.

6. Führen Sie den Test aus und überwachen Sie das Gesamtsystem

Erhöhen Sie die Last entlang der geplanten Lastkurve (gleichmäßiges Ansteigen, Sprung oder plötzlicher Ausbruch) statt eine unbekannte Anzahl Nutzer auf einmal aufzusetzen. Erfassen Sie Webserver-, Anwendungs-, Infrastruktur-, Datenbank-, Netzwerk- und externe Servicedaten parallel zu den Testergebnissen. Ohne Server-Daten wissen Sie nur, dass etwas langsamer wurde, aber nicht was.

7. Analysieren Sie Engpässe

Vergleichen Sie zuerst die Ergebnisse mit den Akzeptanzkriterien. Korrrelieren Sie dann langsame Transaktionen oder Fehler mit CPU-, Speicher-, Datenbank-, Cache-, Warteschlangen-, Verbindungs-Pool-, Netzwerk- und Abhängigkeitsverhalten im selben Zeitfenster. Stoppen Sie, wenn Sie die Komponente und Bedingung benennen können, unter der sie sich verschlechtert, nicht bei durchschnittlicher Antwortzeit.

8. Beheben, nachtesten und automatisieren

Ändern Sie, wenn möglich, eine wichtige Variable gleichzeitig, führen Sie dasselbe Szenario erneut aus und vergleichen Sie es mit der Basislinie. Fügen Sie dann kleinere Regressionstests zu CI/CD hinzu, damit kritische Transaktionen bei jedem Build laufen, und planen Sie größere Tests vor Releases, Kampagnen und saisonalen Spitzen.

Wichtige Metriken für Leistungstests

Testmetriken beschreiben, was Nutzer erleben. Systemmetriken helfen zu erklären, warum. Man benötigt beide für dieselben Testminuten, um Ursachen zu verstehen.

Testmetriken identifizieren Symptome. Server-, Datenbank- und Observability-Daten lokalisieren die Ursache. LoadView Leistungsberichte erfassen die Testseite, von Übersichtsdiagrammen bis zu einem Waterfall-Diagramm für jede Sitzung. Die Serverseite muss aus eigenem Monitoring oder APM kommen, abgestimmt auf die Testzeitlinie.

Wie man Leistungstestergebnisse liest

Einige Muster wiederholen sich in den meisten Websystemen. Keines beweist eine Ursache allein, doch jedes weist den nächsten Untersuchungsort.

Wenn der Durchsatz abflacht und die Antwortzeit stark ansteigt, hat das System wahrscheinlich ein Kapazitätslimit erreicht.

Wann Leistungstests durchführen

Leistungstests sind keine einmalige Aufgabe vor dem Start. Nützliche Auslöser sind:

• Früh im Design, während Architektur und wichtige Benutzerabläufe noch entschieden werden und Änderungen kostengünstig sind.
• Nach bedeutenden Änderungen am Code, Datenbankschema, Infrastruktur oder Integrationen, einschließlich Änderungen an externen Skripten und CDN-Konfiguration.
• In CI/CD, als kurze Regressionstests für die wichtigsten Transaktionen.
• Vor größeren Releases, Kampagnen, saisonalen Spitzen und Migrationen, auf dem Verkehrsniveau, das das Ereignis voraussichtlich bringt.
• Nach einem Vorfall in der Produktion, um zu bestätigen, dass die Korrektur unter den ursächlichen Bedingungen hält.
• Geplant, um Performance-Drift zu erfassen, die kein einzelnes Release erklärt.

Leistungstest vs. Website-Geschwindigkeitstest

Ein Website-Geschwindigkeitstest lädt eine einzelne Seite oder Sitzung zu einem Zeitpunkt, meist ohne anderen Verkehr, und berichtet, wie lange es dauerte. Er ist nützlich für Frontend-Optimierung und zum Vergleich von Builds.

Leistungstests erhöhen Verkehr und gleichzeitige Benutzer, um zu sehen, wie sich Website, Anwendung oder API verhalten, wenn die Nachfrage steigt. Beide geben Seiten- oder Antwortzeiten an. Leistungstests liefern außerdem Antworten auf Geschwindigkeitstests nicht können: Wie viele Nutzer das System unterstützt, Fehlerrate bei Spitzenlast, wo der Durchsatz abflacht und wie lange das System stabil bleibt. Und eine Seite, die im Geschwindigkeitstest gut abschneidet, kann bei 500 gleichzeitigen Sitzungen versagen.

Wie wählt man ein Leistungstest-Werkzeug aus

Bewerten Sie ein Cloud-Leistungs- und Lasttest-Tool anhand der Tests, die Sie ausführen müssen, nicht an einer Funktionsanzahl:

• Unterstützt Websites, mehrstufige Webanwendungen und die API-Protokolle, die Sie nutzen, inklusive Authentifizierungsabläufe.
• Kann realistischen Verkehr modellieren: Browser-Abläufe, API-Sequenzen, Denkzeit, Datenvariation und anpassbare Lastkurven.
• Bietet genügend Skalierung für Ihre Spitze, von Standorten, die Ihre Nutzer repräsentieren.
• Unterstützt Protokolltests, Echtbrowser-Tests oder beides, je nachdem, was Sie messen müssen.
• Erzeugt nutzbare Perzentile, Fehleraufgliederungen, Ergebnisse für jede Transaktion und Berichte, die Sie mit Nicht-Testern teilen können.
• Integriert mit CI/CD und Ihren Monitoring-/Observability-Werkzeugen für die Serverseite.
• Unterstützt interne Webanwendungen, wenn Tests hinter der Firewall erforderlich sind.
• Ist wartbar von den Personen, die die Tests erstellen und neu ausführen.

Best Practices für Leistungstests

• Beginnen Sie mit einer spezifischen geschäftlichen oder technischen Fragestellung und entwerfen Sie den Test, der diese beantwortet.
• Erstellen Sie Arbeitslasten aus Analytics, Logdaten und Prognosen statt aus Vermutungen.
• Testen Sie Login-, Such- und Checkout-Transaktionen, nicht nur die Startseite.
• Nutzen Sie realistische Datenmengen und Umgebungen, die Produktionsbedingungen möglichst entsprechen, und dokumentieren Sie Abweichungen.
• Trennen Sie Probleme im System unter Test von Grenzen im Lastgenerierungs-Setup. Prüfen Sie CPU und Netzwerk der Lastgeneratoren, bevor Sie die Anwendung verantwortlich machen.
• Verfolgen Sie Perzentile, Fehler, Durchsatz und Serverressourcen gemeinsam für dasselbe Testfenster.
• Ändern Sie beim Diagnostizieren von Verbesserungen jeweils nur eine wichtige Variable.
• Speichern Sie Basislinien und vergleichen Sie nach jeder Änderung dasselbe Szenario.
• Beziehen Sie externe Abhängigkeiten und geografische Latenzen ein, wenn sie den Benutzerablauf beeinflussen, denn Produktionsnutzer überspringen diese nicht.

Leistungstests mit LoadView

LoadView ist eine Cloud-Lasttestplattform zur Messung der Performance von Websites, mehrstufigen Webanwendungen und APIs unter Verkehr. Der Verkehr kommt aus einer verwalteten Cloud, so dass keine eigene Lastgenerierungs-Infrastruktur aufgebaut oder unterhalten werden muss.

Wenn Anfragemenge die Fragestellung ist, senden HTTP/S-Tests tausende gleichzeitige Anfragen und berichten Antwortzeiten, Durchsatz und Fehler pro Endpunkt. Wenn der Benutzerablauf die Fragestellung ist, führt Webanwendungs-Lasttest Skripte in echten Browsern aus, sodass JavaScript-Ausführung und Renderzeit Teil der Messung sind. Skripte werden mit dem EveryStep Web Recorder durch einmaliges Durchklicken aufgenommen. API-Lasttests decken REST- und SOAP-Endpunkte ab, inklusive authentifizierter und mehrstufiger Aufrufsequenzen.

Lastkurven sind anpassbar: Eine Laststufenkurve verändert die gleichzeitige Benutzerzahl allmählich in einem definierten Zeitraum, eine zielbasierte Kurve erzeugt eine erforderliche Transaktionsrate in einer festen Zeit, und eine dynamisch anpassbare Kurve erlaubt, die Benutzerlast während des Tests zu ändern. Verkehr kann aus mehr als 40 Zonen im geografisch verteilten Netzwerk kommen, sodass regionale Latenzen und CDN-Verhalten im Ergebnis enthalten sind.

Berichte zeigen den Ausführungsplan, Transaktionen pro Minute, Antwortzeiten und Fehler nach Typ, mit einem Waterfall-Diagramm für jede Sitzung, um langsame Transaktionen auf spezifische Anfragen zurückzuverfolgen. LoadView integriert sich mit Jenkins, Azure DevOps und CircleCI. Jenkins und CircleCI können eine Schwelle für fehlgeschlagene Sitzungen nutzen, um Builds zu markieren, wenn der Anteil an fehlgeschlagenen Sitzungen einen Grenzwert überschreitet. Interne Anwendungen können über zugelassene statische IPs oder einen vor Ort installierten Lastinjektor mit Tests hinter der Firewall getestet werden.

FAQ zu Leistungstests