App-UI-tester

OpenFactory kan kjøre gjenbrukbare browserworkflows i administrerte desktop tester VMs. Applikasjonen kan deployes av OpenFactory eller hostes overalt tester VM når.

Scenarioer kombinerer semantiske handlinger som open, click, type, key, wait og assert med skjermbilder, browserdiagnostikk og en registrert dom. De passer best for en kjent brukerflyt; bruk autonomous walker for avgrenset oppdagelse.

Opprett og kjør et scenario

Skaff tester VM for appen:


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

Lagre deretter et scenario hvis trinn bruker meningsfulle etiketter på skjermen:


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

Bruk create_app_scenario, og kjør deretter den returnerte scenario-ID-en med run_app_scenario. Første kjøring løser elementer via OmniParser. Senere kjøringer kan gjenbruke den herdede elementcachen og bare løse om endrede trinn. Gå gjennom om hvert trinn var cachet eller parset når du diagnostiserer et resultat.

Hva en bestått kjøring betyr

En rapport teller som validering bare når:

status er passed;
den rettet mot tiltenkt miljø og revisjon;
eventuell staging-protection og applikasjonsinnlogging fullførte; og
assertions kjørte inne i produktet, ikke på en innloggings- eller beskyttelsesside.

Et bestått scenario viser bare den erklærte flyten og assertions. Det beviser ikke full applikasjonskorrekthet, tilgjengelighet, sikkerhet eller cross-browser-atferd.

Variabler og secrets

Trinn refererer verdier som ${VAR} og TOTP-seeds som ${totp:VAR}. Ikke-hemmelige defaults kan ligge hos scenarioet. Secrets kan lagres i eierens krypterte key store når scenarioet opprettes; single-run overrides sendt til run_app_scenario slås sammen for den kjøringen og lagres ikke.

Ikke plasser bokstavelige passord, tokens eller TOTP-seeds i trinntekst, scenariobeskrivelser, skjermbilder eller issue-eksporter. For engangskoder på e-post krever handlingen email_otp en aktiv, uttrykkelig tilkoblet Gmail-integrasjon for scenarioeieren.

Nyttige assertions

assert_text verifiserer forventet synlig tekst.
assert_no_error sjekker innebygde eller medfølgende feilfraser.
assert_visual sammenligner en perceptual hash med en lagret baseline.
assert_stable sampler en region for uventet flimring eller forsvinning.
assert_progress verifiserer at en streamingregion fortsetter å endre seg i en minimumsperiode.
network kan avbryte og gjenopprette tester VM sitt nettverk for recovery-tester.

Visuelle og tidsmessige assertions er heuristikker. Juster terskler mot stabil testdata og inspiser innspilte frames før du behandler drift som produktfeil.

Direkte og innspilt testing

For utforskende arbeid styrer du VM med desktop_open_url, desktop_screenshot, desktop_click, desktop_type og relaterte desktopverktøy. Bruk start_app_test, record_app_test_step og finish_app_test når den manuelle sekvensen skal bli en revisjonsbar kjøring.

annotate_screenshot kan legge til merkede bokser i bevis. En annotasjon forklarer hva en reviewer skal inspisere; den beviser ikke i seg selv at elementet fungerte.

Operative merknader

Tester VMs gjenbrukes per app/host. Skaler tester pool for parallelt arbeid i stedet for å opprette vilkårlige duplikater.
Standardtesteren har ingen ekstra persistencedisk. Be om persistence bare når tilstand må overleve en omstart, og aksepter lengre first boot.
En klient-timeout avbryter ikke nødvendigvis backend-arbeid; inspiser kjøringen før du prøver på nytt.
Hold rapporter private med mindre skjermbilder og diagnostikk er gjennomgått for sensitive data.