Testiranje UI aplikacije

OpenFactory lahko v upravljanih desktop tester VMs izvaja ponovno uporabne delovne tokove v brskalniku. Aplikacijo lahko namesti OpenFactory ali pa gostuje kjerkoli, kamor tester VM doseže.

Scenariji združujejo semantična dejanja, kot so open, click, type, key, wait in assert, s posnetki zaslona, diagnostiko brskalnika in zabeleženim sodbom. Primerni so za znan uporabniški flow; za omejeno raziskovanje uporabite autonomous walker.

Ustvarjanje in zagon scenarija

Pridobite tester VM aplikacije:


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

Nato shranite scenarij, katerega koraki uporabljajo smiselne oznake na zaslonu:


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

Uporabite create_app_scenario, nato pa s run_app_scenario zaženite vrnjeni ID scenarija. Prvi zagon elemente razreši prek OmniParser. Kasnejši zagoni lahko znova uporabijo utrjeno cache elementov in znova razrešijo le spremenjene korake. Pri diagnosticiranju rezultata preverite, ali je bil vsak korak iz cache ali razčlenjen.

Kaj pomeni uspešen zagon

Poročilo velja za validacijo le, če:

je njegov status passed;
je ciljalo na predvideno okolje in revizijo;
se je morebitna staging-protection in prijava v aplikacijo zaključila; in
so assertions tekle znotraj produkta, ne na prijavni ali zaščitni strani.

Uspešen scenarij pokaže le deklarirani flow in assertions. Ne dokazuje popolne pravilnosti aplikacije, dostopnosti, varnosti ali vedenja cross-browser.

Spremenljivke in secrets

Koraki se sklicujejo na vrednosti kot ${VAR} in TOTP seeds kot ${totp:VAR}. Privzete vrednosti, ki niso secret, lahko ostanejo pri scenariju. Secrets lahko shranite v šifriran key store lastnika ob ustvarjanju scenarija; single-run overrides, posredovani v run_app_scenario, se združijo za ta zagon in se ne shranijo trajno.

Ne vnašajte dobesednih gesel, tokenov ali TOTP seeds v besedilo koraka, opise scenarija, posnetke zaslona ali izvoze issue. Za enkratne kode iz e-pošte akcija email_otp zahteva aktivno in izrecno povezano integracijo Gmail za lastnika scenarija.

Uporabne assertions

assert_text preveri pričakovano vidno besedilo.
assert_no_error preveri vgrajene ali dodane fraze napak.
assert_visual primerja perceptual hash s shranjeno baseline.
assert_stable vzorči regijo zaradi nepričakovanega utripanja ali izginotja.
assert_progress preveri, da se stream regija še naprej spreminja vsaj minimalno obdobje.
network lahko prekine in obnovi omrežje tester VM za teste obnovitve.

Vizualne in časovne assertions so heuristike. Pragove uskladite s stabilnimi testnimi podatki in preglejte zajete sličice, preden drift obravnavate kot napako produkta.

Neposredno in snemljeno testiranje

Za raziskovalno delo upravljajte VM z desktop_open_url, desktop_screenshot, desktop_click, desktop_type in sorodnimi desktop orodji. Uporabite start_app_test, record_app_test_step in finish_app_test, ko naj ročna sekvenca postane auditabilen zagon.

annotate_screenshot lahko dokazom doda označena polja. Anotacija pojasni, kaj naj reviewer pregleda; sama po sebi ne dokazuje, da je element deloval.

Operativne opombe

Tester VMs se ponovno uporabljajo na app/host. Za vzporedno delo razširite tester pool namesto ustvarjanja poljubnih dvojnikov.
Privzeti tester nima dodatnega persistence diska. Persistence zahtevajte le, če mora stanje preživeti reboot, in sprejmite daljši prvi boot.
Timeout odjemalca ne prekliče nujno dela v ozadju; pred ponovnim poskusom preglejte zagon.
Poročila naj ostanejo zasebna, dokler posnetki in diagnostika niso pregledani glede občutljivih podatkov.