Autonom app-walker

Den autonome walker udforsker en afgrænset del af en webapplikations UI i en administreret tester VM. Den registrerer tilstande, overgange, screenshots, konsol- og netværksdiagnostik samt deduplicerede fund. Den er nyttig til opdagelse; den er ikke bevis for, at hver route eller adfærd blev testet.

Tilgængelighed: walker-dataplanen, rapporter, autentificerede profiler, afgrænsede tilstande mechanical/AI/hybrid/task, sikkerhedskontroller og scenariomining er implementeret. En walk kan stadig overse adfærd på grund af grænser, dynamisk UI, utilgængelige labels, manglende credentials eller model-/parserfejl. Gennemgå dækningen, før du stoler på resultatet.

Start sikkert

Brug et ikke-produktionsmiljø og en dedikeret testkonto. Få en tester VM, og start med standardpolitikken 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 returnerer med det samme. Gem walk_id, poll derefter get_app_walk(walk_id=...); kald stop_app_walk, hvis kørslen skal stoppe tidligt.

Udforskningstilstande

Mode	Adfærd
`mechanical`	Afgrænset gennemløb i DOM-rækkefølge; ingen modelrangering
`ai`	En model rangerer kandidathandlinger og falder tilbage, når kaldgrænsen nås
`hybrid`	Modelrangering for de første konfigurerede tilstande, derefter mechanical-gennemløb
`cot`	Opgavestyret søgning med beslutningsgrænse og valgfrit outputskema

AI- og hybridtilstande falder tilbage til mechanical, når ingen understøttet modelbackend findes. Opgavestyret tilstand fejler i stedet. Modelrangerede handlinger er fortsat underlagt samme origin- og destructive-action-politik.

Sikkerhedskontroller

Destruktive handlinger springes over som standard.
destructive_allowed=true tillader kun den bevogtede klasse; labels med høj indsats forbliver blokeret, medmindre de udtrykkeligt står på en allowlist.
Opgavestyret tilstand accepterer aldrig destructive_allowed=true.
Formularudfyldning undgår følsomme felter og blokerer transaktionelle submits.
Navigation er origin-begrænset; opgavetilstand kan tilføje en eksplicit afgrænset origin-allowlist.
Autentificeringskonfiguration indeholder hemmelige variabelnavne, ikke literal credentials. Scenario runner henter værdier fra ejerens keystore.

En allowlist er en operatørs autorisationsbeslutning. Brug snævre literal labels, gennemgå målmiljøet, og foretræk testdata, der kan kasseres.

Læs resultatet

En fuldført walk rapporterer, hvad den faktisk observerede:

besøgte UI-tilstande og overgange;
screenshots og fingeraftryk for interaktive elementer;
konsol- og meningsfulde netværksfejl;
fund med severity, category, evidence og dedupliceringsnøgle; samt
konfigurerede grænser for state, depth, action, time, model og safety.

completed betyder, at fronten blev udtømt, eller at en konfigureret grænse blev nået uden intern fejl. Det betyder ikke, at applikationen bestod. Gennemgå blocker- og major-fund, sprunget-over handlinger, autentificeringsstatus og dækningssummer.

Autentificerede walks

Foretræk en krypteret browserprofil, når den findes. Legacy-flowet med brugernavn/adgangskode accepterer kun keystore-variabelnavne. Hvis login fejler, eller det forventede indhold efter login mangler, registrerer kørslen autentificeringsfejl; fortolk ikke en walk af login-siden som dækning af produktet.

Gør opdagelse til regressionstests

Efter gennemgang af et fund gemmer du et deterministisk app scenario for det berørte flow. Et udvundet scenario kan have lav tillid, medmindre verificeringscheckpointet bestod; inspicer trinene, før du bruger det som release gate.