Bestanden oder nicht bestanden reicht nicht aus: Wie 14 Urteile entschieden werden

Ein roter Test sollte bedeuten, dass die Anwendung defekt ist. Wenn Rot auch bedeuten kann, dass das DNS kurz ausgesetzt hat, die Website ein CAPTCHA angezeigt hat oder der Browser abgestürzt ist, gewöhnt sich das Team daran, rote Tests einfach erneut auszuführen, anstatt sie zu analysieren – und der eigentliche Fehler geht im Rauschen unter. Nexus Studio weist jedem Durchlauf eines von 14 Urteilen anstelle von zwei zu. Diese Seite erklärt, wie die Engine eines davon auswählt, in welcher Reihenfolge sie entscheidet und wo die Methode an ihre Grenzen stößt.

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

Was sind die 14 Urteile?

Die 14 Urteile lauten SECURE, CHAOS_RESILIENT, AUTO_RECOVER, FLAKY, PERFORMANCE_DEGRADED, A11Y_VIOLATION, SECURITY_VIOLATION, BREACHED, BREACHED_FLAKY, CHAOS_BREACHED, TIMEOUT, UNREACHABLE, BLOCKED und CRASHED. Sie lassen sich in vier Gruppen einteilen: bestanden, bestanden mit Vorbehalt, die Anwendung ist fehlgeschlagen und kein Urteil über die Anwendung möglich, da die Umgebung oder die Testumgebung fehlerhaft ist.

Wie ermittelt die Engine ein Urteil?

Die Engine stellt drei Fragen in dieser Reihenfolge:

1. Hat der Test überhaupt ein Ergebnis geliefert?
2. Wenn er bestanden wurde, verlief er fehlerfrei?
3. Wenn er fehlgeschlagen ist, wer trägt die Schuld: das Test-Harness, die Umgebung oder die Anwendung?

Nur eine einzige Antwort ist ein echter Fehlerbericht: ein Fehlschlag, der auf die Anwendung zurückzuführen ist. Jede andere Antwort liefert Informationen über etwas anderes und erhält eine entsprechende Bezeichnung.

Wann erhält ein Test überhaupt kein Verdict?

Drei Zustände gehören nicht zu den 14, da keiner von ihnen etwas über Ihre Anwendung aussagt: SKIPPED (der Test wurde nie ausgeführt), INTERRUPTED (Strg+C, ein --max-failures-Abbruch oder ein globales Timeout haben ihn gestoppt) und CONFIG_ERROR (das Test-Harness konnte ihn nicht starten). Keiner von ihnen legt einen Nachweisordner oder eine History-Zeile an.

INTERRUPTED existiert aus einem konkreten Grund. Ohne diesen Zustand landete ein abgebrochener Test im Erfolgszweig und wurde als SECURE erfasst: ein grünes Urteil für einen Test, der nie beendet wurde.

Wie wird ein erfolgreicher Test (Pass) bewertet?

• SECURE: Beim ersten Versuch bestanden, und es musste nichts repariert werden.
• AUTO_RECOVER: Bestanden, aber die Selbstreparatur musste in diesem Test einen Selektor ersetzen. Der vom Autor verfasste Locator funktioniert nicht mehr, und die nächste Änderung an der Seite führt unweigerlich zum Scheitern der Testsuite. Daher wird ein reparierter Testdurchlauf niemals als fehlerfrei gemeldet. Beheben Sie den ursprünglichen Selektor.
• FLAKY: Fehlgeschlagen, ein Wiederholungsversuch war jedoch erfolgreich und es wurde nichts repariert. Etwas ist instabil – sei es in der Anwendung oder im Test –, und das Problem wurde nicht behoben.

Eine Ausnahme: Wenn der erste Versuch nur aufgrund einer Zeitüberschreitung fehlgeschlagen ist und der erneute Versuch erfolgreich war, lautet das Urteil SECURE. Dieser erfolgreiche Durchlauf weist auf Latenz hin, nicht auf Instabilität.

Wie wird einem Fehlschlag ein Verdict zugewiesen?

