Lasttest-Probe der Registrierung: So prüfen Sie den Check-in

Ein praktischer Plan für die Abnahme der Registrierung unter Last: Spitzenszenarien, sichere Daten, Backup, PASS/FAIL-Kriterien und Bericht des Auftragnehmers.

Was muss eine Lastprobe beweisen?

Eine Lastprobe der Registrierung muss zeigen, dass der gesamte Gastweg bei realem Andrang funktioniert: Der Eintrag wird gefunden, der QR-Code wird gelesen, der Status ändert sich genau einmal, das Badge wird gedruckt, und das Ergebnis ist an den benachbarten Arbeitsplätzen sichtbar. Hier ist Check-in die Suche nach dem Eintrag und die Erfassung der Ankunft des Gastes. Eine erfolgreiche Antwort eines einzelnen Formulars oder ein Signalton des Scanners beweisen noch nicht die Bereitschaft des gesamten Prozesses.

Wir bei Aventura legen zunächst die Grenzen der Prüfung fest. Der Gast zeigt eine Einladung vor oder bittet darum, den Eintrag zu finden. Das System prüft den Status, erfasst die Ankunft und übergibt die Daten an den Druck.

Der Operator erhält eine verständliche Bestätigung. Zur Abhängigkeitskarte gehören auch externe Dienste.

Der allgemeine Registrierungsweg wird ausführlich im Artikel über die Registrierung von Veranstaltungsteilnehmern behandelt. Hier ist die Aufgabe enger gefasst: diesen Weg unter Last zu prüfen und nach vorab festgelegten Kriterien eine Entscheidung „bestanden“ oder „nicht bestanden“ zu erhalten.

Der Scanner kann nach erfolgreicher Dekodierung des Barcodes einen Ton ausgeben. Das bestätigt das Lesen des Zeichens durch das Gerät, aber nicht das Schreiben eines neuen Status in das zentrale System. Daher gleicht der Beobachter den Bildschirm des Operators, die Gastkarte, den Druck und den abschließenden Export ab und nicht nur die Reaktion des Scanners.

Spitzenandrang in der Sprache des Auftraggebers

Wir definieren die Spitze über das Ankunftsszenario der Gäste und nicht über eine runde Zahl virtueller Nutzer. Der Auftraggeber beschreibt die Ankunftsfenster, den Anteil der Hauptgruppe, mehrere Eingänge, manuelle Fälle und gleichzeitige Vorgänge. Das technische Team berechnet, wie viele Vorgänge in jeder Minute beginnen und wie lange jede Phase dauert.

Für die Organisation einer Konferenz ist es sinnvoll, den Transportplan, den Beginn des Plenarteils, den Zugang zu den Sektionen und die Regeln für die Ausgabe von Materialien zusammenzustellen. Ein Bus oder das Ende eines gemeinsamen Blocks erzeugen eine Nachfragestufe. Die Gäste kommen weiterhin an, auch wenn sich die vorherigen Vorgänge bereits verlangsamt haben.

Das minimale Modell enthält:

• die Zahl der erwarteten Gäste nach Zeitfenstern;
• den Anteil von QR, manueller Suche und Gästen ohne Voranmeldung;
• die Zahl der Eingänge, Theken, Scanner und Drucker;
• den Anteil wiederholter Scans und Nachdrucke;
• späte Änderungen von Status oder Kategorie;
• Abhängigkeiten von Netz, E-Mail, SMS und externen Datenbanken.

Ein solches Profil ermöglicht es, die technische Last mit der sichtbaren Warteschlange zu vergleichen. Der Server kann schnell antworten, und der Arbeitsplatz bedient den Gast trotzdem langsam wegen der Suche, des Drucks oder einer unklaren Fehlermeldung. Daher werden der Systemvorgang und der vollständige Zyklus am Counter getrennt gemessen.

Welche Vorgänge gehören in das Szenario?

Das Szenario sollte die Geschäftsvorgänge nachbilden, die das Team am Eingang ausführt, einschließlich der Ausnahmen. Die Prüfung einer einzigen Registrierungsseite vermittelt ein falsches Gefühl der Bereitschaft. Der Hauptablauf wird zusammen mit manueller Suche, erneutem QR, später Erfassung und Druck ausgeführt, um die Konkurrenz um gemeinsame Ressourcen und den Einfluss schwieriger Fälle auf die Warteschlange zu sehen.

Wir bauen den Ablauf so auf:

