Tests UI app

OpenFactory peut exécuter workflows navigateur réutilisables dans VM testeur bureau gérées. L’application peut être déployée par OpenFactory ou hébergée partout où la VM testeur peut joindre.

Les scénarios combinent actions sémantiques comme open, click, type, key, wait et assert avec captures, diagnostics navigateur et verdict enregistré. Ils conviennent à un flux utilisateur connu ; utilisez le walker autonome pour découverte bornée.

Créer et exécuter un scénario

Obtenez VM testeur de l’app :


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

Enregistrez ensuite scénario dont étapes utilisent libellés écran significatifs :


[
  { "action": "open_url", "value": "${APP_URL}" },
  { "action": "type", "target": "email field", "value": "${EMAIL}" },
  { "action": "type", "target": "password field", "value": "${PASSWORD}" },
  { "action": "click", "target": "Sign in" },
  { "action": "assert_text", "expect": "Dashboard" },
  { "action": "assert_no_error" }
]

Utilisez create_app_scenario, puis exécutez ID scénario renvoyé avec run_app_scenario. Première exécution résout éléments via OmniParser. Exécutions suivantes peuvent réutiliser cache éléments renforcé et ne re-résoudre que étapes changées. Relisez si chaque étape était en cache ou parsée lors diagnostic résultat.

Ce qu’une exécution réussie signifie

Un rapport compte comme validation seulement lorsque :

statut est passed ;
il ciblait environnement et révision voulus ;
protection staging et connexion application se sont terminées ; et
assertions ont tourné dans le produit, pas sur page login ou protection.

Un scénario réussi démontre seulement flux et assertions déclarés. Il n’établit pas exactitude application complète, accessibilité, sécurité ni comportement multi-navigateur.

Variables et secrets

Étapes référencent valeurs en ${VAR} et graines TOTP en ${totp:VAR}. Défauts non secrets peuvent vivre avec scénario. Secrets peuvent être stockés magasin clés chiffré propriétaire à création scénario ; overrides single-run passés à run_app_scenario fusionnent pour cette exécution et ne sont pas persistés.

Ne placez pas mots de passe, jetons ou graines TOTP littéraux dans texte étape, descriptions scénario, captures ou exports ticket. Pour codes OTP e-mail, action email_otp exige intégration Gmail connectée explicitement active pour propriétaire scénario.

Assertions utiles

assert_text vérifie texte visible attendu.
assert_no_error vérifie phrases d’erreur intégrées ou fournies.
assert_visual compare hash perceptuel à baseline stockée.
assert_stable échantillonne région pour scintillement/disparition inattendus.
assert_progress vérifie qu’une région streaming continue de changer pendant période minimum.
network peut interrompre et restaurer réseau VM testeur pour tests reprise.

Assertions visuelles et temporelles sont heuristiques. Ajustez seuils contre données test stables et inspectez frames capturées avant de traiter dérive comme défaut produit.

Tests direct et enregistrés

Pour travail exploratoire, pilotez VM avec desktop_open_url, desktop_screenshot, desktop_click, desktop_type et outils desktop associés. Utilisez start_app_test, record_app_test_step et finish_app_test lorsque séquence manuelle doit devenir exécution auditable.

annotate_screenshot peut ajouter boîtes étiquetées aux preuves. Annotation explique ce qu’un relecteur doit inspecter ; elle ne prouve pas à elle seule que l’élément a fonctionné.

Notes opérationnelles

VM testeur sont réutilisées par app/hôte. Mettez à l’échelle pool testeur pour travail parallèle plutôt que doublons arbitraires.
Testeur par défaut n’a pas disque persistance extra. Demandez persistance seulement si état doit survivre reboot et acceptez first boot plus long.
Timeout client n’annule pas nécessairement travail backend ; inspectez exécution avant retry.
Gardez rapports privés sauf si captures et diagnostics ont été relus pour données sensibles.