Testování UI aplikace

OpenFactory umí spouštět znovu použitelné workflow v prohlížeči ve spravovaných desktop tester VMs. Aplikaci může nasadit OpenFactory, nebo může běžet kdekoli, kam tester VM dosáhne.

Scénáře kombinují sémantické akce jako open, click, type, key, wait a assert se snímky obrazovky, diagnostikou prohlížeče a zaznamenaným verdiktem. Hodí se pro známý uživatelský flow; pro omezený průzkum použijte autonomous walker.

Vytvoření a spuštění scénáře

Získejte tester VM aplikace:


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

Poté uložte scénář, jehož kroky používají smysluplné popisky na obrazovce:


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

Použijte create_app_scenario a pak spusťte vrácené ID scénáře přes run_app_scenario. První běh rozpozná elementy přes OmniParser. Další běhy mohou znovu použít zpevněnou cache elementů a znovu řešit jen změněné kroky. Při diagnostice výsledku zkontrolujte, zda byl každý krok z cache, nebo parsován.

Co znamená úspěšný běh

Report se počítá jako validace jen když:

jeho status je passed;
cílil na zamýšlené prostředí a revizi;
dokončila se případná staging-protection a přihlášení do aplikace; a
assertions běžely uvnitř produktu, ne na přihlašovací nebo ochranné stránce.

Úspěšný scénář ukazuje jen deklarovaný flow a assertions. Nedokazuje úplnou správnost aplikace, přístupnost, bezpečnost ani chování cross-browser.

Proměnné a secrets

Kroky odkazují na hodnoty jako ${VAR} a TOTP seeds jako ${totp:VAR}. Výchozí hodnoty, které nejsou secret, mohou být u scénáře. Secrets lze uložit do šifrovaného key store vlastníka při vytvoření scénáře; single-run overrides předané do run_app_scenario se sloučí pro ten běh a nejsou trvale uloženy.

Nepište doslovná hesla, tokeny ani TOTP seeds do textu kroku, popisů scénáře, snímků obrazovky ani exportů issue. Pro jednorázové kódy z e-mailu akce email_otp vyžaduje aktivní a výslovně připojenou integraci Gmail pro vlastníka scénáře.

Užitečné assertions

assert_text ověří očekávaný viditelný text.
assert_no_error zkontroluje vestavěné nebo dodané chybové fráze.
assert_visual porovná perceptual hash s uloženou baseline.
assert_stable vzorkuje oblast kvůli neočekávanému blikání nebo zmizení.
assert_progress ověří, že streamovaná oblast se po minimální dobu stále mění.
network může přerušit a obnovit síť tester VM pro testy obnovy.

Vizuální a časové assertions jsou heuristiky. Nastavte prahy proti stabilním testovacím datům a prohlédněte zachycené snímky, než drift považujete za vadu produktu.

Přímé a zaznamenávané testování

Pro průzkumnou práci říďte VM přes desktop_open_url, desktop_screenshot, desktop_click, desktop_type a související desktop nástroje. Použijte start_app_test, record_app_test_step a finish_app_test, když má z ruční sekvence vzniknout auditovatelný běh.

annotate_screenshot může k důkazům přidat označené rámečky. Anotace vysvětlí, co má reviewer zkontrolovat; sama o sobě neprokazuje, že element fungoval.

Provozní poznámky

Tester VMs se znovu používají podle app/host. Pro paralelní práci škálujte tester pool místo vytváření libovolných duplicit.
Výchozí tester nemá extra persistence disk. Persistence vyžádejte jen když musí stav přežít reboot a počítejte s delším prvním bootem.
Timeout klienta nemusí backend práci zrušit; před opakováním zkontrolujte běh.
Reporty nechte soukromé, dokud snímky a diagnostika neprojdou kontrolou citlivých dat.