Czy ten test jest niestabilny, czy to rzeczywisty błąd?

Niestabilny test zakończył się niepowodzeniem, a następnie przeszedł przy ponowieniu, choć nikt niczego nie naprawił. Rzeczywisty błąd powoduje niepowodzenie z przyczyny, której żadne ponowienie nie zmieni. Nexus Studio firmy Verdict System LLC rozróżnia te przypadki, rejestrując każde ponowienie: FLAKY oznacza niepowodzenie, po którym ponowienie zakończyło się powodzeniem, BREACHED oznacza rzeczywiście wykryty problem, a BREACHED_FLAKY — niepowodzenie, które samo jest niespójne. Ponowienie nigdy nie zamienia usterki w zielony wynik.

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

Czym jest niestabilny test?

Niestabilny test to taki, którego próby dają różne wyniki: raz kończy się niepowodzeniem, a przy kolejnej próbie przechodzi, mimo że kod i test pozostają bez zmian. W Nexus Studio to określenie ma jedno znaczenie. FLAKY to test, który zakończył się niepowodzeniem, a następnie przeszedł przy ponowieniu, bez żadnej automatycznej naprawy. Coś jest niestabilne — w aplikacji lub w teście — i niczego nie naprawiono.

Trwałe niepowodzenie występujące przy każdej próbie nie oznacza niestabilności, nawet jeśli mechanizm automatycznej naprawy próbował naprawić selektor i mu się to nie udało. Wcześniejsza wersja silnika klasyfikowała taki przypadek jako FLAKY. Zespoły odczytują FLAKY jako "test jest wadliwy" i przechodzą dalej, więc błędna aplikacja trafiała do użytkowników, bo sygnał uznano za szum. Silnik już tak nie robi.

Czy ponowienia ukrywają rzeczywiste błędy?

Mogą, a przyczyną jest liczba stanów. Gdy dostępne są tylko powodzenie i niepowodzenie, udane ponowienie zmienia czerwony wynik na zielony, a sporadyczna usterka w aplikacji staje się niewidoczna. To jeden z najbardziej kosztownych do wykrycia rodzajów błędów. Gdy czerwony wynik może też oznaczać chwilowy zanik sieci lub awarię przeglądarki, zespół uczy się ponawiać nieudane testy zamiast analizować wyniki, a zestaw testów traci wiarygodność.

Nexus Studio zachowuje informację o ponowieniu. Test, który zakończył się niepowodzeniem, a potem przeszedł, nie otrzymuje statusu SECURE. W CI zwraca kod wyjścia 0, więc nie przerywa kompilacji, ale w raporcie i Historii widnieje jako FLAKY, czyli powodzenie z zastrzeżeniem. Pełną kolejność kontroli opisano w sekcji jak ustalanych jest 14 werdyktów.

Czym różnią się FLAKY, BREACHED i BREACHED_FLAKY?

• FLAKY: test zakończył się niepowodzeniem, potem przeszedł przy ponowieniu, a niczego nie naprawiono. Przeczytaj raw-data.json z nieudanej próby, a następnie sprawdź trend w Historii. Zwraca kod wyjścia 0.
• BREACHED: test zakończył się niepowodzeniem przy jedynej próbie, a żaden wzorzec problemów ze środowiskiem ani infrastrukturą testową nie wyjaśnia błędu. Asercja nie została spełniona. To zgłoszenie błędu, które zwraca kod wyjścia 1.
• BREACHED_FLAKY: test zakończył się niepowodzeniem przy ostatniej próbie po wcześniejszym ponowieniu, a żaden wzorzec problemów ze środowiskiem ani infrastrukturą testową tego nie wyjaśnia. Samo niepowodzenie jest niespójne. Porównaj próby, zanim zgłosisz błąd. Zwraca kod wyjścia 1.

Dwa pokrewne werdykty pozwalają zachować rzetelny obraz sytuacji. AUTO_RECOVER oznacza powodzenie, przy którym automatyczna naprawa zastąpiła selektor, więc lokalizator autora już nie działa, a test nie przeszedł bez zastrzeżeń. Jeśli pierwsza próba nie powiodła się wyłącznie z powodu przekroczenia czasu, a ponowienie zakończyło się powodzeniem, werdykt to SECURE, ponieważ wskazuje to na opóźnienie, nie na niestabilność.

