Der Build wird rot, jemand klickt auf „Erneut ausführen“, er wird bestanden und alle machen weiter. Es scheint harmlos, aber unzuverlässige Tests zerstören langsam das Wertvollste, was eine Testsuite hat: das Vertrauen der Menschen in sie. Während es sich bei Fehlern normalerweise um Lärm handelt, werden auch echte Fehler durchgewunken.

In diesem Leitfaden erfahren Sie, warum Tests unregelmäßig werden und wie Sie die einzelnen Ursachen richtig beheben können. Wir haben die Timing- und Shared-State-Demos in Python 3.13 ausgeführt und die angezeigten Zahlen stammen aus diesen Läufen. Dabei handelt es sich um kleine Demonstrationen, die dazu dienen sollen, die Schuppenbildung leicht zu erkennen, sodass Ihre eigenen Ausfallraten unterschiedlich ausfallen.

Was ist ein Flockentest?

Ein Flockentest liefert unterschiedliche Ergebnisse für denselben Code. Es besteht einen Durchlauf und schlägt beim nächsten fehl, obwohl sich am Produkt nichts geändert hat. Möglicherweise liegt ein Fehler im Test vor, oder der Code enthält einen echten zeitweiligen Fehler. Diese zweite Möglichkeit ist genau der Grund, warum Sie sie nicht einfach abtun sollten.

Warum Flockentests so kostspielig sind

• Vertrauen verloren. Sobald Menschen davon ausgehen, dass Rot „wahrscheinlich schuppig“ bedeutet, hören sie auf, echte Fehler zu untersuchen.
• Zeitverschwendung. Entwickler verbringen Stunden damit, Pipelines erneut auszuführen und Fehler zu untersuchen, die nichts mit ihrer Änderung zu tun haben.
• Langsamere Bereitstellung. Zusammenführungen und Veröffentlichungen warten auf Wiederholungen, was den Sinn von CI/CD untergräbt.
• Versteckte Fehler. Race-Bedingungen im Produkt können wie Testgeräusche aussehen, und das sind diejenigen, die in der Produktion schädlich sind.

Häufige Ursachen auf einen Blick

Ursache 1: Timing und feste Schlafzeiten

Dies ist die häufigste Ursache. Bei einem Test wird davon ausgegangen, dass die Hintergrundarbeit nach einer festgelegten Verzögerung abgeschlossen wird. Um den Effekt zu sehen, haben wir einen kleinen Test geschrieben, bei dem die Arbeit bis zu 2 ms dauert, während der Test nur 1 ms wartet, bevor er prüft:

def flaky_timing():
    result = {}
    def work():
        time.sleep(random.uniform(0, 0.002))
        result["done"] = True
    threading.Thread(target=work).start()
    time.sleep(0.001)        # hope it has finished
    assert result.get("done")

Die Lösung besteht darin, auf den tatsächlichen Zustand zu warten, mit einer großzügigen Obergrenze:

def fixed_timing():
    result = threading.Event()
    def work():
        time.sleep(random.uniform(0, 0.002))
        result.set()
    threading.Thread(target=work).start()
    assert result.wait(timeout=1)   # continues as soon as it is ready

Wir haben jede Version 200 Mal ausgeführt:

Das Ergebnis ist mehr als nur Zuverlässigkeit. Die feste Version bewegt sich weiter, sobald die Arbeit erledigt ist, daher ist sie normalerweise auch schneller. Ein längerer Ruhezustand würde dazu führen, dass die erste Version seltener fehlschlägt, aber jede Ausführung wäre dann langsamer und könnte auf einem ausgelasteten CI-Rechner immer noch fehlschlagen.

Bei Browsertests gilt das gleiche Prinzip. Verwenden Sie das automatische Warten von Playwright oder explizite Selenium-Wartezeiten anstelle von time.sleep:

# Playwright: retries until true or a timeout is reached
expect(page.get_by_text("Order placed")).to_be_visible()

