App-UI-test

OpenFactory kan køre genanvendelige browserworkflows i administrerede desktop tester VMs. Applikationen kan deployes af OpenFactory eller hostes overalt, hvor tester VM kan nå frem.

Scenarier kombinerer semantiske handlinger som open, click, type, key, wait og assert med screenshots, browserdiagnostik og en registreret kendelse. De passer bedst til et kendt brugerflow; brug autonomous walker til afgrænset opdagelse.

Opret og kør et scenarie

Hent appens tester VM:


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

Gem derefter et scenarie, hvis trin bruger meningsfulde etiketter på skærmen:


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

Brug create_app_scenario, og kør derefter det returnerede scenarie-ID med run_app_scenario. Første kørsel opløser elementer via OmniParser. Senere kørsler kan genbruge den hærdede elementcache og kun genopløse ændrede trin. Gennemgå om hvert trin var cachet eller parset, når du diagnosticerer et resultat.

Hvad en bestået kørsel betyder

En rapport tæller kun som validering, når:

status er passed;
den målrettede det tilsigtede miljø og revision;
eventuel staging-protection og applikationslogin blev fuldført; og
assertions kørte inde i produktet, ikke på en login- eller beskyttelsesside.

Et bestået scenarie viser kun det erklærede flow og assertions. Det beviser ikke fuld applikationskorrekthed, tilgængelighed, sikkerhed eller cross-browser-adfærd.

Variabler og secrets

Trin refererer værdier som ${VAR} og TOTP-seeds som ${totp:VAR}. Ikke-hemmelige defaults må ligge hos scenariet. Secrets kan gemmes i ejerens krypterede key store, når scenariet oprettes; single-run overrides sendt til run_app_scenario flettes for den kørsel og gemmes ikke.

Placer ikke bogstavelige adgangskoder, tokens eller TOTP-seeds i trintekst, scenariebeskrivelser, screenshots eller issue-eksporter. For engangskoder via e-mail kræver handlingen email_otp en aktiv, udtrykkeligt tilsluttet Gmail-integration for scenarieejeren.

Nyttige assertions

assert_text verificerer forventet synlig tekst.
assert_no_error tjekker indbyggede eller medfølgende fejlfraser.
assert_visual sammenligner en perceptual hash med en gemt baseline.
assert_stable sampler en region for uventet flimren eller forsvinden.
assert_progress verificerer, at en streamingregion fortsætter med at ændre sig i en minimumperiode.
network kan afbryde og gendanne tester VM’s netværk til recovery-tests.

Visuelle og tidsmæssige assertions er heuristikker. Juster tærskler mod stabile testdata og gennemgå optagede frames, før du behandler drift som produktfejl.

Direkte og optaget test

Til udforskende arbejde styrer du VM med desktop_open_url, desktop_screenshot, desktop_click, desktop_type og relaterede desktopværktøjer. Brug start_app_test, record_app_test_step og finish_app_test, når den manuelle sekvens skal blive en revisionsbar kørsel.

annotate_screenshot kan tilføje mærkede bokse til evidens. En annotation forklarer, hvad en reviewer skal inspicere; den beviser ikke i sig selv, at elementet virkede.

Operationelle bemærkninger

Tester VMs genbruges per app/host. Skaler tester pool til parallel arbejde i stedet for at oprette vilkårlige dubletter.
Standardtesteren har ingen ekstra persistencedisk. Anmod kun om persistence, når tilstand skal overleve en genstart, og accepter længere first boot.
En klient-timeout annullerer ikke nødvendigvis backend-arbejde; inspicer kørslen, før du prøver igen.
Hold rapporter private, medmindre screenshots og diagnostik er gennemgået for følsomme data.