Warum schlagen meine Tests fehl, wenn die Anwendung in Ordnung ist?

Ein End-to-End-Test wird rot, wenn das Netzwerk langsam ist, das DNS ausfällt, die Website mit einem 403 oder einem 429 antwortet oder eine Bot-Challenge anzeigt, oder der Browser abstürzt – und nichts davon ist ein Fehler in Ihrer Anwendung. Nexus Studio von Verdict System LLC gibt diesen Fehlschlägen eigene Verdicts: TIMEOUT, UNREACHABLE, BLOCKED und CRASHED. Keines davon wird als Bug in der Anwendung gemeldet.

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

Was lässt einen Test ohne Bug fehlschlagen?

Ein Test meldet nur, dass etwas nicht stattgefunden hat. Die Ursache kann an vier Stellen liegen, die nichts mit Ihrem Code zu tun haben:

• Die Seite war langsam und dem Test ging die Zeit aus;
• der Host konnte nicht erreicht werden, beispielsweise weil der Name nicht aufgelöst werden konnte;
• die Website hat sich mit einem 403, einem 429, einem CAPTCHA oder einer Bot-Challenge verteidigt, sodass die Anfrage Ihr Produkt nie erreicht hat;
• der Browser oder der Prozess ist abgestürzt.

Wenn jedes dieser Ergebnisse einfach nur rot angezeigt wird, stuft das Team sie als Bugs ein oder gewöhnt sich daran, fehlgeschlagene Tests einfach erneut auszuführen, anstatt sie zu analysieren. In beiden Fällen geht der eigentliche Fehler im Rauschen unter.

Wie unterscheidet Nexus Studio einen Fehlalarm von einem echten Bug?

Wenn ein Test fehlschlägt, liest die Engine die Fehlermeldung sowie das Netzwerkprotokoll des Durchlaufs aus und gleicht sie in einer festen Reihenfolge mit Gruppen von Mustern ab. Die erste Gruppe, die übereinstimmt, bestimmt das Ergebnis (Verdict). Die Reihenfolge lautet: CONFIG_ERROR, danach CRASHED, BLOCKED, UNREACHABLE und TIMEOUT, und erst danach BREACHED_FLAKY oder BREACHED. Das Ergebnis BREACHED, das für einen Bug-Report steht, bleibt somit Fehlern vorbehalten, die sich durch kein Umgebungs- oder Test-Harness-Muster erklären lassen. Die Muster decken die Formulierungen von Playwright und Selenium WebDriver ab.

Was bedeuten TIMEOUT, UNREACHABLE, BLOCKED und CRASHED?

• TIMEOUT: Der Test hat nicht rechtzeitig eine Antwort erhalten. Das ist weder ein Beweis dafür, dass die Anwendung fehlerhaft ist, noch dafür, dass sie funktioniert: Der Durchlauf kann es nicht feststellen. Eine Navigation, bei der die Zeit abgelaufen ist, ist ein TIMEOUT, da sie gestartet wurde und die Seite zu langsam war.
• UNREACHABLE: Der Host konnte überhaupt nicht erreicht werden. DNS oder die Verbindung schlug fehl, bevor irgendeine Seite geladen werden konnte – wie bei einem Namen, der nicht aufgelöst werden konnte, einer verweigerten Verbindung oder einem Offline-Rechner. Ein Zertifikatsfehler gehört nicht hierher: Das ist ein Befund (Finding).
• BLOCKED: Die Website hat die Anfrage abgewehrt – durch einen 403, einen 429, eine Sperrseite oder eine Bot-Challenge. Wenn eine solche Abwehrmaßnahme auf dem Bildschirm sichtbar war, wird sie in metadata.json benannt. Ein echtes Android-Smartphone, das in den Ruhezustand gewechselt ist oder gesperrt ist, gilt ebenfalls als BLOCKED, da eine Grundvoraussetzung nicht erfüllt ist.
• CRASHED: Der Browser oder der Prozess ist abgestürzt, beispielsweise durch eine geschlossene Seite, einen DevTools-Protokollfehler oder eine beendete WebDriver-Sitzung. Dies betrifft die Infrastruktur: Überprüfen Sie den Rechner und den Treiber.

Der Leitfaden zu den Ergebnissen führt die genauen Fehlermuster für jeden Fall auf.

Was sieht meine CI-Pipeline?

Sieben der 14 Ergebnisse enden mit dem Exit-Code 0: SECURE, AUTO_RECOVER, FLAKY, CHAOS_RESILIENT, PERFORMANCE_DEGRADED, A11Y_VIOLATION und SECURITY_VIOLATION. Die anderen sieben enden mit Exit-Code 1, darunter TIMEOUT, UNREACHABLE, BLOCKED und CRASHED. Der Build wird also weiterhin rot, da der Test nicht bestanden wurde, aber der Report und der Verlauf zeigen die genaue Ursache an. Die Runner für pytest und Selenium enden mit Exit-Code 2, wenn der Durchlauf überhaupt nicht gestartet werden konnte.

Welche Belege werden bei einem Fehlalarm gespeichert?

Jeder der vier Fälle speichert report.md, metadata.json, raw-data.json und einen Screenshot des letzten Frames. Bei Videoaufzeichnungen gibt es Unterschiede:

• TIMEOUT und BLOCKED: Die Videoaufzeichnung ist standardmäßig deaktiviert. Sie können sie in den Einstellungen unter „Keep failure video for“ aktivieren.
• UNREACHABLE: Es wird kein Video angeboten, da keine Seite geladen wurde und die Aufnahme leer wäre.
• CRASHED: Es wird kein Video angeboten, da die Aufnahme eines abgestürzten Browsers fehlerhaft ist.

Nur Playwright-Web- und emulierte mobile Testläufe zeichnen Videos auf. Ein echtes Android-Smartphone, ein Selenium-Lauf und ein API-Test tun dies nicht.

Wenn Jira aktiviert ist, erstellt ein TIMEOUT ein Ticket; eine Blockierung, ein Absturz und eine nicht erreichbare Website tun dies nie.

Wo liegen die Grenzen?

• Die Klassifizierung liest den Fehlertext aus. Eine von Ihnen selbst verfasste Nachricht, die 403, Forbidden oder Access Denied enthält, wird als BLOCKED interpretiert. Halten Sie benutzerdefinierte Assertion-Nachrichten spezifisch und öffnen Sie metadata.json, wenn Sie ein Urteil überrascht.
• Ein TIMEOUT ist kein Beweis dafür, dass die Anwendung funktioniert. Ein Test, der bei jedem Durchlauf in ein Timeout läuft, sollte überprüft werden.
• Ein längeres Timeout verbirgt kein fehlerhaftes Element: Es schlägt lediglich später fehl.
• Diese Urteile benennen die Ursache eines fehlgeschlagenen Durchlaufs. Sie beseitigen die Ursache nicht: Eine blockierte Website bleibt blockiert, bis Sie die Art und Weise ändern, wie Sie darauf zugreifen.

Wo kann ich das sehen?

Die Evidence-Seite begleitet einen fehlgeschlagenen Test und listet jede Datei auf, die jedes Urteil auf Ihrer Festplatte hinterlässt. Die Urteilsübersicht erklärt, in welcher Reihenfolge die Engine alle 14 entscheidet. Die 30-Tage-Testversion führt dieselbe Engine für Ihre eigenen Tests aus.