1. Der Gast zeigt einen QR-Code vor oder nennt Daten für die Suche.
2. Der Operator findet genau einen richtigen Eintrag.
3. Das System prüft den aktuellen Status und die Zugriffsrechte.
4. Der Check-in ändert den Status genau einmal.
5. Der Drucker gibt ein Badge mit der aktuellen Kategorie aus.
6. Der benachbarte Counter sieht die Änderung ohne manuelle Aktualisierung der Daten.
7. Der abschließende Export enthält genau eine bestätigte Markierung.

Ins Szenario werden ein Tippfehler, ein Namensvetter, ein Fall ohne QR-Code, ein bereits verwendeter Code, eine späte Registrierung und eine Anfrage nach einem Ersatz-Badge aufgenommen. Den detaillierten Satz an Datenträgern kann man mit dem Artikel über sichere QR-Codes bei Veranstaltungen abgleichen, ohne den Lasttest in ein separates Audit der QR-Sicherheit zu verwandeln.

Auch eine späte Änderung muss den gesamten Kreislauf durchlaufen. Der Eintrag wird nach dem Kontroll-Export erstellt oder geändert, dann werden Suche, Rechte, Druck und die Verbreitung des neuen Status geprüft. Der benachbarte Beitrag über späte Registrierungen hilft, ein solches Szenario vorzubereiten, ohne den gesamten Projektkalender zu wiederholen.

Die Registrierung ist vollständig in die Produktion der Veranstaltung eingebunden. Wenn ein übergreifender Rahmen für Location, Dienstleister und Eingangsteam benötigt wird, sehen Sie sich die Organisation von Business-Veranstaltungen an: Wir stimmen Rollen, Kontrollpunkte und Ausweichlösungen im Voraus ab.

Praktische Analysen zur Vorbereitung der Location und zur Arbeit des Teams veröffentlichen wir außerdem im Telegram-Kanal von Aventura.

Drei Testlauf-Modi

In unserem Abnahmeprotokoll verwenden wir drei Modi: eine kurze Prüfung der Basiskette, den erwarteten Arbeitsablauf und einen plötzlichen Anstieg. Sie beantworten unterschiedliche Fragen. Ein einzelner sanfter Hochlauf kann einen Szenariofehler verbergen, und die Suche nach der maximalen Kapazität bestätigt nicht, dass die vereinbarte Spitze die Geschäftskriterien erfüllt.

In der k6-Dokumentation gibt es separate Modi für die Basisprüfung, normale Last, Überlast, plötzlichen Anstieg und die Suche nach der Systemgrenze. Der Auftraggeber muss sich nicht mit der Konfiguration des Tools auskennen, aber das Ziel des Testlaufs verstehen.

Ein Modus zeigt die Reaktion auf einen plötzlichen Ansturm, ein anderer sucht die Grenze. Der Arbeitslauf bestätigt ein konkretes Veranstaltungsszenario.

Vor der großen Generalprobe führt das Team einen Basistestlauf jedes Pfads durch. Er erkennt falsche Testdatensätze, fehlende Berechtigungen und Integrationsfehler. Danach wird die Last nach dem vereinbarten Profil erhöht und nicht nach der Improvisation des technischen Spezialisten.

Wie bereitet man sichere Testdaten vor?

Für die Generalprobe sollten synthetische Profile verwendet werden, die die Struktur der Gästedatenbank ohne echte Kontaktdaten nachbilden. Das Set umfasst verschiedene Rollen und Kategorien. Einzelne Datensätze imitieren ähnliche Nachnamen, späte Änderungen und Ausnahmen. Vor dem Start stimmt das Team Zugriffsrechte und Löschfristen ab und überführt externe Aussendungen in eine sichere Testumgebung.

Die Grundsätze von Artikel 5 des Federal Law No. 152-FZ verlangen einen konkreten Verarbeitungszweck, die Übereinstimmung der Daten mit diesem Zweck und das Fehlen von Übermaß. Für einen Lasttest ist dies ein praktisches Argument dafür, die Produktivdatenbank nicht „aus Realismus“ zu kopieren, wenn dasselbe Szenario mit fiktiven Datensätzen reproduziert werden kann.

Das Set wird schrittweise vorbereitet:

1. Es werden die Felder und Status definiert, die tatsächlich am Check-in beteiligt sind.
2. Es werden synthetische Datensätze der benötigten Kategorien und Verteilungen erstellt.
3. Datensätze für wiederholte QR-Codes, späte Änderungen und Nachdrucke werden gesondert gekennzeichnet.
4. Die Zugriffe von Operatoren und Beobachtern werden auf Testrollen beschränkt.
5. Der Versand von E-Mails und Nachrichten an echte Adressaten wird blockiert.
6. Nach der Abnahme werden Löschfristen für Datensätze, Logs und Exporte festgelegt.