Wenn ein Test fehlschlägt, liest die Engine die Fehlermeldung sowie das Netzwerkprotokoll des Durchlaufs und gleicht sie in einer festen Reihenfolge mit Mustergruppen ab. Die erste übereinstimmende Gruppe bestimmt das Urteil; die Reihenfolge ist somit Teil des Designs.

1. Zuerst CONFIG_ERROR: Cannot find module, ein ReferenceError oder SyntaxError, eine fehlende Umgebungsvariable, eine Fixture, die beim Setup fehlgeschlagen ist. Wenn das Test-Harness gar nicht erst gestartet ist, ist jedes spätere Symptom eine Folge davon. Die Muster sind bewusst eng gefasst und auf Fehler beschränkt, die nur der Testcode oder dessen Umgebung erzeugen kann: Ein CONFIG_ERROR zu viel würde das Test-Harness für einen echten Fehler in Ihrer Anwendung verantwortlich machen.
2. CRASHED: Target closed, Page crashed, ein DevTools-Protokollfehler, SessionNotCreatedError, eine ungültige Sitzungs-ID. Der Browser oder der Treiber ist abgestürzt. Es handelt sich um die Infrastruktur: Überprüfen Sie den Rechner und den Treiber.
3. BLOCKED: Ein 403- oder 429-Fehler im Fehlerbericht oder im Netzwerkprotokoll, ein CAPTCHA, eine Seite mit verweigertem Zugriff oder eine Bot-Challenge, die die Engine auf dem Bildschirm erkannt hat. Die Website hat sich selbst verteidigt, und die Anfrage hat Ihr Produkt nie erreicht.
4. UNREACHABLE: Das Netzwerk hat abgelehnt, bevor irgendeine Seite geladen werden konnte: Der Name wurde nicht aufgelöst (net::ERR_NAME_NOT_RESOLVED in Chromium, NS_ERROR_UNKNOWN_HOST in Firefox, Could not resolve hostname in WebKit), die Verbindung wurde verweigert oder der Rechner war offline. Ein Zertifikatsfehler gehört nicht hierher: Dabei handelt es sich um einen Befund.
5. TIMEOUT: Playwrights Timeout 30000ms exceeded, Seleniums Wait timed out after, ein TimeoutError oder ein von Playwright als abgelaufen markierter Test. Eine Navigation, die das Zeitlimit überschritten hat, ist ein TIMEOUT, nicht UNREACHABLE: Sie wurde gestartet, aber die Seite war zu langsam.
6. BREACHED_FLAKY: Nichts von alledem erklärt das Problem, und der Test wurde bereits wiederholt. Er ist fehlgeschlagen, und der Fehler selbst ist inkonsistent. Vergleichen Sie die Versuche, bevor Sie einen Fehler melden.
7. BREACHED: Nichts von alledem erklärt das Problem bei einem einzelnen Versuch. Eine Assertion ist fehlgeschlagen, und kein Umgebungs- oder Test-Harness-Muster erklärt den Fehler. Dies ist der Fehlerbericht.

Jede Gruppe deckt sowohl die Formulierungen von Playwright als auch die von Selenium WebDriver ab. Bevor die Selenium-Muster existierten, wurden sowohl ein WebDriver-TimeoutError als auch ein SessionNotCreatedError eines veralteten chromedrivers als BREACHED gemeldet – so, als ob die Anwendung einen Defekt hätte.

Ein echtes Android-Telefon, das den Durchlauf nicht ausführen kann, weil es in den Ruhezustand gewechselt ist oder gesperrt ist, wird ebenfalls als BLOCKED eingestuft: eine nicht erfüllte Voraussetzung, kein Produktfehler. Die Regel entstand aus einem gemessenen Fall. Ein Telefon ging mitten in einer Testkampagne in den Ruhezustand, und ein Login-Test, der zuvor viermal hintereinander erfolgreich war, wurde plötzlich als kritisch rot markiert.

Wie werden Chaos-Läufe beurteilt?

