Puppeteer-Script-Tests: Wie sie ablaufen und was sie messen

Die anderen neun Simulationstypen dieser Serie beantworten eine Frage: Hält Ihr Netzrand stand, wenn bösartiger Datenverkehr eintrifft? Das ist wichtig zu wissen, nur ist es nicht die einzige Frage. Eine zweite kann kein Flood klären: Funktioniert Ihr Login noch, wenn sich tausend Personen gleichzeitig anmelden, und verkraftet der Session-Store das?

Für genau diese Frage steht Puppeteer Script im Obsidio-Katalog. Der Typ ist kein Flood, und gemessen wird er nicht in Anfragen pro Sekunde. Der Test führt ein Script, das Sie selbst geschrieben haben, auf jedem Worker gleichzeitig in einem echten Browser aus und meldet, ob jeder Durchlauf zu Ende gekommen ist. Synthetische Nutzertests unter echter Parallelität erreichen damit Schichten eines Banken-Stacks, an die blosser Angriffsverkehr nie herankommt.

Dieser Beitrag gehört zu einer Serie über die zehn Simulationstypen, die Obsidio ausführt – ein Beitrag je Typ. Neun davon sind Angriffssimulationen. Dieser nicht, und genau deshalb gehört er in die Reihe: Er deckt ab, was die anderen neun ungeprüft lassen. Wie die Kategorien zusammenhängen, erklärt unser Leitfaden dazu, wie Sie Ihren DDoS-Schutz testen.

Was Puppeteer-Script-Tests tatsächlich tun

Jeder Worker startet einen einzelnen Chromium-Tab und verbindet Puppeteer damit. Die Puppeteer-Dokumentation beschreibt das nüchtern: connect() hängt Puppeteer an eine bereits laufende Browser-Instanz an («attaches Puppeteer to an existing browser instance»). Zurück erhält der Worker ein page-Objekt, das laut Dokumentation die Methoden bereitstellt, um mit einem einzelnen Tab im Browser zu arbeiten («methods to interact with a single tab or extension background page in the browser»). Navigieren, Klicken, Tippen, JavaScript im Seitenkontext auswerten: alles verfügbar, denn hier läuft ein echter Browser – kein Lastgenerator, der sich über den User-Agent als Browser ausgibt.

Ihr Script läuft als Rumpf einer async-Funktion, einmal je Iteration, in einer Schleife, bis die Laufzeit des Testlaufs endet. Jede Iteration ist ein eigener Versuch mit eigenem Timeout; überzieht eine Iteration, wird sie abgebrochen und mit Begründung als Fehlschlag protokolliert. Ein Syntaxfehler wirft schon beim Start eine Exception und bringt den gesamten Durchlauf zu Fall.

Ein Verkehrsmuster gibt es hier nicht zu beschreiben – genau das unterscheidet diesen Typ von allen anderen im Katalog. Ein Flood folgt einem festen Muster; dieser Test folgt Ihrem Ablauf. Eine Zahlungsauslösung kann ein Dutzend Aufrufe umfassen, zwei davon an Systeme, die Ihnen nicht gehören.

Einfach gesagt: Sie schreiben einen kleinen Browser-Bot, der eine Aufgabe erledigt – anmelden, Formular ausfüllen, Schaltfläche klicken –, und die Plattform verteilt ihn auf jeden Worker und lässt ihn für die Dauer der Simulation in Dauerschleife laufen.

Wozu synthetische Nutzertests gut sind

Floods beantworten Fragen zu Kapazität und Filterung. Gescriptete Abläufe zeigen dagegen, ob die Anwendung unter Last noch korrekt arbeitet – eine Eigenschaft, die unabhängig von der Kapazität wegbrechen kann. Das k6-Projekt von Grafana, das neben Lasttests auf Protokollebene auch Tests auf Browser-Ebene anbietet, formuliert denselben Gedanken: Tests auf Browser-Ebene machen die Nutzererfahrung messbar und decken Probleme auf, die sich auf Protokollebene nur schwer greifen lassen («provides a way to measure user experience and find issues that are difficult to catch on the protocol level»). Vier Fragen lassen sich auf diese Weise sinnvoll klären.

