Lietotnes UI testēšana

OpenFactory var palaist atkārtojamus pārlūka workflow pārvaldītās desktop tester VM. Lietotni var izvietot ar OpenFactory vai hostēt jebkur, kur tester VM var sasniegt.

Scenāriji apvieno semantiskas darbības, piemēram, open, click, type, key, wait un assert, ar ekrānuzņēmumiem, pārlūka diagnostiku un ierakstītu spriedumu. Tie der zināmai lietotāja plūsmai; ierobežotai atklāšanai izmantojiet autonomous walker.

Izveidot un palaist scenāriju

Iegūstiet lietotnes tester VM:


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

Pēc tam saglabājiet scenāriju, kura soļi izmanto jēgpilnas ekrāna etiķetes:


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

Izmantojiet create_app_scenario, pēc tam atgrieztā scenario ID palaidiet ar run_app_scenario. Pirmais palaišanas reizes elements atrisina caur OmniParser. Vēlākās palaišanas var atkārtoti izmantot nostiprināto elementu cache un atrisināt no jauna tikai mainītos soļus. Diagnostikā pārskatiet, vai katrs solī tika cached vai parsed.

Ko nozīmē sekmīga palaišana

Atskaite tiek uzskatīta par validāciju tikai tad, ja:

statuss ir passed;
mērķis bija paredzētā vide un revision;
staging-protection un lietotnes pieteikšanās pabeigta; un
assertions izpildījās produktā, ne pieteikšanās vai aizsardzības lapā.

Sekmīgs scenārijs parāda tikai deklarēto plūsmu un assertions. Tas neapstiprina pilnīgu lietotnes pareizību, pieejamību, drošību vai uzvedību dažādās pārlūkprogrammās.

Mainīgie un secrets

Soļi atsaucas uz vērtībām kā ${VAR} un TOTP seeds kā ${totp:VAR}. Neslepenie noklusējumi var būt scenārijā. Secrets var glabāt īpašnieka šifrētajā key store, izveidojot scenāriju; vienreizējie override, nodoti run_app_scenario, tiek apvienoti šai palaišanai un netiek saglabāti.

Nelieciet literal paroles, token vai TOTP seeds soļu tekstā, scenāriju aprakstos, ekrānuzņēmumos vai issue export. E-pastā nosūtītajiem vienreizējiem kodiem email_otp darbībai vajadzīga aktīva, skaidri pievienota Gmail integrācija scenārija īpašniekam.

Noderīgas assertions

assert_text pārbauda gaidāmo redzamo tekstu.
assert_no_error pārbauda built-in vai norādītās error frāzes.
assert_visual salīdzina perceptual hash ar saglabātu baseline.
assert_stable ņem paraugus no reģiona negaidītai flicker/disappearance.
assert_progress pārbauda, ka streaming reģions turpina mainīties vismaz noteiktu laiku.
network var pārtraukt un atjaunot tester VM tīklu recovery testiem.

Visual un temporal assertions ir heuristikas. Pielāgojiet slieksņus pret stabilu test data un pārskatiet uzņemtos kadrus pirms drift uzskatīšanas par produkta defektu.

Tiešā un ierakstītā testēšana

Izpētes darbam vadiet VM ar desktop_open_url, desktop_screenshot, desktop_click, desktop_type un saistītajiem desktop rīkiem. Izmantojiet start_app_test, record_app_test_step un finish_app_test, ja manuālajai secībai jākļūst par pārbaudāmu palaišanu.

annotate_screenshot var pievienot marķētas kastes evidence. Anotācija skaidro, ko recenzentam jāpārbauda; pati tā nepierāda, ka elements darbojās.

Operacionālās piezīmes

Tester VM tiek atkārtoti izmantotas katram app/host. Palieliniet tester pool paralēlam darbam, nevis veidojiet nejaušus dublikātus.
Noklusējuma tester nav papildu persistence diska. Request persistence tikai tad, ja state jāizdzīvo reboot, un pieņemiet ilgāku first boot.
Klienta timeout ne obligāti atceļ backend darbu; pārskatiet run pirms atkārtotas mēģināšanas.
Turiet reports private, ja vien ekrānuzņēmumi un diagnostika nav pārskatīti attiecībā uz sensitīviem datiem.