Zanim AI Agent zacznie obsługiwać strony internetowe, sprawdź cały łańcuch między środowiskiem a Agentem na czterech poziomach: test dymny pojedynczego kroku, zadania wieloetapowe, obciążenie współbieżne i wstrzykiwanie awarii, z osobnymi wskaźnikami.
Jednorazowy sukces w środowisku demonstracyjnym nie oznacza, że ten sam łańcuch będzie nadawał się do niezawodnego użycia każdego dnia.
Aby to ocenić, trzeba rozdzielić testy: środowisko sprawdzić na jego warstwie, Agent na jego warstwie, a na końcu zweryfikować stabilność po połączeniu obu części.
Test dymny pojedynczego kroku: cztery działania osobno
Test dymny obejmuje tylko cztery czynności, wykonywane pojedynczo i bez łączenia w sekwencję: otwarcie wskazanej strony; zlokalizowanie elementu; kliknięcie go; pobranie tekstu tego elementu. Jeśli wszystkie cztery przejdą pomyślnie, podstawy połączenia, sesji i dostępu do elementów działają.
Ograniczenie testu do czterech oddzielnych działań zawęża obszar awarii. Jeśli strona się nie otwiera, problem zwykle dotyczy wyjścia sieciowego lub uprawnień. Jeśli strona się otwiera, ale elementu nie można znaleźć, być może nie zakończyła ładowania albo locator zbyt mocno zależy od bieżącego układu. Jeśli element jest znaleziony, ale nie da się go kliknąć, sprawdź, czy nie jest zasłonięty lub umieszczony w iframe. Jeśli pobrany tekst jest pusty, najpierw upewnij się, że odczytywana jest treść po renderowaniu, a nie początkowy HTML.
Obserwuj trzy wartości: skuteczność pojedynczego kroku, czas pojedynczego kroku oraz rozkład typów błędów. Powinny być stabilne już na etapie testu dymnego. Jeśli skuteczność pojedynczego kroku waha się tylko w okolicach 80–90%, dalsze testy niewiele powiedzą.
Zadania wieloetapowe: rozgałęzienia ważniejsze niż liczba kroków
Połącz cztery działania w rzeczywiste zadanie, na przykład wypełnienie formularza, przejście przez kilka stron, filtrowanie według warunków i zapis wyniku lokalnie. Większa liczba kroków to tylko zmiana ilościowa; prawdziwym problemem są rozgałęzienia: pojawia się komunikat, znika element docelowy, strona sama przekierowuje albo pojawia się etap weryfikacji wymagający potwierdzenia człowieka.
Tutaj liczy się wskaźnik ukończenia zadania, a nie skuteczność pojedynczych kroków. Po awarii ważniejsze jest, czy Agent potrafi zmienić ścieżkę oraz rozpoznać moment, w którym powinien się zatrzymać i jasno zgłosić problem, niż samo dojście do końca.
Łatwo pominąć także liczbę interwencji człowieka. Jeśli to samo zadanie zostanie wykonane dwadzieścia razy, liczba interwencji i krok, na którym wystąpiło zatrzymanie, mogą lepiej pokazać dojrzałość łańcucha niż ogólny wskaźnik ukończenia.
Współbieżność i wstrzykiwanie awarii
Gdy pojedynczy łańcuch jest stabilny, dodaj współbieżność. Uruchom wiele środowisk jednocześnie z tym samym typem zadania i obserwuj, czy środowiska wpływają na siebie oraz czy wraz ze wzrostem współbieżności rośnie wskaźnik awarii. Problemy na tym etapie często wynikają z presji na zasoby lub sesje, a nie z błędu logiki Agent.
Wstrzykiwanie awarii jest jednym z najczęściej pomijanych testów, a zarazem jednym z najbardziej potrzebnych. Celowo wywołaj timeout, zniknięcie elementu, wygaśnięcie sesji i CAPTCHA, a następnie obserwuj reakcję: czy po timeout ponowienie kończy się sukcesem, czy proces się zawiesza; czy po wygaśnięciu sesji pojawia się jasny błąd, czy łańcuch dalej używa nieważnych danych uwierzytelniających.
Zapisuj trzy wskaźniki: krzywą awaryjności przy współbieżności, skuteczność odzyskiwania po awarii i dodatkowy czas powodowany przez pojedynczą awarię. Niska skuteczność odzyskiwania oznacza, że łańcuch działa tylko w sprzyjających warunkach.
Warstwę środowiska testuj osobno
Powyższe testy odbywają się w jednym środowisku, ale gdy wiele środowisk pracuje razem, trzeba osobno zweryfikować kolejną warstwę. Każde środowisko powinno uruchamiać się niezależnie, mieć własną sesję i cache oraz być przypisane do własnego egress IP.
Zespoły obsługujące wiele kont zwykle zarządzają środowiskami osobno dla każdego konta. Narzędzia takie jak PurpleMark zapewniają izolację środowisk, dając każdemu kontu niezależną przestrzeń uruchomieniową. W teście uruchom równolegle kilka środowisk i upewnij się, że Cookies, cache i egress nie mieszają się między nimi.
Dla tej warstwy obserwuj trzy wartości: skuteczność uruchamiania środowiska, przenikanie danych między środowiskami (normalnie powinno wynosić zero) oraz możliwość kontynuacji sesji po odtworzeniu środowiska.
Jak przypisać przyczynę awarii
Gdy łańcuch przestaje działać, częstym błędem jest natychmiastowa modyfikacja skryptu Agent. Lepsza kolejność to najpierw sprawdzić, czy środowisko się uruchamia i czy sesja nie wygasła, potem skontrolować wyjście sieciowe i węzły, a dopiero na końcu podejrzewać lokalizowanie elementów i planowanie zadań przez Agent. Odwrócenie kolejności prowadzi do wielokrotnych zmian w niewłaściwym miejscu.
Cztery działania z testu dymnego są także narzędziem do lokalizowania przyczyny. Po każdej awarii uruchom je ponownie osobno i zobacz, które ogniwo pęka jako pierwsze. W większości przypadków odpowiedź pojawia się już wtedy.
