DOM-Vergleich vs. visueller Vergleich: Gegenüberstellung zweier Methoden zur Erkennung von Interface-Änderungen -- die erste analysiert Änderungen im HTML-Baum (Document Object Model), die zweite vergleicht Screenshots Pixel für 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 möglich? Weil Ihre Tests prüfen, ob das DOM den richtigen Button mit dem richtigen Text und dem richtigen Link enthält -- aber niemand prüft, ob dieser Button tatsächlich auf dem Bildschirm sichtbar ist, an der richtigen Position, in der richtigen Größe.
Genau das ist das Problem bei der Wahl zwischen DOM-Vergleich und visuellem Vergleich. Diese beiden Ansätze werden oft als Alternativen dargestellt. In Wirklichkeit sind sie zwei komplementäre Facetten desselben Problems -- und nur einen davon zu nutzen bedeutet, einen blinden Fleck in Ihrer Teststrategie zu akzeptieren.
Dieser Artikel erläutert, was jeder Ansatz erkennt, was er übersieht, und warum der strukturelle Vergleich -- der das DOM liest UND die berechneten CSS-Eigenschaften prüft -- heute die umfassendste Antwort auf das Problem der visuellen Regression ist.
Was der DOM-Vergleich tatsächlich 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 hinzugefügt, entfernt oder geändert wurde, zeigt der Diff es an.
Das ist ein leistungsfähiger Ansatz zur Erkennung struktureller Änderungen. Ein versehentlich entfernter Absatz, ein geändertes href-Attribut, eine hinzugefügte 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 Ausführung 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 ändert die CSS-Datei und setzt diese Farbe auf #DC2626 (Rot). Das HTML hat sich nicht verändert. Das DOM ist identisch. Der Jest-Snapshot wird grün.
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-Änderungen. Jede Änderung 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 ändert sich. Und das Rendering ist das, was Ihre Nutzer sehen.
Font-Probleme. Eine Google Font, die nicht mehr lädt, ein System-Fallback, der aktiviert wird, ein Font-Weight, das sich ändert -- das DOM enthält immer noch denselben <p>-Tag mit demselben Text. Aber visuell ist der gesamte typografische Rhythmus Ihrer Seite zerbrochen.
z-index- und Überlappungsprobleme. Zwei Elemente, die sich wegen eines z-index-Konflikts überlappen, ein Modal, das unter dem Inhalt statt darüber erscheint, ein Tooltip, der aus seinem Container herausragt -- das DOM enthält 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 geändert hat.
Spacing- und Ausrichtungsprobleme. Ein Margin, der von 16px auf 0px wechselt, ein Padding, das verschwindet, ein Gap zwischen Elementen, der sich ändert -- nichts im DOM sichtbar, wenn diese Eigenschaften in CSS definiert sind.
Der DOM-Vergleich ist konzeptionell blind für alles, was außerhalb des HTML definiert ist. Und in einer modernen Webanwendung wird der Großteil des visuellen Renderings in CSS definiert -- nicht in HTML.
Was der visuelle Vergleich tatsächlich 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 für 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 ändert, 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-für-Pixel-Vergleich an seine eigenen Grenzen stößt.
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 ermöglicht, 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 Änderungen. Ein Link, dessen href von /checkout zu /cart wechselt, erzeugt keine visuelle Änderung -- Text und Stil des Links sind identisch. Aber der Nutzer, der klickt, landet nicht mehr am richtigen Ort. Der visuelle Vergleich sieht nichts.
Barrierefreiheits-Änderungen. Ein entferntes aria-label, eine geänderte role, ein fehlendes alt bei einem Bild -- nichts in einem Screenshot sichtbar. Aber für Screenreader-Nutzer ist Ihre Seite unbrauchbar geworden.
Dynamische Inhaltänderungen. Ein Preis, der von 29 EUR auf 290 EUR wechselt, ein Zähler, der eine falsche Zahl anzeigt, ein Nutzername, der nicht mehr lädt -- wenn das Layout identisch bleibt, wird der Pixel-für-Pixel-Vergleich es möglicherweise 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 Ausführungen -- all das erzeugt visuelle Diffs, die keine Regressionen sind. Laut einer Google-Studie zur Testverlässlichkeit (2016) machen instabile Tests -- sogenannte "Flaky Tests" -- 1,5 % aller Testausführungen bei Google aus, und Rendering-Variationen sind eine der Hauptursachen für Flakiness bei visuellen Tests.
Fehlende Erklärung. Wenn ein visueller Vergleich Ihnen einen Diff zeigt, sagt er "hier hat sich etwas geändert", indem er einen Bereich hervorhebt. Aber er sagt Ihnen nicht, was. Ist es die Farbe? Die Größe? Die Position? Der Inhalt? Sie müssen selbst ermitteln. Auf einer komplexen Seite mit Dutzenden von Änderungen wird das Triage zur Vollzeitbeschäftigung.
Das eigentliche Problem: Zwei Methoden, zwei symmetrische blinde Flecken
Wenn Sie bis hierhin gefolgt sind, sehen Sie das Paradoxon.
Der DOM-Vergleich erkennt HTML-Änderungen, aber übersieht visuelle Änderungen. Der visuelle Vergleich erkennt visuelle Änderungen, aber übersieht semantische Änderungen. Beide Ansätze sind genau dort blind, wo der andere stark ist.
Dieses Paradoxon ist kein Zufall. Es spiegelt die fundamentale Dualität 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 lösen, indem sie beide Tools kombinieren: Jest für DOM-Snapshots und Percy oder BackstopJS für Screenshots. Das ist besser als nichts, aber es bedeutet auch zwei Pipelines zu pflegen, zwei Baseline-Sätze zu verwalten, zwei False-Positive-Quellen zu sortieren und keine Korrelation zwischen den Ergebnissen. Wenn Jest sagt "das DOM hat sich geändert" und Percy sagt "das Visuelle hat sich geändert", sagt Ihnen niemand, ob diese beiden Änderungen zusammenhängen.
Der strukturelle Vergleich: DOM lesen UND berechnetes CSS prüfen
Es gibt einen dritten Ansatz, der sich weder mit dem DOM allein noch mit Pixeln allein begnügt. Das ist der strukturelle Vergleich -- und das ist der Ansatz, den Delta-QA gewählt 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 tatsächlich angewendet hat, nach Auflösung aller Kaskaden, Vererbungen, Media Queries und CSS-Variablen.
Konkret kennt Delta-QA für jedes Element Ihrer Seite seine exakte Position, seine tatsächlichen Dimensionen, seine effektive Farbe, seine angewandte Typografie, seine aufgelösten Margins und Paddings, seinen berechneten z-index, seine Opazität, seine Sichtbarkeit. Nicht die im CSS-Quellcode deklarierten Styles -- die Styles, wie der Browser sie berechnet und angewendet hat.
Dieser Ansatz löst beide blinden Flecken gleichzeitig.
Er erkennt CSS-Änderungen. Wenn sich eine CSS-Variable ändert 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-Änderungen. Wenn ein Element im HTML-Baum hinzugefügt, entfernt oder verschoben wird, sieht Delta-QA es -- weil er das DOM Element für Element durchläuft.
Er erzeugt keine renderingbedingten False Positives. Kein Pixel-für-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 erklärt, was sich geändert 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 geändert hat, an welchem Element und um welchen Wert.
Der 5-Pass-Algorithmus
Delta-QA begnügt sich nicht mit einem naiven Diff zwischen zwei DOM-Bäumen. Sein struktureller 5-Pass-Algorithmus geht methodisch vor, um die Präzision der Ergebnisse zu gewährleisten.
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 hinzugefügte und entfernte Elemente. Der vierte Pass analysiert räumliche Beziehungen -- ein Element, das sich relativ zu seinen Nachbarn bewegt hat. Der fünfte 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 Änderungen gibt, nach Schweregrad sortiert, mit jeweils dem betroffenen Element, der geänderten 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 überprüfen, dass sich die Struktur Ihrer Komponenten zwischen zwei Commits nicht geändert hat -- und nur die Struktur -- leisten Jest Snapshot-Tests gute Arbeit. Sie sind schnell, kostenlos, in das JavaScript-Ökosystem integriert und erfordern keine zusätzliche Infrastruktur.
Es ist ein leichtgewichtiges Sicherheitsnetz für Frontend-Entwickler, die alarmiert werden möchten, wenn sich ein Komponenten-Rendering ändert. Solange Sie sich bewusst sind, dass dieses Netz nur HTML abdeckt -- nicht CSS, nicht Layout, nicht das endgültige Rendering -- ist es ein legitimes Werkzeug in Ihrem Werkzeugkasten.
Das Problem beginnt, wenn Sie DOM-Snapshot-Tests als Ersatz für 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. Für sehr statische Seiten mit wenig dynamischem Inhalt funktioniert er gut. Für schnelle Überprüfungen vor einem Deployment -- "sieht die Homepage korrekt aus" -- ist ein mit einer Baseline verglichener Screenshot ein guter schneller Indikator.
Er ist auch nützlich, 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 Zuständen oder einfach regelmäßig sich änderndem CSS arbeiten, werden die False Positives des Pixel-für-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 Gebäudegrundriss zu prüfen, ohne zu schauen, ob die Wände am richtigen Platz stehen. Und Screenshots zu vergleichen, ohne die Struktur zu verstehen, ist wie das Foto eines Gebäudes anzuschauen, ohne sagen zu können, 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 weiß, dass der Button existiert (DOM), er weiß, dass er blau ist (berechnetes CSS), er weiß, dass er 200px breit ist (berechnete Dimensionen), und er weiß, dass er 340px vom Seitenanfang positioniert ist (berechnete Position).
Wenn sich eine dieser Eigenschaften ändert, erkennt er es. Wenn sich keine ändert, erzeugt er keinen False Positive. So einfach ist das.
Und weil Delta-QA ohne Code und ohne Cloud funktioniert, müssen Sie kein Entwickler sein, um von dieser Präzision 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 Änderungen im HTML-Baum -- Tags, Attribute und Texte, die die Struktur einer Seite bilden. Der visuelle Vergleich vergleicht Screenshots Pixel für Pixel, um jede auf dem Bildschirm sichtbare Änderung zu erkennen. Der erste übersieht CSS-Änderungen, der zweite übersieht nicht sichtbare semantische Änderungen.
Kann sich das DOM ändern, ohne dass sich das Visuelle ändert?
Ja, häufig. Ein geändertes data-*-Attribut, eine hinzugefügte CSS-Klasse ohne zugehörigen Style, ein hinzugefügter HTML-Kommentar, eine DOM-Umstrukturierung, die dasselbe Rendering erzeugt -- all diese Fälle ändern das DOM, ohne das Erscheinungsbild der Seite zu ändern. Das ist eine Hauptquelle für False Positives bei DOM-Snapshot-Testing-Tools.
Kann sich das Visuelle ändern, ohne dass sich das DOM ändert?
Absolut. Das ist sogar der häufigste Fall in modernen Anwendungen. Eine geänderte CSS-Variable, eine geänderte externe Font, ein CSS-Framework-Update, ein z-index-Bug durch eine geänderte CSS-Regel -- all das ändert das Rendering, ohne das HTML zu berühren. Der DOM-Vergleich ist strukturell unfähig, 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 tatsächlich angewandten Styles. Er kombiniert so die strukturelle Sicht des DOM mit der effektiven Sicht des Renderings, ohne die Nachteile des Pixel-für-Pixel-Vergleichs (False Positives, fehlende Erklärung). 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 nützlich, um versehentliche Strukturänderungen zu erkennen, aber sie sehen keine CSS-Änderungen, Layout-Probleme, z-index-Konflikte oder typografische Regressionen. Es sind Struktur-Tests, keine visuellen Tests.
Wie vermeidet Delta-QA die gängigen 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 geändert haben. Nur echte Änderungen 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 über die grafische Oberfläche.
Weiterführende Lektüre
- Visuelle Technische Schulden: Definition, Auswirkungen und Strategien zur Tilgung
- DevOps und Visuelles Testing: Shift-Left der visuellen Qualität in Ihrer Pipeline
DOM-Vergleich und visueller Vergleich sind keine schlechten Werkzeuge. Sie sind unvollständige Werkzeuge, wenn sie allein eingesetzt werden. Der strukturelle Vergleich übertrifft sie, indem er kombiniert, was jeder am besten kann -- ohne die False Positives des einen oder die blinden Flecken des anderen.
Wenn Sie Ihre Oberfläche mit DOM-Snapshots oder Screenshots testen, haben Sie bereits einen Schritt in die richtige Richtung gemacht. Aber wenn Sie eine vollständige Abdeckung wollen -- Struktur, Style und Layout -- ohne Rauschen, ohne Komplexität und ohne Ihre Daten in die Cloud zu senden, ist der strukturelle Vergleich der nächste logische Schritt.