Flaky Tests und False Positives: Warum Tests grundlos scheitern

Ein roter Build sollte nur eines bedeuten: Die Anwendung ist kaputt.Zu oft bedeutet er etwas anderes: Ein Test hat zu früh geklickt, eine Schrift wurde einen Hauch anders dargestellt, ein Ladekreis drehte sich noch.Das sind instabile Tests und False Positives, und sie sind einer der Hauptgründe, warum Teams ihren End-to-End-Tests nicht mehr trauen.

Dieser Leitfaden erklärt, woher sie in codierten und visuellen Tests kommen und wie Sie False Positives stoppen, ohne echte Bugs durchzulassen.

Was sind instabile Tests (Flaky Tests) und False Positives?

Ein False Positive ist ein Test, der fehlschlägt, obwohl die Anwendung so funktioniert, wie sie soll.Tester sprechen auch von einem falschen Fehlschlag oder einem Fehlalarm.Der Test schlägt Alarm, jemand untersucht ihn, und nichts ist falsch.

Ein instabiler Test (Flaky Test) ist ein Test, der mit demselben Code mal besteht und mal scheitert, ohne dass sich zwischen den Läufen etwas geändert hat.Jeder instabile Fehlschlag ist ein False Positive.Nicht jedes False Positive ist aber instabil: Ein Test, der jedes Mal scheitert, weil sein erwartetes Bild veraltet ist, ist falsch, nicht instabil.

Der umgekehrte Fehler ist das False Negative: ein Test, der besteht, während ein echter Bug auf dem Bildschirm ist.Er ist der gefährlichere der beiden, denn niemand schaut zweimal auf einen grünen Test.

Was False Positives ein Team kosten

Ein Fehlalarm kostet eine Untersuchung.Jemand öffnet die Protokolle, startet den Test erneut und findet nichts.

Die eigentlichen Kosten kommen später.Wenn die meisten roten Builds Rauschen sind, liest sie niemand mehr: Das ist Alarmmüdigkeit.Dann kommen die Gewohnheiten, die Bugs verbergen: einen Test so oft neu starten, bis er grün wird, jeden neuen Screenshot ungeprüft als Baseline übernehmen, den Test abschalten, der immer scheitert.

Jede dieser Gewohnheiten macht aus dem False Positive von heute das False Negative von morgen.Der Bug, für den der Test geschrieben wurde, kommt durch, weil niemand dem Test mehr glaubt.

Was macht End-to-End-Tests instabil?

End-to-End-Tests steuern eine ganze Anwendung über ihre Oberfläche, also begegnen sie allem, was auch ein echter Benutzer erlebt: langsamen Servern, Animationen, anderen Fenstern.Codierte Tests bringen eigene Ursachen mit.

Das Timing steht aus gutem Grund an erster Stelle.Die Dokumentation von Selenium selbst nennt das Wettrennen zwischen Test und Browser eine der Hauptursachen für instabile Tests.

Warum visuelle Regressionstests False Positives liefern

Visuelle Regressionstests vergleichen ein Bild der Anwendung mit einem freigegebenen Baseline-Bild.Sie erkennen, was codierte Assertionen übersehen: eine falsche Farbe, eine Beschriftung, die eine andere überlappt, ein fehlendes Symbol.Sie sehen aber auch Unterschiede, die kein Mensch eine Änderung nennen würde.

Ein strenger Vergleich Pixel für Pixel scheitert an jedem dieser Fälle.Ein lockerer lässt echte Bugs durch.Die Kunst des visuellen Testens besteht darin, beides auseinanderzuhalten.

Wie Teams instabile Tests heute beheben

In codierten Tests

Playwright wartet vor jeder Aktion, bis das Element sichtbar, stabil und aktiviert ist und von keinem anderen Element verdeckt wird, und scheitert sonst an einem Zeitlimit.

Cypress wiederholt seine Abfragen und Assertionen, bis sie erfüllt sind, standardmäßig bis zu 4 Sekunden lang.Es kann auch einen ganzen fehlgeschlagenen Test wiederholen, was standardmäßig ausgeschaltet ist.

Selenium bietet explizite Wartezeiten, die die Anwendung abfragen, bis eine Bedingung erfüllt ist, und seine Dokumentation rät davon ab, sie mit impliziten Wartezeiten zu mischen.

Wiederholungen dienen auch dazu, Instabilität zu erkennen.Playwright meldet einen Test, der erst scheiterte und dann bei einer Wiederholung bestand, als flaky, und Cypress Cloud versieht einen solchen Test mit einem Flaky-Abzeichen.Eine Wiederholung macht den Build grün, beseitigt aber nicht die Ursache.

Beim visuellen Testen

In Playwright nimmt toHaveScreenshot einen Farbschwellenwert pro Pixel, standardmäßig 0.2, und entweder ein absolutes maxDiffPixels oder ein maxDiffPixelRatio.Es kann dynamische Bereiche maskieren und hält standardmäßig Animationen an und blendet die Einfügemarke aus.

