Ist dieser Test flaky, oder handelt es sich um einen echten Fehler?

Ein flaky Test schlägt fehl und besteht dann bei einem erneuten Versuch, ohne dass jemand etwas repariert hat, während ein echter Fehler aus einem Grund fehlschlägt, den kein erneuter Versuch ändert. Nexus Studio von Verdict System LLC unterscheidet sie, indem es jeden erneuten Versuch aufzeichnet: FLAKY für einen Fehler, den ein erneuter Versuch bestanden hat, BREACHED für einen echten Befund und BREACHED_FLAKY für einen Fehler, der selbst inkonsistent ist. Ein erneuter Versuch macht aus einem Defekt niemals einen grünen Durchlauf.

Vom Nexus Studio-Team, Verdict System LLC. 7. Oktober 2026.

Was ist ein Flaky Test?

Ein flaky Test ist ein Test, dessen Versuche nicht übereinstimmen: Er schlägt einmal fehl und besteht bei einem weiteren Versuch, während der Code und der Test unverändert bleiben. In Nexus Studio hat das Wort eine einzige Bedeutung. FLAKY ist ein Test, der fehlschlug und dann bei einem erneuten Versuch bestand, ohne dass etwas repariert wurde. Etwas ist instabil, in der Anwendung oder im Test, und nichts wurde behoben.

Ein harter Fehler, der bei jedem Versuch auftritt, ist nicht flaky, selbst wenn der Self-Healing-Schritt versucht hat und daran gescheitert ist, einen Selektor zu reparieren. Eine frühere Version der Engine stufte diesen Fall als FLAKY ein. Teams interpretieren FLAKY als „der Test ist schlecht“ und gehen weiter, sodass eine fehlerhafte Anwendung als Rauschen ausgeliefert wurde. Die Engine tut dies nicht mehr.

Verbergen erneute Versuche echte Fehler?

Das können sie, und der Grund dafür ist die Anzahl der Zustände. Wenn es nur „bestanden“ und „fehlgeschlagen“ gibt, färbt ein erfolgreicher erneuter Versuch einen roten Durchlauf grün, und ein intermittierender Defekt in der Anwendung wird unsichtbar. Das ist eine der teuersten Arten von Fehlern, die man finden kann. Wenn Rot auch ein kurzes Netzwerkproblem oder einen abgestürzten Browser bedeuten kann, lernt das Team, rote Tests erneut auszuführen, anstatt sie zu analysieren, und die Testsuite verliert an Vertrauen.

Nexus Studio hält den erneuten Versuch sichtbar. Ein Test, der fehlschlug und dann bestand, ist nicht SECURE. Er beendet sich in CI mit 0, bricht also den Build nicht ab, wird jedoch im Bericht und im Verlauf als FLAKY angezeigt – ein Bestehen mit Vorbehalt. Erfahren Sie unter wie die 14 Verdicts entschieden werden mehr über die vollständige Reihenfolge der Prüfungen.

Was ist der Unterschied zwischen FLAKY, BREACHED und BREACHED_FLAKY?

• FLAKY: Fehlgeschlagen, dann durch einen erneuten Versuch bestanden, und nichts wurde repariert. Lesen Sie die raw-data.json des fehlgeschlagenen Versuchs und dann den Verlaufstrend. Er beendet sich mit 0.
• BREACHED: Der Test ist bei einem einzelnen Versuch fehlgeschlagen, und kein Umgebungs- oder Harness-Muster erklärt den Fehler. Eine Assertion ist fehlgeschlagen. Dies ist der Fehlerbericht, und er beendet sich mit 1.
• BREACHED_FLAKY: Der Test ist bei seinem letzten Versuch nach einem früheren erneuten Versuch fehlgeschlagen, und kein Umgebungs- oder Harness-Muster erklärt dies. Der Fehler selbst ist inkonsistent. Vergleichen Sie die Versuche, bevor Sie einen Fehler melden. Er beendet sich mit 1.

Zwei benachbarte Zustände sorgen für ein ehrliches Gesamtbild. AUTO_RECOVER ist ein erfolgreicher Durchlauf, bei dem Self-Healing einen Selektor ersetzt hat, sodass der Locator des Autors tot und der Test nicht sauber ist. Ein erster Versuch, der nur aufgrund der Zeit fehlschlug und dann beim erneuten Versuch bestand, ist SECURE, da dies Latenz und nicht Instabilität zeigt.

