votianng/legacy-ui-tests

Oberflächentests der alten Votian-PHP-Anwendung

Die Tests bedienen die echte Anwendung unter https://test.sb.assecutor.de. Sie verwenden echte Anmeldung, Kundenwahl, Preisberechnung und Auftragsformulare; es gibt keine simulierten Geschäftsdaten. Die Anwendung läuft auf 172.16.0.158 aus /data/0/votian-test/html. Die Tests liegen daneben unter /data/0/votian-test/tests/ui, außerhalb des Webroots. PHP-Produktivcode wird nicht verändert.

Ausführen

Auf dem Server, mit interaktivem Terminal:

/data/0/votian-test/tests/ui/run-server.sh

Benutzername und Passwort werden abgefragt. Der Standardlauf speichert keine Aufträge; der Speichertest wird ausdrücklich übersprungen. Für den vollständigen Lauf einschließlich eines neuen Testauftrags:

/data/0/votian-test/tests/ui/run-server.sh --create-order

Einen bereits angelegten Testauftrag erneut prüfen, ohne einen weiteren anzulegen:

/data/0/votian-test/tests/ui/run-server.sh --verify-order 21891310 UI-TEST-20261026T094639-670e98

Der Runner startet einen kurzlebigen Docker-Container mit mcr.microsoft.com/playwright:v1.63.0-noble, installiert die drei per Lockfile festgelegten npm-Pakete im Testverzeichnis und startet Firefox. Er bindet nur das Testverzeichnis ein, keine Anwendungs- oder Datenbankverzeichnisse. Docker und HTTPS-Zugriff auf die Testanwendung sind erforderlich. Parallel gestartete Läufe im selben Verzeichnis vermeiden.

Lokal, mit Node.js 20 oder neuer und Python 3:

cd legacy-ui-tests
npm ci
npx playwright install firefox
python3 run.py

Alternativ im Projektstamm: npm run test:legacy-ui. Die Servervariante ist auf diesem Arbeitsplatz die geprüfte Ausführungsumgebung: Der lokale Firefox startete hier wegen eines Profilverzeichnisfehlers nicht.

Testumfang

15 Tests prüfen:

• JavaScript-Fehler beim Öffnen und Aufbau der vier Frames;
• leeres Formular und gesperrte Sendeschaltfläche;
• Bezahlerwahl über die echte Kundenliste;
• Auftragseingang „Sonstiges“ und Rücksetzen des Zusatzfelds;
• Abhängigkeiten zwischen Angebot, manueller Disposition und unvollständigem Status;
• Versicherung ein-/ausschalten, Warenwert und drei ungültige Eingaben;
• Vertauschen und Entfernen von Stationen;
• Vorbereitung mit zwei Testkunden, Besteller, Hinweisen und 10,00 € Festpreis;
• optionales Speichern über „Senden“, Serverbestätigung mit Auftragsnummer und erneutes Laden einer frischen Detailansicht. Dort werden Stationsreihenfolge, Hinweise, Festpreis und „UNFERTIG!“ geprüft.

Es handelt sich um funktionale Tests der Einzelerfassung, nicht um vollständige Abdeckung der Verwaltung, Disposition oder Abrechnung. Die Unit-Tests stehen separat in ../legacy-php-tests/.

Testdaten und Schreibzugriffe

Der Speichertest nutzt ausschließlich Testkunde Assecutor 1 (Kostenstelle 878914) und Testkunde Assecutor 2 (878915). Beide Stammsätze sind als „Testaufträge Assecutor“ gekennzeichnet. Jeder neue Auftrag erhält einen eindeutigen UI-TEST-…-Marker im Besteller und in beiden Stationshinweisen, darunter „NICHT AUSFÜHREN“.

Vor dem Senden validiert eine Netzwerksperre die tatsächlichen Formulardaten: genau zwei markierte Teststationen, Testkunde 1 als Bezahler, 10,00 €, manuelle Disposition, unvollständig, kein Kurier, keine Serien-/Mehrfachaufträge, keine Höherversicherung und sendmail=0. Pro Test wird höchstens ein Speichervorgang zugelassen; Wiederholungen und Retries des Speichertests werden abgewiesen. Ein vor dem Versand angelegter Eintrag in reports/created-orders.jsonl verhindert nach einem unklaren Ausgang erneutes Speichern, bis das Ergebnis geprüft wurde. Ein Testauftrag wird nicht automatisch gelöscht oder abgeschlossen.

