Fitimet:
- Aftësia për të prodhuar një kod të fortë testimi UI me inteligjencë artificiale, duke përfshirë testimin e të dhënave, pritjen e hapur dhe pohimin që verifikon rezultatin e vërtetë të përdoruesit
- Aftësia për të shmangur testet e brishta (përzgjedhës i keq, pritje e verbër) dhe për t'i bërë testet të lehta për t'u mirëmbajtur në strukturën e modelit të objektit të faqes
- Aftësia për të testuar çdo test UI të prodhuar duke thyer kodin dhe për të zbuluar dhe rregulluar testet e kaluara false
Çdo klikim, çdo plotësim formulari, çdo tranzicion i faqes që bën një përdorues në një shfletues nuk mund të testohet pa pushim me dorë - kjo është arsyeja pse ekziston automatizimi i testit të UI (ndërfaqja e përdoruesit; këto teste imitojnë sjelljen e përdoruesit duke drejtuar programatikisht një shfletues të vërtetë). Seleni, dramaturgu dhe selvi janë mjetet më të zakonshme për këtë punë. Inteligjenca artificiale (AI) është shumë e aftë në shkrimin e kodit për këto mjete: ju përshkruani një rast testimi, AI ju jep një draft të një skripti automatizimi të zbatueshëm. Por këtu, paralajmërimi qendror i këtij moduli hyn përsëri në lojë: kodi i testit të UI që prodhon AI mund të jenë shpesh teste të brishta që "ndizen jeshile, por verifikojnë gjënë e gabuar" ose përplasen në erë. Detyra juaj nuk është të ekzekutoni këtë kod, por të siguroheni që ai vërtet vërteton me forcë gjënë e duhur.
Në këtë njësi, ne synojmë të prodhojmë teste të fuqishme, të mirëmbajtura dhe vërtet të vlefshme të UI me AI; Do të mësoni të shmangni testet e brishta.
Tre shtyllat e testimit të UI të qëndrueshme
1. Lokatori i saktë i elementeve. Një test përdor një përzgjedhës për të gjetur elementin në faqe. AI shpesh prodhon përzgjedhës të brishtë: shtigje të gjata XPath (adresa varet tepër nga struktura e faqes), përzgjedhës të bazuar në emrat e klasave CSS (ndërprehen kur dizajni ndryshon). Mënyra e fuqishme janë atributet e qëndrueshme si testimi i të dhënave që zhvilluesi shtoi për testim. Imponoje në mënyrë eksplicite këtë në AI.
2. Pritje e qartë. Burimi numër një i cenueshmërisë në testimin e UI është koha. Gjumi i vazhdueshëm(3) (pritja e verbër) është praktikë e keqe: ndonjëherë nuk mjafton, ndonjëherë humbet kohë. Mënyra e saktë është përdorimi i pritjes eksplicite, që thotë "prit derisa të shfaqet ky element". Dramaturgu e bën këtë kryesisht automatikisht; Në Selenium duhet ta kërkoni në mënyrë eksplicite.
3. Pohim kuptimplotë. Testi duhet të verifikojë rezultatin që përdoruesi do të shohë në të vërtetë - si "numri i porosisë u shfaq në ekran", jo vetëm "faqja e ngarkuar". Nëse testi i prodhuar nga AI nuk ka një pohim ose është i parëndësishëm, ai test prodhon një pseudo-kalim (njësia e parë).
Kujdes: Kur shihni për herë të parë një test UI të gjeneruar nga AI, kontrolloni maksimumi tre gjëra: a janë përzgjedhësit të përkushtuar (testimi i të dhënave), janë pritjet në pritje (pa gjumë të verbër) dhe a verifikon deklarata rezultatin aktual të përdoruesit? Nëse këto tre janë në rregull, testi është ndoshta i fortë.
Modeli i objektit të faqes
Ndërsa testet rriten, shkrimi i përzgjedhësve brenda çdo testi bëhet një makth mirëmbajtjeje. Modeli i objektit të faqes (POM - modeli i dizajnit që mbledh përzgjedhësit dhe veprimet për secilën faqe/ekran në një klasë të vetme) e mban përzgjedhësin në një vend; Kur ndërfaqja ndryshon, ju e përditësoni atë në një skedar të vetëm. Lërini AI të prodhojë testet në një strukturë POM, dhe jo drejtpërdrejt; Kjo e bën mirëmbajtjen rrënjësisht më të lehtë.
Prompt i dobët / Prompt i fortë
E dobët: "Shkruani një test Selenium për faqen e hyrjes."
Strong: "Shkruani një test të rrjedhës së hyrjes me Playwright (TypeScript). Përzgjedhësit përdorin vetëm testimin e të dhënave; mos përdorni kontrollin e asaj që shikon përdoruesi, jo titullin e faqes."
Prompt i fuqishëm; Mjeti jep gjuhën, politikën e përzgjedhësit, strategjinë e pritjes, arkitekturën (POM) dhe pritshmërinë shprehëse të pohimit.
Të dhënat e testimit dhe pavarësia e mjedisit
Një test solid UI jo vetëm që shkruhet saktë, por gjithashtu ndërton dhe pastron të dhënat e veta të testit. Testet e krijuara nga AI shpesh lidhen me një përdorues ose regjistrim që supozohet se ekziston tashmë në mjedis (“hyni si përdorues administrator”). Ky supozim prishet kur testi kryhet në një mjedis tjetër ose pas një testi tjetër (problemi i varësisë së rendit në njësinë 9). E vërteta është se çdo test krijon të dhënat që i nevojiten në fillim të testit (ose i përgatit me një thirrje API) dhe i pastron në fund. Udhëzoni në mënyrë eksplicite AI që "të vendosë çdo të dhënë nga e cila varet ky test brenda testit; mos supozoni të dhëna të gatshme nga jashtë".
Një pikë tjetër kritike është të mos bëni testimin e UI me të dhëna reale të përdoruesit. Nëse një kopje e bazës së të dhënave të prodhimit përdoret në mjedisin e testimit, këto të dhëna janë të dhëna të personave realë; pamjet e ekranit dhe regjistrimet e provës mund t'i zbulojnë këto të dhëna. Përdorni llogaritë testuese sintetike (fiktive); ai mbron konfidencialitetin dhe i bën testet të riprodhueshme. Kryerja e një testi "anulimi i porosisë" me një llogari të vërtetë klienti është një gabim etik dhe operacional.
Këshillë: Mbajini sa më pak testet e UI; Lëreni verifikimin aktual testeve të API-së dhe njësive, të cilat janë të shpejta dhe të qëndrueshme. Testimi i ndërfaqes është i shtrenjtë dhe i brishtë — përdorni vetëm për të vërtetuar rrjedhën e vërtetë të përdoruesit nga fundi në fund (logjika e piramidës së testimit).
Krahasimi i automjeteve
veçori
selenium
dramaturg
selvi
gjuhët
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
gatishmëri automatike
Jo (me dorë)
Po (i fortë)
po
Shumë shfletues
gjerë
Chromium/Firefox/WebKit
Krom dominues
tendenca për brishtësinë
E lartë (gadishmëri manuale)
të ulëta
të ulëta
Lehtësia e të mësuarit
e mesme
lehtë
lehtë
funksionimi paralel
Kërkohet rrjetë
të ndërtuara
Banor/me pagesë
Kur kërkoni një kod nga AI, tregoni qartë se cilit automjet i përket; Përndryshe, mund të prodhojë kod konfuz dhe jofunksional.
Katër shabllone të kopjueshëm
1) Gjenerimi i provës së UI të ngurtë:
Roli juaj: inxhinier i lartë i automatizimit të testit. Shkruani teste me [mjet + gjuhë] për rrjedhën e mëposhtme: [rrjedha]. Rregullat: - Vetëm testimi i të dhënave të përzgjedhësve; Përdorimi i klasës XPath/CSS. - Nuk ka gjumë të verbër; Përdorni pritje eksplicite/automatike. - Aplikoni modelin e objektit të faqes. - Lëreni çdo pohim të verifikojë rezultatin aktual të përdoruesit. Komentoni në fillim të çdo testi cilat kritere pranimi po vërtetoni.
2) Kontrolli i brishtësisë:
Shqyrtoni testin e mëposhtëm UI për brishtësinë: - A ka një përzgjedhës të paqëndrueshëm (i gjatë
3) Konvertimi në objektin e faqes:
Konvertoni kodin e thjeshtë të testit të mëposhtëm në strukturën e Modelit të Objektit të Faqes. Zhvendos përzgjedhësit dhe veprimet në klasat e faqeve; Lëreni skedarin e testimit të lexojë vetëm rrjedhën e skenarit. [Mjet/gjuhë]. Kodi: [ngjit kodin]
4) Prova pseudo-tranzicioni:
Vërtetoni se ky test UI vërteton vërtet: Çfarë ndryshimi të vetëm duhet të bëj në kodin e aplikacionit që do ta kthejë këtë test në KUQ? Nëse nuk mund të gjeni një ndryshim që do të prishë testin, testi është i pamjaftueshëm; shtoni pohimet që mungojnë.Testi: [paste test]
tre mini kuti
Rasti 1 - Çlirimi nga përzgjedhësi i brishtë. Nga 40 testet e një ekipi të prodhuar me AI, 70% u prishën pas një përditësimi të ndërfaqes; asnjëri prej tyre nuk ishte gabime aktuale, të gjithë ishin përzgjedhës të brishtë XPath. Ekipi i konvertoi testet në një bazë të testimit të të dhënave me shabllonin e "kontrollit të brishtësisë". Gjatë tre përditësimeve të ardhshme të ndërfaqes, numri i ndërprerjeve të rreme ra në zero; koha e mirëmbajtjes u ul nga 6 orë në 30 minuta në javë.
Rasti 2 - Testi i UI-së me kalim të rremë. Inteligjenca artificiale prodhoi një test "shto në shportë"; testi ishte i gjelbër. Kur u ekzekutua shablloni i "provës së rreme të kalimit", testi u shfaq vetëm për të kontrolluar klikimin e butonit dhe titullin e faqes, duke mos verifikuar kurrë nëse numëruesi i karrocave ishte rritur apo jo. Edhe nëse logjika e karrocave u prish plotësisht, testi kaloi. U shtua pohim i vërtetë (distinktivi i karrocës është "1").
Rasti 3 - Kurthi i pritjes së verbër. Në testin e Selenit të prodhuar nga AI, kishte gjumë(2) pas çdo hapi; 60 teste u deshën 14 minuta dhe përsëri prisheshin herë pas here. Pas kalimit në hapje prisni (pritni që elementi të klikohet) koha zbriti në 5 minuta dhe brishtësia u zhduk. Pritja e verbër ishte e ngadaltë dhe e pabesueshme.
Gabimet e zakonshme
- Duke rënë dakord për përzgjedhësit e brishtë. Përdorimi i XPaths të gjatë të krijuar nga AI siç është; Testet rrëzohen në ndryshimin e parë të ndërfaqes.
- Lënia e 'gjumit' të verbër. "Zgjidhja" e kohës me një pritje fikse; të ngadalshëm dhe të pavendosur.
- Pohimi i parëndësishëm. Vetëm verifikoni që faqja është ngarkuar; mos kontrollimi i rezultatit aktual të përdoruesit (fake-pass).
- Rriteni pa POM. Shpërndani përzgjedhësit për çdo test; Përditësimi manual i dhjetëra skedarëve kur ndërfaqja ndryshon.
- Duke mos specifikuar mjetin. Mos i tregoni AI-së se çfarë mjeti/gjuhe dëshironi; bëhet kod i çrregullt, jofunksional.
- Besimi kur ekzekutoni kodin e krijuar dhe kaloni. Nuk testohet duke thyer kodin.
Në përmbledhje
Automatizimi i testimit të UI verifikon sjelljen e përdoruesit duke drejtuar shfletuesin aktual me programin. Inteligjenca artificiale e gjeneron shpejt këtë kod, por ka dy gracka të mëdha: testet e brishta (përzgjedhësi i keq, pret verbëri) dhe testet e kalimit të rremë (pohim jo i plotë/i parëndësishëm). Tre shtyllat e testimit solid të ndërfaqes së përdoruesit janë përzgjedhësi i kryerjes (testimi i të dhënave), pritshmëria e qartë dhe pohimi që verifikon rezultatin aktual të përdoruesit. Pasja e testeve të krijuara në Modelin e Objektit të Faqes thjeshton rrënjësisht mirëmbajtjen. Testoni çdo test të krijuar me pyetjen "çfarë ndryshimi do ta prishë këtë?"
Detyra e aplikimit
Zgjidhni një fluks përdoruesi nga projekti juaj (p.sh. identifikimi ose kërkimi). Bëni testet e AI-së të shkruajnë me shabllonin e "gjenerimit të testit të UI të fortë". Më pas: (1) kontrolloni dhe rregulloni përzgjedhësit dhe prisni me një "kontroll të brishtësisë", (2) vërtetoni se çdo test vërtetohet me një "provë pseudo-kalimi", (3) thyeni kodin dhe vëzhgoni që testi bëhet i kuq. Raportoni numrin e testeve të prodhuara dhe të korrigjuara, si dhe numrin e dobësive dhe pseudo-kalimeve që keni gjetur.
listë kontrolli
- [ ] I dhashë AI mjetin, gjuhën, politikën e përzgjedhësit dhe arkitekturën (POM) në mënyrë të qartë.
- [ ] Kam verifikuar që përzgjedhësit janë të testuar me të dhëna.
- [ ] U sigurova që të përdorja pritje eksplicite/automatike në vend të gjumit të verbër.
- [ ] Kontrollova që çdo pohim verifikon rezultatin aktual të përdoruesit.
- [ ] Kam testuar çdo test duke thyer kodin; E pashë të bëhej e kuqe.
- [ ] I mblodha testet në strukturën e modelit të objektit të faqes.