Dlaczego moje testy kończą się niepowodzeniem, skoro aplikacja działa poprawnie?

Test end-to-end kończy się niepowodzeniem, gdy sieć działa wolno, zawodzi DNS, witryna odpowiada kodem 403 lub 429 albo żąda weryfikacji, czy użytkownik nie jest botem, lub gdy przeglądarka ulega awarii. Żadna z tych sytuacji nie jest defektem aplikacji. Nexus Studio firmy Verdict System LLC przypisuje takim niepowodzeniom osobne werdykty: TIMEOUT, UNREACHABLE, BLOCKED i CRASHED. Żadne z nich nie jest zgłaszane jako błąd aplikacji.

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

Co powoduje niepowodzenie testu, gdy nie ma błędu?

Test informuje tylko, że coś się nie wydarzyło. Przyczyna może leżeć w jednym z czterech obszarów niezwiązanych z Twoim kodem:

• strona działała wolno i test przekroczył limit czasu;
• nie udało się połączyć z hostem, na przykład dlatego, że nie udało się rozpoznać jego nazwy;
• witryna uruchomiła zabezpieczenia: kod 403, kod 429, CAPTCHA lub weryfikację, czy użytkownik nie jest botem, więc żądanie nigdy nie dotarło do Twojego produktu;
• przeglądarka lub proces uległy awarii.

Gdy każda z tych sytuacji jest oznaczana po prostu na czerwono, zespół zgłasza je jako błędy albo przyzwyczaja się do ponawiania nieudanych testów zamiast analizowania ich wyników. W obu przypadkach prawdziwy defekt ginie w szumie.

Jak Nexus Studio odróżnia pozorne niepowodzenie od błędu?

Gdy test kończy się niepowodzeniem, silnik odczytuje komunikat o błędzie i dziennik sieciowy z przebiegu testu, a następnie porównuje je z grupami wzorców w ustalonej kolejności. Pierwsza pasująca grupa wyznacza werdykt. Kolejność to CONFIG_ERROR, następnie CRASHED, BLOCKED, UNREACHABLE i TIMEOUT, a dopiero potem BREACHED_FLAKY lub BREACHED. Werdykt BREACHED, oznaczający zgłoszenie błędu, jest więc zarezerwowany dla niepowodzeń, których nie wyjaśnia żaden wzorzec związany ze środowiskiem lub mechanizmem uruchamiania testów. Wzorce obejmują sformułowania używane zarówno przez Playwright, jak i Selenium WebDriver.

Co oznaczają TIMEOUT, UNREACHABLE, BLOCKED i CRASHED?

• TIMEOUT: test nie otrzymał odpowiedzi w wyznaczonym czasie. Nie dowodzi to ani tego, że aplikacja jest niesprawna, ani tego, że działa: ten przebieg testu nie pozwala tego ustalić. Nawigacja, która przekroczyła limit czasu, otrzymuje werdykt TIMEOUT, ponieważ się rozpoczęła, ale strona działała wolno.
• UNREACHABLE: w ogóle nie udało się połączyć z hostem. DNS lub połączenie zawiodły, zanim udało się zaobserwować jakąkolwiek stronę, na przykład z powodu nierozpoznanej nazwy, odmowy połączenia lub komputera bez dostępu do sieci. Błąd certyfikatu nie należy do tej kategorii: jest wykrytą nieprawidłowością.
• BLOCKED: witryna uruchomiła zabezpieczenia: kod 403, kod 429, stronę blokady lub weryfikację, czy użytkownik nie jest botem. Jeśli zabezpieczenie było widoczne na ekranie, plik metadata.json podaje jego nazwę. Fizyczny telefon z Androidem, który przeszedł w stan uśpienia lub jest zablokowany, również otrzymuje werdykt BLOCKED z powodu niespełnionego warunku wstępnego.
• CRASHED: przeglądarka lub proces uległy awarii, na przykład zamknięto stronę, wystąpił błąd protokołu DevTools lub sesja WebDriver przestała działać. To problem infrastruktury: sprawdź komputer i sterownik.

Przewodnik po werdyktach zawiera dokładne wzorce błędów odpowiadające każdemu z nich.

Co widzi mój potok CI?

Siedem z 14 werdyktów zwraca kod wyjścia 0: SECURE, AUTO_RECOVER, FLAKY, CHAOS_RESILIENT, PERFORMANCE_DEGRADED, A11Y_VIOLATION i SECURITY_VIOLATION. Pozostałe siedem zwraca kod wyjścia 1, w tym TIMEOUT, UNREACHABLE, BLOCKED i CRASHED. Kompilacja jest więc nadal oznaczona na czerwono, ponieważ test nie zakończył się powodzeniem, ale raport i Historia wskazują przyczynę. Moduły uruchamiające testy pytest i Selenium zwracają kod wyjścia 2, gdy w ogóle nie udało się rozpocząć przebiegu testu.

Jakie materiały dowodowe są zachowywane przy każdym pozornym niepowodzeniu?

W każdym z czterech przypadków zachowywane są pliki report.md, metadata.json, raw-data.json oraz zrzut ekranu ostatniej klatki. Zasady dotyczące nagrań wideo są różne:

• TIMEOUT i BLOCKED: nagrywanie wideo jest domyślnie wyłączone. Włącz je w Ustawieniach, w sekcji Zachowuj nagrania niepowodzeń dla.
• UNREACHABLE: nagranie wideo nie jest dostępne, ponieważ żadna strona się nie załadowała i nagranie byłoby puste.
• CRASHED: nagranie wideo nie jest dostępne, ponieważ nagranie z przeglądarki, która uległa awarii, jest uszkodzone.

Wideo jest nagrywane tylko podczas testów Playwright w przeglądarce i w emulowanym środowisku mobilnym. Testy na fizycznym telefonie z Androidem, testy Selenium i testy API nie są nagrywane.

Przy włączonej integracji z Jira werdykt TIMEOUT powoduje utworzenie zgłoszenia, natomiast blokada, awaria i niedostępność witryny nigdy go nie tworzą.

Jakie są ograniczenia?

• Klasyfikacja opiera się na treści błędu. Własny komunikat zawierający 403, Forbidden lub Access Denied zostanie zinterpretowany jako BLOCKED. Formułuj własne komunikaty asercji precyzyjnie i otwórz plik metadata.json, gdy werdykt Cię zaskoczy.
• Werdykt TIMEOUT nie dowodzi, że aplikacja działa. Testowi, który przekracza limit czasu przy każdym uruchomieniu, warto się przyjrzeć.
• Dłuższy limit czasu nie ukrywa niesprawnego elementu: niepowodzenie następuje później.
• Te werdykty wskazują przyczynę nieudanego uruchomienia. Nie usuwają jej: zablokowana witryna pozostaje zablokowana, dopóki nie zmienisz sposobu uzyskiwania do niej dostępu.

Gdzie mogę to zobaczyć?

Strona z dowodami przedstawia przebieg jednego nieudanego testu i wymienia wszystkie pliki, które każdy werdykt pozostawia na dysku. Przewodnik po werdyktach wyjaśnia, w jakiej kolejności silnik rozstrzyga o wszystkich 14 werdyktach. 30-dniowa wersja próbna uruchamia ten sam silnik na Twoich własnych testach.