Sukces lub porażka to za mało: jak ustala się 14 werdyktów

Czerwony wynik testu powinien oznaczać, że aplikacja nie działa prawidłowo. Gdy czerwony wynik może też oznaczać chwilowy problem z DNS, wyświetlenie CAPTCHA na stronie albo awarię przeglądarki, zespół uczy się ponawiać nieudane testy zamiast analizować ich wyniki, a rzeczywisty błąd ginie w szumie. Nexus Studio przypisuje każdemu uruchomieniu jeden z 14 werdyktów zamiast dwóch. Na tej stronie wyjaśniamy, jak silnik wybiera werdykt, w jakiej kolejności podejmuje decyzje i jakie ograniczenia ma ta metoda.

Autor: zespół Nexus Studio, Verdict System LLC. 7 października 2026.

Jakie jest 14 werdyktów?

Te 14 werdyktów to SECURE, CHAOS_RESILIENT, AUTO_RECOVER, FLAKY, PERFORMANCE_DEGRADED, A11Y_VIOLATION, SECURITY_VIOLATION, BREACHED, BREACHED_FLAKY, CHAOS_BREACHED, TIMEOUT, UNREACHABLE, BLOCKED i CRASHED. Dzielą się na cztery grupy: test zaliczony, test zaliczony z zastrzeżeniem, awaria aplikacji oraz brak werdyktu dotyczącego aplikacji z powodu problemu ze środowiskiem lub mechanizmem testowym.

Jak silnik ustala werdykt?

Silnik zadaje trzy pytania w następującej kolejności:

1. Czy test w ogóle dał wynik?
2. Jeśli zakończył się powodzeniem, to czy bez zastrzeżeń?
3. Jeśli zakończył się niepowodzeniem, to co zawiniło: mechanizm testowy, środowisko czy aplikacja?

Tylko jedna odpowiedź oznacza zgłoszenie błędu: niepowodzenie spowodowane przez aplikację. Każda inna odpowiedź to informacja o czymś innym i otrzymuje nazwę, która jasno to wskazuje.

Kiedy test w ogóle nie otrzymuje werdyktu?

Trzy stany nie należą do tych 14, ponieważ żaden z nich nic nie mówi o aplikacji: SKIPPED (test nigdy nie został uruchomiony), INTERRUPTED (zatrzymały go Ctrl+C, limit --max-failures lub globalny limit czasu) i CONFIG_ERROR (mechanizm testowy nie mógł go uruchomić). Żaden z nich nie tworzy folderu z materiałem dowodowym ani wiersza w Historii.

INTERRUPTED istnieje z konkretnego powodu. Bez tego stanu zatrzymany test trafiał do gałęzi sukcesu i był zapisywany jako SECURE: zielony werdykt dla testu, który nigdy się nie zakończył.

Jak oceniany jest zaliczony test?

• SECURE: test zakończył się powodzeniem przy pierwszej próbie i niczego nie naprawiono.
• AUTO_RECOVER: test zakończył się powodzeniem, ale mechanizm samonaprawy musiał zastąpić w nim selektor. Lokalizator zapisany przez autora już nie działa, a kolejna zmiana strony doprowadzi do rzeczywistej awarii zestawu testów, dlatego sukces po samonaprawie nigdy nie jest zgłaszany jako wynik bez zastrzeżeń. Popraw pierwotny selektor.
• FLAKY: test zakończył się niepowodzeniem, potem powtórzenie zakończyło się sukcesem, a mechanizm samonaprawy niczego nie zmienił. Coś jest niestabilne, w aplikacji lub w teście, i niczego nie naprawiono.

Jeden wyjątek: gdy pierwsza próba zakończyła się niepowodzeniem wyłącznie z powodu przekroczenia limitu czasu, a powtórzenie zakończyło się sukcesem, werdykt to SECURE. Taki sukces wskazuje na opóźnienie, nie na niestabilność.