BackstopJS erlaubt einen Prozentsatz abweichender Pixel, standardmäßig 0.1, und kann die Elemente, die Sie angeben, ausblenden oder entfernen, bevor es seine Bilder aufnimmt.

Chromatic ignoriert geglättete Pixel standardmäßig, und sein diffThreshold, standardmäßig 0.063, legt fest, wie viel Änderung es toleriert.

Argos stabilisiert standardmäßig jeden Screenshot: Es wartet auf Schriften und Bilder, blendet die Einfügemarke und die Bildlaufleisten aus und markiert Screenshots, die sich von Lauf zu Lauf ändern.

Percy friert Animationen und andere dynamische Elemente ein, und Änderungen werden pro Build, pro Gruppe oder Snapshot für Snapshot freigegeben.Sein Visual Review Agent hebt die Änderungen hervor, die er für bedeutsam hält.

Applitools Eyes vergleicht mit Abgleichstufen.Strict will ignorieren, was das menschliche Auge nicht sehen würde, Layout prüft nur die Anordnung, und Dynamic akzeptiert jedes gültige Datum, jede gültige E-Mail-Adresse oder URL.

Jede dieser Möglichkeiten hilft.Jede verlangt aber auch, dass Sie Test für Test eine Zahl, eine Maske oder eine Stufe wählen und neue Bilder von Hand prüfen.Um diese Tools nebeneinander zu sehen, lesen Sie die Vergleichsstudie.

Warum eine großzügigere Toleranz nicht die Antwort ist

Eine Toleranz ist ein Versprechen: So viel Unterschied ist Rauschen.Die Frage ist, worin dieses So-viel gemessen wird.

Ein Verhältnis wächst mit dem Bild.Auf einem ganzen Bildschirm von 1920 × 1080 Pixeln sind 0.1 % rund 2000 Pixel, mehr als ein geändertes Wort.Auf einer Schaltfläche von 100 × 40 Pixeln sind es 4 Pixel, weniger als eine einzige Kante, die anders dargestellt wurde.

Eine absolute Anzahl wächst nicht mit dem Bild, aber sie zählt über das ganze Bild verstreutes Rauschen zusammen, als wäre es eine einzige Änderung.Eine Maske verbirgt das Rauschen, und sie verbirgt auch jeden Bug innerhalb der Maske.

Wie GUI Test Studio False Positives stoppt, ohne Bugs zu übersehen

GUI Test Studio ist eine Suite zur Automatisierung von End-to-End-Tests für Webanwendungen, Windows-Desktopanwendungen, Android und Spiele.Sie zeichnen einen Test einmal auf oder beschreiben ihn in einem Prompt, bearbeiten ihn auf einer Zeitleiste und führen ihn bei jedem Build aus.Seine Prüfungen folgen einer Regel: Ein Test scheitert, wenn ein Mensch ein Problem sehen würde, und nur dann.

Elemente werden auf zwei Wegen gefunden, ohne Selektor, der brechen kann

Die GTS Engine + AI fragt zuerst die Anwendung, wo ein Element ist, über ihre Barrierefreiheitsinformationen unter Windows oder über die eigenen Elemente der Seite in einem Browser.Wenn die Anwendung es nicht sagt, findet sie das Element per Blick auf dem Bildschirm.Es gibt keinen Locator zu schreiben, also bringen eine umbenannte Klasse oder ein neues Framework keinen Test zum Scheitern.Siehe wie GUI Test Studio jedes Element findet.

Prüfungen warten auf den Bildschirm, nie auf einen Timer

Jede Prüfung sucht weiter, bis das, was sie erwartet, auf dem Bildschirm ist, bis zu ihrem Zeitlimit von standardmäßig 5 Sekunden, und der Test geht in dem Moment weiter, in dem es da ist.Eine Bild-Abwesenheits-Assertion wartet, bis ein Ladekreis verschwindet, sodass auf eine langsame Seite gewartet und nicht geraten wird.

Wenn eine Bild-Assertion oder eine Text-Assertion ihr Element nach einer Sekunde nicht in ihrem Suchbereich gefunden hat, sucht sie zusätzlich auf dem ganzen Bildschirm, sodass ein verschobenes Fenster den Test nicht scheitern lässt.Bevor ein Lauf beginnt, vergleicht GUI Test Runner-Recorder Ihren Bildschirm mit dem ersten Moment der Aufzeichnung und hält den Lauf zurück, wenn die Anwendung auf einer anderen Seite ist.Siehe die Einstellungen einer Prüfung.

Die Verifikationsphase zählt, was sich geändert hat, und wo

Sobald das Element gefunden ist, vergleicht die Verifikationsphase es mit dem, was Sie erwarten.Sie zählt die Pixel, die sich im kleinen Bereich des Elements mit den meisten Änderungen deutlich geändert haben: eine absolute Zahl, nie ein Prozentsatz des Bildes.

Rauschen ist verstreut: hier eine weichere Kante, dort ein hellerer Farbton.Eine echte Änderung ist an einer Stelle gebündelt: ein Buchstabe, eine Ziffer, ein Symbol.Deshalb funktioniert dieselbe Regel bei einem kleinen Symbol ebenso wie bei einem ganzen Dialog.

