Visuelle Fehler, die Tests übersehen: testen, was Nutzer wirklich sehen

Was sind visuelle Fehler?

Ihre End-to-End-Tests sind grün.Dann schickt ein Kunde einen Screenshot der Kassenseite: Der Gesamtbetrag der Bestellung ist hinter einem Werbebanner verborgen.Jeder automatisierte Test hat bestanden, weil jeder automatisierte Test den Code der Seite gefragt hat, nicht den Bildschirm.Für visuelle Fehler wie diesen gibt es visuelles Testen: Es prüft, was Ihre Nutzer tatsächlich sehen.

Ein visueller Fehler ist ein Mangel, den Menschen auf dem Bildschirm sehen, während der Code dahinter in Ordnung aussieht.Das Element existiert, es hat eine Größe, es enthält den richtigen Text.Eine Prüfung des Codes besteht.Die Person vor dem Bildschirm kann es nicht lesen, nicht finden oder nicht anklicken.

Dieser Artikel zeigt, woher die Lücke kommt, welche Fehler hineinfallen und wie Sie End-to-End-Tests bauen, die den Bildschirm so sehen wie Ihre Nutzer.

Was „sichtbar“ für Playwright, Cypress und Selenium bedeutet

Ein codierter End-to-End-Test findet ein Element über einen Selektor und prüft etwas daran.Die Assertion, die dem Erleben eines Nutzers am nächsten kommt, lautet „Ist es sichtbar?“.Jedes Tool beantwortet sie auf seine eigene Weise, und keines davon sieht auf den Bildschirm.

Playwright

Bei Playwright besteht toBeVisible(), wenn das Element einen nicht leeren Begrenzungsrahmen und keinen Stil visibility: hidden hat.Die Dokumentation ergänzt, dass ein Element mit opacity: 0 als sichtbar gilt.Ob ein anderes Element das Element verdeckt oder welche Farbe sein Text hat, wird nicht gefragt.

Aktionen sind strenger als Assertionen.Vor einem Klick prüft Playwright, ob am Klickpunkt wirklich das Element getroffen wird, deshalb wartet der Klick bei einer verdeckten Schaltfläche, bis sein Zeitlimit abläuft.Playwright bietet außerdem toBeInViewport() für ein Element, das im Viewport liegen muss, und toHaveText() liest standardmäßig den textContent des Elements.

Cypress

Seit Cypress 16 greift die standardmäßige Sichtbarkeitsprüfung auf die browsereigene Methode Element.checkVisibility() zurück.Ein Element gilt als verborgen, wenn es keine Breite oder Höhe hat oder wenn es display: none, visibility: hidden oder, bei einer Assertion, opacity: 0 hat.Vor einem Klick prüft Cypress, ob die Mitte des Elements nicht verdeckt ist.

Bei einer Assertion sieht es anders aus.Die Dokumentation von Cypress sagt es klar: „Der moderne Algorithmus führt keinen Hit-Test durch und meldet das verdeckte Element deshalb als sichtbar“.

Selenium

Bei Selenium ist isDisplayed() in der W3C-WebDriver-Spezifikation nicht definiert, wegen „der Unmöglichkeit, alle möglichen Bedingungen abzudecken“, wie es die Dokumentation von Selenium ausdrückt.Selenium führt stattdessen eine große JavaScript-Funktion aus, die den Stil des Elements, seine Größe und die übergeordneten Elemente abwägt, die es abschneiden.Sie prüft nicht, ob ein anderes Element darüber gezeichnet wird oder ob der Text des Elements vor seinem Hintergrund lesbar ist.

Ein Klick auf ein verdecktes Element schlägt mit der Fehlermeldung „element click intercepted“ fehl.Ein Element, das der Test nur liest, wird weiterhin als angezeigt gemeldet.

9 visuelle Fehler, die eine codierte Prüfung bestehen

Jeder dieser Fehler lässt das Element im Code der Seite, mit einer Größe und dem richtigen Text.Ein codierter Test, der prüft, ob das Element existiert, sichtbar ist oder seinen Text enthält, besteht.Ihr Nutzer sieht etwas anderes.

