Autonomiczny walker aplikacji

Autonomiczny walker eksploruje ograniczoną część UI aplikacji webowej w zarządzanej tester VM. Rejestruje stany, przejścia, zrzuty ekranu, diagnostykę konsoli i sieci oraz zdeduplikowane ustalenia. Przydaje się do odkrywania; nie dowodzi, że każda trasa lub zachowanie zostało przetestowane.

Dostępność: warstwa danych walkera, raporty, uwierzytelnione profile, ograniczone tryby mechanical/AI/hybrid/task, kontrolki bezpieczeństwa i mining scenariuszy są zaimplementowane. Walk nadal może pominąć zachowanie z powodu limitów, dynamicznego UI, niedostępnych etykiet, braku poświadczeń lub błędu modelu/parsera. Sprawdź pokrycie, zanim polegasz na wyniku.

Bezpieczny start

Użyj środowiska innego niż produkcja i dedykowanego konta testowego. Uzyskaj tester VM, a następnie uruchom z domyślną polityką mechanical:


ensure_tester_vm(app="my-app", app_url="https://staging.example.com")

walk_app(
  app_name="my-app",
  app_url="https://staging.example.com",
  vm_name="<tester-vm>",
  max_states=40,
  max_depth=5,
  max_wall_seconds=600,
  destructive_allowed=false
)

walk_app wraca od razu. Zachowaj walk_id, następnie odpytuj get_app_walk(walk_id=...); wywołaj stop_app_walk, jeśli run ma zakończyć się wcześniej.

Tryby eksploracji

Mode	Zachowanie
`mechanical`	Ograniczone przejście w kolejności DOM; bez rankingu modelu
`ai`	Model rankuje kandydackie akcje, potem przechodzi w tryb zapasowy po osiągnięciu limitu wywołań
`hybrid`	Ranking modelu dla pierwszych skonfigurowanych stanów, potem traversacja mechanical
`cot`	Wyszukiwanie ukierunkowane na zadanie z limitem decyzji i opcjonalnym schematem wyjścia

Tryby AI i hybrid przechodzą na mechanical, gdy brak obsługiwanego backendu modelu. Tryb ukierunkowany na zadanie kończy się błędem. Akcje rankowane przez model nadal podlegają tej samej polityce origin i akcji destrukcyjnych.

Kontrolki bezpieczeństwa

Akcje destrukcyjne są domyślnie pomijane.
destructive_allowed=true zezwala tylko na strzeżoną klasę; etykiety wysokiego ryzyka pozostają zablokowane, chyba że są jawnie na allowliście.
Tryb ukierunkowany na zadanie nigdy nie akceptuje destructive_allowed=true.
Wypełnianie formularzy omija wrażliwe pola i blokuje transakcyjne submity.
Nawigacja jest ograniczona do origin; tryb zadania może dodać jawny, ograniczony allowlist origin.
Konfiguracja uwierzytelniania zawiera nazwy zmiennych secret, nie literalne poświadczenia. Scenario runner pobiera wartości z keystore właściciela.

Allowlist to decyzja autoryzacyjna operatora. Używaj wąskich literalnych etykiet, sprawdź środowisko docelowe i preferuj dane testowe, które można usunąć.

Odczyt wyniku

Ukończony walk raportuje to, co faktycznie zaobserwował:

odwiedzone stany UI i przejścia;
zrzuty ekranu i odciski interaktywnych elementów;
błędy konsoli i istotne błędy sieci;
ustalenia z severity, category, evidence i kluczem deduplikacji; oraz
skonfigurowane limity state, depth, action, time, model i safety.

completed oznacza, że frontier się wyczerpał lub osiągnięto skonfigurowany limit bez błędu wewnętrznego. Nie oznacza, że aplikacja przeszła. Przejrzyj ustalenia blocker i major, pominięte akcje, status uwierzytelnienia i sumy pokrycia.

Walki uwierzytelnione

Preferuj szyfrowany profil przeglądarki, gdy jest dostępny. Legacy flow z nazwą użytkownika/hasłem akceptuje tylko nazwy zmiennych keystore. Jeśli logowanie się nie powiedzie lub brakuje oczekiwanej treści po zalogowaniu, run rejestruje błąd uwierzytelnienia; nie traktuj walka strony logowania jako pokrycia produktu.

Od odkrycia do testów regresji

Po przejrzeniu ustalenia zapisz deterministyczny app scenario dla dotkniętego flow. Wydobyty scenariusz może mieć niską pewność, chyba że checkpoint weryfikacji przeszedł; sprawdź kroki, zanim użyjesz go jako release gate.