Jak przypisywany jest werdykt nieudanemu testowi?

Gdy test kończy się niepowodzeniem, silnik odczytuje komunikat błędu i dziennik sieciowy z danego uruchomienia, a następnie sprawdza je względem grup wzorców w ustalonej kolejności. Pierwsza pasująca grupa rozstrzyga o werdykcie, więc kolejność jest elementem projektu.

1. CONFIG_ERROR jako pierwszy: Cannot find module, ReferenceError lub SyntaxError, brakująca zmienna środowiskowa, błąd przygotowania danych lub zasobów testowych. Jeśli mechanizm testowy w ogóle nie wystartował, każdy późniejszy objaw jest tego konsekwencją. Wzorce są celowo wąskie, ograniczone do błędów, które może wygenerować wyłącznie kod testów lub jego środowisko: jeden nadmiarowy CONFIG_ERROR oznaczałby obarczenie mechanizmu testowego winą za rzeczywisty błąd w aplikacji.
2. CRASHED: Target closed, Page crashed, błąd protokołu DevTools, SessionNotCreatedError, nieprawidłowy identyfikator sesji. Przeglądarka lub sterownik przestały działać. To problem infrastruktury: sprawdź maszynę i sterownik.
3. BLOCKED: kod 403 lub 429 w błędzie albo dzienniku sieciowym, CAPTCHA, strona odmowy dostępu lub rozpoznane przez silnik na ekranie wyzwanie weryfikujące, czy użytkownik nie jest botem. Witryna się obroniła, a żądanie nigdy nie dotarło do Twojego produktu.
4. UNREACHABLE: sieć odmówiła współpracy, zanim zaobserwowano jakąkolwiek stronę: nie udało się rozwiązać nazwy (net::ERR_NAME_NOT_RESOLVED w Chromium, NS_ERROR_UNKNOWN_HOST w Firefox, Could not resolve hostname w WebKit), połączenie zostało odrzucone lub maszyna nie miała dostępu do sieci. Błąd certyfikatu nie należy do tej kategorii: to już wykryty problem.
5. TIMEOUT: Timeout 30000ms exceeded w Playwright, Wait timed out after w Selenium, TimeoutError lub test oznaczony przez Playwright jako zakończony z powodu przekroczenia limitu czasu. Nawigacja, która przekroczyła limit czasu, to TIMEOUT, a nie UNREACHABLE: rozpoczęła się, ale strona działała wolno.
6. BREACHED_FLAKY: żaden z powyższych przypadków tego nie wyjaśnia, a test był już ponawiany. Zakończył się niepowodzeniem, a samo niepowodzenie nie jest spójne między próbami. Porównaj próby, zanim zgłosisz błąd.
7. BREACHED: żaden z powyższych przypadków tego nie wyjaśnia, przy pojedynczej próbie. Asercja nie została spełniona, a żaden wzorzec dotyczący środowiska lub mechanizmu testowego nie wyjaśnia błędu. To jest podstawa zgłoszenia błędu.

Każda grupa obejmuje sformułowania używane zarówno przez Playwright, jak i Selenium WebDriver. Zanim dodano wzorce dla Selenium, zarówno błąd TimeoutError z WebDriver, jak i SessionNotCreatedError z nieaktualnego chromedriver były zgłaszane jako BREACHED, tak jakby aplikacja miała usterkę.

Fizyczny telefon z Androidem, na którym nie można uruchomić testu, bo przeszedł w stan uśpienia lub jest zablokowany, również otrzymuje status BLOCKED: to niespełniony warunek wstępny, a nie awaria produktu. Reguła powstała na podstawie zaobserwowanego przypadku. Telefon przeszedł w stan uśpienia w połowie kampanii, a test logowania, który zakończył się powodzeniem cztery razy z rzędu, otrzymał krytyczny czerwony wynik.

Jak oceniane są przebiegi testów chaosu?