Bevor ein Fehler als BREACHED oder BREACHED_FLAKY eingestuft werden kann, schließt der Klassifizierer die anderen Erklärungen in einer festen Reihenfolge aus: ein Harness-Fehler, ein Absturz, eine Blockierung, ein nicht erreichbarer Host und ein Timeout. Nur ein Fehler, den keine dieser Ursachen erklärt, ist ein Befund. Deshalb wird ein Timeout oder ein CAPTCHA nicht als Fehlerbericht ausgegeben.

Wie werden erneute Versuche gezählt?

Die Engine liest die Versuchsnummer des Durchlaufs aus. Ein erfolgreicher Test mit einer Wiederholungsnummer größer als null ist FLAKY, es sei denn, ein Selektor wurde repariert; in diesem Fall ist es AUTO_RECOVER. Ein fehlschlagender Test oder ein Test mit Timeout mit einer Wiederholungsnummer größer als null und ohne Erklärung durch die Umgebung ist BREACHED_FLAKY. Ein sauberer Durchlauf erfordert null Wiederholungsversuche und keinen reparierten Selektor.

FLAKY bedeutet, dass die Versuche nicht übereinstimmten, und nichts anderes. Ein Fehlschlag bei einem einzelnen Versuch ohne Wiederholungen wird niemals als flaky eingestuft. Jede History-Zeile erfasst zudem retry_attempt und attempts, sodass die Zählung beim Durchlauf bleibt.

Welche Nachweise hinterlässt jedes Urteil?

• FLAKY: screenshot.png, metadata.json und raw-data.json. Der Ordner behält die raw-data.json des fehlgeschlagenen Versuchs, sodass ein Wiederholungsversuch, der den Fehlschlag verdeckt hat, dennoch sein Protokoll hinterlässt. Dies folgt der Einstellung „Keep evidence of a FLAKY / AUTO_RECOVER pass“, die standardmäßig aktiviert ist.
• BREACHED_FLAKY: report.md, metadata.json, raw-data.json und screenshot.png, und das Fehler-Video wird standardmäßig aufbewahrt.
• BREACHED: dieselben Dateien, wobei das Video standardmäßig aufbewahrt wird.

Das Urteil steht im Namen des Nachweisordners, zum Beispiel ein Name, der auf [BREACHED] endet. Die Evidence-Seite verfolgt einen fehlgeschlagenen Test durch jede Datei.

Wie erkennt History einen Test, der kippt?

History speichert eine Zeile pro Durchlauf für jeden Test und jeden Browser bzw. jedes Gerät, inklusive Urteil, Wiederholungsversuch und Fehlersignatur. Aus diesen Zeilen werden Trends nach Sitzung, Tag oder Woche angezeigt: Regressed, Recovered, Still broken und Slower. Ein Test, der grün, rot und wieder grün wird, taucht dort auf, anstatt in Wiederholungsdurchläufen unterzugehen.

Das Risiko-Ranking im Evidence Locker und in Patrol ordnet Tests danach ein, wie oft sie kippen, fehlschlagen oder Zeit kosten. Es zeigt außerdem ein prognostiziertes Risiko aus einer logistischen Regression über Ihren Verlauf, mit einem EWMA-Fallback, falls die Datenlage dünn ist. Unterhalb von fünf Durchläufen wird nichts als flaky eingestuft, da ein oder zwei Durchläufe kein Muster erkennen lassen.

Grenzen

• Wiederholungsversuche (Retries) unterscheiden FLAKY von SECURE und BREACHED_FLAKY von BREACHED. Wenn Wiederholungsversuche deaktiviert sind, gilt ein sporadischer Fehler als BREACHED.
• FLAKY besagt, dass die Versuche nicht übereinstimmten. Es sagt nicht, warum. Die Ursache in der Anwendung oder im Test zu finden, bleibt die Aufgabe eines Menschen.
• Die Klassifizierung liest Fehlertexte aus, sodass eine benutzerdefinierte Assertionsmeldung, die Wörter wie 403 oder Forbidden enthält, als Umgebungsproblem interpretiert werden kann. Öffnen Sie metadata.json, wenn Sie ein Urteil überrascht.
• Unterhalb von fünf Durchläufen stufen History und das Risiko-Ranking nichts als flaky ein.

Nächste Schritte

Die Evidence-Seite zeigt jede Datei, die ein fehlgeschlagener Test hinterlässt, und How Nexus Studio decides 14 test verdicts erklärt die Reihenfolge der Prüfungen. Die 30-Tage-Testversion führt dieselbe Engine für Ihre eigenen Tests aus.

Um die Überprüfung zuerst auf Ihrem eigenen Rechner auszuführen, bietet Wie unterscheide ich einen echten Bug von einem Flaky Test? ein ausführbares Beispiel.