1. Ein von einem anderen verdecktes Element

Ein Cookie-Banner, ein Chat-Widget, eine fixierte Kopfzeile oder ein Dialog, der sich nie geschlossen hat, liegt über dem Element, oft nach einer Änderung des z-index.Das Element ist nach jeder der obigen Definitionen weiterhin sichtbar.Ein Klick darauf wird abgewiesen, aber ein Test, der es nur liest, etwa einen Preis, eine Fehlermeldung oder eine Bestätigung, besteht, während niemand es sehen kann.

2. Text, den niemand lesen kann

Weißer Text auf weißem Hintergrund, Grau auf Grau nach einem Wechsel des Designs oder eine Beschriftung, die eine fehlerhafte Animation durchsichtig zurückgelassen hat.Keine Sichtbarkeitsprüfung liest eine Farbe.Bei Playwright besteht toBeVisible() auch für opacity: 0.

3. Abgeschnittener Text

Eine Beschriftung, die für ihren Rahmen zu lang ist, endet mit Auslassungspunkten, oder eine feste Höhe verbirgt die zweite Zeile.Die Seite enthält weiterhin jedes Wort, deshalb besteht eine Assertion, die den Text liest.Ihr Nutzer liest „Bestellung bestä...“.

4. Ein aus dem sichtbaren Bereich geschobenes Element

Eine breitere Tabelle oder eine längere Überschrift schiebt die Schaltfläche „Kaufen“ über den rechten Rand eines schmalen Bildschirms hinaus.Die Schaltfläche behält ihre Größe, deshalb besteht toBeVisible() weiterhin.Der Test erkennt es nur, wenn er für diese Schaltfläche auch toBeInViewport() abfragt.

5. Das falsche Bild oder Symbol

Ein Produkt zeigt das Foto eines anderen Produkts, eine Symbolschrift versagt und hinterlässt ein leeres Quadrat, oder ein Sprite-Update vertauscht zwei Symbole.Das Bildelement und die Klasse des Symbols sind unverändert, deshalb sieht der Code richtig aus.

6. Ein durch eine CSS-Änderung zerstörtes Layout

Eine Regel ändert einen Außenabstand, eine Flex-Richtung oder eine Grid-Spalte.Karten überlappen sich, eine Spalte rutscht unter eine andere, ein Formular verliert seine Ausrichtung.Jedes Element ist weiterhin im Code, mit seinem Text und seiner Größe, deshalb besteht jede Assertion.

7. Eine übersetzte Beschriftung, die nicht passt

Deutsche oder französische Wörter sind oft länger als englische.Eine Beschriftung läuft über ihre Schaltfläche hinaus, bricht in eine zweite Zeile um oder schiebt die nächste Schaltfläche weg.Die Übersetzung ist richtig, deshalb besteht eine Assertion, die den Text prüft, in jeder Sprache.

8. Eine Schrift, die nicht geladen wurde

Wenn ein Webfont nicht geladen wird, weicht der Browser auf eine andere Schrift aus: Zeilen brechen anders um, und Symbole, die mit einer Schrift gezeichnet werden, werden zu leeren Kästchen.Der Text im Code ist derselbe, deshalb schlägt nichts fehl.

9. Ein Ladekreis, der nie aufhört

Die Daten kommen an und die Zeilen werden der Seite hinzugefügt, aber das Lade-Overlay bleibt darüber liegen.Der Test findet seine Zeilen im Code und besteht.Ihr Nutzer wartet vor einem Ladekreis.

Die Dokumentation von Cypress selbst fasst es in einer Zeile zusammen: „Eine Anwendung kann jeden funktionalen Test bestehen und trotzdem sichtbar fehlerhaft ausgeliefert werden“.

Können visuelle Regressionstests mit Screenshots sie erkennen?

Ja, und das ist die übliche Antwort.Visuelle Regressionstests vergleichen ein Bild des Bildschirms mit einem früher aufgenommenen Referenzbild.

