Skip to Content
TestingWalker autonom al aplicației

Walker autonom al aplicației

Walkerul autonom explorează o porțiune limitată din UI-ul unei aplicații web într-un tester VM gestionat. Înregistrează stări, tranziții, capturi de ecran, diagnostice de consolă și rețea și constatări deduplicate. Este util pentru descoperire; nu dovedește că fiecare rută sau comportament a fost testat.

Disponibilitate: planul de date al walkerului, rapoartele, profilele autentificate, modurile limitate mechanical/AI/hybrid/task, controalele de siguranță și scenario mining sunt implementate. Un walk poate totuși rata comportamente din cauza limitelor, UI dinamic, etichete inaccesibile, credențiale indisponibile sau erori de model/parser. Verificați acoperirea înainte să vă bazați pe rezultat.

Pornire în siguranță

Folosiți un mediu non-producție și un cont de test dedicat. Obțineți un tester VM, apoi porniți walk-ul cu politica mechanical implicită:

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 revine imediat. Păstrați walk_id, apoi interogați get_app_walk(walk_id=...); apelați stop_app_walk dacă rularea trebuie să se oprească mai devreme.

Moduri de explorare

ModeComportament
mechanicalParcurgere limitată în ordinea DOM; fără clasare cu model
aiUn model clasează acțiunile candidate, apoi trece la modul de rezervă când se atinge plafonul de apeluri
hybridClasare cu model pentru primele stări configurate, apoi parcurgere mechanical
cotCăutare orientată pe sarcină cu plafon de decizii și schemă de ieșire opțională

Modurile AI și hybrid trec la mechanical când nu există backend de model suportat. Modul orientat pe sarcină eșuează în schimb. Acțiunile clasate de model rămân supuse aceleiași politici de origin și acțiuni distructive.

Controale de siguranță

  • Acțiunile distructive sunt omise implicit.
  • destructive_allowed=true permite doar clasa protejată; etichetele cu mize mari rămân blocate dacă nu sunt explicit pe allowlist.
  • Modul orientat pe sarcină nu acceptă niciodată destructive_allowed=true.
  • Completarea formularelor evită câmpurile sensibile și blochează trimiterile tranzacționale.
  • Navigarea este limitată la origin; modul de sarcină poate adăuga un allowlist explicit limitat de origin.
  • Configurația de autentificare conține nume de variabile secrete, nu credențiale literale. Scenario runner rezolvă valorile din keystore-ul proprietarului.

Allowlist-ul este o decizie de autorizare a operatorului. Folosiți etichete literale înguste, revizuiți mediul țintă și preferați date de test care pot fi aruncate.

Citirea rezultatului

Un walk finalizat raportează ce a observat efectiv:

  • stări UI vizitate și tranziții;
  • capturi de ecran și amprente ale elementelor interactive;
  • erori de consolă și erori de rețea semnificative;
  • constatări cu severity, category, evidence și cheie de deduplicare; și
  • limitele configurate state, depth, action, time, model și safety.

completed înseamnă că frontiera s-a epuizat sau s-a atins o limită configurată fără eroare internă. Nu înseamnă că aplicația a trecut. Revizuiți constatările blocker și major, acțiunile omise, starea autentificării și totalurile de acoperire.

Walk-uri autentificate

Preferați un profil de browser criptat când este disponibil. Fluxul legacy utilizator/parolă acceptă doar nume de variabile din keystore. Dacă autentificarea eșuează sau lipsește conținutul așteptat după login, rularea înregistrează eșec de autentificare; nu interpretați un walk al paginii de login ca acoperire a produsului.

De la descoperire la teste de regresie

După ce revizuiți o constatare, salvați un app scenario determinist pentru fluxul afectat. Un scenariu extras poate avea încredere scăzută dacă checkpoint-ul de verificare nu a trecut; inspectați pașii înainte să îl adoptați ca release gate.

Legături