Testiranje UI aplikacije

OpenFactory može u upravljanim desktop tester VMs pokretati ponovno upotrebljive tijek rada u pregledniku. Aplikaciju može implementirati OpenFactory ili može biti hostana bilo gdje do čega tester VM može doći.

Scenariji kombiniraju semantičke radnje poput open, click, type, key, wait i assert sa snimkama ekrana, dijagnostikom preglednika i zabilježenim presudom. Najbolji su za poznati korisnički flow; za ograničeno istraživanje koristite autonomous walker.

Stvaranje i pokretanje scenarija

Dobijte tester VM aplikacije:


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

Zatim spremite scenarij čiji koraci koriste smislene oznake na ekranu:


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

Koristite create_app_scenario, zatim pokrenite vraćeni ID scenarija s run_app_scenario. Prvo pokretanje elemente razrješava putem OmniParser. Kasnija pokretanja mogu ponovno upotrijebiti ojačanu cache elemenata i ponovno razriješiti samo promijenjene korake. Pri dijagnosticiranju rezultata provjerite je li svaki korak bio iz cache ili parsiran.

Što znači uspješno pokretanje

Izvještaj se računa kao validacija samo kada:

njegov status je passed;
ciljao je na namijenjeno okruženje i reviziju;
završila se eventualna staging-protection i prijava u aplikaciju; i
assertions su se izvršile unutar produkta, a ne na stranici za prijavu ili zaštitu.

Uspješan scenarij pokazuje samo deklarirani flow i assertions. Ne dokazuje potpunu ispravnost aplikacije, pristupačnost, sigurnost ili ponašanje cross-browser.

Varijable i secrets

Koraci referenciraju vrijednosti kao ${VAR} i TOTP seeds kao ${totp:VAR}. Zadane vrijednosti koje nisu secret mogu ostati uz scenarij. Secrets se mogu spremiti u šifrirani key store vlasnika pri stvaranju scenarija; single-run overrides predani u run_app_scenario spajaju se za to pokretanje i ne spremaju se trajno.

Ne stavljajte doslovne lozinke, tokene ili TOTP seeds u tekst koraka, opise scenarija, snimke ekrana ili izvoz issue. Za jednokratne kodove iz e-pošte akcija email_otp zahtijeva aktivnu i izričito povezanu Gmail integraciju za vlasnika scenarija.

Korisne assertions

assert_text provjerava očekivani vidljivi tekst.
assert_no_error provjerava ugrađene ili dostavljene fraze grešaka.
assert_visual uspoređuje perceptual hash sa spremljenom baseline.
assert_stable uzorkuje regiju zbog neočekivanog treperenja ili nestanka.
assert_progress provjerava da se stream regija i dalje mijenja minimalno razdoblje.
network može prekinuti i vratiti mrežu tester VM za testove oporavka.

Vizualne i vremenske assertions su heuristike. Pragove uskladite sa stabilnim testnim podacima i pregledajte snimljene okvire prije nego drift smatrate greškom produkta.

Izravno i snimljeno testiranje

Za istraživački rad upravljajte VM alatima desktop_open_url, desktop_screenshot, desktop_click, desktop_type i povezanim desktop alatima. Koristite start_app_test, record_app_test_step i finish_app_test kada ručni slijed treba postati auditabilno pokretanje.

annotate_screenshot može dokazima dodati označene okvire. Anotacija objašnjava što reviewer treba pregledati; sama po sebi ne dokazuje da je element radio.

Operativne napomene

Tester VMs se ponovno koriste po app/host. Za paralelni rad skalirajte tester pool umjesto stvaranja proizvoljnih duplikata.
Zadani tester nema dodatni persistence disk. Persistence zatražite samo kada stanje mora preživjeti reboot i prihvatite duže prvo pokretanje.
Timeout klijenta ne mora nužno otkazati backend rad; pregledajte pokretanje prije ponovnog pokušaja.
Izvještaje držite privatnima dok snimke i dijagnostika nisu pregledani zbog osjetljivih podataka.