Bei Playwright ist das mit toHaveScreenshot() eingebaut.Die Dokumentation warnt, dass die Darstellung im Browser je nach Betriebssystem des Hosts, seiner Version und seinen Einstellungen, der Hardware und dem Headless-Modus variieren kann.Deshalb hat jeder Browser und jede Plattform ein eigenes Referenzbild.

Cypress nimmt Screenshots auf, und seine Dokumentation sagt, dass es „selbst keinen Bildvergleich durchführt“.Plugins oder Dienste für visuelles Testen fügen den Vergleich hinzu.

Dienste wie Percy und Applitools Eyes fügen Ihren codierten Tests Bildprüfpunkte hinzu.Percy nimmt während Ihrer Testläufe Screenshots auf und vergleicht sie.Applitools Eyes fügt innerhalb eines Tests einen Prüfaufruf hinzu.

So oder so muss Ihr codierter Test weiterhin jeden Bildschirm erreichen und sagen, wann das Bild aufgenommen wird: Sie schreiben und pflegen diesen Code, seine Selektoren und die Referenzbilder.Ein reiner Pixelvergleich meldet außerdem harmlose Unterschiede zwischen Rechnern, deshalb wird seine Toleranz zu einer Abwägung zwischen Fehlalarmen und übersehenen Fehlern.

Diese Tools im direkten Vergleich finden Sie in der Vergleichsstudie.

Warum manuelles Testen die Lücke nicht schließt

Ein Mensch sieht jeden dieser Fehler auf einen Blick.Deshalb klicken sich viele Teams vor einem Release immer noch durch ihre Anwendung.Manuelles Testen hat allerdings seine Grenzen.

Automatisierte End-to-End-Tests wiederholen bei jedem Build dieselben Prüfungen, ohne zu ermüden.Die Frage ist, wie man sie dazu bringt, den Bildschirm so anzusehen, wie ein Mensch es tut.

Wie bauen Sie End-to-End-Tests, die sehen, was Nutzer sehen?

Welches Tool Sie auch verwenden, sechs Prinzipien sorgen dafür, dass ein End-to-End-Test Ihre Anwendung so erlebt wie ein Nutzer.

1. 1

   Die echte Anwendung bedienen

   Klicken und tippen Sie so, wie ein Mensch es tut, auf dem echten Bildschirm.Ein Test, der eine verdeckte Schaltfläche nicht drücken kann, scheitert dort, wo auch Ihr Nutzer scheitern würde.

2. 2

   Prüfen, was angezeigt wird

   Prüfen Sie den Bildschirm auf drei Arten: das Bild, damit ein Element richtig aussieht; die Wörter, damit es das Richtige sagt; die Anordnung, damit alles dort steht, wo es hingehört.

3. 3

   Erst das Element finden, dann vergleichen

   Ein verschobenes Fenster oder eine gescrollte Seite ist kein Fehler.Ein Test sollte das Element dort finden, wo es jetzt ist, und dann beurteilen, wie es aussieht.

4. 4

   Rauschen ignorieren, nie eine echte Änderung

   Bildschirme unterscheiden sich zwischen Rechnern leicht, deshalb sollte der Vergleich Rendering-Rauschen ignorieren und trotzdem jede Änderung erkennen, die ein Mensch bemerken würde.

5. 5

   Die Nachweise zeigen

   Ein Fehlschlag sollte den erwarteten Bildschirm neben dem gefundenen zeigen, mit markierter Änderung, damit jeder im Team ihn lesen kann.

6. 6

   Die Kosten einer Änderung gering halten

   Wenn sich die Anwendung absichtlich ändert, sollte das Übernehmen des neuen Aussehens einen Klick kosten, kein Neuschreiben.

Wie GUI Test Studio testet, was Nutzer sehen

GUI Test Studio baut End-to-End-Tests nach diesen Prinzipien, ohne Code.Es testet Web-Apps, Windows-Desktop-Apps, Android-Smartphones und Spiele mit einer einzigen Art von Test.Lesen Sie mehr über visuelles Testen und GUI-Tests damit.

