Walker app autonome

Le walker autonome explore une portion bornée de l’UI d’une application web dans VM testeur gérée. Il enregistre états, transitions, captures, diagnostics console et réseau, et constats dédupliqués. Utile pour découverte ; ce n’est pas preuve que chaque route ou comportement a été testé.

Disponibilité : plan données walker, rapports, profils authentifiés, modes mechanical/AI/hybrid/task bornés, contrôles sécurité et mining scénarios sont implémentés. Un walk peut encore manquer comportement à cause limites, UI dynamique, libellés inaccessibles, identifiants indisponibles ou erreur modèle/parser. Relisez couverture avant de compter sur résultat.

Démarrer en sécurité

Utilisez environnement non production et compte test dédié. Obtenez VM testeur, puis démarrez avec politique mechanical par défaut :


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 renvoie immédiatement. Conservez walk_id, puis interrogez get_app_walk(walk_id=...) ; appelez stop_app_walk si exécution doit finir tôt.

Modes d’exploration

Mode	Comportement
`mechanical`	Traversée ordre DOM bornée ; pas classement modèle
`ai`	Modèle classe actions candidates, puis repli quand plafond appels atteint
`hybrid`	Classement modèle premiers états configurés, puis traversée mechanical
`cot`	Recherche orientée tâche avec plafond décision et schéma sortie optionnel

Modes AI et hybrid retombent mechanical quand backend modèle supporté indisponible. Mode orienté tâche échoue à la place. Actions classées modèle restent soumises même politique origine et action destructive.

Contrôles sécurité

Actions destructives ignorées par défaut.
destructive_allowed=true autorise seulement classe gardée ; libellés enjeu élevé restent bloqués sauf allowlist explicite.
Mode orienté tâche n’accepte jamais destructive_allowed=true.
Remplissage formulaire évite champs sensibles et bloque submits transactionnels.
Navigation limitée origine ; mode tâche peut ajouter allowlist origine bornée explicite.
Configuration auth contient noms variables secret, pas identifiants littéraux. Runner scénario résout valeurs depuis keystore propriétaire.

Allowlist est décision autorisation opérateur. Utilisez libellés littéraux étroits, relisez environnement cible et préférez données test jetables.

Lire le résultat

Walk terminé rapporte ce qu’il a réellement observé :

états UI visités et transitions ;
captures et empreintes éléments interactifs ;
erreurs console et réseau significatives ;
constats avec gravité, catégorie, preuves et clé déduplication ; et
limites state, depth, action, temps, modèle et sécurité configurées.

completed signifie frontière terminée ou limite configurée atteinte sans erreur interne. Ce ne signifie pas que application a réussi. Relisez constats blocker et major, actions ignorées, statut auth et totaux couverture.

Walks authentifiés

Préférez profil navigateur chiffré lorsque disponible. Flux legacy username/password accepte seulement noms variables keystore. Si connexion échoue ou contenu post-login attendu absent, exécution enregistre échec auth ; n’interprétez pas walk page login comme couverture produit.

Transformer découverte en tests régression

Après relecture constat, enregistrez scénario app déterministe pour flux affecté. Scénario miné peut être faible confiance sauf si checkpoint vérification a réussi ; inspectez étapes avant adoption comme porte release.