Rechtliche Anforderungen an Formulare und Einwilligungen sind gesondert zu prüfen. Dafür gibt es das Material zum Registrierungsformular nach 152-FZ. In der Lastgeneralprobe prüfen wir das bereits genehmigte Datenschema. Die Zusammensetzung der Testdatensätze, Zugriffsrechte, Protokollierung und Aufbewahrungsfristen werden mit dem Verantwortlichen für personenbezogene Daten oder einem Juristen abgestimmt.

Kriterien „bestanden / nicht bestanden“ (PASS/FAIL) vor dem Start

PASS/FAIL bedeutet „bestanden / nicht bestanden“ anhand eines im Voraus festgelegten Kriteriums. Legen Sie die Abnahmekriterien vor dem Test fest und verknüpfen Sie sie mit dem zugesagten Gastpfad. Es gibt keinen universellen Richtwert für Latenz oder Anzahl der Vorgänge. Das Projektteam legt den zulässigen Durchsatz, Fehler, Servicezeit und Abbruchregeln fest und vergleicht anschließend das tatsächliche Ergebnis damit, ohne die Schwellenwerte im Nachhinein anzupassen.

Schwellenbedingungen von k6 markieren automatisch, ob das Kriterium für eine Metrik bestanden wurde. Konkrete Werte aus der Dokumentation dürfen nicht als Richtwert in das Projekt übernommen werden. Sie werden vom Systemeigentümer, Auftraggeber und Betriebsteam unter Berücksichtigung der zulässigen Warteschlange und des zugesagten Services festgelegt.

Ein besonderes Kriterium betrifft den Lastgenerator. Wenn geplante Vorgänge nicht gestartet wurden, beschreibt der Bericht einen geringeren Durchsatz als angegeben. Die Metrik dropped_iterations hilft dabei, die Degradation des getesteten Systems von Ressourcenmangel oder einer fehlerhaften Konfiguration des Generators selbst zu unterscheiden.

Was während der Probe kaputtgehen soll?

Während der Probe schalten wir einzelne Abhängigkeiten in einem abgestimmten Zeitfenster nacheinander ab oder verlangsamen sie: Netzwerk, Drucker, externer Dienst oder einen Arbeitsplatz. Das Team prüft die Erkennungsgeschwindigkeit, die Verständlichkeit der Meldung und den Übergang zum Reservebetrieb. Jeder Ausfall wird nach einem Szenario ausgelöst, mit dem Recht auf sofortigen Abbruch und einem im Voraus benannten Leiter des Durchlaufs.

Ein nützliches Set an Ausfällen:

• langsames oder kurzzeitig nicht verfügbares Netzwerk;
• Ausfall eines Scanners oder Druckers;
• verlorene Antwort nach einem tatsächlich durchgeführten Check-in;
• HTTP-Antwort „Zu viele Anfragen“ mit Angabe der Pause bis zur Wiederholung;
• nicht verfügbare externe Datenbank oder Druckdienst;
• erneutes Drücken durch den Operator wegen unklarem Status;
• Wiederherstellung der Abhängigkeit nach manuellen Markierungen.

Sofortige automatische Wiederholungen können eine neue Welle von Anfragen erzeugen: Ein bereits überlasteter Dienst erhält noch mehr Aufrufe und braucht länger für die Wiederherstellung. Wenn der Vorgang den Gaststatus ändert, kann eine blinde Wiederholung ein Duplikat erzeugen. Das System muss zwischen sicherer Wiederholung, Warten und manueller Prüfung des Ergebnisses unterscheiden.

Den Netzwerkteil sollte man besser mit dem Infrastrukturverantwortlichen der Location abstimmen. Der Artikel über Gäste-Wi-Fi auf der Konferenz erklärt, warum die dienstliche Registrierung nicht mit einem einzigen allgemeinen Geschwindigkeitstest zusammen mit dem Gastverkehr bewertet werden darf.

Stände, QR-Codes und Rückmeldung

Der Labortest wird durch einen Vor-Ort-Durchlauf an realen Ständen, Geräten und Trägern ergänzt. Das Team prüft Telefonbildschirme mit unterschiedlicher Helligkeit, Papiercodes, Reflexionen, erneutes Vorhalten und Lärm. Der Operator muss ein eindeutiges Ergebnis des Vorgangs sehen, das nicht nur von Ton oder Farbe in der Oberfläche abhängt.

