DOM-Vergleich vs. Visueller Vergleich: Zwei Ansaetze, Zwei Blinde Flecken
DOM-Vergleich vs. visueller Vergleich: Gegenueberstellung zweier Methoden zur Erkennung von Interface-Aenderungen -- die erste analysiert Aenderungen im HTML-Baum (Document Object Model), die zweite vergleicht Screenshots Pixel fuer Pixel -- wobei jede blinde Flecken hat, die die andere nicht abdeckt.
Hier ein Szenario, das Sie wahrscheinlich schon erlebt haben: Ihr Team deployt ein Update. Die Unit-Tests bestehen. Die Integrationstests bestehen. Die End-to-End-Tests bestehen. Und trotzdem meldet ein Nutzer, dass der Zahlungsbutton auf Mobile unter dem Footer verschwunden ist.
Wie ist das moeglich? Weil Ihre Tests pruefen, ob das DOM den richtigen Button mit dem richtigen Text und dem richtigen Link enthaelt -- aber niemand prueft, ob dieser Button tatsaechlich auf dem Bildschirm sichtbar ist, an der richtigen Position, in der richtigen Groesse.
Genau das ist das Problem bei der Wahl zwischen DOM-Vergleich und visuellem Vergleich. Diese beiden Ansaetze werden oft als Alternativen dargestellt. In Wirklichkeit sind sie zwei komplementaere Facetten desselben Problems -- und nur einen davon zu nutzen bedeutet, einen blinden Fleck in Ihrer Teststrategie zu akzeptieren.
Dieser Artikel erlaeutert, was jeder Ansatz erkennt, was er uebersieht, und warum der strukturelle Vergleich -- der das DOM liest UND die berechneten CSS-Eigenschaften prueft -- heute die umfassendste Antwort auf das Problem der visuellen Regression ist.
Was der DOM-Vergleich tatsaechlich leistet
Der DOM-Vergleich besteht darin, einen Snapshot des HTML-Baums einer Seite zu einem Zeitpunkt T zu erstellen und ihn dann mit einem Snapshot zum Zeitpunkt T+1 zu vergleichen. Wenn ein Knoten hinzugefuegt, entfernt oder geaendert wurde, zeigt der Diff es an.
Das ist ein leistungsfaehiger Ansatz zur Erkennung struktureller Aenderungen. Ein versehentlich entfernter Absatz, ein geaendertes href-Attribut, eine hinzugefuegte oder entfernte CSS-Klasse -- der DOM-Vergleich sieht alles, was die Dokumentstruktur betrifft.
Die Tools, die diesen Ansatz verwenden, sind zahlreich. Jest Snapshot-Tests sind das bekannteste Beispiel. Sie serialisieren das Rendering einer React- oder Vue-Komponente, speichern es in einer Datei, und bei jeder Ausfuehrung vergleicht Jest das aktuelle Ergebnis mit dem gespeicherten Snapshot.
Das Problem ist, dass der DOM-Vergleich nur HTML sieht. Er sieht nicht das visuelle Ergebnis.
Was der DOM-Vergleich nicht erkennt
Nehmen wir ein konkretes Beispiel. Sie haben einen Button mit der Klasse .btn-primary. In Ihrer CSS-Datei definiert diese Klasse background-color: #2563EB (Blau). Ein Entwickler aendert die CSS-Datei und setzt diese Farbe auf #DC2626 (Rot). Das HTML hat sich nicht veraendert. Das DOM ist identisch. Der Jest-Snapshot wird gruen.
Aber Ihr Button ist in Produktion von Blau auf Rot gewechselt.
Das ist kein theoretischer Fall. Hier sind die konkreten Situationen, in denen der DOM-Vergleich blind ist.
Externe CSS-Aenderungen. Jede Aenderung in einem Stylesheet, einer Theme-Datei, einer CSS Custom Property, einem Design-System-Token -- nichts davon erscheint im DOM. Das HTML bleibt identisch, nur das Rendering aendert sich. Und das Rendering ist das, was Ihre Nutzer sehen.
Font-Probleme. Eine Google Font, die nicht mehr laedt, ein System-Fallback, der aktiviert wird, ein Font-Weight, das sich aendert -- das DOM enthaelt immer noch denselben <p>-Tag mit demselben Text. Aber visuell ist der gesamte typografische Rhythmus Ihrer Seite zerbrochen.
z-index- und Ueberlappungsprobleme. Zwei Elemente, die sich wegen eines z-index-Konflikts ueberlappen, ein Modal, das unter dem Inhalt statt darueber erscheint, ein Tooltip, der aus seinem Container herausragt -- das DOM enthaelt alle Elemente korrekt. Es ist ihre visuelle Stapelung, die falsch ist.
Responsive-Probleme. Ein Flex-Container, der nicht mehr korrekt umbricht, ein Element, das aus seinem Parent herausragt, eine Media Query, die nicht mehr greift -- das DOM ist dasselbe. Es ist das Layout, das sich geaendert hat.
Spacing- und Ausrichtungsprobleme. Ein Margin, der von 16px auf 0px wechselt, ein Padding, das verschwindet, ein Gap zwischen Elementen, der sich aendert -- nichts im DOM sichtbar, wenn diese Eigenschaften in CSS definiert sind.
Der DOM-Vergleich ist konzeptionell blind fuer alles, was ausserhalb des HTML definiert ist. Und in einer modernen Webanwendung wird der Grossteil des visuellen Renderings in CSS definiert -- nicht in HTML.
Was der visuelle Vergleich tatsaechlich leistet
Der visuelle Vergleich geht das Problem von der anderen Seite an. Statt Code zu vergleichen, vergleicht er Bilder. Sie erfassen einen Screenshot Ihrer Seite zum Zeitpunkt T (die Baseline), dann einen Screenshot zum Zeitpunkt T+1, und ein Algorithmus vergleicht die beiden Bilder Pixel fuer Pixel -- oder mit ausgefeilteren perzeptuellen Methoden wie pHash oder SSIM.
Der Vorteil liegt auf der Hand: Der visuelle Vergleich sieht, was der Nutzer sieht. Wenn ein Button die Farbe aendert, erkennt er es. Wenn ein Text aus seinem Container herausragt, erkennt er es. Wenn ein Element unter einem anderen verschwindet, erkennt er es -- wobei der Pixel-fuer-Pixel-Vergleich an seine eigenen Grenzen stoesst.
Das ist der Ansatz, den Tools wie Percy, Applitools, Chromatic und BackstopJS verwenden. Er hat das Konzept des Visual Regression Testing demokratisiert und Tausenden von Teams ermoeglicht, Bugs zu erkennen, die ihre funktionalen Tests nicht sahen.
Aber er hat auch eigene blinde Flecken. Und sie sind erheblich.
Was der visuelle Vergleich nicht erkennt
Unsichtbare, aber semantisch wichtige Aenderungen. Ein Link, dessen href von /checkout zu /cart wechselt, erzeugt keine visuelle Aenderung -- Text und Stil des Links sind identisch. Aber der Nutzer, der klickt, landet nicht mehr am richtigen Ort. Der visuelle Vergleich sieht nichts.
Barrierefreiheits-Aenderungen. Ein entferntes aria-label, eine geaenderte role, ein fehlendes alt bei einem Bild -- nichts in einem Screenshot sichtbar. Aber fuer Screenreader-Nutzer ist Ihre Seite unbrauchbar geworden.
Dynamische Inhaltaenderungen. Ein Preis, der von 29 EUR auf 290 EUR wechselt, ein Zaehler, der eine falsche Zahl anzeigt, ein Nutzername, der nicht mehr laedt -- wenn das Layout identisch bleibt, wird der Pixel-fuer-Pixel-Vergleich es moeglicherweise nicht als Regression melden, besonders bei hohen Toleranzschwellen.
Massive False Positives. Das ist das Problem Nummer eins beim reinen visuellen Vergleich. Ein blinkender Cursor, eine Animation in einem anderen Frame, dynamischer Inhalt (Datum, Uhrzeit, Werbung), leicht unterschiedliches Font-Rendering zwischen zwei Ausfuehrungen -- all das erzeugt visuelle Diffs, die keine Regressionen sind. Laut einer Google-Studie zur Testverlaesslichkeit (2016) machen instabile Tests -- sogenannte "Flaky Tests" -- 1,5 % aller Testausfuehrungen bei Google aus, und Rendering-Variationen sind eine der Hauptursachen fuer Flakiness bei visuellen Tests.
Fehlende Erklaerung. Wenn ein visueller Vergleich Ihnen einen Diff zeigt, sagt er "hier hat sich etwas geaendert", indem er einen Bereich hervorhebt. Aber er sagt Ihnen nicht, was. Ist es die Farbe? Die Groesse? Die Position? Der Inhalt? Sie muessen selbst ermitteln. Auf einer komplexen Seite mit Dutzenden von Aenderungen wird das Triage zur Vollzeitbeschaeftigung.
Das eigentliche Problem: Zwei Methoden, zwei symmetrische blinde Flecken
Wenn Sie bis hierhin gefolgt sind, sehen Sie das Paradoxon.
Der DOM-Vergleich erkennt HTML-Aenderungen, aber uebersieht visuelle Aenderungen. Der visuelle Vergleich erkennt visuelle Aenderungen, aber uebersieht semantische Aenderungen. Beide Ansaetze sind genau dort blind, wo der andere stark ist.
Dieses Paradoxon ist kein Zufall. Es spiegelt die fundamentale Dualitaet einer Webseite wider: Der Code (DOM + CSS) erzeugt ein visuelles Rendering, aber die Beziehung zwischen beiden ist nicht bijektiv. Dasselbe DOM kann je nach angewandtem CSS sehr unterschiedliche Renderings erzeugen. Und dasselbe visuelle Rendering kann von sehr unterschiedlichen DOMs erzeugt werden.
Deshalb ist die Wahl zwischen DOM-Vergleich und visuellem Vergleich ein falsches Dilemma. Die Frage ist nicht "welcher ist besser" -- die Frage ist "wie decke ich beide Dimensionen ab".
Einige Teams versuchen, dieses Problem zu loesen, indem sie beide Tools kombinieren: Jest fuer DOM-Snapshots und Percy oder BackstopJS fuer Screenshots. Das ist besser als nichts, aber es bedeutet auch zwei Pipelines zu pflegen, zwei Baseline-Saetze zu verwalten, zwei False-Positive-Quellen zu sortieren und keine Korrelation zwischen den Ergebnissen. Wenn Jest sagt "das DOM hat sich geaendert" und Percy sagt "das Visuelle hat sich geaendert", sagt Ihnen niemand, ob diese beiden Aenderungen zusammenhaengen.
Der strukturelle Vergleich: DOM lesen UND berechnetes CSS pruefen
Es gibt einen dritten Ansatz, der sich weder mit dem DOM allein noch mit Pixeln allein begnuegt. Das ist der strukturelle Vergleich -- und das ist der Ansatz, den Delta-QA gewaehlt hat.
Das Prinzip ist folgendes: Statt einen statischen HTML-Baum oder ein flaches Bild zu vergleichen, liest Delta-QA jedes DOM-Element und ruft seine berechneten CSS-Eigenschaften ab -- also die Styles, die der Browser tatsaechlich angewendet hat, nach Aufloesung aller Kaskaden, Vererbungen, Media Queries und CSS-Variablen.
Konkret kennt Delta-QA fuer jedes Element Ihrer Seite seine exakte Position, seine tatsaechlichen Dimensionen, seine effektive Farbe, seine angewandte Typografie, seine aufgeloesten Margins und Paddings, seinen berechneten z-index, seine Opazitaet, seine Sichtbarkeit. Nicht die im CSS-Quellcode deklarierten Styles -- die Styles, wie der Browser sie berechnet und angewendet hat.
Dieser Ansatz loest beide blinden Flecken gleichzeitig.
Er erkennt CSS-Aenderungen. Wenn sich eine CSS-Variable aendert und die Farbe eines Buttons beeinflusst, sieht Delta-QA es -- weil es die berechneten CSS-Eigenschaften vergleicht, nicht den HTML-Quellcode. Die background-color des Buttons ist von rgb(37, 99, 235) auf rgb(220, 38, 38) gewechselt. Der Bericht sagt es explizit.
Er erkennt DOM-Aenderungen. Wenn ein Element im HTML-Baum hinzugefuegt, entfernt oder verschoben wird, sieht Delta-QA es -- weil er das DOM Element fuer Element durchlaeuft.
Er erzeugt keine renderingbedingten False Positives. Kein Pixel-fuer-Pixel-Vergleich, also kein Diff durch einen blinkenden Cursor, eine Animation in einem anderen Frame oder leichtes Font-Antialiasing. Wenn die berechnete CSS-Eigenschaft identisch ist, gibt es keinen Diff.
Er erklaert, was sich geaendert hat. Statt einen Bereich auf einem Screenshot rot zu markieren, sagt Delta-QA: "Das padding-top dieses Elements ist von 16px auf 8px gewechselt" oder "Das font-weight dieses Titels ist von 700 auf 400 gewechselt". Sie wissen genau, was sich geaendert hat, an welchem Element und um welchen Wert.
Der 5-Pass-Algorithmus
Delta-QA begnuegt sich nicht mit einem naiven Diff zwischen zwei DOM-Baeumen. Sein struktureller 5-Pass-Algorithmus geht methodisch vor, um die Praezision der Ergebnisse zu gewaehrleisten.
Der erste Pass identifiziert korrespondierende Elemente zwischen den beiden Versionen der Seite anhand einer Kombination aus CSS-Selektoren, Position im Baum und Textinhalt. Der zweite Pass vergleicht die berechneten CSS-Eigenschaften jedes Elementpaars. Der dritte Pass erkennt hinzugefuegte und entfernte Elemente. Der vierte Pass analysiert raeumliche Beziehungen -- ein Element, das sich relativ zu seinen Nachbarn bewegt hat. Der fuenfte Pass aggregiert die Ergebnisse und eliminiert Rauschen -- Mikrovariationen im Rendering, die keine signifikanten Regressionen darstellen.
Das Ergebnis ist ein Bericht, der Ihnen die exakte Liste der Aenderungen gibt, nach Schweregrad sortiert, mit jeweils dem betroffenen Element, der geaenderten Eigenschaft, dem Wert vorher und dem Wert nachher.
Wann der DOM-Vergleich ausreicht
Seien wir ehrlich: Der DOM-Vergleich hat seinen Platz. Wenn Ihr Ziel ist zu ueberpruefen, dass sich die Struktur Ihrer Komponenten zwischen zwei Commits nicht geaendert hat -- und nur die Struktur -- leisten Jest Snapshot-Tests gute Arbeit. Sie sind schnell, kostenlos, in das JavaScript-Oekosystem integriert und erfordern keine zusaetzliche Infrastruktur.
Es ist ein leichtgewichtiges Sicherheitsnetz fuer Frontend-Entwickler, die alarmiert werden moechten, wenn sich ein Komponenten-Rendering aendert. Solange Sie sich bewusst sind, dass dieses Netz nur HTML abdeckt -- nicht CSS, nicht Layout, nicht das endgueltige Rendering -- ist es ein legitimes Werkzeug in Ihrem Werkzeugkasten.
Das Problem beginnt, wenn Sie DOM-Snapshot-Tests als Ersatz fuer visuelles Testing behandeln. Das sind sie nicht. Es ist ein Strukturtest, kein Erscheinungstest.
Wann der visuelle Vergleich ausreicht
Der visuelle Screenshot-Vergleich hat ebenfalls seinen Platz. Fuer sehr statische Seiten mit wenig dynamischem Inhalt funktioniert er gut. Fuer schnelle Ueberpruefungen vor einem Deployment -- "sieht die Homepage korrekt aus" -- ist ein mit einer Baseline verglichener Screenshot ein guter schneller Indikator.
Er ist auch nuetzlich, um browserspezifische Rendering-Regressionen zu erkennen. Ein WebKit-Bug, der das Rendering eines CSS-Gradienten beeinflusst, wird weder durch einen DOM- noch einen strukturellen Vergleich erkannt -- man muss das vom Browser gerenderte Bild sehen.
Aber wenn Sie an einer Anwendung mit dynamischem Inhalt, Animationen, interaktiven Zustaenden oder einfach regelmaessig sich aenderndem CSS arbeiten, werden die False Positives des Pixel-fuer-Pixel-Vergleichs schnell zu einem operativen Problem. Laut Erfahrungsberichten aus der Visual-Testing-Community verbringen Teams durchschnittlich zwischen 30 und 60 Minuten pro Tag mit dem Sortieren von False Positives bei Screenshot-Vergleichstools.
Warum der strukturelle Vergleich 2026 die richtige Antwort ist
Das Web hat sich weiterentwickelt. Moderne Anwendungen werden mit Design Systems, CSS-Variablen, Komponenten-Frameworks, komplexem Responsive Design und dynamischen Themes gebaut. CSS ist keine statische Datei mehr, die man einmal schreibt -- es ist ein System dynamischer Regeln, die miteinander interagieren.
In diesem Kontext ist es, das DOM zu vergleichen, ohne auf das CSS zu schauen, wie einen Gebaeudegrundriss zu pruefen, ohne zu schauen, ob die Waende am richtigen Platz stehen. Und Screenshots zu vergleichen, ohne die Struktur zu verstehen, ist wie das Foto eines Gebaeudes anzuschauen, ohne sagen zu koennen, ob sich das Dach oder das Fundament bewegt hat.
Der strukturelle Vergleich -- wie Delta-QA ihn praktiziert -- ist der einzige Ansatz, der sowohl Struktur als auch Rendering versteht. Er weiss, dass der Button existiert (DOM), er weiss, dass er blau ist (berechnetes CSS), er weiss, dass er 200px breit ist (berechnete Dimensionen), und er weiss, dass er 340px vom Seitenanfang positioniert ist (berechnete Position).
Wenn sich eine dieser Eigenschaften aendert, erkennt er es. Wenn sich keine aendert, erzeugt er keinen False Positive. So einfach ist das.
Und weil Delta-QA ohne Code und ohne Cloud funktioniert, muessen Sie kein Entwickler sein, um von dieser Praezision zu profitieren. Sie installieren die Anwendung, navigieren auf Ihrer Website, und das Tool erledigt den Rest. Lokal. Ohne Ihre Daten irgendwohin zu senden.
FAQ
Was ist der fundamentale Unterschied zwischen DOM-Vergleich und visuellem Vergleich?
Der DOM-Vergleich analysiert Aenderungen im HTML-Baum -- Tags, Attribute und Texte, die die Struktur einer Seite bilden. Der visuelle Vergleich vergleicht Screenshots Pixel fuer Pixel, um jede auf dem Bildschirm sichtbare Aenderung zu erkennen. Der erste uebersieht CSS-Aenderungen, der zweite uebersieht nicht sichtbare semantische Aenderungen.
Kann sich das DOM aendern, ohne dass sich das Visuelle aendert?
Ja, haeufig. Ein geaendertes data-*-Attribut, eine hinzugefuegte CSS-Klasse ohne zugehoerigen Style, ein hinzugefuegter HTML-Kommentar, eine DOM-Umstrukturierung, die dasselbe Rendering erzeugt -- all diese Faelle aendern das DOM, ohne das Erscheinungsbild der Seite zu aendern. Das ist eine Hauptquelle fuer False Positives bei DOM-Snapshot-Testing-Tools.
Kann sich das Visuelle aendern, ohne dass sich das DOM aendert?
Absolut. Das ist sogar der haeufigste Fall in modernen Anwendungen. Eine geaenderte CSS-Variable, eine geaenderte externe Font, ein CSS-Framework-Update, ein z-index-Bug durch eine geaenderte CSS-Regel -- all das aendert das Rendering, ohne das HTML zu beruehren. Der DOM-Vergleich ist strukturell unfaehig, diese Regressionen zu erkennen.
Was ist der strukturelle Vergleich und worin unterscheidet er sich von den anderen beiden?
Der strukturelle Vergleich liest jedes DOM-Element und ruft seine berechneten CSS-Eigenschaften ab -- die vom Browser tatsaechlich angewandten Styles. Er kombiniert so die strukturelle Sicht des DOM mit der effektiven Sicht des Renderings, ohne die Nachteile des Pixel-fuer-Pixel-Vergleichs (False Positives, fehlende Erklaerung). Das ist der von Delta-QA verwendete Ansatz.
Reichen Jest Snapshot-Tests aus, um visuelle Regressionen zu erkennen?
Nein. Jest Snapshot-Tests vergleichen den von Ihren Komponenten generierten HTML-Code, nicht deren Erscheinungsbild. Sie sind nuetzlich, um versehentliche Strukturaenderungen zu erkennen, aber sie sehen keine CSS-Aenderungen, Layout-Probleme, z-index-Konflikte oder typografische Regressionen. Es sind Struktur-Tests, keine visuellen Tests.
Wie vermeidet Delta-QA die gaengigen False Positives beim visuellen Vergleich?
Delta-QA vergleicht keine Pixel -- es vergleicht berechnete CSS-Eigenschaften. Ein blinkender Cursor, eine Animation in einem anderen Frame oder leichtes Font-Antialiasing erzeugen keinen Diff, weil sich die zugrundeliegenden CSS-Eigenschaften nicht geaendert haben. Nur echte Aenderungen von Style, Position oder Dimension werden gemeldet.
Muss man Entwickler sein, um den strukturellen Vergleich von Delta-QA zu nutzen?
Nein. Delta-QA ist ein No-Code-Tool. Sie installieren die Desktop-Anwendung, navigieren auf Ihrer Website wie gewohnt, und das Tool zeichnet auf und vergleicht automatisch. Kein SDK zu integrieren, kein Script zu schreiben, keine CI/CD-Pipeline zu konfigurieren. Alles geschieht ueber die grafische Oberflaeche.
DOM-Vergleich und visueller Vergleich sind keine schlechten Werkzeuge. Sie sind unvollstaendige Werkzeuge, wenn sie allein eingesetzt werden. Der strukturelle Vergleich uebertrifft sie, indem er kombiniert, was jeder am besten kann -- ohne die False Positives des einen oder die blinden Flecken des anderen.
Wenn Sie Ihre Oberflaeche mit DOM-Snapshots oder Screenshots testen, haben Sie bereits einen Schritt in die richtige Richtung gemacht. Aber wenn Sie eine vollstaendige Abdeckung wollen -- Struktur, Style und Layout -- ohne Rauschen, ohne Komplexitaet und ohne Ihre Daten in die Cloud zu senden, ist der strukturelle Vergleich der naechste logische Schritt.