Lasttests für Webanwendungen bringen wenig, wenn sie sich darauf beschränken, eine isolierte Anfrage zu wiederholen. Eine Seite kann schnell antworten, während der zugrunde liegende Prozess beim Speichern von Daten fehlschlägt, die Kapazität einer externen Abhängigkeit ausschöpft oder Bestätigungen ausstehen lässt. Nutzer erleben keine URL: Sie verfolgen ein Geschäftsziel.
Daher bildet ein nützlicher Test repräsentative Nutzerabläufe nach, etwa sich anzumelden, zu suchen, einen Datensatz anzulegen, ihn zu aktualisieren und einen Vorgang zu bestätigen. Es geht nicht darum, jedes mögliche Verhalten zu simulieren, sondern reproduzierbare Evidenz darüber zu gewinnen, was geschieht, wenn die Abläufe, die den Betrieb tragen, zeitlich zusammenfallen.
Warum eine einzelne Anfrage die tatsächliche Erfahrung nicht abbildet
Die Messung einer isolierten Schnittstelle kann geeignet sein, um eine konkrete Komponente zu diagnostizieren, nicht jedoch, um zu beantworten, ob eine Anwendung die vorgesehene Nutzung bewältigt. Ein vollständiger Ablauf umfasst Elemente, die eine einzelne Anfrage verbirgt: Authentifizierung, Sitzungen, Validierungen, verkettete Abfragen, Datenbankschreibvorgänge, asynchrone Ereignisse und Integrationen.
Ein Registrierungsablauf kann beispielsweise erfordern, Berechtigungen zu prüfen, die Verfügbarkeit abzufragen, eine Entität anzulegen, eine Nachricht zu senden und eine Bestätigung anzuzeigen. Wird nur der Erstellungsvorgang getestet, bleiben Kosten, Abhängigkeiten und Zustände außen vor, die das tatsächliche Verhalten bestimmen können.
Die Alternative besteht nicht darin, technische Tests auf niedriger Ebene aufzugeben. Es empfiehlt sich, sie beizubehalten, um Regressionen einzugrenzen, und sie durch End-to-End-Szenarien zu ergänzen, um Erfahrung und Betriebskapazität zu validieren.
Die Nutzerabläufe auswählen, deren Belastung sich lohnt
Beginnen Sie damit, die Aktionen nach ihrer Auswirkung zu klassifizieren. Priorisieren Sie diejenigen, die Umsatz erzeugen, einen kritischen Vorgang ermöglichen, zeitlich begrenzt sind oder andere Nutzer blockieren. Unterscheiden Sie anschließend zwischen Aktionen, die interaktiv bleiben müssen, und solchen, die im Hintergrund verarbeitet oder ohne wesentlichen Schaden verschoben werden können.
- Kritische Nutzerabläufe: Anmeldung, wesentliche Abfrage, Vertragsabschluss, Zahlung, Bestätigung oder Übermittlung einer Anfrage.
- Unterstützende Nutzerabläufe: Profilaktualisierung, Dokumentendownload oder Konfiguration.
- Aufschiebbare Prozesse: aufwendige Berichte, Massensynchronisierungen, Benachrichtigungen oder nicht unmittelbare Berechnungen.
Diese Priorisierung vermeidet ein unrealistisches Ziel: dass alles unter jeder Last gleich gut funktioniert. Sie ermöglicht zudem, ausdrückliche Entscheidungen zu treffen. Wenn hoher Druck besteht, kann es akzeptabel sein, einen Bericht zu verzögern, nicht jedoch, eine bereits begonnene Bestätigung zu verhindern.
Einen Nutzerablauf in ein überprüfbares Szenario überführen
Beschreiben Sie jedes Szenario als konkrete und überprüfbare Abfolge. Es sollte den Akteur, die Schritte, die erforderlichen Daten, die beteiligten Abhängigkeiten und das Ergebnis enthalten, das belegt, dass der Vorgang abgeschlossen wurde. Vermeiden Sie es, ausschließlich Antwortcodes als Erfolgssignal zu verwenden: Ein 200 beweist nicht, dass eine Reservierung, eine Bestellung oder eine Statusänderung korrekt übernommen wurde.
Authentifizierter Akteur 1. Meldet sich an 2. Ruft eine Liste mit Filtern ab 3. Öffnet ein verfügbares Element 4. Erstellt eine Anfrage 5. Bestätigt das Ergebnis und prüft dessen Status
Definieren Sie außerdem, was geschehen soll, wenn eine Integration langsam antwortet oder nicht verfügbar ist. Das erwartete Verhalten kann eine kontrollierte Antwort, ein Wiederholungsversuch, eine Warteschlange oder eine klare Meldung sein. Entscheidend ist, dass das Ergebnis bewusst festgelegt und überprüfbar ist, nicht ein mehrdeutiger Fehler oder ein nur teilweise abgeschlossener Vorgang.
Ausgangsbasis, Daten und Nutzungsprofile festlegen
Bevor Sie die Last erhöhen, führen Sie das Szenario mit geringer Parallelität in einer Umgebung aus, die den zu bewertenden Bedingungen nahekommt. Erfassen Sie Zeiten pro Schritt, funktionale Ergebnisse, Ressourcennutzung und Aktivität der Abhängigkeiten. Diese Ausgangsbasis ermöglicht es, eine bereits bestehende Einschränkung von einer durch die angewendete Last verursachten Verschlechterung zu unterscheiden.
Testdaten verdienen dieselbe Sorgfalt wie das Skript. Sie müssen über ausreichend Volumen und eine geeignete Verteilung verfügen, damit Abfragen, Indizes, Berechtigungen und Geschäftsregeln sich repräsentativ verhalten. Immer denselben Nutzer, Datensatz oder Bezeichner wiederzuverwenden, kann künstliche Sperren erzeugen oder umgekehrt tatsächliche Ressourcenkonflikte verdecken. Verwenden Sie isolierte Identitäten und Entitäten, kennzeichnen Sie die erstellten Daten und richten Sie einen sicheren Bereinigungsmechanismus ein.
Führen Sie keine destruktiven Szenarien gegen produktive Prozesse aus, sofern keine ausdrückliche Genehmigung, Kontrollen zur Begrenzung des Testumfangs und ein Rückabwicklungsplan vorliegen. Auch eine Testumgebung, die zu stark abweicht, erlaubt keine unvorsichtige Extrapolation der Ergebnisse; dokumentieren Sie Unterschiede bei Konfiguration, Kapazität, Daten und Integrationen.
Das Lastprofil sollte ausdrücken, wie der Dienst genutzt wird, und nicht nur, wie viele gleichzeitige Nutzer gewünscht sind. Definieren Sie:
- Zielparallelität und Ankunftsrate neuer Aktionen;
- die Mischung der Nutzerabläufe, einschließlich Lese- und Schreibvorgängen;
- realistische Pausen zwischen den Schritten, sofern zutreffend;
- eine ausreichende Dauer, um einen Aufstau in Warteschlangen, Pools oder Speichern aufzudecken;
- schrittweise Steigerungen und eine stabile Phase, um das System zu beobachten.
Ein kurzer Test mit vielen Anfragen kann eine Grenze bei Lastspitzen aufdecken. Ein langfristig ausgeführter Test kann Ressourcenlecks, die Sättigung von Verbindungen oder asynchrone Arbeit aufdecken, die schneller anwächst, als sie verarbeitet wird. Es handelt sich um unterschiedliche Fragen, die entsprechend gestaltet werden müssen.
Verschlechterung messen, nicht nur Latenz
Beobachten Sie die Anwendung vom Nutzerablauf bis zu ihren Komponenten. Kombinieren Sie Metriken zum funktionalen Erfolg, Antwortzeiten nach Perzentilen, Fehlerrate, Wiederholungsversuchen, unvollständigen Vorgängen und Szenarioabbrüchen. Setzen Sie diese in Beziehung zur Auslastung von CPU, Speicher, Verbindungen, Datenspeicherung, Warteschlangen, Caches und den Grenzen abhängiger Dienste.
Verteilte Ablaufverfolgung und korrelierte Protokolle helfen zu beantworten, wo Zeit verbraucht wird. Ohne diese Korrelation kann eine hohe Latenz fälschlich der Benutzeroberfläche zugeschrieben werden, obwohl die Ursache in einer Abfrage, einer Integration oder einer überlasteten Warteschlange liegt.
Definieren Sie Schwellenwerte entsprechend der Auswirkung des Nutzerablaufs. Ein nützliches Kriterium verbindet Nutzungserfahrung und Korrektheit: beispielsweise, dass der kritische Ablauf bei der Mehrzahl der Ausführungen innerhalb des vereinbarten Ziels abgeschlossen wird, eine festgelegte Fehlerrate nicht überschreitet und keine Vorgänge in inkonsistenten Zuständen zurücklässt. Die konkreten Werte müssen mit Produkt, Fachbereich und Betrieb abgestimmt werden; es gibt keine universell gültige Zahl für alle Anwendungen.
Steigerungen ausführen und die erste relevante Grenze ermitteln
Erhöhen Sie die Last stufenweise und behalten Sie dieselben Bedingungen für Szenario, Daten und Beobachtbarkeit bei. Tritt eine Verschlechterung auf, nehmen Sie nicht an, dass die erste Ressource mit hoher Auslastung die Ursache ist. Suchen Sie nach der ersten Komponente, deren Sättigung oder Wartezeit zeitlich mit der Verschlechterung des Nutzerablaufs zusammenfällt.
Der Engpass kann in der Anwendung, der Datenbank, einer Integration, der Infrastruktur oder einer Parallelitätsrichtlinie liegen. Grenzen Sie Hypothesen durch kontrollierte Änderungen ein: Vergleichen Sie eine instrumentierte Abfrage, entkoppeln Sie eine Abhängigkeit in einer Testumgebung, passen Sie die Größe eines Pools an oder wiederholen Sie das Szenario mit einer anderen Mischung. Ändern Sie jeweils nur eine Variable, damit die Evidenz interpretierbar bleibt.
Die geeignete Maßnahme festlegen und validieren
Eine Korrektur bedeutet nicht immer, Ressourcen zu skalieren. Je nach Diagnose kann es sinnvoll sein, eine Abfrage zu optimieren, redundante Arbeit zu reduzieren, Daten zwischenzuspeichern, wenn eine gewisse Aktualitätsverzögerung tolerierbar ist, eine kostspielige Aktion zu begrenzen, einen aufschiebbaren Prozess in eine Warteschlange zu stellen oder einen Ablauf neu zu gestalten, um synchronisierte Wartezeiten zu vermeiden. Skalierung kann angemessen sein, wenn die Architektur dies zulässt und die Einschränkung die Kapazität betrifft, sie löst jedoch weder Ressourcenkonflikte noch eine Abhängigkeit mit eigener Kapazitätsgrenze oder einen unnötig kostspieligen Vorgang.
Prüfen Sie nach jeder Änderung dieselbe Hypothese erneut und vergleichen Sie die Ergebnisse mit der Ausgangsbasis. Bewahren Sie das Skript, die Version der Umgebung, die relevante Konfiguration, das Lastprofil, die verwendeten Daten, Metriken, Ablaufverfolgungen und Schlussfolgerungen auf. Diese Evidenz ermöglicht es zu überprüfen, dass die Verbesserung das Problem nicht auf einen anderen Nutzerablauf verlagert hat.
Checkliste für Änderungen und Veröffentlichungen
- Sind die kritischen Nutzerabläufe priorisiert und verfügen sie über ein überprüfbares funktionales Ergebnis?
- Bildet das Profil die erwartete Parallelität, Rate, Dauer und Nutzungsmischung ab?
- Sind die Daten isoliert, repräsentativ und lassen sie sich bereinigen, ohne reale Prozesse zu beeinträchtigen?
- Gibt es abgestimmte Schwellenwerte für Nutzungserfahrung, Fehler und die Integrität der Vorgänge?
- Ermöglicht die Beobachtbarkeit, jeden Nutzerablauf mit Anwendung, Daten und Integrationen in Beziehung zu setzen?
- Wurde der Test nach der Änderung unter vergleichbaren Bedingungen wiederholt?
- Gibt es eine dokumentierte Entscheidung für den Fall, dass ein Schwellenwert nicht erfüllt wird: korrigieren, begrenzen, verschieben, skalieren oder neu gestalten?
Die Einbindung dieser Tests in relevante Änderungen macht Entscheidungen über Kapazität evidenzbasiert. Das Ziel ist nicht, das Ausbleiben von Vorfällen zu versprechen, sondern Grenzen zu kennen, Risiken zu priorisieren und zu handeln, bevor Nutzer die Verschlechterung erleben.