Geschäftsabläufe unter Parallelität prüfen. Die Frage ist nicht, ob die Seite eine Antwort geliefert hat, sondern ob die Überweisung angelegt wurde und die Bestätigung den richtigen Betrag zeigt. Assertions im Script halten das je Iteration fest – das Ergebnis ist eine Erfolgsquote für den Ablauf, keine Latenzkurve.

Authentifizierung und Session-Verhalten. Kaum ein Pfad in einer Bank ist so verwinkelt und so fehleranfällig wie die Anmeldung: Token-Ausgabe, Session-Speicher, Step-up-Verifikation, Limits gegen Credential Stuffing. Bei tausend gleichzeitigen Anmeldungen greifen diese Komponenten auf eine Weise ineinander, die so nie geplant war – und ein Test auf Protokollebene, der ein mitgeschnittenes Token wieder einspielt, prüft davon nichts.

Die Teile des Stacks, die ein Flood nie berührt. Ein langsamer Angriff wie Slowloris endet am Webserver und erreicht Ihre Anwendung nie. Ein gescripteter Ablauf schreibt in Ihre Datenbank, belegt Ihren Session-Store und ruft die nachgelagerten Dienste auf, von denen er abhängt.

Ihre eigenen Schutzmassnahmen, aus Sicht des Kunden. Stellt die Bot-Erkennung den Ablauf vor eine Challenge, oder blockiert Ihre WAF ein Formular ab einem gewissen Aufkommen, dann wissen Sie, wie Ihre Schutzmassnahmen mit legitimem automatisiertem Datenverkehr umgehen – den jede Bank in ihren Partner-Integrationen hat.

Welche Teile Ihres Stacks dieser Test belastet

Bei den Angriffssimulationen lautet die nützliche Frage, welche Schutzmassnahme den Angriff hätte abfangen müssen. Hier ist es umgekehrt: Der Test versucht gar nicht erst, an einer Massnahme vorbeizukommen. Es geht stattdessen um Abdeckung – welche Schichten dieser Test wirklich erreicht und welche er auslässt.

Die Parameter – und der Unterschied zu Browser Flood

Vier Parameter lassen sich konfigurieren; auf einen davon kommt es am meisten an.

• Das Script. Der Haupthebel. Es erhält das page-Objekt, ein Kontextobjekt mit Ziel-URL und Ihren Parametern sowie Helfer für Verzögerungen, Logging, benannte Assertions und eigene Metriken. Ein langsameres Script bedeutet weniger Iterationen je Worker in derselben Laufzeit.
• Iterations-Delay. Die Pause zwischen zwei Iterationen, standardmässig eine Sekunde, einstellbar von 100 Millisekunden bis 10 Sekunden. Sie bestimmt zugleich den Timeout je Iteration: das Fünffache des Delays oder 30 Sekunden, je nachdem, was grösser ist. Ein höherer Wert verlangsamt die Schleife und gibt jeder Iteration mehr Spielraum, bevor sie abgebrochen wird.
• User Agent. Für den Durchlauf fest vorgegeben, wenn Sie ihn setzen; andernfalls das, was die Browser-Laufzeit mitbringt.
• Header. Zusätzliche HTTP-Header, die mit jeder Anfrage der Seite mitgeschickt werden. Die Puppeteer-Dokumentation hält fest, dass sie bei jeder von der Seite ausgelösten Anfrage gesendet werden («with every request the page initiates») – genau das macht sie brauchbar für ein Auth-Token oder einen Bypass-Header, den es nur im Test gibt.

Zwei Einschränkungen sollten Sie kennen. Ein Browser je Worker, ohne Parallelität innerhalb eines Workers: Iterationen laufen nacheinander, die Parallelität ergibt sich also allein aus der Worker-Zahl. Und der Test setzt die Browser-Laufzeit auf dem Worker-Gerät voraus, ohne HTTP-Fallback. Fehlt sie, bricht er sofort mit einem Fehler ab, statt stillschweigend auf etwas weniger Realistisches auszuweichen – genau das erwartet man von einem Test, dessen ganzer Wert im echten Browser liegt.

