UI-тестування застосунків

OpenFactory can run reusable browser workflows in managed desktop tester VMs. Application may be deployed by OpenFactory or hosted anywhere tester VM can reach.

Scenarios combine semantic actions such as open, click, type, key, wait, assert with screenshots, browser diagnostics, recorded verdict. Best for known user flow; use autonomous walker for bounded discovery.

Create and run a scenario

Get app tester VM:


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

Then save scenario whose steps use meaningful on-screen labels:


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

Use create_app_scenario, then run returned scenario ID with run_app_scenario. First run resolves elements through OmniParser. Later runs can reuse hardened element cache and re-resolve only changed steps. Review whether each step cached or parsed when diagnosing result.

What a passing run means

Report counts as validation only when:

status is passed;
targeted intended environment and revision;
any staging-protection and application login completed; and
assertions ran inside product, not on login or protection page.

Passing scenario demonstrates only declared flow and assertions. Does not establish complete application correctness, accessibility, security, cross-browser behavior.

Variables and secrets

Steps reference values as ${VAR} and TOTP seeds as ${totp:VAR}. Non-secret defaults may live with scenario. Secrets can be stored in owner encrypted key store when scenario created; single-run overrides passed to run_app_scenario merged for that run and not persisted.

Do not place literal passwords, tokens, TOTP seeds in step text, scenario descriptions, screenshots, issue exports. For emailed one-time codes email_otp action requires active, explicitly connected Gmail integration for scenario owner.

Useful assertions

assert_text verifies expected visible text.
assert_no_error checks built-in or supplied error phrases.
assert_visual compares perceptual hash with stored baseline.
assert_stable samples region for unexpected flicker/disappearance.
assert_progress verifies streaming region continues changing for minimum period.
network can interrupt and restore tester VM network for recovery tests.

Visual and temporal assertions heuristics. Tune thresholds against stable test data and inspect captured frames before treating drift as product defect.

Direct and recorded testing

For exploratory work drive VM with desktop_open_url, desktop_screenshot, desktop_click, desktop_type, related desktop tools. Use start_app_test, record_app_test_step, finish_app_test when manual sequence should become auditable run.

annotate_screenshot can add labeled boxes to evidence. Annotation explains what reviewer should inspect; does not itself prove element worked.

Operational notes

Tester VMs reused per app/host. Scale tester pool for parallel work instead of creating arbitrary duplicates.
Default tester no extra persistence disk. Request persistence only when state must survive reboot and accept longer first boot.
Client timeout does not necessarily cancel backend work; inspect run before retrying.
Keep reports private unless screenshots and diagnostics reviewed for sensitive data.