GS1 bringt die Lesbarkeit eines zweidimensionalen Codes mit einem freien Feld um das Symbol, Kontrast, einem gleichmäßigen Raster und dem Fehlen von grafischem Rauschen in Verbindung. Deshalb werden in den Durchlauf die Größen, Materialien und Darstellungsarten einbezogen, die die Gäste erhalten. Ein perfektes Testbild auf dem Monitor ersetzt keinen realen Träger.

In unserem Szenario prüfen wir sechs unterscheidbare Zustände: „Code gelesen“, „Prüfung läuft“, „Eintritt bestätigt“, „bereits erfasst“, „Eintrag nicht gefunden“ und „keine Verbindung“. Die W3C-Richtlinie zu Statusmeldungen verlangt, dass eine Zustandsänderung programmatisch festgestellt werden kann, ohne den Fokus zwangsweise zu verschieben. Für den Stand ist das auch eine Frage der Schulungsgeschwindigkeit des Personals.

Das physische Schema der Eingänge, die Warteschlangen und die Platzierung der Geräte müssen bei der Auswahl der Location berücksichtigt werden. Das System kann einen Servertest bestehen, aber Durchsatzkapazität durch ein enges Foyer, eine gemeinsame Linie für mehrere Kategorien oder einen Drucker verlieren, zu dem die Operatoren durch den Gästestrom gehen.

Wie prüft man Backup und Wiederherstellung?

Ein Backup gilt erst dann als funktionsfähig, wenn ein tatsächliches Umschalten, die Fortsetzung des Check-ins und ein anschließender Abgleich erfolgt sind. Wenn ein lokaler oder autonomer Modus angekündigt ist, trennt das Team die primäre Abhängigkeit, sammelt Vorgänge, stellt die Verbindung wieder her und prüft auf Konflikte. Wenn es keinen autonomen Modus gibt, wird der manuelle Prozess und ein einheitlicher Umschaltbefehl für alle Stände geprobt.

Das Wiederherstellungsszenario läuft so ab:

1. Der Übungsleiter erklärt den Ausfall der gewählten Abhängigkeit.
2. Das Team erfasst den Zeitpunkt der Erkennung und das sichtbare Symptom.
3. Der leitende Registrierungsmitarbeiter gibt einen abgestimmten Umschaltbefehl.
4. Die Operatoren setzen den Check-in über den Backup-Weg fort.
5. Der Beobachter erfasst manuelle und lokale Vermerke.
6. Der Hauptdienst wird in der abgestimmten Reihenfolge wiederhergestellt.
7. Die Daten werden abgeglichen, Konflikte geklärt und die endgültige Version bestätigt.

Ein detailliertes Schema zur Verbindung und zum Umgang mit lokalen Listen finden Sie im Artikel über Veranstaltungen ohne mobiles Internet. In der aktuellen Übung sind die Übergabepunkte und die Rücksynchronisierung wichtig: wer den Befehl gibt, was der Operator sieht und wie eine doppelte Anwesenheitsmarkierung ausgeschlossen wird.

Das Backup darf nicht eigenmächtig von jedem Stand aktiviert werden. Nicht abgestimmte lokale Entscheidungen erzeugen mehrere Versionen der Wahrheit. Ein Leiter entscheidet über den Modus, und das Übungsprotokoll hält Zeitpunkt, Grund und Geltungsbereich fest.

Bericht des Auftragnehmers nach dem Probelauf

Der Bericht muss die tatsächlich erzeugte Last und das Ergebnis jeder Geschäftsoperation zeigen. Getrennt davon werden Einschränkungen und Verantwortliche für Korrekturen angegeben. Ein einzelnes Diagramm der durchschnittlichen Latenz reicht nicht aus.

Der Auftraggeber benötigt ein Zeitprofil, den Status des Drucks und das Verhalten der Reserve. Für kritische Defekte wird zusätzlich das Ergebnis eines erneuten Probelaufs nach dem ursprünglichen Szenario ergänzt.

Der Bericht enthält:

