Dobici:
- Sposobnost izrade robusnog UI koda za testiranje s umjetnom inteligencijom, uključujući data-testid, otvoreno čekanje i assert koji provjerava stvarni rezultat korisnika
- Sposobnost izbjegavanja krhkih testova (loš selektor, slijepo čekanje) i olakšavanje održavanja testova u strukturi modela stranice objekta
- Mogućnost testiranja svakog UI testa proizvedenog razbijanjem koda i otkrivanja i popravljanja lažno prošlih testova
Svaki klik, svako popunjavanje obrasca, svaka tranzicija stranice koju korisnik napravi u pretraživaču ne može se testirati iznova i iznova ručno — zato postoji automatizacija UI testa (korisnički interfejs; ovi testovi oponašaju ponašanje korisnika programskim pokretanjem pravog pretraživača). Selen, dramaturg i čempres su najčešći alati za ovaj posao. Umjetna inteligencija (AI) je visoko vješta u pisanju koda za ove alate: opisujete test slučaj, AI vam daje nacrt funkcionalne skripte za automatizaciju. Ali ovdje ponovo dolazi do izražaja centralno upozorenje ovog modula: UI testni kod koji AI proizvodi često može biti krhki test koji „svijetli zeleno, ali potvrđuju pogrešnu stvar“ ili klapaju na vjetru. Vaš posao nije da pokrenete ovaj kod, već da se uverite da on zaista robusno verifikuje pravu stvar.
U ovoj jedinici, cilj nam je da proizvedemo robusne, održive i istinski validirajuće UI testove sa AI; Naučit ćete izbjegavati krhke testove.
Tri stuba čvrstog UI testiranja
1. Ispravan lokator elemenata. Test koristi selektor da pronađe element na stranici. AI često proizvodi krhke selektore: duge XPath putanje (adresa previše ovisi o strukturi stranice), selektore zasnovane na imenima CSS klasa (prekid kada se dizajn promijeni). Robustan način su stabilni atributi poput data-testid koje je programer dodao za testiranje. Eksplicitno nametnite ovo AI.
2. Eksplicitno čekanje. Izvor broj jedan ranjivosti u UI testiranju je tajming. Stalno spavanje(3) (slijepo čekanje) je loša praksa: ponekad nije dovoljno, ponekad gubi vrijeme. Ispravan način je korištenje eksplicitnog čekanja, što kaže "čekaj dok se ovaj element ne pojavi". Dramaturg to radi uglavnom automatski; U Selenu to morate eksplicitno zahtijevati.
3. Smislena tvrdnja. Test bi trebao potvrditi rezultat koji će korisnik zaista vidjeti – poput „broj narudžbe se pojavio na ekranu“, a ne samo „stranica je učitana“. Ako test proizveden od strane AI nema tvrdnju ili je nevažan, taj test proizvodi pseudo prolaz (1. jedinica).
Oprez: Kada prvi put vidite UI generiran UI test, provjerite najviše tri stvari: da li su selektori predani (data-testid), jesu li uključeni (bez slijepog spavanja) i da li assert potvrđuje stvarni rezultat korisnika? Ako su ova tri u redu, test je vjerovatno solidan.
Objektni model stranice
Kako testovi rastu, pisanje selektora unutar svakog testa postaje noćna mora održavanja. Objektni model stranice (POM — obrazac dizajna koji prikuplja selektore i akcije za svaku stranicu/ekran u jednu klasu) drži selektor na jednom mjestu; Kada se interfejs promeni, ažurirate ga u jednoj datoteci. Neka AI proizvodi testove u POM strukturi, a ne direktno; To čini održavanje radikalno lakšim.
Slaba prompt / Jaka prompt
Slabo: "Napišite Selenium test za stranicu za prijavu."
Jaka: "Napišite test toka prijave sa Playwrightom (TypeScript). Selektori koriste samo data-testid; ne koriste kontrolu onoga što korisnik vidi, a ne naslov stranice."
Snažan prompt; Alat daje jezik, politiku selektora, strategiju čekanja, arhitekturu (POM) i ekspresivno očekivanje tvrdnje.
Test podataka i nezavisnost okoline
Čvrsti UI test ne samo da je ispravno napisan, već i gradi i čisti svoje vlastite testne podatke. Testovi generirani od umjetne inteligencije često se povezuju s korisnikom ili zapisom za koji se pretpostavlja da već postoji u okruženju („prijavite se kao korisnik administrator“). Ova pretpostavka se prekida kada se test izvodi u drugom okruženju ili nakon drugog testa (problem ovisnosti o redoslijedu u jedinici 9). Istina je da svaki test kreira podatke koji su mu potrebni na početku testa (ili ih priprema pomoću API poziva) i čisti ih na kraju. Eksplicitno uputite AI da "podesi sve podatke o kojima ovaj test zavisi unutar testa; nemojte pretpostavljati gotove podatke izvana."
Još jedna kritična tačka je da se UI testiranje ne vrši sa stvarnim korisničkim podacima. Ako se kopija proizvodne baze podataka koristi u testnom okruženju, ovi zapisi su podaci stvarnih osoba; snimci ekrana i testni snimci mogu otkriti ove podatke. Koristite sintetičke (izmišljene) testne naloge; istovremeno štiti povjerljivost i čini testove ponovljivim. Provođenje testa "otkazivanje narudžbe" sa stvarnim korisničkim računom je i etička i operativna greška.
Savjet: držite UI testove što je moguće manje; Ostavite stvarnu verifikaciju API-ju i jediničnim testovima, koji su brzi i stabilni. Testiranje korisničkog sučelja je skupo i krhko – koristite ga samo za validaciju stvarnog toka korisnika od kraja do kraja (test piramidalne logike).
Poređenje vozila
karakteristika
selen
dramaturg
čempres
jezicima
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
auto standby
ne (ručno)
da (jako)
Da
Multi browser
širok
Chromium/Firefox/WebKit
Dominantan hrom
sklonost lomljivosti
Visoka (ručno stanje pripravnosti)
nisko
nisko
Lakoća učenja
srednje
lako
lako
paralelni rad
Potrebna je mreža
ugrađen
Rezident/plaćeno
Kada tražite kod od AI, jasno navedite kojem vozilu pripada; U suprotnom, može proizvesti zbunjujući, nefunkcionalni kod.
Četiri šablona za kopiranje
1) Generacija solidnog UI testa:
Vaša uloga: viši inženjer za automatizaciju testiranja. Pišite testove sa [alat + jezik] za sljedeći tok: [tok].Pravila:- Selektori samo podaci-testid; Korištenje XPath/CSS klase. - Nema slepog sna; Koristite eksplicitno/automatsko čekanje. - Primijenite objektni model stranice. - Neka svaki asert potvrdi stvarni rezultat korisnika. Komentirajte na početku svakog testa koje kriterije prihvatanja potvrđujete.
2) Kontrola krhkosti:
Ispitajte sljedeći UI test za krhkost: - Postoji li nestabilan selektor (dug
3) Konverzija u objekt stranice:
Pretvorite sljedeći običan test kod u strukturu modela stranice. Premjestite selektore i akcije u klase stranica; Neka testna datoteka čita samo tok scenarija. [Alat/jezik].Kôd: [zalijepi kod]
4) Dokaz pseudo-tranzicije:
Dokažite da ovaj UI test zapravo potvrđuje: Koju pojedinu promjenu da napravim u kodu aplikacije koja će ovaj test pretvoriti u CRVENI? Ako ne možete pronaći promjenu koja će prekinuti test, test je neadekvatan; dodaj nedostajuće tvrdnje. Test: [zalijepi test]
tri mini kofera
Slučaj 1 — Oslobađanje od krhkog selektora. Od 40 testova koji je jedan tim napravio sa AI, 70% je pokvareno nakon ažuriranja interfejsa; nijedan od njih nije bio stvarne greške, svi su bili krhki XPath selektori. Tim je konvertovao testove u bazu podataka testida sa šablonom "provera krhkosti". Tokom naredna tri ažuriranja interfejsa, broj lažnih prekida je pao na nulu; vrijeme održavanja smanjeno je sa 6 sati na 30 minuta sedmično.
Slučaj 2 — Lažni prolazni UI test. AI je napravio test „dodaj u kolica“; test je bio zelen. Kada je pokrenut predložak "lažni dokaz o prolazu", činilo se da test samo provjerava klik na dugme i naslov stranice, nikada ne provjeravajući da li se brojač kolica povećao ili ne. Čak i ako je logika kolica bila potpuno pokvarena, test je prošao. Dodano istinito potvrđivanje (značka kolica je "1").
Slučaj 3 — Zamka za slijepo čekanje. U testu selena koji je proizveo AI, bilo je spavanja(2) nakon svakog koraka; 60 testova trajalo je 14 minuta i povremeno su se prekidali. Nakon prelaska na otvoreno čekanje (pričekajte da se element može kliknuti) vrijeme se smanjilo na 5 minuta i lomljivost je nestala. Slijepo čekanje je bilo sporo i nepouzdano.
Uobičajene greške
- Pristajem na krhke selektore. Korištenje dugih XPathova koje generira AI kao što jesu; Testovi se ruše pri prvoj promeni interfejsa.
- Ostavljanje slijepog `spavanja`. "Rješavanje" vremena sa fiksnim čekanjem; i spori i neodlučni.
- Trivijalna tvrdnja. Samo provjerite da li se stranica učitala; ne provjerava stvarni rezultat korisnika (lažni prolaz).
- Raste bez POM. Raspodijelite selektore svakom testu; Ručno ažuriranje desetina fajlova kada se promeni interfejs.
- Bez navođenja alata. Ne reći AI koji alat/jezik želite; postaje neuredan, nefunkcionalan kod.
- Pouzdanje kada pokrenete generirani kod i prođete. Ne testirati razbijanjem koda.
Ukratko
Automatizacija UI testiranja provjerava ponašanje korisnika tako što pokreće stvarni pretraživač s programom. AI brzo generiše ovaj kod, ali postoje dvije velike zamke: krhki testovi (loš selektor, slijepo čekanje) i testovi lažnog prolaza (nepotpuna/trivijalna tvrdnja). Tri stuba čvrstog UI testiranja su selektor urezivanja (data-testid), eksplicitno čekanje i assert koji provjerava stvarni rezultat korisnika. Imajući testove generisane u objektnom modelu stranice, radikalno se pojednostavljuje održavanje. Testirajte svaki generirani test sa pitanjem "koja promjena će ovo prekinuti?"
Zadatak aplikacije
Odaberite korisnički tok iz vlastitog projekta (npr. prijava ili pretraga). Neka AI napiše testove sa šablonom „generisanje robusnog UI testa“. Zatim: (1) provjerite i popravite selektore i čekate "provjerom krhkosti", (2) dokažite da svaki test zapravo potvrđuje "dokazom pseudo prolaza", (3) razbijte kod i uočite da test postaje crven. Izvijestite o broju proizvedenih i ispravljenih testova, kao io broju ranjivosti i pseudo prolaza koje ste pronašli.
kontrolna lista
- [ ] Jasno sam dao AI alat, jezik, politiku selektora i arhitekturu (POM).
- [ ] Provjerio sam da su selektori data-testid.
- [ ] Pobrinuo sam se da koristim eksplicitno/automatsko čekanje umjesto slijepog spavanja.
- [ ] Provjerio sam da svaki assert potvrđuje stvarni rezultat korisnika.
- [ ] Testirao sam svaki test razbijanjem koda; Video sam da postaje crveno.
- [ ] Sakupio sam testove u strukturi Page Object Model.