Andere fachliche Schreibzugriffe werden vor dem Versand blockiert. Freigegeben sind Anmeldung, gelesene Nachschlagefunktionen, Kunden-/Tourensuche und Preisberechnung. Die automatische News-Ticker-Bestätigung und JavaScript-Fehlertelemetrie werden im Browser beantwortet, ohne sie zu speichern. Google-Maps-Telemetrie wird unterdrückt. Normale serverseitige Sitzungen, Zugriffsprotokolle und Folgearbeiten der PHP-Anwendung bleiben möglich; dies ist keine vollständig schreibfreie Datenbank-Sandbox.

Zugangsdaten werden nur abgefragt bzw. aus VOTIAN_UI_USERNAME und VOTIAN_UI_PASSWORD gelesen. Sie werden nicht in Dateien gespeichert. Anmeldung und Sitzungszustand bleiben im Speicher; Traces und Videos sind deaktiviert. Berichte und Screenshots sind von Git ausgeschlossen und können Daten der Testanwendung enthalten.

Bekannter Fehler und Browserwahl

jobs/job_edit.php:13 führt top.opener.top.job_edit = this aus, obwohl die über target="_blank" geöffnete Seite kein window.opener besitzt. Der Test „Auftragserfassung startet ohne JavaScript-Ausnahme“ bleibt deshalb absichtlich rot. Der exakt erkannte Fehler wird in den anderen Tests als Anhang protokolliert; neue JavaScript-Ausnahmen lassen jeden betroffenen Test scheitern. Es gibt kein test.fail() oder stilles Überspringen dieses Anwendungsfehlers.

Im vollständigen Speichertest trat zusätzlich TypeError: can't access property "currentTSZ", parent.job_options.document.tourOptions is undefined auf. Die Preisantwort greift auf ein während des Speicherns neu geladenes Formular zu (erzeugter JavaScript-Code aus jobs/job_options.php:3357). Das Speichern und die Prüfung der frischen Detailansicht waren trotzdem erfolgreich. Der Test bleibt wegen der erfassten Ausnahme rot; sie wird nicht als erlaubter Fehler unterdrückt. Der zeitliche Zusammenhang spricht für eine Race Condition, deren genauer Auslöser gesondert untersucht werden muss.

Für die Netzwerksperre mit den alten document.write-Popups wird Firefox verwendet. Playwright 1.63 blockiert diese Popups unter Chromium bereits durch aktiviertes Routing; das ist ein bestätigter Playwright-Fehler, kein Beleg für einen Speicherfehler der PHP-Anwendung. Der Ablauf wurde dafür nicht durch direkte API- oder Datenbank-Schreibzugriffe ersetzt.

Ergebnisse

Vollständiger Serverlauf vom 26.10.2026, mit --create-order: 15 ausgeführt, 13 bestanden, 2 fehlgeschlagen, 0 übersprungen, Laufzeit 41 Sekunden. Beide Fehlschläge betreffen die oben dokumentierten JavaScript-Ausnahmen. Alle fachlichen Prüfungen des gespeicherten Auftrags waren erfolgreich.

Angelegte und erhaltene Testaufträge:

Auftrag	Marker	Prüfung
21891310	UI-TEST-20261026T094639-670e98	Erstlauf; Speicherung zusätzlich per lesender Datenbankabfrage bestätigt, frische Detailansicht geprüft
21891311	UI-TEST-20261026T095313-b89f03	Vollständiger Lauf; Serverbestätigung und Detailansicht geprüft

Beide verwenden 10,00 € Festpreis, Testkunde 1 als Bezahler, manuelle Disposition, „unvollständig“ und keine Kurierzuweisung. Sie wurden nicht abgeschlossen oder gelöscht.

Geprüftes Container-Image: sha256:2c1f4e0fd6450f43ddb46d60c2a6df30855a8588e165b1f2559fb0eda8d7ff35 (Tag mcr.microsoft.com/playwright:v1.63.0-noble). Im vollständigen Lauf wurde die Datenübertragung nicht simuliert; die Zugangsdaten kamen aus der interaktiven Eingabe.

Nach jedem Lauf: reports/html/index.html, reports/junit.xml, reports/results.json und test-results/ mit Screenshots. Die Liste angelegter Aufträge wird separat fortgeschrieben und nicht durch den nächsten Testlauf gelöscht.

HTML-Bericht öffnen:

npx playwright show-report reports/html

Der Rückgabecode bleibt bei einem offenen Anwendungsfehler ungleich null. Maßgeblich ist der letzte vollständige Lauf; ein gefilterter Wiederholungslauf überschreibt die Standardberichte.