Leistungstest vs. Stresstest vs. Lasttest<\/a>.<\/p>\nWie man Leistungstests durchf\u00fchrt<\/h2>\n
Die folgenden Schritte gelten f\u00fcr eine Landingpage, einen Checkout-Prozess oder eine authentifizierte API-Sequenz.<\/p>\n
1. Ziel und Akzeptanzkriterien definieren<\/h3>\n
Formulieren Sie, was der Test beweisen muss, in Zahlen. Beispiele: p95-Antwortzeit unter 2 Sekunden f\u00fcr Checkout bei 1.500 gleichzeitigen Benutzern; Fehlerrate unter 0,5 %; die Bestell-API bew\u00e4ltigt 400 Transaktionen pro Sekunde. Ein Test ohne Bestehen\/Nichtbestehen-Kriterien liefert Daten, aber keine Entscheidung.<\/p>\n
2. Modellieren Sie den Website-, Anwendungs- oder API-Verkehr<\/h3>\n
Nutzen Sie Web-Analytics, Zugriffsprotokolle, APM-Daten und Gesch\u00e4ftsvorhersagen. Identifizieren Sie die kritischen Seiten oder Abl\u00e4ufe, 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\u00e4gliche Seitenaufrufe k\u00f6nnen eine Spitze von einigen Hundert gleichzeitigen Sitzungen bedeuten; das Modell sollte angeben, welche.<\/p>\n
3. Erstellen Sie eine repr\u00e4sentative Testumgebung<\/h3>\n
Spiegeln Sie den Produktiv-Webstack, die Anwendungsversion, Datenbankgr\u00f6\u00dfe, CDN- und Cache-Verhalten, API-Abh\u00e4ngigkeiten, Integrationen und Skalierungsregeln m\u00f6glichst genau nach. Verwenden Sie sichere Testkonten und Zahlungssandboxes. Wo Unterschiede n\u00f6tig sind, dokumentieren Sie diese, damit das Ergebnis nicht als Produktionsgarantie fehlinterpretiert wird.<\/p>\n
4. W\u00e4hlen Sie Testtyp und Testmethode<\/h3>\n
W\u00e4hlen 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\u00fchren JavaScript aus und simulieren mehrstufiges Benutzerverhalten, messen also, wie lange eine Person wartet. Viele Teams kombinieren Protokolltests f\u00fcr Skalierung und eine kleinere Gruppe Echtbrowser-Tests f\u00fcr Benutzererfahrung.<\/p>\n
5. Basislinie festlegen<\/h3>\n
F\u00fchren Sie einen kontrollierten Test mit moderater Last vor \u00c4nderungen durch. Das best\u00e4tigt, dass das Skript vollst\u00e4ndig l\u00e4uft, die Testdaten g\u00fcltig sind, und die Lastgeneratoren nicht der Engpass sind. Speichern Sie Ergebnis und Testbedingungen, denn Unterschiede bei Cache, Testdaten oder Umgebung k\u00f6nnen sp\u00e4tere Vergleiche unzuverl\u00e4ssig machen.<\/p>\n
6. F\u00fchren Sie den Test aus und \u00fcberwachen Sie das Gesamtsystem<\/h3>\n
Erh\u00f6hen Sie die Last entlang der geplanten Lastkurve (gleichm\u00e4\u00dfiges Ansteigen, Sprung oder pl\u00f6tzlicher 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.<\/p>\n
7. Analysieren Sie Engp\u00e4sse<\/h3>\n
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\u00e4ngigkeitsverhalten im selben Zeitfenster. Stoppen Sie, wenn Sie die Komponente und Bedingung benennen k\u00f6nnen, unter der sie sich verschlechtert, nicht bei durchschnittlicher Antwortzeit.<\/p>\n
8. Beheben, nachtesten und automatisieren<\/h3>\n
\u00c4ndern Sie, wenn m\u00f6glich, eine wichtige Variable gleichzeitig, f\u00fchren Sie dasselbe Szenario erneut aus und vergleichen Sie es mit der Basislinie. F\u00fcgen Sie dann kleinere Regressionstests zu CI\/CD hinzu, damit kritische Transaktionen bei jedem Build laufen, und planen Sie gr\u00f6\u00dfere Tests vor Releases, Kampagnen und saisonalen Spitzen.<\/p>\n
Wichtige Metriken f\u00fcr Leistungstests<\/h2>\n
Testmetriken beschreiben, was Nutzer erleben. Systemmetriken helfen zu erkl\u00e4ren, warum. Man ben\u00f6tigt beide f\u00fcr dieselben Testminuten, um Ursachen zu verstehen.<\/p>\n
[\/et_pb_text][et_pb_code _builder_version=”4.27.6″ _module_preset=”default” global_colors_info=”{}”]<\/p>\n