Testarea UI a aplicației
OpenFactory poate rula fluxuri de lucru reutilizabile în browser în desktop tester VMs administrate. Aplicația poate fi implementată de OpenFactory sau găzduită oriunde tester VM poate ajunge.
Scenariile combină acțiuni semantice precum open, click, type, key, wait și assert cu capturi de ecran, diagnostic de browser și un verdict înregistrat. Sunt potrivite pentru un flow de utilizator cunoscut; pentru descoperire limitată folosiți autonomous walker.
Crearea și rularea unui scenariu
Obțineți tester VM al aplicației:
ensure_tester_vm(app="my-app", app_url="https://staging.example.com")Apoi salvați un scenariu al cărui pași folosesc etichete pe ecran cu sens:
[
{ "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" }
]Folosiți create_app_scenario, apoi rulați ID-ul de scenariu returnat cu run_app_scenario.
Prima rulare rezolvă elementele prin OmniParser. Rulările ulterioare pot reutiliza cache-ul
de elemente întărit și re-rezolvă doar pașii schimbați. La diagnosticarea unui rezultat, verificați
dacă fiecare pas a venit din cache sau a fost parsat.
Ce înseamnă o rulare reușită
Un raport contează ca validare doar când:
- statusul este
passed; - a vizat mediul și revizia intenționate;
- s-au încheiat staging-protection și autentificarea în aplicație, dacă era cazul; și
- assertions au rulat în interiorul produsului, nu pe o pagină de login sau de protecție.
Un scenariu reușit demonstrează doar flow-ul și assertions declarate. Nu stabilește corectitudinea completă a aplicației, accesibilitatea, securitatea sau comportamentul cross-browser.
Variabile și secrets
Pașii referă valori ca ${VAR} și TOTP seeds ca ${totp:VAR}. Valorile implicite care nu sunt
secret pot rămâne la scenariu. Secrets pot fi stocate în key store criptat al proprietarului la
crearea scenariului; single-run overrides transmise la run_app_scenario se combină pentru acea
rulare și nu sunt păstrate.
Nu puneți parole, tokeni sau TOTP seeds literale în textul pasului, descrierile scenariului,
capturile de ecran sau exporturile de issue. Pentru coduri unice primite prin e-mail, acțiunea
email_otp cere o integrare Gmail activă și conectată explicit pentru proprietarul scenariului.
Assertions utile
assert_textverifică textul vizibil așteptat.assert_no_errorverifică fraze de eroare integrate sau furnizate.assert_visualcompară un hash perceptual cu o baseline stocată.assert_stableeșantionează o regiune pentru pâlpâire sau dispariție neașteptată.assert_progressverifică că o regiune în streaming continuă să se schimbe un interval minim.networkpoate întrerupe și restabili rețeaua tester VM pentru teste de recuperare.
Assertions vizuale și temporale sunt euristici. Reglați pragurile pe date de test stabile și inspectați cadrele capturate înainte să tratați drift-ul ca defect de produs.
Testare directă și înregistrată
Pentru lucru exploratoriu, conduceți VM-ul cu desktop_open_url, desktop_screenshot,
desktop_click, desktop_type și instrumente desktop aferente. Folosiți start_app_test,
record_app_test_step și finish_app_test când secvența manuală trebuie să devină o rulare
auditabilă.
annotate_screenshot poate adăuga casete etichetate la dovezi. O adnotare explică ce ar trebui
să inspecteze reviewer-ul; nu dovedește de una singură că elementul a funcționat.
Note operaționale
- Tester VMs sunt reutilizate pe app/host. Scalați tester pool pentru lucru paralel în loc să creați duplicate arbitrare.
- Testerul implicit nu are disc persistence suplimentar. Cereți persistence doar când starea trebuie să supraviețuiască unui reboot și acceptați un prim boot mai lung.
- Un timeout de client nu anulează neapărat munca din backend; inspectați rularea înainte de reîncercare.
- Păstrați rapoartele private până când capturile și diagnostica au fost verificate pentru date sensibile.