Visuelle Regressionstests

Visuelle Regressionstests vergleichen automatisiert Screenshots einer Oberfläche vor und nach einer Änderung, um unbeabsichtigte optische Abweichungen zu erkennen.

Related workflow terms: Headless-Browser, Playwright.

So funktionieren visuelle Regressionstests

Der Ablauf besteht aus Aufnahme, Vergleich und Prüfung. Zunächst entsteht für jeden UI-Zustand, also eine Seite, Komponente oder bestimmte Viewport-Größe, ein Referenzbild. Diese Baseline steht für das erwartete Aussehen.

Nach einer Codeänderung werden dieselben Zustände erneut aufgenommen. Das Testwerkzeug vergleicht jedes neue Bild pixelweise oder mit einem Wahrnehmungsalgorithmus mit seiner Baseline und hebt Unterschiede hervor.

Anschließend prüft ein Mensch die Abweichungen. Gewollte Änderungen wie eine neu gestaltete Schaltfläche werden akzeptiert und zur neuen Baseline. Unbeabsichtigte Änderungen wie verrutschte Elemente oder defekte Layouts gelten als Regression und müssen korrigiert werden.

Dieser Zyklus läuft meist in CI/CD und stoppt sichtbare Fehler vor der Produktion.

Typische Einsatzbereiche

• Designsysteme: Änderungen an gemeinsamen Komponenten dürfen ihre Darstellung in mehreren Anwendungen nicht unbeabsichtigt verändern.
• Browser-Vergleiche: Dieselbe Seite wird in Chrome, Firefox, Safari und Edge auf einheitliches Rendering geprüft.
• Responsive Layouts: Aufnahmen in mehreren Breiten decken fehlerhafte Breakpoints auf.
• Theme-Änderungen: Dunkelmodus, Markenfarben und Typografie werden auf Nebenwirkungen in anderen UI-Bereichen geprüft.
• Barrierefreiheitsprüfungen: Sichtbare Änderungen an Lesbarkeit, Kontrast oder Fokusmarkierung fallen nach einer Codeänderung auf.

Pixel-Diff und wahrnehmungsbasierter Diff

Ein Pixel-Diff meldet jeden abweichenden Pixel. Das ist genau, aber störanfällig: Kantenglättung, Subpixel-Schrift und leicht andere Animationszeitpunkte lösen Fehlalarme aus. Ein Toleranzwert kann dieses Rauschen reduzieren.

Ein wahrnehmungsbasierter Diff bewertet Unterschiede eher wie das menschliche Auge. Kaum sichtbare Farb- oder Subpixelabweichungen bleiben unbeachtet, erkennbare Änderungen werden gemeldet. Das senkt Fehlalarme, kann aber sehr feine Regressionen übersehen.

Viele Teams beginnen mit Pixelvergleich und kleiner Toleranz und wechseln bei einer wachsenden Testsuite auf Wahrnehmungsvergleich, wenn zu viele Fehlalarme entstehen.

Verlässlich werden solche Tests erst mit stabilen Voraussetzungen: feste Schriften, deterministische Daten und maskierte dynamische Bereiche. Andernfalls verliert das Team das Vertrauen in die Meldungen.

Häufige Fehler

• Dynamische Inhalte nicht stabilisieren. Maskiere Zeitstempel, Live-Daten, Zufallsinhalte und Anzeigen oder verwende feste Testdaten.
• In verschiedenen Umgebungen aufnehmen. macOS und Linux rendern Schrift, Kantenglättung und Browser-Vorgaben unterschiedlich. Nutze dieselbe containerisierte Umgebung.
• Die Toleranz zu hoch setzen. So verschwinden neben Fehlalarmen auch echte Fehler. Beginne niedrig und passe nur an beobachtetes Rauschen an.
• Baselines nicht pflegen. Prüfe und aktualisiere sie bewusst. Eine Änderung darf nicht automatisch nur deshalb akzeptiert werden, weil das Bild anders aussieht.