Testy UI aplikacji

OpenFactory może uruchamiać wielokrotnego użytku workflow w przeglądarce w zarządzanych desktop tester VMs. Aplikacja może być wdrożona przez OpenFactory lub hostowana wszędzie, gdzie tester VM ma dostęp.

Scenariusze łączą akcje semantyczne takie jak open, click, type, key, wait i assert ze zrzutami ekranu, diagnostyką przeglądarki i zapisanym werdyktem. Sprawdzają się przy znanym flow użytkownika; do ograniczonego odkrywania użyj autonomous walker.

Tworzenie i uruchamianie scenariusza

Uzyskaj tester VM aplikacji:


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

Następnie zapisz scenariusz, którego kroki używają sensownych etykiet na ekranie:


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

Użyj create_app_scenario, a następnie uruchom zwrócone ID scenariusza przez run_app_scenario. Pierwsze uruchomienie rozpoznaje elementy przez OmniParser. Kolejne mogą ponownie użyć utwardzonej cache elementów i rozwiązać tylko zmienione kroki. Przy diagnozowaniu wyniku sprawdź, czy każdy krok pochodził z cache, czy został sparsowany.

Co oznacza zaliczony przebieg

Raport liczy się jako walidacja tylko gdy:

jego status to passed;
wskazywał zamierzone środowisko i rewizję;
zakończyła się ewentualna staging-protection i logowanie do aplikacji; oraz
assertions wykonały się w produkcie, a nie na stronie logowania lub ochrony.

Zaliczony scenariusz pokazuje wyłącznie zadeklarowany flow i assertions. Nie dowodzi pełnej poprawności aplikacji, dostępności, bezpieczeństwa ani zachowania cross-browser.

Zmienne i secrets

Kroki odwołują się do wartości jako ${VAR} i seedów TOTP jako ${totp:VAR}. Domyślne wartości niebędące secretami mogą być przy scenariuszu. Secrets można przechowywać w szyfrowanym key store właściciela przy tworzeniu scenariusza; single-run overrides przekazane do run_app_scenario są scalane na ten przebieg i nie są trwale zapisywane.

Nie umieszczaj dosłownych haseł, tokenów ani seedów TOTP w tekście kroku, opisach scenariusza, zrzutach ekranu ani eksportach issue. Dla jednorazowych kodów z e-maila akcja email_otp wymaga aktywnej, wyraźnie podłączonej integracji Gmail dla właściciela scenariusza.

Przydatne assertions

assert_text weryfikuje oczekiwany widoczny tekst.
assert_no_error sprawdza wbudowane lub dostarczone frazy błędów.
assert_visual porównuje perceptual hash z zapisaną baseline.
assert_stable próbkuje region pod kątem niespodziewanego migotania lub zniknięcia.
assert_progress weryfikuje, że region streamingu nadal się zmienia przez minimalny okres.
network może przerwać i przywrócić sieć tester VM na potrzeby testów recovery.

Wizualne i czasowe assertions to heurystyki. Dostosuj progi do stabilnych danych testowych i przejrzyj zarejestrowane klatki, zanim uznasz drift za wadę produktu.

Testy bezpośrednie i nagrywane

Do pracy eksploracyjnej steruj VM przez desktop_open_url, desktop_screenshot, desktop_click, desktop_type i powiązane narzędzia desktop. Użyj start_app_test, record_app_test_step i finish_app_test, gdy ta ręczna sekwencja ma stać się audytowalnym przebiegiem.

annotate_screenshot może dodać opisane ramki do dowodów. Adnotacja wyjaśnia, co reviewer powinien sprawdzić; sama w sobie nie dowodzi, że element zadziałał.

Uwagi operacyjne

Tester VMs są współdzielone per app/host. Skaluj tester pool przy pracy równoległej zamiast tworzyć dowolne duplikaty.
Domyślny tester nie ma dodatkowego dysku persistence. Żądaj persistence tylko gdy stan musi przetrwać reboot i zaakceptuj dłuższy first boot.
Timeout klienta nie musi anulować pracy backend; sprawdź przebieg przed ponowną próbą.
Trzymaj raporty prywatne, chyba że zrzuty ekranu i diagnostyka zostały sprawdzone pod kątem danych wrażliwych.