Browser Flood wird häufig mit diesem Typ verwechselt, denn beide steuern echtes Chromium. Der Unterschied liegt darin, was sie laden. Browser Flood ruft Ihre Seite wieder und wieder auf und zählt jede Unterressource, die die Engine holt – die Last besteht aus dem HTML, dem CSS und dem JavaScript, den Bildern und den Hintergrundaufrufen Ihrer Seite. Puppeteer Script lässt die Unterressourcen ausser Acht und folgt stattdessen dem Ablauf: navigieren, tippen, absenden, Ergebnis prüfen. Das eine erzeugt realistisches Volumen, das andere realistisches Verhalten.

Was Sie selbst prüfen können – und wo die Lücke liegt

Die Antwort fällt hier anders aus als in den übrigen neun Beiträgen. Ihr Team kann diese Abläufe scripten. Wer bereits Lasttests für Webanwendungen mit den gängigen Werkzeugen fährt oder End-to-End-Browser-Suiten in der Pipeline pflegt, hat das Können und den grössten Teil des Codes bereits im Haus. Die Lücke liegt an zwei anderen Stellen.

Parallelität in realistischem Massstab. Jede Browser-Session verbraucht spürbar Arbeitsspeicher und CPU-Zeit auf der Maschine, die sie steuert. Die k6-Dokumentation benennt die Folge direkt: Das Hochfahren eines Browser-VU koste zusätzliche Leistung («an additional performance overhead when it comes to spinning up a browser VU»); als ressourcenschonendere Alternative empfiehlt sie, eine kleine Zahl virtueller Nutzer für den Browser-Test mit einer grossen Zahl virtueller Nutzer für einen Test auf Protokollebene zu kombinieren («combining a small number of virtual users for a browser test with a large number of virtual users for a protocol-level test»). Für ein CI-Budget ist dieser Kompromiss vernünftig. Ihre ursprüngliche Frage bleibt damit trotzdem offen: was Ihr Session-Store bei tausend gleichzeitigen echten Abläufen tut.

Geografische Verteilung und Netzvielfalt. Hundert Browser-Sessions aus einer Cloud-Region teilen sich eine Handvoll Adressen, einen Netzwerkpfad und ein Latenzprofil. Ein Montagmorgen mit Hochbetrieb sieht völlig anders aus – und ein solcher Aufbau kann nicht zeigen, wie Ihre Geo-Regeln, Ihr Bot-Scoring oder Ihr Fraud-Monitoring reagieren, wenn derselbe Ablauf gleichzeitig aus dreissig Ländern eintrifft.

Fahren Sie Ihre eigenen gescripteten Abläufe also durchaus gegen Staging. Nur: Ein sauberes Ergebnis bei niedriger Parallelität von einem einzigen Standort ist kein Beleg dafür, dass der Ablauf auch im grossen Massstab hält.

Wie Sie diesen Test sicher gegen die Produktion fahren

Am Anfang steht die Autorisierung – und die ist mehr als ein gesetztes Häkchen. Obsidio prüft die Domain-Inhaberschaft über einen DNS-TXT-Eintrag, bevor Datenverkehr fliesst, fährt die Last schrittweise hoch, statt mit voller Worker-Zahl zu beginnen, und jeder Durchlauf lässt sich live abbrechen. Ein gescripteter Ablauf verlangt darüber hinaus eigene Vorbereitung: Ihr Script erzeugt echte Datensätze. Legen Sie vorab fest, welches Konto es verwendet, was es schreibt und wer hinterher aufräumt. Ein Ablauf, der tausend Überweisungsaufträge einreicht, braucht dieselbe Freigabe im Change-Management wie jede andere Aktivität in der Produktion.

Die Herkunft der Worker schliesst genau die Lücke aus dem vorigen Abschnitt. Obsidio führt Simulationen über 100’000 weltweit verteilte echte Geräte aus – ein gescripteter Ablauf trifft dadurch gleichzeitig aus vielen Ländern und Netzen ein statt aus einer gemieteten Region.