Jede Prüfung hat eine Verifikationsstrenge: Exakt, Streng, Standard oder Großzügig.Standard passt zu alltäglichen Schaltflächen, Beschriftungen und Symbolen, Großzügig zu großen Bereichen und unruhigen Bildschirmen.Siehe Bildprüfungen.

Der richtige Moment, mit dem Zeiger dort, wo er stand

Ein Element wird oft gefunden, während sich der Bildschirm noch beruhigt: ein Menü, das eingeblendet wird, eine Seite, die noch lädt.Der Erweiterte Genauigkeitsdurchlauf betrachtet die Einzelbilder nach dem Treffer, behält das, auf dem das Element am besten aussieht, und hört dort auf, wo der nächste Schritt des Tests beginnt.Siehe den Erweiterten Genauigkeitsdurchlauf.

In einem aufgezeichneten Test setzt der Lauf den Mauszeiger dorthin zurück, wo er stand, als das Bild aufgenommen wurde.So ist eine Schaltfläche im Lauf genau dann hervorgehoben, wenn sie es in der Aufzeichnung war.

Ein Test, den Sie gerade aufgezeichnet und noch nicht bearbeitet haben, bekommt zusätzliche Hilfe.Wenn ein Element nicht so erscheint, wie es aufgezeichnet wurde, passt der Lauf den Test intelligent an, um es zu finden, und er tut das nie, um einen echten Unterschied zu verbergen.

Absichtlich anders: Baseline-Profile

Manche Unterschiede sind echt und gewollt: der Dunkelmodus, ein Laptop-Bildschirm statt eines 4K-Monitors, eine andere Windows-Version, die Anwendung in einer anderen Sprache.Ein Baseline-Profil hält pro Umgebung eine erwartete Version einer Prüfung bereit, sodass ein einziger Test alle abdeckt.Wo gesucht wird, wie lange gewartet wird und wie streng verglichen wird, teilen sich alle Versionen.Siehe Baseline-Profile.

Die Intelligente KI-Analyse spricht das letzte Wort

Wenn eine Prüfung geänderte Pixel findet, kann die Intelligente KI-Analyse ein zweites Mal hinsehen und entscheiden, mit einem Cloud-Modell und Ihrem eigenen Schlüssel oder einem lokalen KI-Modell auf Ihrem eigenen Computer, einem von uns oder Ihrem eigenen.Sie ist ausgeschaltet, bis Sie sie einschalten.

Sie lässt eine Prüfung bestehen, wenn sie nur geringfügige Unterschiede findet, die ein Benutzer vielleicht nicht bemerkt, während ein geändertes Wort, eine geänderte Zahl oder ein geänderter Wert, oder ein fehlendes Symbol oder Abzeichen, nie geringfügig ist und die Prüfung scheitern lässt.Der Bericht sagt, welcher Fall vorlag.

Der Mauszeiger und die blinkende Einfügemarke zählen nie als Unterschied, während ein geänderter Buchstabe oder ein geändertes Symbol immer zählt.Sie können einer Prüfung auch Anweisungen für die KI in Ihren eigenen Worten geben, etwa: Das Datum in der Ecke ändert sich jeden Tag.Siehe Intelligente KI-Analyse.

Vergrößern

Ein Bericht, der sagt, was sich geändert hat

Der Konfidenzbericht zeigt jede Bildprüfung in zwei Phasen.Die Suchphase beantwortet, ob das Element gefunden wurde, und die Verifikationsphase, ob es wie erwartet aussieht.Pulsieren hebt auf dem Bildschirm hervor, was sich geändert hat, und das Urteil sagt es in einfachen Worten.

Vergrößern

Seine Schwachstellen zeigen auf die Prüfungen, die am knappsten bestanden haben, also die, die am ehesten als Nächste scheitern.Der Verlauf zeigt, wann eine Prüfung zu scheitern begann.Wenn eine Änderung gewollt ist, übernehmen Sie das neue Aussehen im Bericht, und nichts wird geschrieben, bis Sie speichern.Siehe den Konfidenzbericht.

Anhalten oder fortsetzen: Sie entscheiden, was ein Fehlschlag bedeutet

Jede Prüfung sagt, was ihr Fehlschlag bewirkt: den Test anhalten oder ihn fortsetzen.Eine Prüfung, von der die folgenden Klicks abhängen, hält den Test standardmäßig an, denn ohne sie würde ein Klick die falsche Stelle treffen.Eine Prüfung, die nur bestätigt, was auf dem Bildschirm ist, wird fortgesetzt, sodass ein einziger Lauf jedes Problem meldet, auf das er trifft.

In einer Pipeline kann gtr-cli einen fehlgeschlagenen Test mit seiner Wiederholungsoption noch einmal ausführen.Nutzen Sie das als letztes Mittel: Beheben sollten Sie die Ursachen oben.

Eine Checkliste gegen False Positives

Möchten Sie das mit Ihrer eigenen Anwendung sehen?Visuelles Testen mit GUI Test Studio zeigt die ganze Idee auf einer Seite.

Fragen

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