Voitot:
- Kyky tuottaa vankkaa käyttöliittymätestikoodia tekoälyllä, mukaan lukien data-testid, avoin odotus ja väite, joka vahvistaa todellisen käyttäjän tuloksen
- Mahdollisuus välttää hauraita testejä (huono valitsin, sokea odotus) ja tehdä testeistä helppo ylläpitää sivuobjektimallirakenteessa
- Mahdollisuus testata jokaista koodia rikkomalla tuotettua käyttöliittymätestiä sekä havaita ja korjata väärennetyt testit
Jokaista klikkausta, jokaista lomakkeen täyttöä, jokaista käyttäjän selaimessa tekemää sivun siirtoa ei voida testata uudestaan ja uudestaan käsin – siksi käyttöliittymätestiautomaatio (käyttöliittymä; nämä testit jäljittelevät käyttäjän käyttäytymistä ohjaamalla ohjelmallisesti oikeaa selainta) on olemassa. Seleeni, näytelmäkirjailija ja sypressi ovat yleisimmät työkalut tähän työhön. Tekoäly (AI) on erittäin taitava kirjoittamaan näiden työkalujen koodin: sinä kuvaat testitapauksen, tekoäly antaa sinulle luonnoksen toimivasta automaatiokäsikirjoituksesta. Mutta tässä tämän moduulin keskeinen varoitus astuu jälleen esille: tekoälyn tuottama käyttöliittymätestikoodi voi usein olla hauraita testejä, jotka "säilevät vihreänä, mutta varmistavat väärän asian" tai lentävät tuulessa. Sinun tehtäväsi ei ole suorittaa tätä koodia, vaan varmistaa, että se todella vahvistaa oikean asian.
Tässä yksikössä pyrimme tuottamaan vankkoja, ylläpidettäviä ja todella validoivia käyttöliittymätestejä tekoälyllä. Opit välttämään hauraita testejä.
Kiinteän käyttöliittymän testauksen kolme pilaria
1. Oikea elementin paikannus. Testi käyttää valitsinta elementin etsimiseen sivulla. Tekoäly tuottaa usein hauraita valitsimia: pitkiä XPath-polkuja (osoite liian riippuvainen sivurakenteesta), valitsimia, jotka perustuvat CSS-luokan nimiin (katko, kun rakenne muuttuu). Vankka tapa on vakaat attribuutit, kuten data-testid, jotka kehittäjä lisäsi testausta varten. Määrää tämä nimenomaan tekoälylle.
2. Nimenomainen odotus. Käyttöliittymätestauksen haavoittuvuuden lähde numero yksi on ajoitus. Jatkuva uni(3) (sokea odotus) on huono käytäntö: joskus se ei riitä, joskus se hukkaa aikaa. Oikea tapa on käyttää nimenomaista odotusta, jossa lukee "odota, kunnes tämä elementti tulee näkyviin". Näytelmäkirjailija tekee tämän suurelta osin automaattisesti; Seleenissä sinun on pyydettävä sitä nimenomaisesti.
3. Merkittävä väite. Testin tulee varmistaa tulos, jonka käyttäjä todella näkee – kuten "tilausnumero ilmestyi näytölle", ei vain "sivu ladattu". Jos tekoälyn tuottamassa testissä ei ole väitettä tai se on merkityksetön, testi tuottaa pseudohyväksynnän (1. yksikkö).
Varoitus: Kun näet ensimmäisen kerran tekoälyn luoman käyttöliittymätestin, tarkista korkeintaan kolme asiaa: ovatko valitsimet sitoutuneet (data-testid), onko odotuksia päällä (ei sokeaa unta) ja vahvistaako väite todellisen käyttäjän tuloksen? Jos nämä kolme ovat kunnossa, testi on todennäköisesti vakaa.
Sivun objektimalli
Kun testit kasvavat, jokaisen testin sisällä olevista valitsimista tulee ylläpidon painajainen. Page Object Model (POM — suunnittelumalli, joka kokoaa valitsimet ja toiminnot jokaiselle sivulle/näytölle yhdeksi luokkaksi) pitää valitsimen yhdessä paikassa; Kun käyttöliittymä muuttuu, päivität sen yhdessä tiedostossa. Pyydä tekoälyä tuottamaan testit POM-rakenteessa, ei suoraan; Tämä tekee ylläpidosta radikaalisti helpompaa.
Heikko kehote / Vahva kehote
Heikko: "Kirjoita seleenitesti kirjautumissivulle."
Vahva: "Kirjoita sisäänkirjautumistesti Playwrightilla (TypeScript). Valitsijat käyttävät vain data-testidiä; älä ohjaa sitä, mitä käyttäjä näkee, eivät sivun otsikkoa."
Tehokas kehote; Työkalu antaa kielen, valitsinpolitiikan, odotusstrategian, arkkitehtuurin (POM) ja ilmeisen väitteen.
Testitiedot ja ympäristöriippumattomuus
Kiinteä käyttöliittymätesti ei ole vain kirjoitettu oikein, vaan se myös rakentaa ja puhdistaa omat testidatansa. Tekoälyn luomat testit linkittävät usein käyttäjään tai tietueeseen, jonka oletetaan jo olevan ympäristössä ("kirjaudu sisään järjestelmänvalvojana"). Tämä oletus rikkoutuu, kun testi suoritetaan toisessa ympäristössä tai toisen testin jälkeen (tilausriippuvuusongelma yksikössä 9). Totuus on, että jokainen testi luo tarvitsemansa tiedot testin alussa (tai valmistelee sen API-kutsulla) ja puhdistaa sen lopussa. Ohjeita tekoälyä nimenomaisesti "asettamaan kaikki tiedot, joista tämä testi riippuu testissä; älä oleta valmiita tietoja ulkopuolelta."
Toinen kriittinen kohta on olla tekemättä käyttöliittymätestausta todellisilla käyttäjätiedoilla. Jos testiympäristössä käytetään tuotantotietokannan kopiota, nämä tietueet ovat oikeiden henkilöiden tietoja; kuvakaappaukset ja testitallenteet voivat paljastaa nämä tiedot. Käytä synteettisiä (fiktiivisiä) testitilejä; se sekä suojaa luottamuksellisuutta että tekee testeistä toistettavia. "Tilauksen peruutus" -testin suorittaminen oikealla asiakastilillä on sekä eettinen että toiminnallinen virhe.
Vinkki: Pidä käyttöliittymätestejä mahdollisimman vähän; Jätä varsinainen todentaminen API- ja yksikkötesteille, jotka ovat nopeita ja vakaita. Käyttöliittymätestaus on kallista ja hauras – käytä sitä vain todellisen päästä päähän -käyttäjävirran validointiin (testipyramidilogiikka).
Ajoneuvojen vertailu
ominaisuus
seleeni
näytelmäkirjailija
sypressi
kieliä
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
automaattinen valmiustila
Ei (käsin)
Kyllä (vahva)
Kyllä
Moni selain
leveä
Chromium/Firefox/WebKit
Kromidominoiva
taipumus haurastumiseen
Korkea (manuaalinen valmiustila)
alhainen
alhainen
Oppimisen helppous
keskikokoinen
helppoa
helppoa
rinnakkainen toiminta
Ruudukko vaaditaan
sisäänrakennettu
Asukas/palkkainen
Kun pyydät koodia tekoälyltä, kerro selvästi, mihin ajoneuvoon se kuuluu; Muuten se voi tuottaa hämmentävää, toimimatonta koodia.
Neljä kopioitavaa mallia
1) Kiinteän käyttöliittymän testisukupolvi:
Roolisi: vanhempi testiautomaatioinsinööri.Kirjoita testejä [työkalulla + kieli] seuraavalle prosessille: [flow]. Säännöt: - Vain valitsimet data-testid; XPath/CSS-luokan käyttö. - Ei sokeaa unta; Käytä nimenomaista/automaattista odotusta. - Käytä sivuobjektimallia. - Anna jokaisen väitteen vahvistaa todellisen käyttäjän tulos. Kommentoi jokaisen testin alussa, mitä hyväksymiskriteereitä olet vahvistamassa.
2) Haurauden hallinta:
Tarkista seuraava käyttöliittymätesti haurauden varalta: - Onko valitsinta epävakaa (pitkä
3) Muunnos sivuobjektiksi:
Muunna seuraava yksinkertainen testikoodi sivuobjektimallirakenteeksi. Siirrä valitsimia ja toimintoja sivuluokkiin; Anna testitiedoston lukea vain skenaariokulku. [Työkalu/kieli]. Koodi: [liitä koodi]
4) Pseudo-siirtymätodistus:
Todista, että tämä käyttöliittymätesti todella vahvistaa: Minkä yksittäisen muutoksen teen sovelluskoodiin, joka muuttaa tämän testin PUNAISEKSI? Jos et löydä muutosta, joka rikkoo testin, testi on riittämätön; lisää puuttuvat väitteet.Testi: [liitä testi]
kolme minilaukkua
Tapaus 1 — Vapautuminen herkästä valitsimesta. 40 testistä, joita yksi tiimi tuotti tekoälyllä, 70 % oli rikki käyttöliittymäpäivityksen jälkeen; mikään niistä ei ollut todellista bugeja, ne olivat kaikki hauraita XPath-valitsimia. Tiimi muunsi testit tietopohjaksi "fragility check" -mallin avulla. Seuraavien kolmen käyttöliittymäpäivityksen aikana väärien katkosten määrä putosi nollaan; huoltoaika lyheni 6 tunnista 30 minuuttiin viikossa.
Tapaus 2 – Väärennetyn läpäisyn käyttöliittymätesti. AI tuotti "lisää ostoskoriin" -testin; testi oli vihreä. Kun "fake-proof-of-passage" -mallia suoritettiin, testi näytti tarkastavan vain painikkeen napsautusta ja sivun otsikkoa, mutta ei koskaan tarkistanut, oliko ostoskorin laskuri noussut vai ei. Vaikka kärryn logiikka olisi täysin rikki, testi onnistui. Lisätty tosi väittämä (ostoskorin merkki on "1").
Tapaus 3 – Sokea odotusloukku. Tekoälyn tuottamassa seleenitestissä oli unta(2) jokaisen vaiheen jälkeen; 60 testiä kesti 14 minuuttia ja silti rikkoutui toisinaan. Avoin odotustilaan vaihtamisen jälkeen (odota, että elementti on napsautettava) aika laski 5 minuuttiin ja hauraus hävisi. Sokea odottaminen oli sekä hidasta että epäluotettavaa.
Yleisiä virheitä
- Hyväksyminen hauraiden valitsijoiden kanssa. Käyttää tekoälyn luomia pitkiä XPatheja sellaisenaan; Testit kaatuvat ensimmäisen käyttöliittymämuutoksen yhteydessä.
- Sokean "nukkumaan" jättäminen. Ajoituksen "ratkaiseminen" kiinteällä odotuksella; sekä hitaita että päättämättömiä.
- Triviaali väite. Varmista vain, että sivu on latautunut; ei tarkista todellista käyttäjän tulosta (fake-pass).
- Kasvata ilman POM:ia. Jaa valitsimet jokaiseen testiin; Kymmenien tiedostojen manuaalinen päivittäminen käyttöliittymän muuttuessa.
- Työkalua ei määritellä. Älä kerro tekoälylle, minkä työkalun/kielen haluat; tulossa sotkuinen, toimimaton koodi.
- Luota, kun suoritat luodun koodin ja läpäiset. Ei testata rikkomalla koodia.
Yhteenvetona
Käyttöliittymän testausautomaatio varmistaa käyttäjien käyttäytymisen ohjaamalla varsinaista selainta ohjelman kanssa. Tekoäly luo tämän koodin nopeasti, mutta siinä on kaksi suurta sudenkuoppaa: hauraat testit (huono valitsin, sokea odottaa) ja väärennetyt läpäisytestit (epätäydellinen/triviaali väite). Kiinteän käyttöliittymän testauksen kolme pilaria ovat sitoutumisen valitsin (data-testid), eksplisiittinen odotus ja vahvistus, joka varmistaa todellisen käyttäjän tuloksen. Sivuobjektimallissa luotujen testien ottaminen yksinkertaistaa ylläpitoa radikaalisti. Testaa jokaista luotua testiä kysymyksellä "mikä muutos rikkoo tämän?"
Sovellustehtävä
Valitse käyttäjäkulku omasta projektistasi (esim. kirjautuminen tai haku). Tee tekoälyn kirjoitustestit "vankalla käyttöliittymätestisukupolvi" -mallilla. Sitten: (1) tarkista ja korjaa valitsimet ja odottaa "hauraustarkastuksella", (2) todista, että jokainen testi todellakin validoituu "pseudo-pass proofilla", (3) murra koodi ja huomaa, että testi muuttuu punaiseksi. Raportoi tehtyjen ja korjattujen testien määrä sekä löytämiesi haavoittuvuuksien ja pseudohyväksynnän määrä.
tarkistuslista
- [ ] Annoin tekoälylle selkeästi työkalun, kielen, valitsinpolitiikan ja arkkitehtuurin (POM).
- [ ] Varmistin, että valitsimet ovat datatestattuja.
- [ ] Varmistin, että käytän nimenomaista/automaattista odotusta sokean unen sijaan.
- [ ] Tarkistin, että jokainen väite vahvistaa todellisen käyttäjän tuloksen.
- [ ] Testasin jokaisen testin rikkomalla koodin; Näin sen muuttuvan punaiseksi.
- [ ] Kokosin testit Page Object Model -rakenteeseen.