Achten Sie anschliessend auf die richtigen Zahlen, denn zwei Gewohnheiten aus Flood-Tests führen hier in die Irre.

• Lassen Sie die Anfragerate ausser Acht. Für diesen Typ wird bewusst keine Durchsatzschätzung ausgewiesen. Lesen Sie stattdessen Erfolgsquote und Dauer je Iteration. Die Dauer ist hier die tatsächlich verstrichene Zeit des gesamten Ablaufs und nicht die Zeit bis zum ersten Byte einer einzelnen Anfrage – sie ist also mit dem vergleichbar, was ein Kunde erlebt.
• Prüfen Sie mit Assertions, statt sich auf Annahmen zu verlassen. Eine Seite, die lädt, ist noch kein Ablauf, der funktioniert hat. Hinterlegen Sie im Script benannte Assertions für alles, was stimmen muss – Bestätigungstext, Saldo, Weiterleitungsziel – und werten Sie die Pass- und Fail-Zähler aus. Eigene Werte, die Sie je Iteration melden, kommen mit den Ergebnissen zurück: Extrahieren Sie also die Referenznummer, die belegt, dass die Transaktion stattgefunden hat.

Die Arbeitsteilung bei der Auswertung ist dieselbe wie bei allen anderen Typen. Obsidio misst, was von aussen sichtbar ist: ob jede Iteration abgeschlossen wurde, wie lange sie gedauert hat, welche Assertions bestanden haben und wie Ihre vorgelagerten Schutzmassnahmen reagiert haben. Ob Ihr Datenbank-Connection-Pool gesättigt war, ob Ihr SIEM etwas korreliert hat und ob der Pikettdienst alarmiert wurde, zeigen nur Ihre eigenen Konsolen. Während des Testfensters sollte deshalb jemand mitschauen – sonst liefert der Durchlauf nur den halben Befund.

Stärke wird bewiesen, nicht versprochen. Ein Flood zeigt, ob Ihre Abwehr standhält. Ein gescripteter Ablauf zeigt, ob Ihre Bank währenddessen noch funktioniert.

Wo dieser Test in ein Testprogramm gehört

Ein Programm, das nur aus Angriffssimulationen besteht, hat einen grossen blinden Fleck. Jeder der anderen neun Typen sagt etwas über Kapazität, Filterung oder Verbindungsverarbeitung aus. Keiner sagt, ob die Überweisung durchgegangen ist. Für ein reguliertes Institut heisst Resilienz: Die Kunden konnten weiterhin erledigen, wozu sie gekommen sind – und um das zu belegen, braucht es einen Test, der genau das nachstellt.

Konkret heisst das: einen Flood gegen die vorgelagerten Schichten fahren, parallel dazu einen gescripteten Ablauf – und dann prüfen, ob der Ablauf während des Floods noch durchläuft. Näher kommt eine kontrollierte Simulation der Frage nicht, die ein Verwaltungsrat nach einem Vorfall stellt. Es ist zudem die Kombination, die auch die k6-Dokumentation empfiehlt: eine kleine Browser-Last neben einer grossen auf Protokollebene, statt sich zwischen beiden entscheiden zu müssen.

Für regulierte Institute zählt der Nachweis ebenso viel wie das Ergebnis. Obsidio erstellt kryptografisch attestierte Berichte, bei denen jede nachträgliche Änderung erkennbar wäre, FINMA, DORA und NIS2 zugeordnet und in Trusted Execution Environments erzeugt. Ein autorisierter funktionaler Testlauf hinterlässt damit einen Beleg für die Akten statt eines Screenshots, für den jemand bürgen muss.

Wenn Sie einen autorisierten synthetischen Nutzertest gegen die eigene Infrastruktur planen möchten, sehen Sie sich die Obsidio-Plattform an oder nehmen Sie Kontakt auf. Unabhängig, neutral, überprüfbar: Resilienz, die Sie belegen können.