Gdy podczas wykonania wstrzykiwane są usterki z Chaos Lab, werdykt odpowiada na inne pytanie: czy aplikacja wytrzymała? Wynik pozytywny, SECURE lub AUTO_RECOVER, zmienia się w CHAOS_RESILIENT. Każdy inny wynik zmienia się w CHAOS_BREACHED, w tym pozytywny wynik FLAKY i TIMEOUT, ponieważ przy wstrzykniętej usterce to one stanowią jej skutek. SKIPPED, INTERRUPTED i CONFIG_ERROR pozostają bez zmian: test, który się nie wykonał, nic nie mówi o odporności.

Które rygorystyczne kontrole mogą zmienić wynik zaliczonego testu?

Obok asercji wykonywane są trzy kontrole: nagłówków bezpieczeństwa, dostępności za pomocą axe-core oraz limitów wydajności dla Web Vitals i leniwego ładowania. Przy każdym wykonaniu zapisują swoje ustalenia. Zmieniają werdykt tylko wtedy, gdy włączysz dla nich tryb rygorystyczny w Ustawieniach. W istniejącej aplikacji każda z nich mogłaby już pierwszego dnia oznaczyć cały zestaw testów na czerwono, a zestawu, który zawsze jest czerwony, nikt nie przegląda.

W trybie rygorystycznym dotyczą wyłącznie testu zakończonego powodzeniem, w następującej kolejności: SECURITY_VIOLATION, A11Y_VIOLATION, PERFORMANCE_DEGRADED. Bezpieczeństwo jest pierwsze, ponieważ spośród tych trzech obszarów to właśnie ono może prowadzić do incydentu, a nie tylko skargi. Negatywny wynik testu nigdy nie jest eskalowany: BREACHED już wskazuje na coś poważniejszego, a dodatkowe ostrzeżenie przesłoniłoby to ustalenie.

Co widzi CI?

Siedem werdyktów oznaczających powodzenie zwraca kod wyjścia 0: SECURE, AUTO_RECOVER, FLAKY, CHAOS_RESILIENT, PERFORMANCE_DEGRADED, A11Y_VIOLATION i SECURITY_VIOLATION. Zastrzeżenie pojawia się w raporcie i w Historii, a nie jako błąd kompilacji. Pozostałe siedem zwraca kod wyjścia 1. Moduły uruchamiające pytest i Selenium zwracają kod wyjścia 2, gdy wykonanie w ogóle nie mogło się rozpocząć, na przykład z powodu braku Pythona lub użycia przeglądarki, dla której silnik nie ma sterownika.

Jakie są ograniczenia tej metody?

• Klasyfikacja opiera się na treści błędu. Własny komunikat zawierający 403, Forbidden lub Access Denied zostanie odczytany jako BLOCKED, a błąd zawierający is not a function jako CONFIG_ERROR. Formułuj własne komunikaty asercji precyzyjnie i otwórz metadata.json, gdy werdykt Cię zaskoczy.
• TIMEOUT nie jest dowodem, że aplikacja działa. Oznacza, że wykonanie testu nie pozwala tego stwierdzić. Warto przyjrzeć się testowi, który przy każdym wykonaniu przekracza limit czasu.
• To ponowienia odróżniają FLAKY od SECURE, a BREACHED_FLAKY od BREACHED. Gdy ponowienia są wyłączone, sporadyczne niepowodzenie oznacza BREACHED.
• Testy API mają siedem własnych werdyktów, ustalanych według innych reguł: zobacz Testy API.

Gdzie mogę zobaczyć werdykt dotyczący rzeczywistej awarii?

Strona z dowodami przedstawia jeden nieudany test i wymienia wszystkie pliki, które każdy werdykt pozostawia na dysku: report.md, metadata.json, raw-data.json, zrzut ekranu oraz, w przypadku rzeczywistego niepowodzenia, nagranie wideo. 30-dniowa wersja próbna uruchamia ten sam silnik na Twoich własnych testach.