Wie Sie echte Fehler von unzuverlässigen Tests trennen

Führen Sie den Test mehrmals ohne Wiederholungsversuche aus und zählen Sie. Ein echter Fehler schlägt bei jedem Durchlauf auf dieselbe Weise fehl, und ein unzuverlässiger Test ist bei einigen Durchläufen erfolgreich und schlägt bei anderen fehl, ohne dass etwas geändert wurde. Das folgende Beispiel macht genau das auf jedem Rechner mit Playwright und zeigt anschließend, was Nexus Studio mit jedem Ergebnis macht.

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

Wie kann ich sie in einer Minute voneinander unterscheiden?

Führen Sie den Test mehrmals hintereinander ohne Wiederholungsversuche aus. Playwright erledigt dies mit zwei Flags: --retries=0, damit ein Wiederholungsversuch einen Fehlschlag nicht verbergen kann, und --repeat-each=6, wodurch jeder Test sechsmal ausgeführt wird. Zählen Sie dann die Ergebnisse jedes Tests.

Es ist jedes Mal fehlgeschlagen: Behandeln Sie es als Fehler, bis Sie das Gegenteil beweisen können. Ein Fehlschlag bei jedem Durchlauf kann dennoch von der Umgebung herrühren, wie z. B. einer blockierten Anfrage oder einem nicht erreichbaren Host; lesen Sie daher zuerst die Fehlermeldung.
Es war bei einigen Durchläufen erfolgreich und schlug bei anderen fehl: Er ist unzuverlässig (flaky). Der Code und der Test haben sich zwischen diesen Durchläufen nicht geändert, daher ist etwas Instabiles im Spiel – in der Anwendung oder im Test.
Es war jedes Mal erfolgreich: Bisher gibt es nichts zu sehen. Ein Defekt, der nur einmal in fünfzig Durchläufen auftritt, erfordert mehr Durchläufe oder einen Blick in den Verlauf des Tests.

Kann ich es an einem ausführbaren Beispiel ausprobieren?

Speichern Sie dies als bug-or-flaky.spec.js. Der erste Test simuliert einen Flake: Er schlägt bei einem von drei Durchläufen fehl. Der zweite Test ist ein echter Fehler: Die Seite zeigt „Welcome“ an und der Test erwartet „Welcome back“, sodass kein Durchlauf erfolgreich sein kann.

import { test, expect } from '@playwright/test';

// Fails on its first attempt of every third run, passes otherwise: a simulated flake.
test('flaky: a slow load now and then', async ({ page }, info) => {
    await page.setContent('<h1>Welcome</h1>');
    expect((info.repeatEachIndex + info.retry) % 3, 'simulated slow load').not.toBe(0);
});

// Fails the same way every time: the heading says "Welcome", the test expects "Welcome back".
test('real bug: wrong heading', async ({ page }) => {
    await page.setContent('<h1>Welcome</h1>');
    await expect(page.locator('h1')).toHaveText('Welcome back', { timeout: 300 });
});

Führen Sie es sechsmal mit deaktivierten Wiederholungsversuchen aus:

npx playwright test --retries=0 --repeat-each=6

Playwright endet mit 8 fehlgeschlagenen und 4 bestandenen Tests. Die Anzahl pro Test liefert die Antwort und genau das hat der List-Reporter Zeile für Zeile ausgegeben:

flaky: a slow load now and then    4 passed, 2 failed
real bug: wrong heading            0 passed, 6 failed

Führen Sie es nun einmal mit zwei Wiederholungsversuchen aus:

npx playwright test --retries=2

Playwright endet mit einem Test in jeder Gruppe. Der Flaky-Test schlug beim ersten Versuch fehl und bestand bei Wiederholungsversuch #1. Der eigentliche Fehler schlug bei allen drei Versuchen fehl.

1 failed
  bug-or-flaky.spec.js:10:1 › real bug: wrong heading
1 flaky
  bug-or-flaky.spec.js:4:1 › flaky: a slow load now and then

Bedeutet ein erfolgreicher Wiederholungsversuch, dass die Anwendung in Ordnung ist?

Nein. Ein erfolgreicher Wiederholungsversuch zeigt Ihnen lediglich, dass die Versuche unterschiedliche Ergebnisse lieferten – mehr nicht. Wenn der Durchlauf grün wird und niemand hinsieht, wird ein sporadischer Fehler in der Anwendung, wie etwa eine Race Condition, geteilte Daten oder eine langsame Abhängigkeit, unsichtbar. Und das gehört zu den am teuersten zu findenden Fehlern. Betrachten Sie ein Flaky-Ergebnis als Befund und nicht als Erfolg, den Sie ignorieren können, und nehmen Sie nicht an, dass der Fehler beim Test liegt.

Was macht Nexus Studio mit jedem Ergebnis?

Nexus Studio zeichnet jeden Versuch auf und weist dem Ergebnis ein eigenes Verdict zu, sodass ein Wiederholungsversuch einen Fehler niemals in einen schlichten grünen Durchlauf verwandelt.

FLAKY: Der Test schlug fehl, wurde dann bei einem Wiederholungsversuch bestanden und nichts wurde repariert. Der Exit-Code ist 0, sodass der Build nicht abbricht, und der Bericht sowie History zeigen den Vorbehalt an.
BREACHED: Der Test schlug bei einem einzelnen Versuch fehl, und kein Umgebungs- oder Test-Harness-Muster erklärt den Fehler. Der Exit-Code ist 1.
BREACHED_FLAKY: Der Test schlug bei seinem letzten Versuch nach einem früheren Wiederholungsversuch fehl, und kein Umgebungsmuster erklärt dies. Der Exit-Code ist 1. Vergleichen Sie die Versuche, bevor Sie einen Fehler melden.

History speichert eine Zeile pro Durchlauf jedes Tests, sodass ein Test, der grün, rot und wieder grün wird, als Trend sichtbar wird, anstatt in erneuten Durchläufen unterzugehen. Der Leitfaden für Flaky-Tests listet die Dateien auf, die jedes Verdict hinterlässt.

Wo liegen die Grenzen?

Der Flake im Beispiel wird rechnerisch simuliert, damit er sich wiederholt. Echtes Flaky-Verhalten hat eine Ursache, und diese zu finden, erfordert nach wie vor menschliche Arbeit.
Sechs Durchläufe sind eine schnelle Überprüfung, keine Statistik. Ein Fehler, der einmal in fünfzig Durchläufen auftritt, kann sechsmal erfolgreich sein.
Ein Fehlschlag bei jedem Durchlauf ist nicht immer ein Fehler in Ihrer Anwendung: Ein langsames Netzwerk, eine Sperrseite oder ein abgestürzter Browser führen ebenfalls dazu, dass Tests fehlschlagen. Der Leitfaden für False Failures zeigt, wie Sie dies erkennen können.
Wenn Wiederholungsversuche deaktiviert sind, ist ein zeitweiliger Fehler in Nexus Studio ein BREACHED, da nur ein Wiederholungsversuch FLAKY von einem einfachen Fehler unterscheiden kann. Die Klassifizierung liest den Fehlertext aus; öffnen Sie daher metadata.json, wenn Sie ein Urteil überrascht.

Wo kann ich das sehen?

Der Leitfaden zu den Urteilen erklärt, in welcher Reihenfolge die Engine alle 14 Urteile fällt, und die Evidence-Seite verfolgt einen fehlgeschlagenen Test durch jede Datei, die er hinterlässt. Die 30-Tage-Testversion führt dieselbe Engine für Ihre eigenen Tests aus.