Skip to Content
TestingAlkalmazás UI tesztelése

Alkalmazás UI tesztelése

Az OpenFactory kezelt desktop tester VMs-ben futtathat újrahasználható böngészős workflow-kat. Az alkalmazást telepítheti az OpenFactory, vagy bárhol hostolható, ahová a tester VM elér.

A forgatókönyvek open, click, type, key, wait és assert jellegű szemantikus műveleteket egyesítenek képernyőképekkel, böngésződiagnosztikával és rögzített ítélettel. Ismert felhasználói flow-hoz illenek; korlátozott felfedezéshez használja az autonomous walker eszközt.

Forgatókönyv létrehozása és futtatása

Szerezze be az alkalmazás tester VM-jét:

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

Ezután mentse el a forgatókönyvet, amelynek lépései értelmes képernyőcímkéket használnak:

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

Használja a create_app_scenario hívást, majd a visszaadott forgatókönyv ID-t futtassa a run_app_scenario eszközzel. Az első futás az OmniParseren keresztül oldja fel az elemeket. A későbbi futások újrahasználhatják a megerősített element cache-t, és csak a megváltozott lépéseket oldják fel újra. Eredmény diagnosztizálásakor nézze meg, mely lépés cache-ből jött, és melyet parse-oltak.

Mit jelent a sikeres futás

A jelentés csak akkor számít validációnak, ha:

  • a status értéke passed;
  • a szándékolt környezetet és revíziót célozta;
  • a staging-protection és az alkalmazásba való bejelentkezés lefutott; és
  • az assertions a terméken belül futottak, nem bejelentkezési vagy védelmi oldalon.

A sikeres forgatókönyv csak a deklarált flow-t és assertions-t mutatja. Nem bizonyítja az alkalmazás teljes helyességét, akadálymentességét, biztonságát vagy cross-browser viselkedését.

Változók és secrets

A lépések ${VAR} formában hivatkoznak értékekre, a TOTP seeds ${totp:VAR} formában szerepelnek. A nem secret alapértékek a forgatókönyvnél maradhatnak. A secrets a tulajdonos titkosított key store-jában tárolhatók a forgatókönyv létrehozásakor; a run_app_scenario felé adott single-run overrides az adott futásra olvadnak össze, és nem maradnak meg.

Ne tegyen szó szerinti jelszavakat, tokeneket vagy TOTP seeds értékeket lépésszövegbe, forgatókönyv-leírásokba, képernyőképekbe vagy issue exportokba. E-mailes egyszeri kódokhoz az email_otp művelet aktív, kifejezetten csatlakoztatott Gmail integrációt vár a forgatókönyv tulajdonosától.

Hasznos assertions

  • Az assert_text az elvárt látható szöveget ellenőrzi.
  • Az assert_no_error a beépített vagy megadott hibaüzeneteket nézi.
  • Az assert_visual perceptual hash-t hasonlít össze tárolt baseline-nal.
  • Az assert_stable egy régiót mintavételez váratlan villogás vagy eltűnés miatt.
  • Az assert_progress ellenőrzi, hogy egy stream régió minimum ideig tovább változik.
  • A network megszakíthatja és visszaállíthatja a tester VM hálózatát helyreállítási tesztekhez.

A vizuális és időbeli assertions heurisztikák. Állítsa be a küszöböket stabil tesztadatokhoz, és nézze meg a rögzített képkockákat, mielőtt a driftet termékhibának tekintené.

Közvetlen és rögzített tesztelés

Felfedező munkához irányítsa a VM-et a desktop_open_url, desktop_screenshot, desktop_click, desktop_type és kapcsolódó desktop eszközökkel. Használja a start_app_test, record_app_test_step és finish_app_test hívásokat, ha a kézi sorozat auditálható futássá kell váljon.

Az annotate_screenshot címkézett dobozokat adhat a bizonyítékhoz. Az annotáció elmagyarázza, mit kell a reviewernek megvizsgálnia; önmagában nem bizonyítja, hogy az elem működött.

Üzemeltetési megjegyzések

  • A tester VMs app/host szerint újrahasználódnak. Párhuzamos munkához skálázza a tester poolt véletlenszerű duplikátumok helyett.
  • Az alapértelmezett testernek nincs extra persistence lemeze. Persistence-t csak akkor kérjen, ha az állapotnak reboot után is meg kell maradnia, és számítson hosszabb első bootra.
  • Az ügyfél timeout nem feltétlenül szakítja meg a backend munkát; ismételt próba előtt nézze meg a futást.
  • A jelentéseket tartsa privátnak, amíg a képernyőképek és diagnosztika nem mentek át érzékeny adat ellenőrzésen.

Kapcsolódó