Assessor_2.0/docs/USER_FLOW_CHECKS.md

ASSESSOR – Prüfläufe für Benutzerabläufe

Stand: 2026-07-17 Zugehörige Planphase: Phase 1 – bestehenden Funktionsumfang und Testkorpus absichern

Ziel

Dieses Dokument trennt automatisierte Fachabläufe von manuellen Browserprüfungen und legt fest, wann echte Browser-End-to-End-Tests eingeführt werden.

Automatisierter Assessment-Ablauf

Der Test tests/workflows/assessment-workflow.test.ts prüft zusammenhängend:

1. Import einer CSV- und einer JSON-Datei
2. Zusammenführung beider Dateien zu einem Projekt
3. Erhaltung von Quelldatei und Quellblatt
4. Suche nach einem Finding über den kombinierten Datenbestand
5. Aufnahme des Findings in die Actionlist
6. Pflege von Status, Priorität, Owner und nächstem Schritt
7. Filterung auf markierte Actionlist-Einträge
8. Erzeugung des HTML-Management-Dashboards
9. Erzeugung und erneutes Einlesen eines Snapshots
10. Erhaltung der Reviewdaten nach dem Snapshot-Roundtrip

Der Ablauf prüft die Fachmodule ohne React- oder Tauri-Abhängigkeit. Damit bildet er die Grundlage für die spätere Server- und Datenbankmigration.

Import- und Belastungsbaseline

Automatisch geprüft werden außerdem:

• generische CSV-Fixture über die vollständige Importpipeline
• Windows-1252-Fallback bei ungültigem UTF-8
• Ablehnung vollständig leerer Dateien
• Import von 5.000 CSV-Findings ohne Zeilenverlust
• kontrollierte Ablehnung eines abgeschnittenen XLSX-ZIP-Containers
• Entfernung aktiver HTML-Inhalte
• Ablehnung syntaktisch ungültiger XML- und JSON-Inhalte
• keine Offenlegung von Excel-Formeln als importierter Zellinhalt

Die Grenze von 5.000 Findings bleibt die verifizierte UI-Testbaseline. Die verbindlichen Import-, Parser- und Speichergrenzen stehen in docs/IMPORT_SECURITY_LIMITS.md; zusätzlich prüft der Lasttest einen Import mit 30.000 Datensätzen.

Manueller Browser-Prüflauf

Bis Browser-End-to-End-Tests eingeführt werden, soll bei größeren UI-, Import- oder Exportänderungen folgender Ablauf manuell geprüft werden:

1. Anwendung im Entwicklungsmodus starten.
2. fixtures/generic/findings.synthetic.csv importieren.
3. Zusätzlich eine zweite synthetische Datei importieren.
4. Kontrollieren, dass Projekt- und Quellansichten vorhanden sind.
5. Nach Synthetic suchen und Trefferanzahl prüfen.
6. Nach Severity oder einem numerischen Feld sortieren.
7. Ein Finding in die Actionlist aufnehmen.
8. Status, Priorität, Owner, Frist und nächsten Schritt pflegen.
9. Auf die Actionlist-Ansicht filtern.
10. HTML-Dashboard erzeugen und auf maskierte beziehungsweise escaped Werte prüfen.
11. Snapshot exportieren und erneut einlesen.
12. Kontrollieren, dass Findings und Reviewdaten erhalten bleiben.
13. Anwendung neu laden und die erwartete lokale Reviewpersistenz prüfen.
14. Local-only-Verhalten kontrollieren: keine externen Requests und keine externen Assets.

Ergebnisse eines manuellen Prüflaufs sollen bei Releases mit Datum, geprüfter Version und Abweichungen dokumentiert werden.

Entscheidung zu Browser-End-to-End-Tests

Browser-End-to-End-Tests sind für ASSESSOR erforderlich, werden aber nicht als Teil der gegenwärtigen Parser-Baseline eingeführt.

Begründung:

• Die Fachlogik ist bereits ohne UI automatisiert prüfbar.
• Die Oberfläche befindet sich noch im Übergang von Tauri zu einer plattformneutralen Browserarchitektur.
• Zu frühe UI-Automatisierung würde stark an temporäre DOM-Strukturen und Tauri-Verhalten gekoppelt.
• Nach Phase 4 können dieselben Tests gegen Browser- und optionale Tauri-Ausführung verwendet werden.

Einführungspunkt:

• spätestens nach Abschluss von Phase 4
• zwingend vor Abschluss von Phase 10 und vor dem Firmenbetrieb

Mindestens zu automatisierende Browserabläufe:

• Einzel- und Mehrdateiauswahl
• Importvorschau und Fehlerdarstellung
• Wechsel zwischen Projekt- und Quelltabellen
• Suche, Filter und Sortierung
• Review- und Actionlist-Bearbeitung
• Exportdownload
• Snapshot-Wiederherstellung
• Persistenz nach Neuladen
• Tastaturbedienung der zentralen Dialoge und Tabellen
• Nachweis, dass importiertes HTML nicht aktiv ausgeführt wird

Noch nicht abgedeckt

Für den Abschluss von Phase 1 fehlen weiterhin belastbare synthetische oder freigegebene Fixtures für:

• PingCastle
• CIS-CAT
• Maester

Reale Kunden- oder Assessment-Daten dürfen nur nach ausdrücklicher Freigabe und vollständiger Anonymisierung in den Testkorpus aufgenommen werden.