• die Version des Systems und des Szenarios;
• die Version der Testdaten und der Hardware;
• das geplante Profil des Beginns der Operationen;
• das tatsächlich erzeugte Profil;
• die Ergebnisse jeder einzelnen Operation;
• Fehler und Timeouts;
• Antworten „Zu viele Anfragen“ und das Verhalten der Wiederholungen;
• dropped_iterations und die Ressourcen des Generators;
• die vollständige Bearbeitungszeit am Arbeitsplatz;
• die Druckwarteschlange und Fälle erneuter Ausgabe;
• das Ergebnis des Umschaltens auf die Reserve und der Wiederherstellung;
• die Liste der Defekte, Verantwortlichen und Kriterien für die erneute Prüfung.

Wir verknüpfen den Defekt mit einem reproduzierbaren Szenario. In der Karte bleiben die Ausgangsbedingungen und die Reihenfolge der Aktionen erhalten. Dort geben wir auch das erwartete Ergebnis und das an, was das Team beim Probelauf gesehen hat.

Für die Fortsetzung der Arbeit werden die Auswirkung, eine vorläufige Maßnahme und der Verantwortliche festgehalten. Das allgemeine Vorgehen lässt sich mit dem Incident-Log bei der Veranstaltung abgleichen. Vor der Eröffnung der Location werden Defekte getrennt vom Arbeitsjournal der Veranstaltung geführt.

Die Meldung „behoben“ schließt die Anmerkung nicht. Das Team wiederholt dasselbe Szenario unter vergleichbaren Ausgangsbedingungen. Wenn sich das Ergebnis geändert hat, erscheint im Bericht ein neues PASS. Wenn nicht, bleibt der Defekt offen oder wird als ausdrücklich vereinbarte Einschränkung akzeptiert.

Abnahme-Checkliste für den Auftraggeber

Sie benötigen eine kurze Liste verständlicher Bestätigungen, nicht Zugriff auf jeden technischen Ablaufplan. Prüfen Sie vor Abschluss der Probe, dass das Ankunftsprofil nachgebildet wurde, Sonderfälle den Hauptstrom nicht gestoppt haben und die Reserve tatsächlich aktiviert ist. Benennen Sie für jeden kritischen Defekt einen Verantwortlichen und führen Sie nach der Behebung einen erneuten Durchlauf mit festgehaltenem Ergebnis durch.

1. Ankunftsfenster, Eingänge und Ablauf der Vorgänge sind beschrieben.
2. Der Basis-Durchlauf jeder Route ist vor der hohen Last abgeschlossen.
3. Erwarteter Strom und plötzlicher Anstieg wurden getrennt durchgeführt.
4. Die tatsächliche Intensität entspricht dem Plan, oder die Abweichung ist erklärt.
5. Ein erfolgreicher QR-Code endet mit genau einer korrekten Markierung.
6. Eine Wiederholung nach dem Timeout erzeugt kein Duplikat.
7. Der Druck wurde auf realen Druckern und mit realen Verbrauchsmaterialien geprüft.
8. Manuelle Fälle laufen in einer separaten Linie und blockieren den Hauptstrom nicht.
9. Die Operatoren sehen verständliche Status und die nächste Aktion.
10. Es wurden synthetische Daten mit eingeschränkten Zugriffen verwendet.
11. Ausfall einer Abhängigkeit und Wiederherstellung wurden in der Praxis durchlaufen.
12. Jeder kritische Defekt wurde nach der Behebung erneut geprüft.

Eine Vor-Ort-Probe lässt sich am besten nach denselben Regeln aufbauen wie eine technische Probe der Veranstaltung: Szenario, beobachtbares Ergebnis, Verantwortlicher für die Anmerkung und erneute Prüfung. Der Unterschied liegt im Fokus – hier achtet das gesamte Team nur auf den Registrierungskreislauf und seine Abhängigkeiten.

Die Abnahme muss den gesamten Weg des Gastes unter realem Strom, bei einer Störung und nach der Wiederherstellung abdecken. Ein einzelner Scanner oder ein Formular liefern kein vollständiges Bild.

Quellen

• Grafana k6: Arten von Lasttests
• Grafana k6: Thresholds-Kriterien
• Grafana k6: Dropped Iterations
• Microsoft Azure Architecture Center: Retry Storm Antipattern
• Microsoft Azure Architecture Center: Retry Pattern
• Zebra DataWedge: Barcode-Eingabe und Feedback
• GS1: Leitfaden zu Qualität und Lesbarkeit zweidimensionaler Codes
• IETF RFC 6585: HTTP 429 Too Many Requests
• W3C WCAG 2.2: Status Messages
• Federal Law No. 152-FZ: Grundsätze der Verarbeitung personenbezogener Daten