App UI Testing

OpenFactory kann wiederverwendbare Browser-Workflows in managed desktop tester VMs ausführen. Die Anwendung kann von OpenFactory deployed oder anywhere hosted sein, wo tester VM reach kann.

Szenarien kombinieren semantic actions wie open, click, type, key, wait und assert mit Screenshots, browser diagnostics und recorded verdict. Best für known user flow; nutzen Sie autonomous walker für bounded discovery.

Szenario anlegen und ausführen

Tester VM der App holen:


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

Dann scenario speichern, dessen steps meaningful on-screen labels nutzen:


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

create_app_scenario, dann returned scenario ID mit run_app_scenario ausführen. First run resolved elements durch OmniParser. Later runs können hardened element cache reuse und nur changed steps re-resolve. Review ob step cached oder parsed war beim Diagnose eines results.

Was ein bestandener Lauf bedeutet

Report zählt als validation nur wenn:

status passed ist;
intended environment und revision targeted wurden;
staging-protection und application login completed; und
assertions inside product liefen, nicht on login or protection page.

Passing scenario demonstriert nur declared flow und assertions. Es etabliert nicht complete application correctness, accessibility, security oder cross-browser behavior.

Variablen und Secrets

Steps referenzieren values als ${VAR} und TOTP seeds als ${totp:VAR}. Non-secret defaults dürfen beim scenario leben. Secrets können in owner encrypted key store when scenario created; single-run overrides to run_app_scenario merged for that run und nicht persisted.

Keine literal passwords, tokens oder TOTP seeds in step text, scenario descriptions, screenshots oder issue exports. Für emailed one-time codes braucht email_otp action active explicitly connected Gmail integration für scenario owner.

Nützliche Assertions

assert_text verifiziert expected visible text.
assert_no_error prüft built-in oder supplied error phrases.
assert_visual vergleicht perceptual hash mit stored baseline.
assert_stable sampled region für unexpected flicker/disappearance.
assert_progress verifiziert streaming region continues changing für minimum period.
network kann tester VM network interrupt und restore für recovery tests.

Visual und temporal assertions sind heuristics. Thresholds gegen stable test data tunen und captured frames inspizieren before treating drift als product defect.

Direct und recorded testing

Für exploratory work VM steuern mit desktop_open_url, desktop_screenshot, desktop_click, desktop_type und related desktop tools. start_app_test, record_app_test_step, finish_app_test wenn manual sequence auditable run werden soll.

annotate_screenshot kann labeled boxes zu evidence hinzufügen. Annotation erklärt was reviewer inspizieren soll; beweist nicht selbst dass element worked.

Operative Hinweise

Tester VMs reused per app/host. Tester pool skalieren für parallel work statt arbitrary duplicates.
Default tester hat keine extra persistence disk. Persistence nur when state reboot überleben muss und longer first boot akzeptieren.
Client timeout cancelled backend work nicht necessarily; run inspizieren before retrying.
Reports private halten unless screenshots und diagnostics auf sensitive data reviewed wurden.