{"id":21081,"date":"2018-03-14T09:13:50","date_gmt":"2018-03-14T08:13:50","guid":{"rendered":"http:\/\/www.inovex.de\/blog\/?p=12748"},"modified":"2022-11-29T09:12:18","modified_gmt":"2022-11-29T08:12:18","slug":"visuelle-regressionstests-im-web","status":"publish","type":"post","link":"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/","title":{"rendered":"Visuelle Regressionstests im Web: Eine praktikable Alternative zu DOM-basierten E2E-Tests?"},"content":{"rendered":"<p>Visuelle Regressionstests (Visual-Regression-Testing, VRT) sollen es dem\/der Software-Entwickler:in erleichtern, im Web-Frontend-Bereich sichere Aussagen zur Qualit\u00e4t der entwickelten Anwendungen zu geben. Dabei werden Screenshots von Benutzeroberfl\u00e4chen gemacht und diese mit einem vorhandenen Referenzsatz verglichen. Auf diese Weise k\u00f6nnen CSS- und Template-Regressionen erkannt werden, die mit DOM-basierten E2E-Tests nicht zu erkennen sind. Dazu z\u00e4hlen beispielsweise ungewollte \u00dcberschreibungen von CSS-Klassen oder Grafiken, die versehentlich nicht mehr sichtbar sind. Damit schlie\u00dft dieses Testverfahren eine L\u00fccke in der Reihe automatisierter Software-Tests. M\u00fchselige manuelle Testaufw\u00e4nde werden so reduziert und Probleme DOM-basierter E2E-Tests \u00fcberwunden. Was visuelle Regressionstests in der Praxis leisten k\u00f6nnen und ob diese tats\u00e4chlich DOM-basierte E2E-Tests ersetzen k\u00f6nnen, versuche ich in diesem Beitrag zu kl\u00e4ren.<!--more--><\/p>\n<p>Im Rahmen meiner Bachelor-Thesis &#8222;Visuelle Regressionstests f\u00fcr Web-Frontends&#8220; wurde die Tauglichkeit dieser Testform untersucht. Dazu habe ich vorhandene Tools evaluiert und die vielversprechendsten L\u00f6sungen miteinander verglichen. Doe Arbeit bildet die Grundlage f\u00fcr diesen Artikel.<\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_82_2 counter-hierarchy ez-toc-counter ez-toc-custom ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\"><p class=\"ez-toc-title\" style=\"cursor:inherit\"><\/p>\n<\/div><nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#Visuelle-Regressionstests\" >Visuelle Regressionstests<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#Workflow\" >Workflow<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#Einordnung-und-Kritik\" >Einordnung und Kritik<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#Evaluation-vorhandener-VRT-Tools\" >Evaluation vorhandener VRT-Tools<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#Anforderungen\" >Anforderungen<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#False-Positives\" >False-Positives<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#Tool-Auswahl\" >Tool-Auswahl<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#Implementierung-der-Tests\" >Implementierung der Tests<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#DOM-basierte-vs-visuelle-Regressionstests\" >DOM-basierte vs. visuelle Regressionstests<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#Problematik-der-False-Positives\" >Problematik der False-Positives<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#Lessons-learned\" >Lessons learned<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-12\" href=\"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#Was-soll-getestet-werden\" >Was soll getestet werden?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-13\" href=\"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#Wie-soll-getestet-werden\" >Wie soll getestet werden?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-14\" href=\"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#Wann-soll-getestet-werden\" >Wann soll getestet werden?<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-15\" href=\"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#Ausblick\" >Ausblick<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-16\" href=\"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#Fazit\" >Fazit<\/a><\/li><\/ul><\/nav><\/div>\n<h2><span class=\"ez-toc-section\" id=\"Visuelle-Regressionstests\"><\/span>Visuelle Regressionstests<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Wie eingangs bereits beschrieben, geht es bei den visuellen Regressionstests (VRT) um die Erkennung von CSS- und Template-Regressionen. Durch automatisierte Pixel-f\u00fcr-Pixel-Vergleiche soll Frontend-Entwickler:innen erm\u00f6glicht werden, \u00c4nderungen im Layout einer Web-Applikation visuell nachzuvollziehen und ungewollte \u00c4nderungen besser erkennen zu k\u00f6nnen.<\/p>\n<p>Neben den \u00fcblichen Teststrategien wie Unit-, Integration- und End-to-End-Testing werden Web-Anwendungen meist manuell getestet. D.h., Entwickler:innen oder Tester:innen klicken eine Anwendung h\u00e4ndisch durch und simulieren damit Use-Cases der Endanwendung. Diese Methode ist zeitintensiv und nur schwer skalierbar. Je gr\u00f6\u00dfer die Anwendung, desto mehr Zeit und damit Geld muss in das manuelle Testen investiert werden. Dies ist fehleranf\u00e4llig und wenig effizient. Menschen k\u00f6nnen marginale Ver\u00e4nderungen einfach \u00fcbersehen, was einer Maschine nicht passieren kann. Dieses Ph\u00e4nomen nennt sich <a href=\"https:\/\/en.wikipedia.org\/wiki\/Change_blindness\" target=\"_blank\" rel=\"noopener\">Change-Blindness<\/a>. In der folgenden Abbildung unserer zu testenden Anwendung (dabei wird auf die <a href=\"http:\/\/todomvc.com\" target=\"_blank\" rel=\"noopener\">TodoMVC-App<\/a> zur\u00fcckgegriffen) fehlt im neu aufgenommenen Screenshot (Mitte) beispielsweise das Input-Element zum Abhaken des To-Do-Eintrags. Diese marginalen Ver\u00e4nderungen sind vom menschlichen Auge nur schwer zu erfassen.<\/p>\n<figure id=\"attachment_12752\" aria-describedby=\"caption-attachment-12752\" style=\"width: 1024px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/vrt-bsp-intro-change_blindness.png\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-12752 size-large\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/vrt-bsp-intro-change_blindness-1024x588.png\" alt=\"Abbildung: Change-Blindness\" width=\"1024\" height=\"588\" \/><\/a><figcaption id=\"caption-attachment-12752\" class=\"wp-caption-text\">Abbildung: Change-Blindness<\/figcaption><\/figure>\n<p>F\u00fcr das VRT muss es m\u00f6glich sein, Screenshots einer Web-Anwendung automatisiert zu erstellen und diese dann mit einem Referenzsatz vorhandener Screenshots zu vergleichen, um Regressionen zu detektieren.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Workflow\"><\/span>Workflow<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Der Ablauf oder Workflow von visuellen Regressionstests ist unterteilt in vier Stufen, wobei die Stufen drei und vier optional und davon abh\u00e4ngig sind, ob es Unterschiede in den Screenshots gibt. Die zu testende Anwendung wird hier als &#8222;AUT&#8220; (Application-Under-Test) bezeichnet:<\/p>\n<figure id=\"attachment_12755\" aria-describedby=\"caption-attachment-12755\" style=\"width: 1024px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/vrt-workflow.png\" rel=\"attachment wp-att-12755\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-12755 size-large\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/vrt-workflow-1024x480.png\" alt=\"Abbildung: Workflow\" width=\"1024\" height=\"480\" \/><\/a><figcaption id=\"caption-attachment-12755\" class=\"wp-caption-text\">Abbildung: Workflow<\/figcaption><\/figure>\n<ol>\n<li>Im ersten Schritt wird die AUT in einer kontrollierten Teststellung ausgef\u00fchrt. Dazu werden entweder reale Daten benutzt oder es wird auf Testdaten zur\u00fcckgegriffen. Dann werden die in den Tests beschriebenen Teile der Anwendung aufgenommen und gespeichert. Das bedeutet, es werden verschiedene Status von verschiedenen Seiten der AUT in Form von Screenshots festgehalten.<\/li>\n<li>Anschlie\u00dfend werden im Schritt zwei die aufgenommenen Screenshots mit einem bereits existierenden Satz an Referenz-Screenshots verglichen. Diese Referenz-Screenshots werden als Baseline bezeichnet. Sie werden vor dem ersten Test aufgenommen und manuell auf ihre Korrektheit \u00fcberpr\u00fcft. Nach dieser initialen Pr\u00fcfung ist ein automatisierter, maschineller Abgleich der im Test aufgenommenen Bilder mit der Baseline m\u00f6glich.Die Pr\u00fcfung der Screenshots geschieht in den meisten F\u00e4llen ohne weitere Logik \u2013 Pixel f\u00fcr Pixel. Das bedeutet, es werden die zueinandergeh\u00f6rigen Bilddaten \u00fcbereinander gelegt und dann Reihe f\u00fcr Reihe, Pixel f\u00fcr Pixel die RGB-Farbdaten miteinander verglichen.\n<p><figure id=\"attachment_12757\" aria-describedby=\"caption-attachment-12757\" style=\"width: 1024px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/vrt-rgb-pixel.png\" rel=\"attachment wp-att-12757\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-12757 size-large\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/vrt-rgb-pixel-1024x552.png\" alt=\"Abbildung: Pixel Zusammensetzung eines RGB-Bildes\" width=\"1024\" height=\"552\" \/><\/a><figcaption id=\"caption-attachment-12757\" class=\"wp-caption-text\">Abbildung: Pixel-Zusammensetzung eines RGB-Bildes<\/figcaption><\/figure><\/li>\n<li>Der dritte Schritt beinhaltet das Aufzeichnen und Melden von gefundenen Unterschieden in den verglichenen Screenshots. Dabei wird eine Kopie der jeweiligen Baseline gemacht und die sich unterscheidenden Pixel Rot (oder in einer anderen auff\u00e4lligen Farbe) in dem neu erzeugten Bild markiert. Zus\u00e4tzlich zu dem neu angelegten Differenzbild k\u00f6nnen auch Metadaten wie beispielsweise die Anzahl der unterschiedlichen Pixel f\u00fcr eine weitere Nutzung gespeichert werden.<\/li>\n<li>Im letzten Schritt geht es darum, die im Vergleich als &#8222;fehlgeschlagen&#8220; markierten Screenshots manuell zu pr\u00fcfen. An dieser Stelle kann festgestellt werden, ob die Ver\u00e4nderungen in der AUT beabsichtigt waren oder nicht. Waren die \u00c4nderungen gewollt, zum Beispiel weil ein neues Feature implementiert wurde, wird der neu aufgenommene Screenshot als neue Baseline \u00fcbernommen. Die Baseline l\u00e4sst sich dabei bequem per Git versionieren. Waren die \u00c4nderungen nicht gewollt, konnte der Test erfolgreich einen Fehler erkennen und dieser kann nun behoben werden.<\/li>\n<\/ol>\n<h2><span class=\"ez-toc-section\" id=\"Einordnung-und-Kritik\"><\/span>Einordnung und Kritik<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Visuelle Regressionstests geh\u00f6ren zu den E2E-Tests. Da wir uns hier lediglich auf die Verwendung im Web-Frontend-Bereich beschr\u00e4nken, werden UI-Tests in diesem Artikel synonym mit E2E-Tests verstanden. UI-Tests z\u00e4hlen in der Qualit\u00e4tssicherung zu den Black-Box-Ans\u00e4tzen. Black-Box-Testtechniken nehmen das zu testende System als Ganzes wahr. Sie haben keinerlei Kenntnis \u00fcber Details des zugrundeliegenden Quellcodes. Die einzigen beiden Faktoren, die hierbei beeinflusst bzw. abgeglichen werden k\u00f6nnen, sind Ein- und Ausgabewerte der Software. Black-Box-Tests entsprechen damit weitestgehend der Sicht, die der Endnutzer auf das Software-Produkt hat. Damit eignen sich besonders User-Stories zur Identifizierung geeigneter Testszenarien.<\/p>\n<p>Anders als bei den Unit- und Integrations-Tests werden bei den UI-Tests durch den Black-Box-Ansatz jedoch einige Probleme offenkundig. Dazu ist es sinnvoll, sich die Test-Automation-Pyramide nach Mike Cohn genauer anzuschauen.<\/p>\n<figure id=\"attachment_12758\" aria-describedby=\"caption-attachment-12758\" style=\"width: 1024px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/vrt-pyramide-cohn.png\" rel=\"attachment wp-att-12758\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-12758 size-large\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/vrt-pyramide-cohn-1024x384.png\" alt=\"Abbildung: Test\u2013Automation\u2013Pyramide nach Mike Cohn\" width=\"1024\" height=\"384\" \/><\/a><figcaption id=\"caption-attachment-12758\" class=\"wp-caption-text\">Abbildung: Test\u2013Automation\u2013Pyramide nach Mike Cohn<\/figcaption><\/figure>\n<p>Mike Cohn beschrieb 2010 in seinem Buch &#8222;Succeeding with Agile&#8220; eine dreistufige Pyramide f\u00fcr eine effektive und effiziente Automation von Software-Tests. Die unterste Stufe, und damit die Basis der Pyramide, bilden die Unit-Tests. Sie repr\u00e4sentieren den gr\u00f6\u00dften Anteil an Tests, der nach Cohn auch der komfortabelste ist. Sie haben extrem kurze Laufzeiten und liefern \u00e4u\u00dferst granulare Fehlermeldungen zum Ursprung des Problems. Die mittlere Stufe repr\u00e4sentiert die Service- oder Integration-Tests, also jene Testf\u00e4lle, die mehrere Module &#8222;unterhalb&#8220; des User-Interfaces integriert testen. Die oberste, dritte Stufe der Pyramide bilden die UI-Tests, von denen, nach Cohn, so viele wie n\u00f6tig und dabei so wenig wie m\u00f6glich geschrieben werden sollten. Dabei bem\u00e4ngelt er, dass diese instabil, teuer und zeitaufw\u00e4ndig seien. Zudem entst\u00fcnden dadurch Redundanzen. Da f\u00fcr UI-Tests immer die vollst\u00e4ndige Code-Basis aufgerufen wird, werden auch immer Funktionalit\u00e4ten getestet, die durch Tests der darunterliegenden Stufen einfacher und schneller zu testen sind.<\/p>\n<p>Die von Cohn erw\u00e4hnte Instabilit\u00e4t der UI-Tests gr\u00fcndet auf dem Problem, den Status der AUT zu kontrollieren. Wurde zur Zeit der Testausf\u00fchrung beispielsweise das CSS, Bilder oder DOM-Elemente noch nicht vollst\u00e4ndig geladen, schlagen die Tests fehl, obwohl die Anwendung korrekt funktioniert. Diese und \u00e4hnliche Fehler werden False-Negatives genannt. In der Praxis wird jedoch deutlich h\u00e4ufiger der Begriff &#8222;False-Positives&#8220; synonym daf\u00fcr verwendet. Je nach Interpretation, ist beides korrekt. In diesem Artikel wird dazu False-Positives gesagt. Bei &#8222;klassischen&#8220; oder auch &#8222;DOM-basierten&#8220; E2E-Tests werden False-Positives meist durch fehlende DOM-Elemente verursacht. Im Prinzip unterscheiden sich diese Tests in der Ausf\u00fchrung nicht von visuellen Regressionstests. F\u00fcr diese wird ebenfalls die komplette Anwendung f\u00fcr ihre Ausf\u00fchrung geladen. Daraufhin wird dann auf die Existenz bzw. die Abwesenheit von DOM-Elementen bzw. auf deren Inhalt im Browser getestet. False-Positives beim VRT werden zus\u00e4tzlich durch Unterschiede im Rendering der Inhalte im Browser induziert. Weiter unten wird darauf noch einmal detaillierter eingegangen.<\/p>\n<p>Der h\u00f6here Zeitaufwand bei UI-Tests ist nicht nur durch eine l\u00e4ngere Ausf\u00fchrungsdauer bedingt, sondern auch durch weniger nachvollziehbare Fehlerquellen. Im Gegensatz zu Unit-Tests k\u00f6nnen UI-Tests meist nicht auf eine bestimmte Stelle im Code verweisen, um deren Ursache zu beheben. Durch den Black-Box-Ansatz wird lediglich das finale Ergebnis im Browser betrachtet. Dieses wiederum ist jedoch meist Ergebnis eines Zusammenspiels von Templates, Controllern und Services.<\/p>\n<p>Je l\u00e4nger die Ausf\u00fchrung der Tests dauert, je schwerer diese zu warten sind und je instabiler sie laufen, desto geringer ist die Wahrscheinlichkeit, dass Entwickler UI-Tests wiederholt ausf\u00fchren. Dies wiederum f\u00fchrt tendenziell zu einer h\u00f6heren Fehlerrate in der Entwicklung und damit zu einer l\u00e4ngeren Entwicklungszeit.<\/p>\n<p>Aus den aufgef\u00fchrten Gr\u00fcnden ist der produktive Einsatzzweck von visuellen Regressionstests etwas umstritten. Es gibt einige Vertreter der Meinung (z. B. Pete Hunt, Autor des VRT-Tools <a href=\"https:\/\/github.com\/facebookarchive\/huxley\" target=\"_blank\" rel=\"noopener\">Huxley<\/a> f\u00fcr die Instagram-Web-Anwendung; die Weiterentwicklung des Werkzeugs wurde mittlerweile eingestellt), dass mit den vorhandenen L\u00f6sungen Tests dieser Art lediglich als Code Review Tool taugen, nicht aber als vollwertiges Testwerkzeug. D.h., sie sehen deren Einsatz nicht integriert in eine automatisierte Teststellung, sondern eher als lokales Werkzeug zum visuellen Abgleich der vorgenommenen \u00c4nderungen.<\/p>\n<p>Um visuelle Regressionstests als ernstzunehmende Testmethode etablieren zu k\u00f6nnen, muss es folglich das Ziel sein herauszufinden, welche Szenarien sinnvollerweise zu pr\u00fcfen sind, gleichzeitig die Stabilit\u00e4t der Tests zu gew\u00e4hrleisten und deren False-Positive-Rate m\u00f6glichst gering zu halten.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Evaluation-vorhandener-VRT-Tools\"><\/span>Evaluation vorhandener VRT-Tools<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Insgesamt wurden im Rahmen meiner Thesis etwas mehr als 30 Testing-Tools untersucht. Dabei wurden sowohl Open-Source- als auch kommerzielle L\u00f6sungen betrachtet. \u00dcber mehrere Filterstufen hinweg wurden Tools aussortiert, die entweder nicht mehr aktiv gepflegt werden oder nicht den Anforderungen (siehe n\u00e4chster Abschnitt) entsprechen. Am Ende sollten dann drei VRT-Tools \u00fcbrig bleiben, welche im Rahmen eines Implementierungsteils benutzt wurden, um Tests f\u00fcr eine reale AngularJS-Anwendung zu schreiben. In diesem Blog-Artikel werden die Tests anhand der oben gezeigten TodoMVC-App implementiert.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Anforderungen\"><\/span>Anforderungen<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Die folgenden Anforderungen an die Testing-Tools wurden im Rahmen der Abschlussarbeit erarbeitet:<\/p>\n\n<table id=\"tablepress-7\" class=\"tablepress tablepress-id-7\">\n<thead>\n<tr class=\"row-1\">\n\t<th class=\"column-1\">Funktionale Anforderungen<\/th><th class=\"column-2\">Nicht-funktionale Anforderungen<\/th>\n<\/tr>\n<\/thead>\n<tbody class=\"row-striping row-hover\">\n<tr class=\"row-2\">\n\t<td class=\"column-1\"><ol><li><strong>Basisfunktionen<\/strong><\/li><li>Erweiterte Funktionen<br><ul><li><strong>Interaktion mit der AUT<\/strong><\/li><li>Komponentenauswahl<\/li><li><strong>Erkennung von False-Positives<\/strong><\/li><li><strong>Automation<\/strong><\/li><\/ul><\/li><\/td><td class=\"column-2\"><ol><li>Portabilit\u00e4t<\/li><li>Usability<\/li><li>Performance<\/li><li><strong>Robustheit<\/strong><\/li><li>Dokumentation<\/li><\/ol><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<!-- #tablepress-7 from cache -->\n<p>Unter den Basisfunktionen bei den funktionalen Anforderungen sind dabei die vier Schritte des zuvor beschriebenen Workflows zu verstehen. Viele Tools decken dabei nur einen Teil dieser Basisfunktionen ab. <a href=\"https:\/\/github.com\/wearefriday\/spectre\" target=\"_blank\" rel=\"noopener\">Spectre<\/a> ist beispielsweise lediglich eine Web-Anwendung f\u00fcr den Bildvergleich. Das bedeutet, es gibt eine Schnittstelle, \u00fcber welche Bilddaten an die Anwendung gereicht werden k\u00f6nnen, die dort miteinander verglichen und dann ausgewertet werden. Deshalb ist es hier sinnvoll die St\u00e4rken der einzelnen Werkzeuge zu verkn\u00fcpfen.<\/p>\n<p>Die erweiterten Funktionen zielen auf einen sinnvollen produktiven Einsatz ab. Dazu sollte mit der Anwendung interagiert werden k\u00f6nnen, um diese in den gew\u00fcnschten, zu testenden Status zu versetzen (z. B. korrekt ausgef\u00fclltes Formular in einem Bestellprozess). Weiter soll es m\u00f6glich sein, beispielsweise per CSS-Selektor, gezielt nur Teile der Anwendung als Screenshot zu speichern. Der ansonsten g\u00e4ngige Ansatz ist es, die vollst\u00e4ndige Seite, entweder nur den im Browserfenster sichtbaren Bereich oder die komplette scrollbare H\u00f6he, aufzunehmen. Die wichtigsten Punkte bei den erweiterten funktionalen Anforderungen sind die letzten beiden. Die Erkennung von False-Positives soll die Stabilit\u00e4t der Tests gew\u00e4hrleisten und die Automatisierung die Integration in eine bereits vorhandene Teststellung.<\/p>\n<p>Bei den nicht-funktionalen Anforderungen ist ein besonderer Fokus auf die Robustheit zu legen. Dieser ist eng verkn\u00fcpft mit der Erkennung von False-Positives und soll die Akzeptanz bei Entwickler:innen verbessern.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"False-Positives\"><\/span>False-Positives<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>False-Positive-Ergebnisse, oder kurz False-Positives, k\u00f6nnen viele Ursachen haben. Neben gewollten \u00c4nderungen (Features), die zu erwartenden Fehlern im Vergleich der Screenshots f\u00fchren, gibt es Fehlerursachen, welche ungewollt, f\u00fcr das menschliche Auge nicht oder nur kaum zu erkennen und technischer Natur sind. Dazu z\u00e4hlen beispielsweise Anti-Aliasing und Image-Scaling. Des weiteren f\u00fchren dynamische Inhalte, Verschiebungen von Inhalten und Verz\u00f6gerungen beim Laden einzelner Komponenten der AUT zu fehlerhaften Testergebnissen. Diese False-Positives gilt es zu erkennen und zu vermeiden.<\/p>\n<p>Es gibt unterschiedliche Ans\u00e4tze False-Positives zu verhindern. Wie das Tool <a href=\"https:\/\/github.com\/gemini-testing\/looks-same\" target=\"_blank\" rel=\"noopener\">LooksSame<\/a> von Yandex orientieren sich viele an der menschlichen Wahrnehmung der Inhalte. Das bedeutet, Farbabweichungen, die f\u00fcr einen Menschen kaum sichtbar sind, werden nach dem Modell <a href=\"https:\/\/en.wikipedia.org\/wiki\/Color_difference#CIEDE2000\" target=\"_blank\" rel=\"noopener\">CIE-DE2000<\/a> herausgerechnet. Auch die Unterschiede in den Pixel-Rasterungen von Kanten (Anti-Aliasing) wird von den meisten Tools gut erkannt und verursacht somit keine False-Positives. Problematisch wird es allerdings, wenn sich beispielsweise der Inhalt um nur einen Pixel nach unten verschiebt. Damit wird, obwohl sich inhaltlich nichts ver\u00e4ndert hat und diese Verschiebung durch das menschliche Auge nicht wahrnehmbar ist, die gesamten verschobenen Pixel als &#8222;Fehler-Pixel&#8220; markiert. Um diese Art der False-Positives in den Griff zu bekommen, bieten einige Testing-Tools die M\u00f6glichkeit, eine Mismatch-Toleranz anzugeben. Diese Mismatch-Toleranz misst den Prozentsatz an Pixel, der sich unterscheiden darf, bevor der neu aufgenommene Screenshot als &#8222;unterschiedlich&#8220; zur Baseline markiert wird. Dies birgt jedoch ein Problem: Je h\u00f6her nat\u00fcrlich die Aufl\u00f6sung des Screenshots, desto mehr Pixel d\u00fcrfen sich unterscheiden, ohne dass &#8222;Alarm&#8220; geschlagen wird. Damit ist die Mismatch-Toleranz mit Vorsicht zu genie\u00dfen. Ein intelligenterer Ansatz w\u00e4re es, Inhalte zu detektieren (z. B. via OCR oder Layout-Elemente als Objekte klassifizieren) und dann festzustellen, ob sich inhaltlich oder strukturell was am Status der AUT ver\u00e4ndert hat. Dies erfordert einen deutlich h\u00f6heren Aufwand in der Bildverarbeitung und wird aktuell nur von dem kommerziellen Dienst <a href=\"https:\/\/applitools.com\/\" target=\"_blank\" rel=\"noopener\">Applitools Eyes<\/a> angewendet.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Tool-Auswahl\"><\/span>Tool-Auswahl<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>F\u00fcr die Auswahl der richtigen Testwerkzeuge wurde, neben den oben aufgef\u00fchrten Anforderungen, speziell auf zwei Faktoren viel Wert gelegt. Zum einen sollte der Technologie-Stack f\u00fcr Frontend-Entwickler:innen nicht unn\u00f6tig erweitert werden und zum anderen sollten die Tests in realen Browsern (nicht nur in Headless-Browsern wie beispielsweise <a href=\"http:\/\/phantomjs.org\/\" target=\"_blank\" rel=\"noopener\">PhantomJS<\/a>) ausf\u00fchrbar sein. Ersteres bevorzugt eine JavaScript API und letzteres eine Selenium-Basis der Werkzeuge. Die Selenium-Basis erm\u00f6glicht das Testen der Eigenheiten der einzelnen Browser. Sofern man keine eigene Infrastruktur mit Test-Ger\u00e4ten hat, kann hier auf Dienste wie <a href=\"https:\/\/www.browserstack.com\/\" target=\"_blank\" rel=\"noopener\">BrowserStack<\/a> oder <a href=\"https:\/\/saucelabs.com\/\" target=\"_blank\" rel=\"noopener\">Sauce Labs<\/a> zur\u00fcckgegriffen werden.<\/p>\n<p>Das Team von Yandex hat mit seinem Tool <a href=\"https:\/\/github.com\/gemini-testing\/gemini\" target=\"_blank\" rel=\"noopener\">Gemini<\/a> eine solide L\u00f6sung f\u00fcr das Problem der visuellen Regressionen entwickelt. Mit einer guten Community und Performance war dieses ein Teil der Auswahl im Rahmen der Thesis. In der originalen Auswahl war auch das Tool <a href=\"https:\/\/github.com\/webdriverio\/webdrivercss\" target=\"_blank\" rel=\"noopener\">WebdriverCSS<\/a> im Zusammenspiel mit WebdriverIO f\u00fcr die Browser-Automatisierung und Applitools Eyes f\u00fcr den Bildvergleich. WebdriverCSS wird jedoch nicht mehr aktiv weiterentwickelt. Stattdessen wird das von Applitools entwickelte SDK <a href=\"https:\/\/github.com\/applitools\/eyes.webdriverio.javascript\" target=\"_blank\" rel=\"noopener\">eyes.webdriverio.javascript<\/a> f\u00fcr WebdriverIO verwendet. Applitools Eyes ist das einzige kommerzielle Tool in der Auswahl und bietet \u00fcber seine Web-Anwendung die M\u00f6glichkeit, die Ergebnisse der Bildvergleiche zu inspizieren. Mit Applitools Eyes soll vor allem gezeigt werden, wo die Vorteile einer intelligenten Bildverarbeitung im Bildvergleich liegt.<\/p>\n<figure id=\"attachment_12766\" aria-describedby=\"caption-attachment-12766\" style=\"width: 1024px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/tool-auswahl-overview.png\" rel=\"attachment wp-att-12766\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-12766 size-large\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/tool-auswahl-overview-1024x463.png\" alt=\"Abbildung: Tool-Auswahl\" width=\"1024\" height=\"463\" \/><\/a><figcaption id=\"caption-attachment-12766\" class=\"wp-caption-text\">Abbildung: Tool-Auswahl<\/figcaption><\/figure>\n<h2><span class=\"ez-toc-section\" id=\"Implementierung-der-Tests\"><\/span>Implementierung der Tests<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>An dieser Stelle sollen besonders zwei Dinge gezeigt werden:<\/p>\n<ol>\n<li>Unterschied von DOM-basierten zu visuellen Regressionstests<\/li>\n<li>Problematik der False-Positives bei visuellen Regressionstests<\/li>\n<\/ol>\n<p>Als Testszenario wird daf\u00fcr jeweils die &#8222;Abhaken&#8220;-Funktion der To-Do-Liste unser Test-App verwendet. In der folgenden Abbildung ist das Szenario abgebildet. Links ist der initiale Status der AUT zu sehen und rechts der Zielzustand, der getestet werden soll.<\/p>\n<figure id=\"attachment_12768\" aria-describedby=\"caption-attachment-12768\" style=\"width: 1024px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/testszenario.png\" rel=\"attachment wp-att-12768\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-12768 size-large\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/testszenario-1024x339.png\" alt=\"Abbildung: Testszenario f\u00fcr die &quot;Abhaken&quot;-Funktion; [1] initialer Zustand der AUT, [2] zu testender Status der AUT\" width=\"1024\" height=\"339\" \/><\/a><figcaption id=\"caption-attachment-12768\" class=\"wp-caption-text\">Abbildung: Testszenario f\u00fcr die &#8222;Abhaken&#8220;-Funktion; [1] initialer Zustand der AUT, [2] zu testender Status der AUT<\/figcaption><\/figure>\n<h3><span class=\"ez-toc-section\" id=\"DOM-basierte-vs-visuelle-Regressionstests\"><\/span>DOM-basierte vs. visuelle Regressionstests<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>F\u00fcr den ersten Teil der Implementierung soll zu dem Testszenario der dazugeh\u00f6rige DOM-basierte Test mit <a href=\"http:\/\/www.protractortest.org\/#\/\" target=\"_blank\" rel=\"noopener\">Protractor<\/a> und der visuelle Test mit Gemini implementiert werden.<\/p>\n<pre class=\"lang:js decode:true \" title=\"Code: Protractor-Test\">describe('todo-check', () =&gt; {\r\n\r\n    beforeEach(() =&gt; {\r\n\r\n        browser.get('http:\/\/localhost:8080\/examples\/angular2\/');\r\n\r\n    });\r\n\r\n    it('should mark \"UI-Tests schreiben\" as done and update UI accordingly', () =&gt; {\r\n\r\n        let todoCount = element(by.css('todo-app .todoapp .footer span.todo-count strong'));\r\n\r\n        let todoEntry = element(by.css('ul.todo-list li:last-child'));\r\n\r\n        let todoEntryCheckbox = todoEntry(by.css('input'));\r\n\r\n        todoEntryCheckbox.click()\r\n\r\n            .then(() =&gt; {\r\n\r\n                expect(todoCount.getText()).toBe('0');\r\n\r\n                expect(todoEntryCheckbox.isSelected()).toBe(true);\r\n\r\n                expect(todoEntry.getAttribute('class')).toMatch('completed');\r\n\r\n            });\r\n\r\n    });\r\n\r\n});<\/pre>\n<pre class=\"lang:js decode:true\" title=\"Code: Gemini-Test\">gemini.suite('todo-check', (suite) =&gt; {\r\n\r\n    suite.setUrl('http:\/\/localhost:8080\/examples\/angular2\/')\r\n\r\n        .setCaptureElements('html')\r\n\r\n        .before((actions, find) =&gt; {\r\n\r\n            this.todoEntryCheckbox = find('ul.todo-list li:last-child input');\r\n\r\n            this.todoEntryLabel = find('ul.todo-list li:last-child label');\r\n\r\n        })\r\n\r\n        .capture('todo-ui_tests-done', (actions, find) =&gt; {\r\n\r\n            actions.click(this.todoEntryCheckbox);\r\n\r\n        });\r\n\r\n});<\/pre>\n<p>Nachdem f\u00fcr diesen Test die Baseline erstellt wurde, wird eine \u00c4nderung im CSS vorgenommen, welche &#8222;ungewollte&#8220; Auswirkungen auf die Darstellung hat. Dazu wurde das\u00a0<span class=\"lang:css decode:true crayon-inline\">padding<\/span>\u00a0 f\u00fcr alle\u00a0<span class=\"lang:css decode:true crayon-inline\">input<\/span>\u00a0 Elemente mit\u00a0<span class=\"lang:css decode:true crayon-inline\">50px<\/span>\u00a0 \u00fcberschrieben (vgl. nachfolgende Abbildung des Ergebnisses des visuellen Regressionstests). Da es sich hier um eine reine \u00c4nderung am CSS handelt, bekommt der DOM-basierte Test davon nichts mit und l\u00e4uft weiterhin ohne Fehler durch. Da nach dieser \u00c4nderung jedoch die\u00a0<span class=\"lang:css decode:true crayon-inline \">input<\/span>\u00a0 Elemente in andere klickbare Bereiche hineinragen, ist das UI f\u00fcr eine:n Endnutzer:in nicht mehr ohne weiteres zu bedienen und damit die Funktionalit\u00e4t eingeschr\u00e4nkt.<\/p>\n<figure id=\"attachment_12771\" aria-describedby=\"caption-attachment-12771\" style=\"width: 1024px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/dom-vs-vrt-failed-test.png\"><img loading=\"lazy\" decoding=\"async\" class=\"size-large wp-image-12771\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/dom-vs-vrt-failed-test-1024x496.png\" alt=\"Abbildung: Ergebnis des visuellen Regressionstests\" width=\"1024\" height=\"496\" \/><\/a><figcaption id=\"caption-attachment-12771\" class=\"wp-caption-text\">Abbildung: Ergebnis des visuellen Regressionstests<\/figcaption><\/figure>\n<p>Das Ergebnis eines erneuten Testdurchlaufs mit Gemini zeigt, dass das Tool die Regression erkennt und der Test fehlschl\u00e4gt. An dieser Stelle hat der\/die Entwickler:in dann die M\u00f6glichkeit, die Fehler zu beheben oder gewollte \u00c4nderungen \u00fcber den &#8222;Accept&#8220;-Button in die neue Baseline zu \u00fcbernehmen.<\/p>\n<p>In der Code-L\u00e4nge unterscheiden sich die beiden Implementierung zuerst nur minimal. M\u00f6chte man allerdings bei den DOM-basierten Tests auch pr\u00fcfen, ob die anderen To-Dos nach dem Durchlauf des Tests den korrekten Zustand haben und nicht beeinflusst wurden, kommt f\u00fcr jedes Element mehr Code hinzu. Bei den visuellen Tests bekommt man diese zus\u00e4tzliche Abdeckung aller sichtbaren UI-Elemente <em>kostenlos<\/em> dazu (vgl. nachfolgende Abbildung).<\/p>\n<figure id=\"attachment_12772\" aria-describedby=\"caption-attachment-12772\" style=\"width: 1024px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/dom-vs-vrt-testabdeckung.png\"><img loading=\"lazy\" decoding=\"async\" class=\"size-large wp-image-12772\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/dom-vs-vrt-testabdeckung-1024x339.png\" alt=\"Abbildung: Testabdeckungen: [1] DOM-basierte UI-Test, [2] visueller Regressionstest\" width=\"1024\" height=\"339\" \/><\/a><figcaption id=\"caption-attachment-12772\" class=\"wp-caption-text\">Abbildung: Testabdeckungen: [1] DOM-basierte UI-Test, [2] visueller Regressionstest<\/figcaption><\/figure>\n<h3><span class=\"ez-toc-section\" id=\"Problematik-der-False-Positives\"><\/span>Problematik der False-Positives<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Im zweiten Teil der Implementierung soll zus\u00e4tzlich zum Gemini-Test ein weiterer visueller Test mithilfe von WebdriverIO und Applitools Eyes erstellt werden. WebdriverIO ist eine auf Node.js basierende Implementierung des <a href=\"https:\/\/www.w3.org\/TR\/webdriver\/\" target=\"_blank\" rel=\"noopener\">W3C-WebDriver-Protokolls<\/a> und soll dabei unterst\u00fctzen, die AUT in den zu testenden Zustand zu bringen. Dieser Zustand wird dann in Form eines Screenshots festgehalten und per HTTP-Request an Applitools Eyes gesendet, wo der Bildvergleich stattfindet. Die Baseline wird wieder im Voraus aufgenommen und automatisch bei Applitools Eyes gespeichert. An dieser Stelle sollen die beiden Tool-Setups (Gemini vs. WebdriverIO + Applitools Eyes) verglichen werden.<\/p>\n<p>Am Gemini-Test hat sich nichts ver\u00e4ndert. Der einzige Unterschied ist die eingebaute \u00c4nderung in der To-Do-App, die im zweiten Durchlauf erkannt werden soll. Auch hierbei handelt es wieder um eine reine CSS-\u00c4nderung. Daf\u00fcr wird der\u00a0<span class=\"lang:css decode:true crayon-inline \">margin-top<\/span>\u00a0 der\u00a0<span class=\"lang:css decode:true crayon-inline\">section.todoapp<\/span>\u00a0 (entspricht der To-Dos-Liste; Titel ist auch abh\u00e4ngig von dessen Position) um ein Pixel vergr\u00f6\u00dfert. D. h. der komplette Inhalt rutscht einen Pixel weiter nach unten.<\/p>\n<p>Das Ergebnis des Gemini-Tests ist in der nachfolgenden Abbildung zu sehen. Der Test schl\u00e4gt fehl und markiert alle nicht-wei\u00dfen Pixel als Fehler-Pixel, obwohl der Unterschied zwischen der Baseline (bei Gemini &#8222;Reference&#8220; genannt) und der aktuellen Aufnahme f\u00fcr den Menschen nicht sichtbar ist. Eine weitere Schwierigkeit dieser Art der False-Positives ist, dass die Fehlerquelle nicht direkt ersichtlich ist. W\u00e4re der Hintergrund der To-Do-Liste nicht wei\u00df, sondern h\u00e4tte beispielsweise eine Struktur (mit einer H\u00f6he &gt; 1 Pixel), w\u00e4re nicht nur der Inhalt im Differenzbild hervorgehoben, sondern die komplette Fl\u00e4che ab der H\u00f6he des verschobenen Pixels.<\/p>\n<figure id=\"attachment_12774\" aria-describedby=\"caption-attachment-12774\" style=\"width: 1024px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/fp-failed-test.png\"><img loading=\"lazy\" decoding=\"async\" class=\"size-large wp-image-12774\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/fp-failed-test-1024x496.png\" alt=\"Abbildung: Ergebnis des Gemini-Tests\" width=\"1024\" height=\"496\" \/><\/a><figcaption id=\"caption-attachment-12774\" class=\"wp-caption-text\">Abbildung: Ergebnis des Gemini-Tests<\/figcaption><\/figure>\n<p>Die Implementierung des Tests mit WebdriverIO im Zusammenspiel mit Applitools Eyes sieht dabei wie folgt aus:<\/p>\n<pre class=\"lang:js decode:true \" title=\"Code: Test mit WebdriverIO zusammen mit Applitools Eyes\">async function main() {\r\n\r\n    const wdio = require('webdriverio');\r\n\r\n    const browserOptions = {\r\n\r\n        remoteHost: 'http:\/\/localhost:4444',\r\n\r\n        desiredCapabilities: {\r\n\r\n            browserName: 'chrome',\r\n\r\n            chromeOptions: {\r\n\r\n                args: [\r\n\r\n                    'disable-infobars'\r\n\r\n                ]\r\n\r\n            }\r\n\r\n        }\r\n\r\n    };\r\n\r\n    const driver = wdio.remote(browserOptions);\r\n\r\n    let browser = driver.init();\r\n\r\n    const { Eyes, Target } = require('@applitools\/eyes.webdriverio');\r\n\r\n    let eyes = new Eyes();\r\n\r\n    eyes.setApiKey('APPLITOOLS_API_KEY');\r\n\r\n    try {\r\n\r\n        await eyes.open(browser, 'todo-mvc', 'todo-check', { width: 1024, height: 680 });\r\n\r\n        await browser.url('http:\/\/localhost:8080\/examples\/angular2\/');\r\n\r\n        await browser.click('ul.todo-list li:nth-child(3) input');\r\n\r\n        await eyes.check('Main page', Target.window());\r\n\r\n        await eyes.close();\r\n\r\n    } finally {\r\n\r\n        await browser.end();\r\n\r\n        await eyes.abortIfNotClosed();\r\n\r\n    }\r\n\r\n}\r\n\r\nmain();<\/pre>\n<p>Das Ergebnis des Bildvergleichs mit Applitools Eyes ist hier abgebildet:<\/p>\n<p><figure id=\"attachment_12775\" aria-describedby=\"caption-attachment-12775\" style=\"width: 1024px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/fp-applitools_eyes.png\"><img loading=\"lazy\" decoding=\"async\" class=\"size-large wp-image-12775\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/fp-applitools_eyes-1024x366.png\" alt=\"Abbildung: Ergebnis des Tests mit WebdriverIO und Applitools Eyes: [1] Match-Level: Exact, [2] Match-Level: Strict\" width=\"1024\" height=\"366\" \/><\/a><figcaption id=\"caption-attachment-12775\" class=\"wp-caption-text\">Abbildung: Ergebnis des Tests mit WebdriverIO und Applitools Eyes: [1] Match-Level: Exact, [2] Match-Level: Strict<\/figcaption><\/figure>Applitools Eyes biete mehrere sogenannte &#8222;Match-Level&#8220;. Diese entsprechen verschiedenen Modi f\u00fcr den Bildvergleich. Insgesamt gibt es vier verschiedene Level:<\/p>\n<ol>\n<li><strong>Strict (default):<\/strong>\u00a0Imitiert die Wahrnehmung des menschlichen Auges (siehe z. B. CIE-DE2000)<\/li>\n<li><strong>Exact:<\/strong> Pixel-f\u00fcr-Pixel-Verlgeich<\/li>\n<li><strong>Content:<\/strong> Ignoriert Styling und Pixel-Unterschiede durch Anti-Aliasing<\/li>\n<li><strong>Layout:<\/strong> Ignoriert inhaltliche \u00c4nderungen (z. B. bei dynamischem Inhalt)<\/li>\n<\/ol>\n<p>Die wohl am h\u00e4ufigsten benutzten Level sind &#8222;Strict&#8220; und &#8222;Layout&#8220;. In unserem Beispiel reicht das Standard-Level &#8222;Strict&#8220;, um den durch die Pixelverschiebung provozierten False-Positive zu verhindern. M\u00f6chte man jedoch dynamische Inhalte bzw. lediglich strukturelle Aspekte einer AUT testen, eignet sich das Level &#8222;Layout&#8220; f\u00fcr den Bildvergleich. Dabei wird die Struktur des Layouts mithilfe ausgefeilter Algorithmen in der Bildverarbeitung erkannt und auf Regressionen gepr\u00fcft. Daf\u00fcr liegt der Fokus im Bildvergleich auf neuen, fehlenden oder fehlplatzierten Objekten in der Layout-Struktur. Nachfolgend wird dazu ein kurzes Beispielszenario dargestellt. Dabei hat sich zum einen die L\u00e4nge eines der To-Dos ge\u00e4ndert und zum anderen die Platzierung der \u00dcberschrift.<\/p>\n<p><figure id=\"attachment_12776\" aria-describedby=\"caption-attachment-12776\" style=\"width: 1024px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/fp-applitools_eyes-2.png\"><img loading=\"lazy\" decoding=\"async\" class=\"size-large wp-image-12776\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/fp-applitools_eyes-2-1024x397.png\" alt=\"Abbildung: Ergebnis des Tests mit WebdriverIO und Applitools Eyes: [1] Match-Level: Exact, [2] Match-Level: Layout\" width=\"1024\" height=\"397\" \/><\/a><figcaption id=\"caption-attachment-12776\" class=\"wp-caption-text\">Abbildung: Ergebnis des Tests mit WebdriverIO und Applitools Eyes: [1] Match-Level: Exact, [2] Match-Level: Layout<\/figcaption><\/figure>Die Ergebnisse der Tests zeigen, dass vor allem Applitools Eyes mit den unterschiedlichen Match Levels eine ausgereifte L\u00f6sung f\u00fcr das Problem der False-Positives liefert. Gemini bietet zwar die M\u00f6glichkeit Farbunterschiede nach dem CIE-DE2000 Modell zu ignorieren und Elemente der AUT per CSS-Selektoren vom Bildvergleich auszuschlie\u00dfen, dies reicht jedoch nicht aus, um vermeintliche einfache False-Positives, wie f\u00fcr den Menschen unsichtbare Pixelverschiebungen, zu identifizieren.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Lessons-learned\"><\/span>Lessons learned<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<h3><span class=\"ez-toc-section\" id=\"Was-soll-getestet-werden\"><\/span>Was soll getestet werden?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Wichtig an dieser Stelle ist das Identifizieren sogenannter Validation-Points. Damit sind die Status gemeint, die eine hohe Priorit\u00e4t f\u00fcr die Endnutzer:innen haben oder zu einem kritischen Workflow wie beispielsweise dem Check-out-Prozess geh\u00f6ren. Erstere k\u00f6nnen zum Beispiel anhand von Nutzungsstatistiken erkannt werden.<\/p>\n<p>Ein weiteres Kriterium f\u00fcr einen Validation-Point ist, wie viele interaktive UI-Elemente die Benutzeroberfl\u00e4che hat. Je mehr Interaktionsm\u00f6glichkeit das UI bietet, desto anf\u00e4lliger ist dieses f\u00fcr Fehler und daf\u00fcr diese beim manuellen Testen zu \u00fcbersehen.<\/p>\n<p>Web-Anwendungen, die wenig verschiedene UIs und kaum interaktive Elemente besitzen, taugen selbstverst\u00e4ndlich weniger dazu, den zus\u00e4tzlichen Aufwand f\u00fcr die Tests zu investieren.<\/p>\n<p>Ein weiterer Use-Case, bei dem es sich lohnt, visuelle Regressionstests f\u00fcr eine bestehende Anwendung zu schreiben, ist der einer CSS-Refaktorisierung. Mit VRT kann das UI vor dem Umbau in einer Baseline &#8222;eingefroren&#8220; und dann das CSS \u00fcberarbeitet werden.<\/p>\n<p>Gem\u00e4\u00df der Testing-Pyramide von Mike Cohn sollte VRT als reines CSS- bzw. GUI-Testing-Werkzeug gesehen werden. VRT ist keine sinnvolle Methode, um Business-Logik zu validieren.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Wie-soll-getestet-werden\"><\/span>Wie soll getestet werden?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Um immer mit aktuellen Browser-Versionen und den unterschiedlichen Browser-Typen testen zu k\u00f6nnen, sind auf Selenium basierende Tools zu bevorzugen.<\/p>\n<p>Die besten Erfahrungen wurden mit WebdriverIO in Kombination mit Applitools Eyes f\u00fcr den Bildvergleich gemacht. WebdriverIO bietet eine schnelle Ausf\u00fchrungsgeschwindigkeit und gleichzeitig eine einfache Integration in JavaScript-basierte Web-Projekte.<\/p>\n<p>Besonders wichtig ist der vorsichtige Umgang mit Mismatch-Toleranzen. Am besten wird darauf vollst\u00e4ndig verzichtet.<\/p>\n<p>Wie f\u00fcr DOM-basierte Tests gilt auch bei den visuellen Regressionstests die Kapselung der Tests von der Implementierung. Dies wird durch die Nutzung des <a href=\"https:\/\/martinfowler.com\/bliki\/PageObject.html\" target=\"_blank\" rel=\"noopener\">Page-Object-Pattern<\/a> realisiert, welches leider h\u00e4ufig missachtet wird und zu redundanten Pflegeaufw\u00e4nden der UI-Tests f\u00fchrt.<\/p>\n<p>Ein weiterer wichtiger Punkt sind <span class=\"lang:js decode:true crayon-inline \">wait<\/span>\u00a0-Statements in den Tests. Sofern diese sich nicht auf konkrete Elemente im DOM beziehen (z. B. bei Gemini mit <span class=\"lang:js decode:true crayon-inline \">actions.waitForElementToShow(&lt;selector&gt;, &lt;timeout&gt;)<\/span>\u00a0), sollte darauf verzichtet werden. M\u00f6chte man beispielsweise auf das Ende einer Animation warten bevor der Screenshot aufgenommen werden soll, ist es sinnvoller auf dynamisch gesetzte CSS-Klassen zu warten oder CSS-Attribute zu pr\u00fcfen. <span class=\"lang:css decode:true crayon-inline \">wait<\/span>\u00a0-Statements alleine verlangsamen die Tests k\u00fcnstlich und k\u00f6nnen trotzdem zu fehlerschlagenden Tests f\u00fchren. Ein m\u00f6glicher Ansatz um Timing-Probleme in den Griff zu bekommen ist es, die fehlgeschlagenen Tests automatisiert ein weiteres Mal auszuf\u00fchren und erst wenn diese erneut fehlschlagen diese wirklich als &#8222;fehlerhaft&#8220; zu markieren. Dieser Ansatz verl\u00e4ngert jedoch wiederum die Ausf\u00fchrungsdauer der Tests.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Wann-soll-getestet-werden\"><\/span>Wann soll getestet werden?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Der optimale Zeitpunkt zum Testen auf Systemebene ist vor der Integration eines neuen Features in eine bestehende Anwendung. Das bedeutet zum einen, dass VRT kein Ansatz f\u00fcr TDD (Test-Driven-Development) sein sollte, da sich gerade zu Beginn eines Projektes die Baseline regelm\u00e4\u00dfig stark ver\u00e4ndert. Zum anderen ist damit gemeint, dass speziell Pull oder Merge Request von Feature Branches auf beispielsweise den Develop oder Master Branch (vgl. <a href=\"http:\/\/nvie.com\/posts\/a-successful-git-branching-model\/\" target=\"_blank\" rel=\"noopener\">GitFlow<\/a>) als Zeitpunkt f\u00fcr den visuellen Vergleich mit der Baseline sinnvoll sind. Dazu lassen sich die getesteten Tools problemlos in Build-Umgebungen einbinden und somit automatisieren.<\/p>\n<p>Neben dem Einsatz als eine Art Akzeptanz-Test, bietet sich der visuelle Vergleich auch als Monitoring-Werkzeug an. Daf\u00fcr werden in regelm\u00e4\u00dfigen Zeitabst\u00e4nden automatisiert Screenshots einer produktiven Web-Anwendung gemacht und diese auf Regressionen gepr\u00fcft.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Ausblick\"><\/span>Ausblick<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Visuelle Regressionstests haben ihre klaren Schw\u00e4chen im effektiven Vergleich zweier Screenshots in der Bildverarbeitung. Bis auf Applitools Eyes nutzen alle evaluierten Werkzeuge ausschlie\u00dflich den Ansatz des direkten Pixel-Vergleichs. Daf\u00fcr sind bei einigen Tools zus\u00e4tzlich Algorithmen zur Vernachl\u00e4ssigung von Anti-Aliasing-Effekten bzw. geringen Farbdifferenzen implementiert. Jedoch bietet keine der Open-Source-L\u00f6sungen einen Ansatz zur Layout-Validierung.<\/p>\n<p>Zus\u00e4tzlich w\u00e4re es w\u00fcnschenswert, \u00c4nderungen in den Screenshots selektiv in die Baseline \u00fcbernehmen zu k\u00f6nnen. Daf\u00fcr w\u00e4re jedoch ebenfalls eine Erweiterung der Bildverarbeitung notwendig, um Pixel-Gruppen zu identifizieren.<\/p>\n<p>VRT in der Mobile-Application-Entwicklung ist zudem ein interessantes Thema. \u00dcber <a href=\"http:\/\/appium.io\/\" target=\"_blank\" rel=\"noopener\">Appium<\/a> (Selenium-Pendant f\u00fcr mobile Endger\u00e4te) l\u00e4sst sich der gleiche Test-Workflow in der Mobile-Application-Entwicklung umsetzen.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Fazit\"><\/span>Fazit<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Automatisierte Tests, die f\u00fcr die unterschiedlichen Ebenen der Programmstruktur geschrieben werden, sollen helfen, die Software-Qualit\u00e4t zu verbessern. Trotzdem wird es f\u00fcr Software-Entwickler:innen zunehmend schwieriger, Aussagen \u00fcber die Qualit\u00e4t der von ihnen entwickelten Anwendungen zu treffen. Das Problem dabei sind die zunehmend komplexer werdenden Systeme. Im Fall der Web-Frontend-Entwicklung entspricht dies hochdynamischen grafischen Benutzeroberfl\u00e4chen. Inhalte werden nicht mehr nur statisch angezeigt, sondern in Teilen dynamisch nachgeladen und aktualisiert. Das Internet verbreitet sich dabei als Software-Plattform immer rasanter. Desktop-Anwendungen werden h\u00e4ufiger in Form von Web-Anwendungen neu implementiert und damit steigt auch der Grad der Interaktionsm\u00f6glichkeiten, die Web-Frontends bieten m\u00fcssen. Trotzdem werden gerade diese kaum durch automatisierbare Tests gepr\u00fcft. Die Kernfragen meiner Abschlussarbeit, auf der dieser Artikel basiert, zielen folglich darauf ab, den Grund hierf\u00fcr herauszufinden und eine Aussage zu treffen, ob das Gebiet der visuellen Regressionstests Abhilfe schaffen kann.<\/p>\n<p>Die Implementierung und Integration von UI-Tests mit unterschiedlichen Werkzeugen hat gezeigt, dass visuelle Regressionstests einen gangbaren Weg darstellen, Benutzeroberfl\u00e4chen zu validieren. Diese sind nicht nur weniger aufw\u00e4ndig zu entwickeln und zu pflegen als DOM-basierte UI-Tests, sondern bieten zus\u00e4tzlich eine Erkennung von CSS- und Template-Regressionen.<\/p>\n<p>False-Positives lassen sich mit ausgereiften Algorithmen in der Bildverarbeitung kompensieren und die automatisierte Interaktion mit den unterschiedlichen Web-Browsern ist mittlerweile gut ausgebaut und ausreichend zuverl\u00e4ssig. Wird in den Tests mit der Anwendung interagiert, um in den zu testenden Zustand der AUT zu kommen, wird funktional das gleiche getestet wie bei DOM-basierten Tests. Damit sind visuelle Regressionstests nicht nur eine komplement\u00e4re, sondern, aus meiner Sicht, auch ersetzende L\u00f6sung f\u00fcr DOM-basierte UI-Tests.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Visuelle Regressionstests (Visual-Regression-Testing, VRT) sollen es dem\/der Software-Entwickler:in erleichtern, im Web-Frontend-Bereich sichere Aussagen zur Qualit\u00e4t der entwickelten Anwendungen zu geben. Dabei werden Screenshots von Benutzeroberfl\u00e4chen gemacht und diese mit einem vorhandenen Referenzsatz verglichen. Auf diese Weise k\u00f6nnen CSS- und Template-Regressionen erkannt werden, die mit DOM-basierten E2E-Tests nicht zu erkennen sind. Dazu z\u00e4hlen beispielsweise ungewollte \u00dcberschreibungen [&hellip;]<\/p>\n","protected":false},"author":66,"featured_media":13386,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"ep_exclude_from_search":false,"footnotes":""},"tags":[69],"service":[444],"coauthors":[{"id":66,"display_name":"Frederik Martin","user_nicename":"fmartin"}],"class_list":["post-21081","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","tag-digital-quality","service-frontend"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.5 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Visuelle Regressionstests vs. DOM-basierte E2E-Tests<\/title>\n<meta name=\"description\" content=\"Dieser Beitrag kl\u00e4rt, was visuelle Regressionstests in der Praxis leisten und ob diese tats\u00e4chlich DOM-basierte E2E-Tests ersetzen k\u00f6nnen.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/\" \/>\n<meta property=\"og:locale\" content=\"de_DE\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Visuelle Regressionstests vs. DOM-basierte E2E-Tests\" \/>\n<meta property=\"og:description\" content=\"Dieser Beitrag kl\u00e4rt, was visuelle Regressionstests in der Praxis leisten und ob diese tats\u00e4chlich DOM-basierte E2E-Tests ersetzen k\u00f6nnen.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/\" \/>\n<meta property=\"og:site_name\" content=\"inovex GmbH\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/inovexde\" \/>\n<meta property=\"article:published_time\" content=\"2018-03-14T08:13:50+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2022-11-29T08:12:18+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/artikelbild-visuelle-regressionstests.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1920\" \/>\n\t<meta property=\"og:image:height\" content=\"1080\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Frederik Martin\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:image\" content=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/artikelbild-visuelle-regressionstests-1024x576.png\" \/>\n<meta name=\"twitter:creator\" content=\"@inovexgmbh\" \/>\n<meta name=\"twitter:site\" content=\"@inovexgmbh\" \/>\n<meta name=\"twitter:label1\" content=\"Verfasst von\" \/>\n\t<meta name=\"twitter:data1\" content=\"Frederik Martin\" \/>\n\t<meta name=\"twitter:label2\" content=\"Gesch\u00e4tzte Lesezeit\" \/>\n\t<meta name=\"twitter:data2\" content=\"22\u00a0Minuten\" \/>\n\t<meta name=\"twitter:label3\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data3\" content=\"Frederik Martin\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/visuelle-regressionstests-im-web\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/visuelle-regressionstests-im-web\\\/\"},\"author\":{\"name\":\"Frederik Martin\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/person\\\/cd55a69b5f353d1ee2db99709d0dc50b\"},\"headline\":\"Visuelle Regressionstests im Web: Eine praktikable Alternative zu DOM-basierten E2E-Tests?\",\"datePublished\":\"2018-03-14T08:13:50+00:00\",\"dateModified\":\"2022-11-29T08:12:18+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/visuelle-regressionstests-im-web\\\/\"},\"wordCount\":4199,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/visuelle-regressionstests-im-web\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2018\\\/03\\\/artikelbild-visuelle-regressionstests.png\",\"keywords\":[\"Digital Quality\"],\"articleSection\":[\"General\",\"Methods\"],\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/visuelle-regressionstests-im-web\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/visuelle-regressionstests-im-web\\\/\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/visuelle-regressionstests-im-web\\\/\",\"name\":\"Visuelle Regressionstests vs. DOM-basierte E2E-Tests\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/visuelle-regressionstests-im-web\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/visuelle-regressionstests-im-web\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2018\\\/03\\\/artikelbild-visuelle-regressionstests.png\",\"datePublished\":\"2018-03-14T08:13:50+00:00\",\"dateModified\":\"2022-11-29T08:12:18+00:00\",\"description\":\"Dieser Beitrag kl\u00e4rt, was visuelle Regressionstests in der Praxis leisten und ob diese tats\u00e4chlich DOM-basierte E2E-Tests ersetzen k\u00f6nnen.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/visuelle-regressionstests-im-web\\\/#breadcrumb\"},\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/visuelle-regressionstests-im-web\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/visuelle-regressionstests-im-web\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2018\\\/03\\\/artikelbild-visuelle-regressionstests.png\",\"contentUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2018\\\/03\\\/artikelbild-visuelle-regressionstests.png\",\"width\":1920,\"height\":1080},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/visuelle-regressionstests-im-web\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Visuelle Regressionstests im Web: Eine praktikable Alternative zu DOM-basierten E2E-Tests?\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#website\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\",\"name\":\"inovex GmbH\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"de\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\",\"name\":\"inovex GmbH\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2021\\\/03\\\/inovex-logo-16-9-1.png\",\"contentUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2021\\\/03\\\/inovex-logo-16-9-1.png\",\"width\":1921,\"height\":1081,\"caption\":\"inovex GmbH\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/www.facebook.com\\\/inovexde\",\"https:\\\/\\\/x.com\\\/inovexgmbh\",\"https:\\\/\\\/www.instagram.com\\\/inovexlife\\\/\",\"https:\\\/\\\/www.linkedin.com\\\/company\\\/inovex\",\"https:\\\/\\\/www.youtube.com\\\/channel\\\/UC7r66GT14hROB_RQsQBAQUQ\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/person\\\/cd55a69b5f353d1ee2db99709d0dc50b\",\"name\":\"Frederik Martin\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/ec8190ce6bf5a248cf66011f28ce7600504789ca38548ca27719887204d1bb97?s=96&d=retro&r=ga3e4a6e02222b6c3a5ea38d2464a3d46\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/ec8190ce6bf5a248cf66011f28ce7600504789ca38548ca27719887204d1bb97?s=96&d=retro&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/ec8190ce6bf5a248cf66011f28ce7600504789ca38548ca27719887204d1bb97?s=96&d=retro&r=g\",\"caption\":\"Frederik Martin\"},\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/author\\\/fmartin\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Visuelle Regressionstests vs. DOM-basierte E2E-Tests","description":"Dieser Beitrag kl\u00e4rt, was visuelle Regressionstests in der Praxis leisten und ob diese tats\u00e4chlich DOM-basierte E2E-Tests ersetzen k\u00f6nnen.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/","og_locale":"de_DE","og_type":"article","og_title":"Visuelle Regressionstests vs. DOM-basierte E2E-Tests","og_description":"Dieser Beitrag kl\u00e4rt, was visuelle Regressionstests in der Praxis leisten und ob diese tats\u00e4chlich DOM-basierte E2E-Tests ersetzen k\u00f6nnen.","og_url":"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/","og_site_name":"inovex GmbH","article_publisher":"https:\/\/www.facebook.com\/inovexde","article_published_time":"2018-03-14T08:13:50+00:00","article_modified_time":"2022-11-29T08:12:18+00:00","og_image":[{"width":1920,"height":1080,"url":"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/artikelbild-visuelle-regressionstests.png","type":"image\/png"}],"author":"Frederik Martin","twitter_card":"summary_large_image","twitter_image":"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/artikelbild-visuelle-regressionstests-1024x576.png","twitter_creator":"@inovexgmbh","twitter_site":"@inovexgmbh","twitter_misc":{"Verfasst von":"Frederik Martin","Gesch\u00e4tzte Lesezeit":"22\u00a0Minuten","Written by":"Frederik Martin"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#article","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/"},"author":{"name":"Frederik Martin","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/cd55a69b5f353d1ee2db99709d0dc50b"},"headline":"Visuelle Regressionstests im Web: Eine praktikable Alternative zu DOM-basierten E2E-Tests?","datePublished":"2018-03-14T08:13:50+00:00","dateModified":"2022-11-29T08:12:18+00:00","mainEntityOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/"},"wordCount":4199,"commentCount":0,"publisher":{"@id":"https:\/\/www.inovex.de\/de\/#organization"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/artikelbild-visuelle-regressionstests.png","keywords":["Digital Quality"],"articleSection":["General","Methods"],"inLanguage":"de","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/","url":"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/","name":"Visuelle Regressionstests vs. DOM-basierte E2E-Tests","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#primaryimage"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/artikelbild-visuelle-regressionstests.png","datePublished":"2018-03-14T08:13:50+00:00","dateModified":"2022-11-29T08:12:18+00:00","description":"Dieser Beitrag kl\u00e4rt, was visuelle Regressionstests in der Praxis leisten und ob diese tats\u00e4chlich DOM-basierte E2E-Tests ersetzen k\u00f6nnen.","breadcrumb":{"@id":"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#breadcrumb"},"inLanguage":"de","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/"]}]},{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#primaryimage","url":"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/artikelbild-visuelle-regressionstests.png","contentUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2018\/03\/artikelbild-visuelle-regressionstests.png","width":1920,"height":1080},{"@type":"BreadcrumbList","@id":"https:\/\/www.inovex.de\/de\/blog\/visuelle-regressionstests-im-web\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.inovex.de\/de\/"},{"@type":"ListItem","position":2,"name":"Visuelle Regressionstests im Web: Eine praktikable Alternative zu DOM-basierten E2E-Tests?"}]},{"@type":"WebSite","@id":"https:\/\/www.inovex.de\/de\/#website","url":"https:\/\/www.inovex.de\/de\/","name":"inovex GmbH","description":"","publisher":{"@id":"https:\/\/www.inovex.de\/de\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.inovex.de\/de\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"de"},{"@type":"Organization","@id":"https:\/\/www.inovex.de\/de\/#organization","name":"inovex GmbH","url":"https:\/\/www.inovex.de\/de\/","logo":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/","url":"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png","contentUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png","width":1921,"height":1081,"caption":"inovex GmbH"},"image":{"@id":"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/inovexde","https:\/\/x.com\/inovexgmbh","https:\/\/www.instagram.com\/inovexlife\/","https:\/\/www.linkedin.com\/company\/inovex","https:\/\/www.youtube.com\/channel\/UC7r66GT14hROB_RQsQBAQUQ"]},{"@type":"Person","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/cd55a69b5f353d1ee2db99709d0dc50b","name":"Frederik Martin","image":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/secure.gravatar.com\/avatar\/ec8190ce6bf5a248cf66011f28ce7600504789ca38548ca27719887204d1bb97?s=96&d=retro&r=ga3e4a6e02222b6c3a5ea38d2464a3d46","url":"https:\/\/secure.gravatar.com\/avatar\/ec8190ce6bf5a248cf66011f28ce7600504789ca38548ca27719887204d1bb97?s=96&d=retro&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/ec8190ce6bf5a248cf66011f28ce7600504789ca38548ca27719887204d1bb97?s=96&d=retro&r=g","caption":"Frederik Martin"},"url":"https:\/\/www.inovex.de\/de\/blog\/author\/fmartin\/"}]}},"_links":{"self":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/21081","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/users\/66"}],"replies":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/comments?post=21081"}],"version-history":[{"count":6,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/21081\/revisions"}],"predecessor-version":[{"id":38001,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/21081\/revisions\/38001"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/media\/13386"}],"wp:attachment":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/media?parent=21081"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/tags?post=21081"},{"taxonomy":"service","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/service?post=21081"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/coauthors?post=21081"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}