Zanim niepowodzenie otrzyma werdykt BREACHED lub BREACHED_FLAKY, klasyfikator wyklucza inne wyjaśnienia w ustalonej kolejności: błąd infrastruktury testowej, awarię, blokadę, nieosiągalny host i przekroczenie limitu czasu. Tylko niepowodzenie, którego żadne z nich nie wyjaśnia, jest uznawane za wykryty problem. Dlatego przekroczenie limitu czasu lub CAPTCHA nie trafia do zgłoszeń błędów.

Jak zliczane są ponowienia?

Silnik odczytuje numer próby danego uruchomienia. Test zakończony powodzeniem z numerem ponowienia większym od zera otrzymuje FLAKY, chyba że naprawiono selektor — wtedy otrzymuje AUTO_RECOVER. Test zakończony niepowodzeniem lub przekroczeniem limitu czasu, z numerem ponowienia większym od zera i bez wyjaśnienia związanego ze środowiskiem, otrzymuje BREACHED_FLAKY. Powodzenie bez zastrzeżeń wymaga numeru ponowienia równego zero i braku naprawionego selektora.

FLAKY oznacza wyłącznie to, że próby dały różne wyniki. Niepowodzenie przy jedynej próbie, bez ponowień, nigdy nie jest oznaczane jako niestabilne. Każdy wiersz Historii zapisuje też retry_attempt i attempts, więc liczba prób pozostaje powiązana z uruchomieniem.

Jakie dowody pozostawia każdy werdykt?

• FLAKY: screenshot.png, metadata.json i raw-data.json. Folder zachowuje raw-data.json z nieudanej próby, więc nawet gdy ponowienie ukryje niepowodzenie, jego dziennik pozostaje. Decyduje o tym ustawienie Zachowuj dowody powodzenia FLAKY / AUTO_RECOVER, które jest domyślnie włączone.
• BREACHED_FLAKY: report.md, metadata.json, raw-data.json i screenshot.png, a nagranie niepowodzenia jest domyślnie zachowywane.
• BREACHED: te same pliki, z nagraniem zachowywanym domyślnie.

Werdykt znajduje się w nazwie folderu z dowodami, na przykład w nazwie zakończonej na [BREACHED]. Strona Dowody przedstawia jeden nieudany test, omawiając każdy jego plik.

Jak Historia wykrywa test o zmiennych wynikach?

Historia zachowuje po jednym wierszu na każde uruchomienie testu w danej przeglądarce lub na danym urządzeniu, wraz z werdyktem, numerem próby i sygnaturą błędu. Na podstawie tych wierszy pokazuje trendy według sesji, dni lub tygodni: Regresja, Powrót do poprawnego działania, Nadal nie działa i Wolniej. Test, który najpierw przechodzi, potem zawodzi i znów przechodzi, jest tam widoczny, zamiast ginąć wśród ponownych uruchomień.

Ranking ryzyka w Evidence Locker i Patrol porządkuje testy według tego, jak często zmieniają wynik, zawodzą lub zabierają czas. Pokazuje też przewidywane ryzyko na podstawie regresji logistycznej wykorzystującej historię testów, a przy niewielkiej ilości danych korzysta z EWMA. Żaden test nie jest uznawany za niestabilny przed pięcioma uruchomieniami, ponieważ jedno lub dwa uruchomienia nie pozwalają dostrzec prawidłowości.

Ograniczenia

• To ponowienia odróżniają FLAKY od SECURE, a BREACHED_FLAKY od BREACHED. Gdy ponowienia są wyłączone, sporadyczne niepowodzenie oznacza BREACHED.
• FLAKY oznacza, że próby dały różne wyniki. Nie wyjaśnia dlaczego. Znalezienie przyczyny w aplikacji lub w teście nadal należy do człowieka.
• Klasyfikacja analizuje tekst błędu, więc własny komunikat asercji zawierający słowa takie jak 403 lub Forbidden może zostać odczytany jako problem ze środowiskiem. Otwórz metadata.json, gdy werdykt Cię zaskoczy.
• Przed pięcioma uruchomieniami Historia i ranking ryzyka nie uznają żadnego testu za niestabilny.

Co dalej

Na stronie materiałów dowodowych znajdziesz wszystkie pliki pozostawione przez test zakończony niepowodzeniem, a artykuł Jak Nexus Studio ustala 14 werdyktów testów wyjaśnia kolejność sprawdzania. 30-dniowa wersja próbna pozwala uruchomić ten sam silnik na własnych testach.

Aby najpierw przeprowadzić weryfikację na własnym komputerze, skorzystaj z przykładu do uruchomienia na stronie Jak odróżnić rzeczywisty błąd od niestabilnego testu?.