Kasu:
- Võimalus toota tehisintellektiga tugevat kasutajaliidese testkoodi, sealhulgas andmete testimist, avatud ootamist ja kinnitust, mis kontrollib tegelikku kasutaja tulemust
- Võimalus vältida hapraid teste (halb valija, pime ootamine) ja muuta testid leheobjekti mudeli struktuuris hõlpsasti hooldatavaks
- Võimalus testida iga koodi murdmise teel loodud kasutajaliidese testi ning tuvastada ja parandada võltsitud testid
Iga klõpsu, iga vormi täitmist, iga lehe üleminekut, mida kasutaja brauseris teeb, ei saa ikka ja jälle käsitsi testida – seepärast eksisteerib kasutajaliidese testimise automatiseerimine (kasutajaliides; need testid jäljendavad kasutaja käitumist, kasutades programmiliselt tõelist brauserit). Seleen, näitekirjanik ja küpress on selle töö jaoks kõige levinumad tööriistad. Tehisintellekt (AI) on nende tööriistade koodi kirjutamisel kõrgelt kvalifitseeritud: kirjeldate testjuhtumit, tehisintellekt annab teile toimiva automatiseerimisskripti mustandi. Kuid siin tuleb taas mängu selle mooduli keskne hoiatus: tehisintellekti toodetav kasutajaliidese testikood võib sageli olla habras testid, mis "süttivad roheliselt, kuid kinnitavad vale asja" või lehvivad tuules. Teie ülesanne ei ole seda koodi käivitada, vaid veenduda, et see tõesti kontrollib kindlalt õiget asja.
Selle üksuse eesmärk on toota tehisintellektiga tugevaid, hooldatavaid ja tõeliselt valideerivaid kasutajaliidese teste; Õpid vältima hapraid teste.
Tahke kasutajaliidese testimise kolm tugisammast
1. Õige elemendi lokaator. Test kasutab lehelt elemendi leidmiseks valijat. Tehisintellekt toodab sageli hapraid selektoreid: pikad XPath-teed (aadress sõltub liigselt lehe struktuurist), CSS-klasside nimedel põhinevad selektorid (katkeb kujunduse muutumisel). Tugev viis on stabiilsed atribuudid, näiteks data-testid, mille arendaja testimiseks lisas. Määrake see AI-le selgesõnaliselt peale.
2. Otsene ootamine. Kasutajaliidese testimise haavatavuse allikas number üks on ajastus. Pidev uni(3) (pime ootamine) on halb tava: mõnikord ei piisa, mõnikord raiskab aega. Õige viis on kasutada selgesõnalist ootamist, mis ütleb "oodake, kuni see element ilmub". Näitekirjanik teeb seda suures osas automaatselt; Seleeni puhul peate seda selgesõnaliselt taotlema.
3. Sisukas väide. Test peaks kontrollima tulemust, mida kasutaja tegelikult näeb – näiteks "ekraanile ilmus tellimuse number", mitte lihtsalt "leht on laaditud". Kui tehisintellekti loodud testil pole väidet või see on ebaoluline, annab see test pseudo-sobivuse (1. üksus).
Ettevaatust. Kui näete esimest korda tehisintellekti loodud kasutajaliidese testi, kontrollige maksimaalselt kolme asja: kas selektorid on sooritatud (andmete testimine), kas ooteaeg on sisse lülitatud (pime uni pole) ja kas väide kontrollib tegelikku kasutaja tulemust? Kui need kolm on korras, on test tõenäoliselt kindel.
Lehekülje objekti mudel
Testide arvu suurenedes muutub iga testi sees valijate kirjutamine hoolduse õudusunenäoks. Page Object Model (POM — kujundusmuster, mis kogub iga lehe/ekraani valijad ja toimingud ühte klassi) hoiab valijat ühes kohas; Kui liides muutub, värskendate seda ühes failis. Laske AI-l testid koostada POM-struktuuris, mitte otse; See muudab hoolduse radikaalselt lihtsamaks.
Nõrk viip / Tugev viip
Nõrk: "Kirjutage sisselogimislehe jaoks Seleeni test."
Tugev: "Kirjutage Playwrightiga (TypeScript) sisselogimisvoo test. Selektorid kasutavad ainult data-testid; ärge juhtige seda, mida kasutaja näeb, mitte lehe pealkirja."
Võimas viip; Tööriist annab keele, valija poliitika, ootestrateegia, arhitektuuri (POM) ja väljendusrikka kinnituse.
Testiandmete ja keskkonna sõltumatus
Tugev kasutajaliidese test pole mitte ainult õigesti kirjutatud, vaid loob ja puhastab ka oma testiandmeid. Tehisintellekti loodud testid lingivad sageli kasutaja või kirjega, mis eeldatavasti on keskkonnas juba olemas (“logi sisse administraatori kasutajana”). See eeldus katkeb, kui test jookseb teises keskkonnas või pärast teist testi (tellimuse sõltuvusprobleem üksuses 9). Tõde on see, et iga test loob testi alguses vajalikud andmed (või valmistab need API-kutsega ette) ja puhastab need lõpus. Tehke tehisintellektile selgesõnaline juhend "seadistada testis kõik andmed, millest see test sõltub; ärge eeldage väljastpoolt pärit valmisandmeid".
Teine kriitiline punkt on mitte teha kasutajaliidese testimist tegelike kasutajaandmetega. Kui testkeskkonnas kasutatakse tootmisandmebaasi koopiat, on need kirjed reaalsete isikute andmed; ekraanipildid ja testsalvestused võivad need andmed paljastada. Kasutage sünteetilisi (väljamõeldud) testkontosid; see kaitseb nii konfidentsiaalsust kui muudab testid reprodutseeritavaks. Päris kliendikontoga "tellimuse tühistamise" testi läbiviimine on nii eetiline kui ka tegevusviga.
Näpunäide. Hoidke kasutajaliidese teste nii vähe kui võimalik; Jätke tegelik kinnitamine API- ja üksusetestide hooleks, mis on kiired ja stabiilsed. Kasutajaliidese testimine on kallis ja habras – kasutage seda ainult selleks, et kinnitada tõeliselt lõppkasutajate voogu (testipüramiidi loogika).
Sõidukite võrdlus
funktsiooni
seleen
näitekirjanik
küpress
keeled
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
automaatne ooterežiim
Ei (käega)
jah (tugev)
Jah
Mitu brauserit
lai
Chromium/Firefox/WebKit
Kroom domineeriv
kalduvus rabedusele
Kõrge (käsitsi ooterežiim)
madal
madal
Õppimise lihtsus
keskmine
lihtne
lihtne
paralleelne töö
Nõutav võrk
sisseehitatud
Resident/palgaline
Tehisintellektilt koodi küsimisel märkige selgelt, millisele sõidukile see kuulub; Vastasel juhul võib see tekitada segadust tekitava mittetöötava koodi.
Neli kopeeritavat malli
1) Tahke kasutajaliidese testi genereerimine:
Teie roll: testide automatiseerimise vaneminsener.Kirjutage testid [tööriist + keel] järgmise voo jaoks: [voog].Reeglid:- Ainult selektorid andmetestid; XPath/CSS-klassi kasutamine. - pimedat und pole; Kasutage selgesõnalist/automaatset ootamist. - Rakenda leheobjekti mudel. - Laske igal kinnitusel kontrollida tegelikku kasutaja tulemust. Kommenteerige iga testi alguses, milliseid aktsepteerimiskriteeriume te valideerite.
2) Hapruse kontroll:
Kontrollige järgmist kasutajaliidese hapruse testi: - kas valija on ebastabiilne (pikk
3) Teisendus leheobjektiks:
Teisendage järgmine tavaline testkood leheobjekti mudeli struktuuriks. teisaldada valijad ja toimingud leheklassidesse; Laske testfailil lugeda ainult stsenaariumivoogu. [Tööriist/keel]. Kood: [kleebi kood]
4) Pseudoülemineku tõestus:
Tõestage, et see kasutajaliidese test tegelikult kinnitab: Millise üksiku muudatuse ma rakenduse koodis teen, mis muudab selle testi PUNASEKS? Kui te ei leia muudatust, mis testi rikub, on test ebapiisav; lisage puuduvad kinnitused.Test: [kleebi test]
kolm minikarpi
Juhtum 1 – vabanemine haprast selektorist. 40 testist, mille üks meeskond tegi tehisintellektiga, oli 70% pärast liidese värskendamist katki; ükski neist polnud tegelikud vead, need olid kõik haprad XPathi valijad. Meeskond teisendas testid "nõrkusekontrolli" malli abil andmetestide baasiks. Järgmise kolme liidese värskenduse jooksul langes valepauside arv nullini; hooldusaeg vähenes 6 tunnilt 30 minutile nädalas.
2. juhtum – kasutajaliidese võltsitud läbimise test. AI koostas "lisa ostukorvi" testi; test oli roheline. Kui käivitati võltsitud läbisõidukinnituse mall, näis test kontrollivat ainult nupuklõpsu ja lehe pealkirja, kuid ei kontrollinud kunagi, kas ostukorvi loendur on suurenenud või mitte. Isegi kui vankriloogika oli täiesti katki, läks test läbi. Lisatud tõene väide (käru märgiks on "1").
Juhtum 3 – pime ootelõks. Tehisintellekti poolt toodetud seleeni testis oli iga sammu järel uni(2); 60 testi kestsid 14 minutit ja ikka läksid aeg-ajalt katki. Pärast lülitumist avatud ootele (oodake, kuni element on klõpsatav) vähenes aeg 5 minutini ja rabedus kadus. Pime ootamine oli ühtaegu aeglane ja ebausaldusväärne.
Levinud vead
- Nõus habraste valijatega. AI poolt loodud pikkade XPathide kasutamine sellisel kujul; Testid jooksevad kokku esimesel liidese muutmisel.
- Pimedast `uinust` lahkumine. Ajastuse "lahendamine" fikseeritud ootamisega; nii aeglane kui ka otsustusvõimetu.
- Triviaalne väide. Lihtsalt veenduge, et leht on laaditud; tegeliku kasutaja tulemuse kontrollimata jätmine (võltspääs).
- Kasvake ilma POM-ita. Jaotage iga testi jaoks valijad; Kümnete failide käsitsi värskendamine, kui liides muutub.
- Tööriista ei täpsustata. ei ütle AI-le, millist tööriista/keelt soovite; saada räpane, mittetöötav kood.
- Usaldus, kui käivitate loodud koodi ja edastate selle. Ei testita koodi murdmisega.
Kokkuvõttes
Kasutajaliidese testimise automatiseerimine kontrollib kasutaja käitumist, käivitades programmiga tegeliku brauseri. AI genereerib selle koodi kiiresti, kuid sellel on kaks suurt lõksu: rabedad testid (halb valija, pime ootamine) ja võltsitud läbimise testid (puudulik/triviaalne väide). Tahke kasutajaliidese testimise kolm tugisammast on sidumise valija (data-testid), selgesõnaline ootamine ja kinnitus, mis kontrollib tegelikku kasutaja tulemust. Testide loomine leheobjekti mudelis lihtsustab oluliselt hooldust. Testige iga loodud testi küsimusega "milline muudatus selle katkestab?"
Rakenduse ülesanne
Valige oma projektist kasutajavoog (nt sisselogimine või otsing). Laske teha tehisintellekti kirjutamiskatseid, kasutades malli „tugev kasutajaliidese testi genereerimine”. Seejärel: (1) kontrollige ja fikseerige selektorid ning oodake "nõrkuskontrolliga", (2) tõestage, et iga test tegelikult kinnitab "pseudo-passitõendi", (3) murdke kood ja jälgige, et test muutub punaseks. Teatage tehtud ja parandatud testide arvust ning leitud haavatavuste ja pseudopääsmete arvust.
kontrollnimekiri
- [ ] Andsin tehisintellektile selgelt tööriista, keele, valijapoliitika ja arhitektuuri (POM).
- [ ] Kontrollisin, et valijad oleksid andmetestitud.
- [ ] Kasutasin pimeda une asemel selgesõnalist/automaatset ootamist.
- [ ] Kontrollisin, et iga väide kontrolliks tegelikku kasutaja tulemust.
- [ ] Testisin iga testi koodi murdes; Ma nägin, et see läks punaseks.
- [ ] Testid kogusin Page Object Model struktuuri.