Wenn der Durchlauf Fehler aus dem Chaos Lab einschleust, beantwortet das Urteil eine andere Frage: Hat die Anwendung standgehalten? Ein bestandener Test, SECURE oder AUTO_RECOVER, wird zu CHAOS_RESILIENT. Alles andere wird zu CHAOS_BREACHED, einschließlich eines FLAKY-Durchlaufs und eines TIMEOUTs, da dies unter einem eingeschleusten Fehler die tatsächlichen Auswirkungen sind. SKIPPED, INTERRUPTED und CONFIG_ERROR bleiben unverändert: Ein Test, der nicht ausgeführt wurde, sagt nichts über die Resilienz aus.

Welche strengen Prüfungen können einen Pass ändern?

Neben Ihren Assertions laufen drei Prüfungen: Sicherheits-Header, Barrierefreiheit mit axe-core und Performance-Budgets für Web Vitals und Lazy Loading. Sie erfassen bei jedem Durchlauf ihre Ergebnisse. Sie ändern das Urteil nur dann, wenn Sie sie in den Einstellungen auf strikt setzen. Bei einer bestehenden Anwendung würde jede dieser Prüfungen die gesamte Testsuite am ersten Tag rot färben – und eine Testsuite, die immer rot ist, liest niemand mehr.

Wenn sie strikt eingestellt sind, gelten sie nur für einen bestandenen Test, und zwar in dieser Reihenfolge: SECURITY_VIOLATION, A11Y_VIOLATION, PERFORMANCE_DEGRADED. Sicherheit steht an erster Stelle, weil sie von den dreien zu einem Sicherheitsvorfall statt nur zu einer Beschwerde führen kann. Ein fehlgeschlagener Test wird niemals eskaliert: BREACHED drückt bereits etwas Schwerwiegenderes aus, und ein zusätzlicher Hinweis würde den eigentlichen Befund nur verschleiern.

Was sieht CI?

Die sieben bestandenen Urteile enden mit Exit-Code 0: SECURE, AUTO_RECOVER, FLAKY, CHAOS_RESILIENT, PERFORMANCE_DEGRADED, A11Y_VIOLATION und SECURITY_VIOLATION. Ein Vorbehalt wird im Bericht und im Verlauf angezeigt, nicht als fehlerhafter Build. Die anderen sieben enden mit Exit-Code 1. Die pytest- und Selenium-Runner enden mit Exit-Code 2, wenn der Durchlauf überhaupt nicht gestartet werden konnte, beispielsweise ohne Python oder mit einem Browser, für den die Engine keinen Treiber hat.

Wo liegen die Grenzen der Methode?

• Die Klassifizierung liest Fehlertexte aus. Eine selbst verfasste Nachricht, die 403, Forbidden oder Access Denied enthält, wird als BLOCKED interpretiert, und ein Fehler, der is not a function enthält, als CONFIG_ERROR. Halten Sie benutzerdefinierte Assertionsmeldungen spezifisch und öffnen Sie metadata.json, wenn Sie von einem Urteil überrascht werden.
• Ein TIMEOUT ist kein Beweis dafür, dass die Anwendung funktioniert. Es bedeutet, dass der Durchlauf keine Aussage treffen kann. Ein Test, bei dem es bei jedem Durchlauf zu einem Timeout kommt, sollte genauer untersucht werden.
• Wiederholungsversuche (Retries) unterscheiden FLAKY von SECURE und BREACHED_FLAKY von BREACHED. Wenn Wiederholungsversuche deaktiviert sind, gilt ein sporadischer Fehler als BREACHED.
• API-Tests haben sieben eigene Urteile, die nach anderen Regeln festgelegt werden: siehe API-Tests.

Wo kann ich ein Verdict zu einem echten Fehlschlag sehen?

Die Evidence-Seite verfolgt einen fehlgeschlagenen Test und listet jede Datei auf, die jedes Urteil auf Ihrer Festplatte hinterlässt: report.md, metadata.json, raw-data.json, einen Screenshot und, bei einem echten Fehler, das Video. Die 30-Tage-Testversion führt dieselbe Engine mit Ihren eigenen Tests aus.