Dobički:
- Sposobnost izdelave robustne testne kode uporabniškega vmesnika z umetno inteligenco, vključno s podatkovnim testom, odprtim čakanjem in potrditvijo, ki preveri dejanski rezultat uporabnika
- Sposobnost izogibanja krhkim testom (slab izbirnik, slepo čakanje) in omogoča enostavno vzdrževanje testov v strukturi Page Object Model
- Zmožnost testiranja vsakega testa uporabniškega vmesnika, ki nastane z zlomom kode, ter odkrivanja in popravljanja lažno opravljenih testov
Vsakega klika, vsakega izpolnjevanja obrazca, vsakega prehoda strani, ki ga uporabnik naredi v brskalniku, ni mogoče znova in znova preizkusiti ročno – zato obstaja avtomatizacija testiranja uporabniškega vmesnika (uporabniški vmesnik; ti testi posnemajo vedenje uporabnika s programskim poganjanjem pravega brskalnika). Selenium, Playwright in Cypress so najpogostejša orodja za to delo. Umetna inteligenca (AI) je zelo usposobljena za pisanje kode za ta orodja: vi opišete testni primer, AI vam ponudi osnutek delujočega skripta za avtomatizacijo. Toda tukaj ponovno pride v poštev osrednje opozorilo tega modula: testna koda uporabniškega vmesnika, ki jo ustvari umetna inteligenca, so lahko pogosto krhki testi, ki »zasvetijo zeleno, vendar preverijo napačno stvar« ali plapolajo v vetru. Vaša naloga ni zagnati to kodo, ampak zagotoviti, da dejansko robustno preverja pravo stvar.
V tej enoti želimo izdelati robustne, vzdržljive in resnično potrjene teste uporabniškega vmesnika z umetno inteligenco; Naučili se boste izogibati krhkim testom.
Trije stebri trdnega testiranja uporabniškega vmesnika
1. Pravilen lokator elementov. Preizkus uporablja izbirnik za iskanje elementa na strani. Umetna inteligenca pogosto ustvari krhke izbirnike: dolge poti XPath (naslov je preveč odvisen od strukture strani), izbirnike, ki temeljijo na imenih razredov CSS (prekinejo se ob spremembi zasnove). Robusten način so stabilni atributi, kot je data-testid, ki jih je razvijalec dodal za testiranje. To izrecno naložite AI.
2. Eksplicitno čakanje. Vir številka ena ranljivosti pri testiranju uporabniškega vmesnika je čas. Stalno spanje(3) (čakanje na slepo) je slaba praksa: včasih ni dovolj, včasih izgublja čas. Pravilen način je uporaba eksplicitnega čakanja, ki pravi "počakaj, dokler se ne pojavi ta element". Dramatik to počne večinoma samodejno; V Seleniumu morate to izrecno zahtevati.
3. Smiselna trditev. Preizkus mora preveriti rezultat, ki ga bo uporabnik dejansko videl – na primer »številka naročila se je pojavila na zaslonu«, ne le »stran naložena«. Če test, ki ga je izdelal AI, nima trditve ali je nepomemben, ta test ustvari psevdo-prepust (1. enota).
Pozor: Ko prvič vidite preizkus uporabniškega vmesnika, ustvarjen z umetno inteligenco, preverite največ tri stvari: ali so izbirniki odobreni (data-testid), ali čakanje (brez slepega spanja) in ali trditev preverja dejanski rezultat uporabnika? Če so ti trije v redu, je test verjetno soliden.
Objektni model strani
Ko testi postajajo večji, pisanje izbirnikov znotraj vsakega testa postane nočna mora za vzdrževanje. Page Object Model (POM — načrtovalni vzorec, ki zbira izbirnike in dejanja za vsako stran/zaslon v en razred) ohranja izbirnik na enem mestu; Ko se vmesnik spremeni, ga posodobite v eni sami datoteki. Naj AI izdela teste v strukturi POM in ne neposredno; To bistveno olajša vzdrževanje.
Šibek poziv/močan poziv
Slabo: "Napišite test Selenium za stran za prijavo."
Močno: "Napišite preizkus toka prijave s Playwrightom (TypeScript). Izbirniki uporabljajo samo data-testid; ne uporabljajte nadzora nad tem, kaj uporabnik vidi, ne naslova strani."
Močan poziv; Orodje ponuja jezik, politiko izbirnika, strategijo čakanja, arhitekturo (POM) in ekspresivno pričakovanje potrditve.
Testni podatki in neodvisnost okolja
Trden preizkus uporabniškega vmesnika ni le pravilno napisan, ampak tudi gradi in čisti lastne testne podatke. Testi, ki jih ustvari umetna inteligenca, se pogosto povezujejo z uporabnikom ali zapisom, za katerega se domneva, da že obstaja v okolju (»prijavite se kot skrbniški uporabnik«). Ta predpostavka se prekine, ko se test izvaja v drugem okolju ali po drugem testu (problem odvisnosti od naročila v enoti 9). Resnica je, da vsak test ustvari podatke, ki jih potrebuje na začetku testa (ali jih pripravi s klicem API-ja) in jih očisti na koncu. Umetni inteligenci izrecno naročite, naj "nastavi vse podatke, od katerih je ta test odvisen znotraj testa; ne predpostavljajte že pripravljenih podatkov od zunaj."
Druga kritična točka je, da testiranja uporabniškega vmesnika ne izvajate z resničnimi uporabniškimi podatki. Če je v testnem okolju uporabljena kopija produkcijske baze podatkov, so ti zapisi podatki resničnih oseb; posnetki zaslona in preskusni posnetki lahko razkrijejo te podatke. Uporabite sintetične (izmišljene) testne račune; ščiti zaupnost in omogoča ponovljivost testov. Izvajanje testa »preklic naročila« z dejanskim računom stranke je tako etična kot operativna napaka.
Namig: preizkusov uporabniškega vmesnika naj bo čim manj; Prepustite dejansko preverjanje API-ju in testom enote, ki so hitri in stabilni. Testiranje uporabniškega vmesnika je drago in krhko – uporabite ga samo za potrjevanje resničnega pretoka uporabnikov od konca do konca (preizkusite logiko piramide).
Primerjava vozil
funkcija
selen
dramatik
cipresa
jezikov
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
samodejno stanje pripravljenosti
Ne (ročno)
Da (močno)
ja
Več brskalnikov
široka
Chromium/Firefox/WebKit
Prevladuje krom
nagnjenost k krhkosti
Visoka (ročna pripravljenost)
nizka
nizka
Enostavnost učenja
srednje
enostavno
enostavno
vzporedno delovanje
Potrebna mreža
vgrajena
Rezident/plačan
Ko od AI zahtevate kodo, jasno povejte, kateremu vozilu pripada; V nasprotnem primeru lahko ustvari zmedeno, nedelujočo kodo.
Štiri predloge za kopiranje
1) Ustvarjanje trdnega testa uporabniškega vmesnika:
Vaša vloga: višji inženir za avtomatizacijo testiranja. Pišite teste z [orodjem + jezikom] za naslednji tok: [tok]. Pravila: - Samo izbirniki data-testid; Uporaba razreda XPath/CSS. - Brez slepega spanca; Uporabite izrecno/samodejno čakanje. - Uporabite predmetni model strani. - Naj vsaka trditev preveri dejanski rezultat uporabnika. Na začetku vsakega preizkusa komentirajte, katera merila sprejemljivosti preverjate.
2) Nadzor krhkosti:
Preglejte naslednji test uporabniškega vmesnika glede krhkosti: - Ali obstaja nestabilen izbirnik (dolg
3) Pretvorba v predmet strani:
Pretvorite naslednjo navadno preskusno kodo v strukturo Page Object Model. Premaknite izbirnike in dejanja v razrede strani; Naj testna datoteka bere samo potek scenarija. [Orodje/jezik].Koda: [prilepi kodo]
4) Dokaz o psevdoprehodu:
Dokažite, da ta preizkus uporabniškega vmesnika dejansko potrjuje: Katero posamezno spremembo v kodi aplikacije naredim, da bo ta preizkus RDEČ? Če ne najdete spremembe, ki bi pokvarila test, je test neustrezen; dodaj manjkajoče trditve. Test: [prilepi test]
trije mini kovčki
Primer 1 – Osvoboditev od krhkega selektorja. Od 40 testov, ki jih je ena ekipa izdelala z AI, jih je bilo 70 % pokvarjenih po posodobitvi vmesnika; nobeden od njih ni bil dejanski hrošč, vsi so bili krhki izbirniki XPath. Ekipa je teste pretvorila v podatkovno bazo testov s predlogo "preverjanje krhkosti". V naslednjih treh posodobitvah vmesnika je število lažnih prekinitev padlo na nič; čas vzdrževanja se je zmanjšal s 6 ur na 30 minut na teden.
2. primer – preizkus uporabniškega vmesnika z lažnim prehodom. AI je izdelal test »dodaj v košarico«; test je bil zelen. Ko je bila zagnana predloga »lažnega dokaza prehoda«, se je zdelo, da test preverja samo klik gumba in naslov strani, nikoli pa ni preveril, ali se je števec košarice povečal ali ne. Tudi če je bila logika vozička popolnoma pokvarjena, je test uspel. Dodana resnična trditev (značka vozička je "1").
Primer 3 – Past slepega čakanja. V testu Selenium, ki ga je izdelal AI, je bilo po vsakem koraku spanje(2); 60 testov je trajalo 14 minut in se je kljub temu občasno pokvarilo. Po preklopu na odprto čakanje (počakajte, da element lahko kliknete) se je čas zmanjšal na 5 minut in krhkost je izginila. Čakanje na slepo je bilo počasno in nezanesljivo.
Pogoste napake
- Pristajanje na krhke selektorje. Uporaba dolgih XPathov, ki jih generira AI, kot so; Testi se zrušijo ob prvi spremembi vmesnika.
- Zapuščanje slepega `spanja`. "Reševanje" časovnega razporeda s fiksnim čakanjem; tako počasen kot neodločen.
- Trivialna trditev. Samo preverite, ali se je stran naložila; ne preverjanje dejanskega uporabniškega rezultata (fake-pass).
- Rasti brez POM. Porazdelite izbirnike vsakemu testu; Ročno posodabljanje na desetine datotek, ko se spremeni vmesnik.
- Brez navedbe orodja. Ne poveste AI, katero orodje/jezik želite; postaja neurejena, nedelujoča koda.
- Zaupanje, ko zaženete ustvarjeno kodo in prenesete. Brez testiranja z zlomom kode.
Če povzamem
Avtomatizacija testiranja uporabniškega vmesnika preveri vedenje uporabnika tako, da poganja dejanski brskalnik s programom. Umetna inteligenca hitro ustvari to kodo, vendar obstajata dve veliki pasti: občutljivi testi (slab izbirnik, slepo čakanje) in lažni preizkusi uspešnosti (nepopolna/trivialna trditev). Trije stebri trdnega testiranja uporabniškega vmesnika so izbirnik objave (data-testid), eksplicitno čakanje in trditev, ki preveri dejanski uporabniški rezultat. Testi, ustvarjeni v Page Object Modelu, radikalno poenostavljajo vzdrževanje. Preizkusite vsak ustvarjen test z vprašanjem "katera sprememba bo to pokvarila?"
Aplikacijska naloga
Izberite uporabniški tok iz lastnega projekta (npr. prijava ali iskanje). Umetna inteligenca naj napiše teste s predlogo »generiranje robustnega testa uporabniškega vmesnika«. Nato: (1) preverite in popravite izbirnike in počakajte s "preverjanjem krhkosti", (2) dokažite, da je vsak test dejansko potrjen s "dokazom psevdoprepustnosti", (3) zlomite kodo in opazujte, da se test obarva rdeče. Poročajte o številu izdelanih in popravljenih testov ter o številu ranljivosti in psevdoprepustov, ki ste jih našli.
kontrolni seznam
- [ ] AI sem jasno dal orodje, jezik, politiko izbirnika in arhitekturo (POM).
- [ ] Preveril sem, da so izbirniki podatkovno preizkušeni.
- [ ] Poskrbel sem za uporabo eksplicitnega/samodejnega čakanja namesto slepega spanja.
- [ ] Preveril sem, ali vsaka trditev preverja dejanski uporabniški rezultat.
- [ ] Vsak test sem preizkusil tako, da sem razbil kodo; Videl sem, da je postalo rdeče.
- [ ] Teste sem zbral v strukturi Page Object Model.