# Selenium: an explicit wait for a condition
WebDriverWait(driver, 10).until(
    EC.visibility_of_element_located((By.ID, "confirmation"))
)

Ursache 2: Gemeinsamer Status und Testreihenfolge

Wenn Tests Daten gemeinsam nutzen, kann sich einer auf einen anderen auswirken, und das Ergebnis hängt von der Reihenfolge ab, in der sie ausgeführt werden. Diese beiden Tests verwenden eine gemeinsame Liste:

store = []

def test_add():
    store.append("x")
    assert len(store) == 1

def test_empty():
    assert store == []

Unser Lauf hat dies bestätigt, und das ist der Grund, warum eine Suite Monate dauern und dann abbrechen kann, wenn jemand parallele Läufe oder ein Plugin für zufällige Reihenfolge hinzufügt. Das Heilmittel ist Isolation:

• Geben Sie jedem Test neue Daten, indem Sie eine Vorrichtung verwenden, die ihn einrichtet und bereinigt. Unser Pytest-Tutorial zeigt, wie.
• Erstellen Sie anstelle eines gemeinsamen „Testbenutzers“ eindeutige Datensätze, z. B. eine E-Mail mit einem zufälligen Suffix.
• Binden Sie Datenbanktests in eine Transaktion ein und führen Sie einen Rollback durch, wenn Ihr Setup dies zulässt.
• Führen Sie regelmäßig Tests in zufälliger Reihenfolge durch, damit diese Probleme frühzeitig auftauchen.

Ursache 3: Daten, Zeitzonen und Zufälligkeit

Ein Test, der die ganze Woche über bestanden wird, kann an einem Samstag, um Mitternacht oder am letzten Tag des Monats fehlschlagen. Machen Sie Zeit zu einer Eingabe, anstatt die Uhr in Ihrer Logik abzulesen:

def is_weekend(today=None):
    today = today or datetime.date.today()
    return today.weekday() >= 5

is_weekend(datetime.date(2026, 11, 7))   # True  (a Saturday)
is_weekend(datetime.date(2026, 11, 9))   # False (a Monday)

Diese Tests liefern an jedem Tag das gleiche Ergebnis. Legen Sie in Tests ebenfalls einen festen Startwert für Zufallswerte fest und protokollieren Sie ihn, wenn Sie Zufallsdaten verwenden, damit Sie einen Fehler reproduzieren können. Gehen Sie nicht von einer bestimmten Reihenfolge aus Mengen, Wörterbüchern aus externen Quellen oder Datenbankabfragen ohne ORDER BY aus.

Ursache 4: Spröde Selektoren

Ein Test, der eine Schaltfläche mit div:nth-child(3) > span findet, bricht bei jeder Layout-Optimierung ab und schlägt möglicherweise nur bei einigen Bildschirmgrößen oder -varianten fehl. Bevorzugen Sie Locators basierend auf dem, was Benutzer sehen, oder dedizierte Testattribute. Unser Leitfaden zu Playwright-Locators erklärt die Reihenfolge, in der man sie ausprobiert. Animationen sind eine weitere häufige Problemquelle, daher sollten Sie erwägen, sie in Testumgebungen zu deaktivieren.

Ursache 5: Externe Dienste und Netzwerke

Wenn ein Test einen echten Zahlungsanbieter oder eine Drittanbieter-API aufruft, hängt das Ergebnis von der Betriebszeit und den Ratenlimits einer anderen Person ab. Machen Sie diese Aufrufe für die meisten Tests simulieren und führen Sie eine kleine Anzahl separater Vertragsprüfungen gegenüber dem tatsächlichen Dienst durch, damit Sie immer noch erfahren, ob sich dieser ändert. Unser Leitfaden zu Einheits- und Integrationstests erklärt, wie man diese aufteilt.

So diagnostizieren Sie einen schuppigen Test

