App-UI-tester

OpenFactory kan köra återanvändbara browserworkflows i hanterade desktop tester VMs. Applikationen kan deployas av OpenFactory eller hostas var tester VM når.

Scenarier kombinerar semantiska åtgärder som open, click, type, key, wait och assert med skärmdumpar, browserdiagnostik och ett registrerat utslag. De passar bäst för ett känt användarflöde; använd autonomous walker för avgränsad upptäckt.

Skapa och köra ett scenario

Skaffa appens tester VM:


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

Spara sedan ett scenario vars steg använder meningsfulla 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" }
]

Använd create_app_scenario och kör sedan det returnerade scenario-ID:t med run_app_scenario. Första körningen löser element via OmniParser. Senare körningar kan återanvända den härdade elementcachen och bara lösa om ändrade steg. Granska om varje steg var cachat eller parsat när du diagnostiserar ett resultat.

Vad en godkänd körning betyder

En rapport räknas som validering endast när:

status är passed;
den riktade mot avsedda miljö och revision;
eventuell staging-protection och applikationsinloggning slutfördes; och
assertions kördes inuti produkten, inte på en inloggnings- eller skyddssida.

Ett godkänt scenario visar bara det deklarerade flödet och assertions. Det visar inte full applikationskorrekthet, tillgänglighet, säkerhet eller cross-browser-beteende.

Variabler och secrets

Steg refererar värden som ${VAR} och TOTP-seeds som ${totp:VAR}. Icke-hemliga defaults får ligga hos scenariot. Secrets kan lagras i ägarens krypterade key store när scenariot skapas; single-run overrides som skickas till run_app_scenario slås ihop för den körningen och sparas inte.

Placera inte bokstavliga lösenord, tokens eller TOTP-seeds i stegtext, scenariobeskrivningar, skärmdumpar eller issue-exporter. För engångskoder via e-post kräver åtgärden email_otp en aktiv, uttryckligen ansluten Gmail-integration för scenarioägaren.

Användbara assertions

assert_text verifierar förväntad synlig text.
assert_no_error kontrollerar inbyggda eller medföljande felmeddelanden.
assert_visual jämför en perceptual hash med en lagrad baseline.
assert_stable samplar en region för oväntad flimmer eller försvinnande.
assert_progress verifierar att en streamingregion fortsätter ändras under en minimiperiod.
network kan avbryta och återställa tester VM:s nätverk för recovery-tester.

Visuella och tidsmässiga assertions är heuristiker. Justera trösklar mot stabil testdata och granska inspelade frames innan du behandlar drift som produktfel.

Direkt och inspelad testning

För utforskande arbete styr du VM med desktop_open_url, desktop_screenshot, desktop_click, desktop_type och relaterade desktopverktyg. Använd start_app_test, record_app_test_step och finish_app_test när den manuella sekvensen ska bli en granskningsbar körning.

annotate_screenshot kan lägga till märkta rutor i bevis. En annotering förklarar vad en granskare ska titta på; den bevisar inte i sig att elementet fungerade.

Operativa anteckningar

Tester VMs återanvänds per app/host. Skala tester pool för parallellt arbete i stället för att skapa godtyckliga dubbletter.
Standardtestern har ingen extra persistenceskiva. Begär persistence endast när tillstånd måste överleva en omstart och acceptera längre first boot.
En klienttimeout avbryter inte nödvändigtvis backendarbete; inspektera körningen innan du försöker igen.
Håll rapporter privata om inte skärmdumpar och diagnostik granskats för känsliga data.