101 lines
4.3 KiB
Markdown
101 lines
4.3 KiB
Markdown
# 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.
|