Test UI applicazioni

OpenFactory può eseguire workflow browser riutilizzabili in VM tester desktop gestite. L’applicazione può essere deployata da OpenFactory o hostata ovunque la tester VM possa raggiungere.

Gli scenari combinano azioni semantiche come open, click, type, key, wait e assert con screenshot, diagnostica browser e verdetto registrato. Sono adatti a un flusso utente noto; usa il walker autonomo per discovery delimitata.

Crea ed esegui uno scenario

Ottieni la tester VM dell’app:


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

Poi salva uno scenario i cui passi usano etichette on-screen significative:


[
  { "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" }
]

Usa create_app_scenario, poi esegui l’ID scenario restituito con run_app_scenario. La prima run risolve elementi tramite OmniParser. Run successive possono riusare cache elementi hardened e ri-risolvere solo passi cambiati. Rivedi se ogni passo era cached o parsed quando diagnostichi un risultato.

Cosa significa una run superata

Un report conta come validazione solo quando:

il suo stato è passed;
ha targetato ambiente e revisione previsti;
eventuale protezione staging e login applicazione sono completati; e
le asserzioni sono girate dentro il prodotto, non su pagina login o protezione.

Uno scenario superato dimostra solo il flusso e le asserzioni dichiarate. Non stabilisce correttezza applicazione completa, accessibilità, sicurezza o comportamento cross-browser.

Variabili e segreti

I passi referenziano valori come ${VAR} e seed TOTP come ${totp:VAR}. Default non segreti possono stare con lo scenario. I segreti possono essere memorizzati nel key store cifrato dell’owner quando lo scenario è creato; override singola-run passati a run_app_scenario sono uniti per quella run e non persistiti.

Non mettere password, token o seed TOTP letterali in testo passo, descrizioni scenario, screenshot o export issue. Per codici one-time via email, l’azione email_otp richiede un’integrazione Gmail attiva e esplicitamente collegata per l’owner dello scenario.

Asserzioni utili

assert_text verifica testo visibile atteso.
assert_no_error controlla frasi errore integrate o fornite.
assert_visual confronta un hash percettivo con baseline memorizzata.
assert_stable campiona una regione per flicker/sparizione inattesa.
assert_progress verifica che una regione streaming continui a cambiare per un periodo minimo.
network può interrompere e ripristinare rete tester VM per test recovery.

Asserzioni visive e temporali sono euristiche. Regola soglie su dati test stabili e ispeziona frame catturati prima di trattare drift come difetto prodotto.

Test diretto e registrato

Per lavoro esplorativo, guida la VM con desktop_open_url, desktop_screenshot, desktop_click, desktop_type e tool desktop correlati. Usa start_app_test, record_app_test_step e finish_app_test quando quella sequenza manuale deve diventare una run auditabile.

annotate_screenshot può aggiungere box etichettati all’evidenza. Un’annotazione spiega cosa un revisore dovrebbe ispezionare; non prova da sola che l’elemento abbia funzionato.

Note operative

Le tester VM sono riusate per app/host. Scala il pool tester per lavoro parallelo invece di creare duplicati arbitrari.
La tester default non ha disco persistenza extra. Richiedi persistenza solo quando lo stato deve sopravvivere a reboot e accetta first boot più lungo.
Un timeout client non annulla necessariamente lavoro backend; ispeziona la run prima di riprovare.
Mantieni report privati salvo che screenshot e diagnostica siano stati revisionati per dati sensibili.