Den Ablauf einmal aufzeichnen

Klicken Sie im GUI Test Runner-Recorder auf Aufzeichnen und führen Sie den Ablauf aus wie immer: Er zeichnet Ihre Maus, Ihre Tastatur und den Bildschirm auf.Sie können den Ablauf auch in einem Prompt beschreiben, für Claude, ChatGPT oder ein lokales KI-Modell, eines von uns oder Ihr eigenes, das ihn für Sie aufzeichnet.

Wenn Sie stoppen, fragt er, was der Test prüfen soll.Mit den Standardantworten bekommt jedes Element, das Sie anklicken oder in das Sie tippen, direkt vor Ihrer Aktion eine Bild-Assertion.Was von selbst erscheint, etwa ein Menü, ein Dialog oder eine Meldung, bekommt eine Gruppen-Assertion.

Prüfungen dessen, was der Bildschirm zeigt

Jede hat ihren Leitfaden: Bildprüfungen, Textprüfungen und Layout- und Gruppenprüfungen.

Das Element finden, dann vergleichen

Jede Bildprüfung wird in zwei Phasen entschieden.Die Suchphase fragt, ob das Element auf dem Bildschirm ist, und wartet darauf bis zum Zeitlimit der Prüfung.Die GTS Engine + AI findet das Element, indem sie zuerst die Anwendung fragt, über ihre Barrierefreiheitsinformationen oder die eigenen Elemente der Seite, und am Aussehen, wenn die Anwendung nichts sagt.Siehe wie GUI Test Studio jedes Element findet.

Die Verifikationsphase vergleicht das Element dann genau mit seinem visuellen Ziel, dem Bild, das der Test erwartet.Sie ignoriert, was das Auge nicht sieht, etwa Kantenglättung und Videokompression, und erkennt trotzdem die echten Regressionen, die ein Mensch eine Änderung nennen würde: ein anderes Wort, eine Farbe, ein Symbol.

Wird das Element an einer anderen Stelle gefunden als in der Aufzeichnung, zielen die Klicks danach dorthin, wo es jetzt ist.Und ein Test klickt nie blind durch ein Banner: Ist das Element verdeckt, schlägt seine Prüfung vor dem Klick fehl.

Lesen, was sich geändert hat

Nach einem Lauf zeigt der Konfidenzbericht jede Prüfung mit dem erwarteten Bild neben dem gefundenen Bild, die Änderung hervorgehoben und das Ergebnis in einem einfachen Satz.

Vergrößern

Ist die Intelligente KI-Analyse eingeschaltet, bekommt eine fehlgeschlagene Prüfung außerdem einen zweiten Blick von einer KI, die in einfachen Worten sagt, was sich geändert hat.Sie läuft mit einem Cloud-Modell und Ihrem eigenen Schlüssel oder mit einem lokalen KI-Modell auf Ihrem eigenen Computer: einem von uns, oder Ihrem eigenen.

Ist die Änderung gewollt, übernehmen Sie das neue Aussehen aus dem Bericht, und der Test erwartet es von da an.Die Befehlszeile, gtr-cli, führt dieselben Tests aus jeder CI/CD-Pipeline aus, bei jedem Build.

Welche Prüfung welchen visuellen Fehler erkennt

Noch einmal die neun Fehler, jeweils mit der Prüfung von GUI Test Studio, die ihn erkennt.

Vergrößern

Wo codierte Prüfungen weiterhin hingehören

Visuelles Testen ersetzt nicht Ihre Unit- und API-Tests, die Logik und Daten schnell prüfen, unterhalb des Bildschirms.Auch eine codierte Prüfung, die bereits die richtige Frage stellt, etwa ein Hit-Test vor einem Klick, behält ihren Platz.Visuelles Testen fügt die Ebene hinzu, die keiner von ihnen sehen kann: den Bildschirm, den Ihre Nutzer ansehen.

Fragen

Selenium, Playwright, Cypress, Percy und Applitools Eyes sind Marken ihrer jeweiligen Inhaber.