W zadaniach webowych wykonywanych przez Agent błędy najczęściej pojawiają się w czterech obszarach: lokalizowaniu elementów, oczekiwaniu i timeoutach, zapisie stanu oraz blokadach środowiskowych. Idempotentne kroki, kontrolowane ponowienia, utrwalanie stanu i izolacja środowiska per zadanie znacznie stabilizują skuteczność.
Na początku pracy z automatyzacją webową podejście zwykle wydaje się proste: opisać przebieg i uruchomić skrypt. Logika wygląda poprawnie, a jednak zadania sporadycznie się nie udają, a stan konta czasem staje się nietypowy. Pierwszym odruchem jest sprawdzenie kodu, ale dokładniejsza analiza zwykle sprowadza problemy do czterech obszarów.
Zmiana strony unieważnia lokalizowanie elementów
Większość skryptów odnajduje elementy za pomocą selektorów. Gdy selektor jest zapisany na sztywno, niemal każda zmiana strony może go zepsuć: przycisk dostaje inną klasę, zmienia się jedno słowo tekstu, sekcja przechodzi z renderowania po stronie serwera na ładowanie asynchroniczne albo element trafia do nowego kontenera. Podczas testu A/B ta sama strona może nawet mieć różną strukturę dla różnych kont.
Typowe objawy to brak możliwości znalezienia elementu, kliknięcie w niewłaściwe miejsce albo kliknięcie kontrolki o tej samej nazwie, lecz w innej pozycji. Taki błąd nie wynika z wahań sieci i kilka ponowień go nie naprawi.
Praktycznym rozwiązaniem jest mniejsza zależność od ścieżek bezwzględnych. Lepiej korzystać z atrybutów dostępności, stabilnych identyfikatorów biznesowych lub relacji względnych między elementami; dla tego samego typu strony warto przygotować selektory zapasowe, aby po awarii głównego automatycznie przełączyć się na alternatywę. Jeśli strona zawiera iframe lub Shadow DOM, najpierw trzeba przejść do właściwego kontekstu, inaczej lokalizacja się nie powiedzie.
Oczekiwanie i timeouty mają zły zakres
Jeśli czas oczekiwania jest zbyt krótki, element może zostać uznany za niedostępny, zanim zakończy renderowanie, co wygląda jak błąd skryptu. Jeśli jest zbyt długi, czas pojedynczego zadania niepotrzebnie rośnie, przepustowość spada, a timeout może przesłonić właściwy problem.
Jawne oczekiwanie jest bardziej niezawodne niż stałe sleep: czekamy na konkretny warunek, np. pojawienie się elementu docelowego, odpowiedź żądania lub zniknięcie animacji ładowania. Budżety timeoutów należy ustalać warstwowo, osobno dla pojedynczego kroku, strony i całego zadania, a następnie stopniowo je zawężać zamiast stosować jedną wartość wszędzie.
Trzeba też odróżnić czekanie, aż strona będzie użyteczna, od czekania, aż powstanie wynik biznesowy. W pierwszym przypadku zwykle wystarczy gotowy DOM; w drugim może być potrzebny callback API albo zmiana tekstu statusu na stronie. Oczekiwanie na zły sygnał może sprawić, że operacja wygląda na udaną, mimo że dane nie zostały zapisane.
W połowie wieloetapowego zadania ginie postęp
Rejestracja, składanie zamówienia czy publikacja mogą łatwo obejmować kilkanaście kroków. Jeśli proces zakończy się po drodze z powodu timeoutu, awarii przeglądarki lub restartu hosta, a stan jest przechowywany tylko w pamięci, następne uruchomienie musi zacząć od początku albo ponownie wysłać poprzedni krok.
Skutki podwójnego wykonania bywają trudniejsze do zdiagnozowania niż zwykła awaria: ta sama operacja wykonuje się dwa razy, system nadrzędny dostaje dodatkowy rekord, a źródło problemu trudno ustalić.
Rozwiązaniem jest punkt trwałego zapisu dla każdego kroku. Po zakończeniu każdego kroku zapisujemy postęp w trwałym miejscu wraz z unikalnym identyfikatorem zadania; po restarcie kontynuujemy od ostatniego pomyślnie ukończonego punktu. Nie potrzeba do tego złożonego frameworka — wystarczy plik lub pojedynczy rekord stanu.
Blokada po stronie środowiska wygląda jak błąd kodu
Pierwsze trzy rodzaje problemów występują wewnątrz zadania, ale kolejny pochodzi ze środowiska. Serwis może łączyć cechy przeglądarki, zachowanie podczas dostępu i pochodzenie sieciowe, aby ocenić źródło ruchu. Jeśli uzna ruch za podejrzany, może zwrócić stronę weryfikacyjną, pustą treść albo po prostu doprowadzić do timeoutu. W logach zadania wygląda to niemal tak samo jak błąd wykonania.
Częste przyczyny to:
- Lokalizacja wyjściowego IP, strefa czasowa i język nie są ze sobą zgodne
- Wszystkie zadania wysyłają żądania z tego samego środowiska przeglądarki, przez co gęstość żądań w jednostce czasu jest wyraźnie większa niż u rzeczywistych użytkowników
- Środowisko często się zmienia albo konto wielokrotnie loguje się ponownie
Cztery działania zwiększające skuteczność
- Każdy krok powinien być idempotentny. Przed wykonaniem sprawdź, czy warunek wstępny został już spełniony, aby powtórzenie działania nie powodowało dodatkowych skutków ubocznych. Operacje odczytu są naturalnie idempotentne; zapisy wymagają unikalnego identyfikatora lub klucza deduplikacji.
- Klasyfikuj błędy. Błędy tymczasowe, takie jak jeszcze niewyrenderowany element, wahania sieci czy odpowiedź API 5xx, można ponawiać z backoffem. Błędy deterministyczne, takie jak ograniczone konto, nieprawidłowe parametry czy brak docelowego zasobu, nie poprawią się po kolejnych próbach; należy je zakończyć, aby nie zajmowały stale limitu współbieżności.
- Regularnie utrwalaj stan. Zapisuj postęp, wyniki pośrednie i bieżący krok, dzięki czemu po restarcie zadanie będzie kontynuowane, zamiast zaczynać od pierwszego kroku.
- Izoluj środowisko uruchomieniowe per zadanie. Każde konto lub zadanie powinno mieć osobne środowisko przeglądarki, bez współdzielenia Cookies i pamięci lokalnej, z rozsądnie zróżnicowanymi cechami fingerprintu oraz strefą czasową i językiem zgodnymi z regionem wyjściowego IP.
Czwarty punkt staje się szczególnie ważny, gdy rośnie skala zadań. Gdy dziesiątki lub setki zadań działają równolegle, warstwa środowiska wyznacza górną granicę stabilności i określa zasięg skutków, gdy coś pójdzie nie tak. PurpleMark w takich scenariuszach umożliwia tworzenie izolowanych środowisk na żądanie i ich zbiorcze odzyskiwanie, dzięki czemu każde konto ma własne środowisko, a stany zadań nie zanieczyszczają się wzajemnie.
Ta treść służy wyłącznie badaniom technicznym i wymianie praktyk programistycznych. Korzystaj z opisanych technologii zgodnie z prawem i obowiązującymi zasadami oraz przestrzegaj warunków korzystania z platformy docelowej.