1. Bestätigen Sie es. Führen Sie den Test viele Male ohne Änderungen durch. Mit Pytest funktioniert eine einfache Shell-Schleife, und ein Plugin wie pytest-repeat liefert Ihnen --count=100.
2. Zeichnen Sie Beweise auf. Speichern Sie Protokolle, Screenshots und Spuren für jeden Fehler. Der Trace Viewer von Playwright ist hier besonders nützlich.
3. Betonen Sie die Bedingungen. Führen Sie es mit begrenzter CPU parallel oder in zufälliger Reihenfolge aus. Wenn man es häufiger scheitert, wird das Lernen einfacher.
4. Testen Sie es alleine. Wenn es immer alleine funktioniert, aber in der Suite fehlschlägt, vermuten Sie den gemeinsamen Status.
5. Suchen Sie nach Mustern. Überprüfen Sie, welche Maschinen, Tageszeiten und benachbarten Tests beteiligt sind.
6. Überprüfen Sie das Produkt. Fragen Sie ehrlich, ob dies eine echte Rennbedingung in Ihrer Anwendung sein könnte.

Sind automatische Wiederholungsversuche eine Lösung?

Wiederholungsversuche sind ein nützliches kurzfristiges Sicherheitsnetz, aber kein Heilmittel. Ein einziger automatischer Wiederholungsversuch in CI kann die Arbeit während der Untersuchung am Laufen halten, aber ein Test, der zum Bestehen eines Tests einen Wiederholungsversuch erfordert, sagt Ihnen trotzdem etwas. Schlimmer noch: Ein tatsächlich auftretender Produktfehler, der in 20 % der Fälle fehlschlägt, bleibt bei einem erneuten Versuch normalerweise unbemerkt.

Verwenden Sie Wiederholungsversuche mit diesen Regeln: Beschränken Sie sie auf ein oder zwei, zeichnen Sie jeden Test auf, bei dem einer erforderlich war, und behandeln Sie diese Liste als Ihre To-Do-Liste. Ein als „bestanden bei Wiederholung“ gemeldeter Test sollte als zu untersuchendes Problem und nicht als Erfolg gewertet werden.

Ein Teamprozess für flockige Tests

1. Messen. Verfolgen Sie, welche Tests fehlschlagen, und geben Sie dann denselben Commit weiter. Viele CI-Tools und Testreporter können dies zeigen.
2. Quarantäne. Verschieben Sie einen bestätigten Flaky-Test aus dem Blockierungslauf, damit er nicht mehr alle stört, aber führen Sie ihn weiterhin aus und verfolgen Sie ihn.
3. Weisen Sie einen Eigentümer und eine Frist zu. Eine Quarantäne ohne Frist wird einfach zu einem Friedhof.
4. Reparieren oder löschen. Wenn es sich nicht lohnt, einen Test zu reparieren, entfernen Sie ihn und prüfen Sie, ob seine Abdeckung an anderer Stelle noch vorhanden ist.
5. Vorbeugen. Führen Sie neue Tests mehrmals durch, bevor Sie sie zusammenführen. Ein Test, der einmal in fünfzig Durchgängen fehlschlägt, ist jetzt besser zu erkennen als in sechs Monaten.

Behandeln Sie einen flockigen Test als Fehler mit Priorität und nicht als Hintergrundgeräusch. Auch hier gelten Schweregrad und Priorität, wie unter Schweregrad vs. Priorität beschrieben. Wenn Unzulänglichkeiten weit verbreitet sind, informieren Sie sich über umfassendere Testautomatisierungsfehler und überlegen Sie, ob Sie zu viele Tests auf Browserebene haben.

Fazit

Flockige Tests wirken zufällig, sind es aber selten. Fast jeder kommt auf eine Annahme über Zeit, Reihenfolge, Daten oder Umgebung zurück, die nicht immer wahr ist. Wählen Sie den Test aus, der diese Woche in Ihrer Pipeline am häufigsten fehlschlägt. Führen Sie es fünfzig Mal aus, finden Sie die Annahme und korrigieren Sie sie endgültig. Ein echter Fix bringt einem Team mehr bei als hundert Wiederholungen.

Häufige Fragen

Lerne weiter