Autonom app-walker
Den autonoma walkern utforskar en avgränsad del av ett webbprograms UI i en hanterad tester VM. Den registrerar tillstånd, övergångar, skärmdumpar, konsol- och nätverksdiagnostik samt deduplicerade fynd. Den är användbar för upptäckt; den bevisar inte att varje route eller beteende testades.
Tillgänglighet: walker-dataplanen, rapporter, autentiserade profiler, avgränsade lägen mechanical/AI/hybrid/task, säkerhetskontroller och scenariomining är implementerade. En walk kan fortfarande missa beteende på grund av gränser, dynamiskt UI, otillgängliga etiketter, saknade credentials eller model-/parserfel. Granska täckningen innan du litar på resultatet.
Starta säkert
Använd en icke-produktionsmiljö och ett dedikerat testkonto. Skaffa en tester VM och starta med standardpolicyn 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 returnerar direkt. Spara walk_id, poll sedan
get_app_walk(walk_id=...); anropa stop_app_walk om körningen ska avslutas tidigt.
Utforskningslägen
| Mode | Beteende |
|---|---|
mechanical | Avgränsad traversering i DOM-ordning; ingen modellranking |
ai | En modell rankar kandidathandlingar och faller tillbaka när anropsgränsen nås |
hybrid | Modellranking för de första konfigurerade tillstånden, sedan mechanical-traversering |
cot | Uppgiftsstyrd sökning med beslutsgräns och valfritt outputschema |
AI- och hybridlägen faller tillbaka till mechanical när ingen supporterad modelbackend finns. Uppgiftsstyrt läge misslyckas i stället. Modellrankade handlingar omfattas fortfarande av samma origin- och destructive-action-policy.
Säkerhetskontroller
- Destruktiva handlingar hoppas över som standard.
destructive_allowed=truetillåter endast den bevakade klassen; etiketter med hög insats blockeras kvar om de inte uttryckligen står på en allowlist.- Uppgiftsstyrt läge accepterar aldrig
destructive_allowed=true. - Formulärfyllning undviker känsliga fält och blockerar transaktionella submits.
- Navigering är origin-begränsad; uppgiftsläge kan lägga till en explicit avgränsad origin-allowlist.
- Autentiseringskonfiguration innehåller hemliga variabelnamn, inte literal credentials. Scenario runner löser värden från ägarens keystore.
En allowlist är ett auktoriseringsbeslut av operatören. Använd smala literal etiketter, granska målmiljön och föredra testdata som kan kasseras.
Läsa resultatet
En slutförd walk rapporterar vad den faktiskt observerade:
- besökta UI-tillstånd och övergångar;
- skärmdumpar och fingeravtryck för interaktiva element;
- konsol- och meningsfulla nätverksfel;
- fynd med severity, category, evidence och dedupliceringsnyckel; samt
- konfigurerade gränser för state, depth, action, time, model och safety.
completed betyder att fronten tog slut eller att en konfigurerad gräns nåddes utan
internt fel. Det betyder inte att applikationen godkändes. Granska blocker- och
major-fynd, hoppade handlingar, autentiseringsstatus och täckningssummor.
Autentiserade walks
Föredra en krypterad webbläsarprofil när den finns. Legacy-flödet med användarnamn/lösenord accepterar endast keystore-variabelnamn. Om inloggning misslyckas eller förväntat innehåll efter inloggning saknas registrerar körningen autentiseringsfel; tolka inte en walk av inloggningssidan som täckning av produkten.
Gör upptäckt till regressionstester
Efter att du granskat ett fynd sparar du ett deterministiskt app scenario för det berörda flödet. Ett utvunnet scenario kan ha låg tillförlitlighet om inte verifieringscheckpointen passerade; inspektera stegen innan du använder det som release gate.