Testes de UI de app

OpenFactory pode rodar workflows de navegador reutilizáveis em VMs desktop tester gerenciadas. Aplicativo pode ser deployado pelo OpenFactory ou hospedado onde VM tester alcançar.

Cenários combinam ações semânticas como open, click, type, key, wait e assert com screenshots, diagnósticos de navegador e veredicto registrado. São melhores para fluxo conhecido; use autonomous walker para descoberta limitada.

Criar e rodar cenário

Obtenha VM tester do app:


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

Depois salve cenário cujos steps usam labels visíveis significativos:


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

Use create_app_scenario, depois rode ID de cenário retornado com run_app_scenario. Primeira execução resolve elementos via OmniParser. Execuções posteriores podem reutilizar cache de elementos hardened e re-resolver só steps alterados. Revise se cada step foi cached ou parsed ao diagnosticar resultado.

O que run passed significa

Relatório conta como validação só quando:

status é passed;
mirou ambiente e revisão pretendidos;
proteção de staging e login de aplicativo completaram; e
asserções rodaram dentro do produto, não em página de login ou proteção.

Cenário passed demonstra só fluxo e asserções declarados. Não estabelece correção completa de aplicativo, acessibilidade, segurança ou comportamento cross-browser.

Variáveis e segredos

Steps referenciam valores como ${VAR} e seeds TOTP como ${totp:VAR}. Defaults não secretos podem ficar com cenário. Segredos podem ser armazenados no key store criptografado do owner quando cenário é criado; overrides de single-run passados a run_app_scenario são mesclados naquele run e não persistem.

Não coloque senhas, tokens ou seeds TOTP literais em texto de step, descrições de cenário, screenshots ou exports de issue. Para códigos one-time por email, ação email_otp exige integração Gmail ativa e explicitamente conectada para owner do cenário.

Asserções úteis

assert_text verifica texto visível esperado.
assert_no_error checa frases de erro built-in ou fornecidas.
assert_visual compara hash perceptual com baseline armazenada.
assert_stable amostra região por flicker/desaparecimento inesperado.
assert_progress verifica que região streaming continua mudando por período mínimo.
network pode interromper e restaurar rede da VM tester para testes de recovery.

Asserções visuais e temporais são heurísticas. Ajuste limiares contra dados de teste estáveis e inspecione frames capturados antes de tratar drift como defeito de produto.

Teste direto e gravado

Para trabalho exploratório, dirija VM com desktop_open_url, desktop_screenshot, desktop_click, desktop_type e ferramentas desktop relacionadas. Use start_app_test, record_app_test_step e finish_app_test quando sequência manual deve virar run auditável.

annotate_screenshot pode adicionar caixas rotuladas à evidência. Anotação explica o que revisor deve inspecionar; não prova por si que elemento funcionou.

Notas operacionais

VMs tester são reutilizadas por app/host. Escale pool tester para trabalho paralelo em vez de duplicatas arbitrárias.
Tester default não tem disco de persistência extra. Peça persistência só quando estado deve sobreviver reboot e aceite first boot mais longo.
Timeout de cliente não cancela necessariamente trabalho backend; inspecione run antes de retry.
Mantenha relatórios privados salvo se screenshots e diagnósticos foram revisados por dados sensíveis.