Gevinster:
- Evne til å produsere robust brukergrensesnitt-testkode med kunstig intelligens, inkludert data-testid, åpen ventetid og påstand som verifiserer det virkelige brukerresultatet
- Evne til å unngå skjøre tester (dårlig velger, blind venting) og gjøre tester enkle å vedlikeholde i sideobjektmodellstrukturen
- Evne til å teste hver UI-test som produseres ved å bryte koden og oppdage og fikse falske beståtte tester
Hvert klikk, hver skjemafylling, hver sideovergang en bruker gjør i en nettleser kan ikke testes om og om igjen for hånd – det er grunnen til at UI-testautomatisering (brukergrensesnitt; disse testene etterligner brukeratferd ved å programmere en ekte nettleser) eksisterer. Selen, dramatiker og sypress er de vanligste verktøyene for denne jobben. Kunstig intelligens (AI) er svært dyktig til å skrive koden for disse verktøyene: du beskriver en testcase, AI gir deg et utkast til et brukbart automatiseringsskript. Men her kommer den sentrale advarselen til denne modulen inn igjen: UI-testkode som AI produserer kan ofte være skjøre tester som «lyser grønt, men verifiserer feil ting» eller klaffer i vinden. Din jobb er ikke å kjøre denne koden, men å sørge for at den faktisk bekrefter det riktige.
I denne enheten tar vi sikte på å produsere robuste, vedlikeholdbare og virkelig validerende UI-tester med AI; Du vil lære å unngå skjøre tester.
De tre pilarene i solid UI-testing
1. Riktig elementplassering. En test bruker en velger for å finne elementet på siden. AI produserer ofte sprø velgere: lange XPath-baner (adresse altfor avhengig av sidestruktur), velgere basert på CSS-klassenavn (brudd når design endres). Den robuste måten er stabile attributter som data-testid som utvikleren la til for testing. Pålegg dette eksplisitt på AI.
2. Eksplisitt venting. Den største kilden til sårbarhet i UI-testing er timing. Den konstante søvnen(3) (blind venting) er dårlig praksis: noen ganger er det ikke nok, noen ganger kaster det bort tid. Den riktige måten er å bruke eksplisitt vente, som sier "vent til dette elementet vises". Dramatiker gjør dette stort sett automatisk; I Selenium må du eksplisitt be om det.
3. Meningsfull påstand. Testen skal verifisere resultatet brukeren faktisk vil se - som "ordrenummeret dukket opp på skjermen," ikke bare "siden lastet." Hvis testen produsert av AI ikke har en påstand eller er uviktig, gir den testen et pseudo-pass (1. enhet).
Forsiktig: Når du først ser en AI-generert UI-test, må du kontrollere tre ting på det meste: er velgerne forpliktet (data-testid), venter på (ingen blind søvn), og bekrefter påstanden det faktiske brukerresultatet? Hvis disse tre er OK, er testen sannsynligvis solid.
Sideobjektmodell
Etter hvert som testene vokser seg større, blir det å skrive velgere i hver test et vedlikeholdsmareritt. Sideobjektmodell (POM — designmønster som samler velgere og handlinger for hver side/skjerm i en enkelt klasse) holder velgeren på ett sted; Når grensesnittet endres, oppdaterer du det i en enkelt fil. Få AI til å produsere testene i en POM-struktur, i stedet for direkte; Dette gjør vedlikeholdet radikalt enklere.
Svak forespørsel / Sterk forespørsel
Svak: "Skriv en Selenium-test for påloggingssiden."
Sterkt: "Skriv en påloggingsflyttest med Playwright (TypeScript). Velgere bruker bare data-testid; ikke bruk kontroll hva brukeren ser, ikke sidetittelen."
Kraftig ledetekst; Verktøyet gir språk, velgerpolicy, ventestrategi, arkitektur (POM) og uttrykksfulle påstandsforventninger.
Test data og miljøuavhengighet
En solid UI-test er ikke bare skrevet riktig, men bygger og renser også sine egne testdata. AI-genererte tester kobler ofte til en bruker eller post som antas å eksistere allerede i miljøet ("logg inn som admin-bruker"). Denne antagelsen brytes når testen kjører i et annet miljø eller etter en annen test (ordreavhengighetsproblem i enhet 9). Sannheten er at hver test lager dataene den trenger i begynnelsen av testen (eller forbereder den med et API-kall) og renser dem på slutten. Instruer eksplisitt AI om å "sette opp data denne testen avhenger av i testen; ikke anta ferdige data utenfra."
Et annet kritisk poeng er å ikke gjøre UI-testing med ekte brukerdata. Hvis en kopi av produksjonsdatabasen brukes i testmiljøet, er disse postene data om virkelige personer; skjermbilder og testopptak kan avsløre disse dataene. Bruk syntetiske (fiktive) testkontoer; det både beskytter konfidensialitet og gjør tester reproduserbare. Å gjennomføre en «ordre cancellation»-test med en ekte kundekonto er både en etisk og operasjonell feil.
Tips: Hold UI-tester så få som mulig; Overlat selve verifiseringen til API og enhetstester, som er raske og stabile. UI-testing er dyrt og sprøtt – bruk det bare til å validere virkelig ende-til-ende brukerflyt (testpyramidelogikk).
Sammenligning av kjøretøy
funksjon
selen
dramatiker
sypress
språk
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
automatisk standby
Nei (for hånd)
Ja (sterk)
Ja
Multi nettleser
bredt
Chromium/Firefox/WebKit
Kromdominant
tendens til sprøhet
Høy (manuell standby)
lav
lav
Enkel læring
medium
enkelt
enkelt
parallell drift
Rutenett kreves
innebygd
Bosatt/betalt
Når du ber om en kode fra AI, oppgi tydelig hvilket kjøretøy den tilhører; Ellers kan det produsere forvirrende kode som ikke fungerer.
Fire kopierbare maler
1) Solid UI-testgenerering:
Din rolle: senior testautomatiseringsingeniør.Skriv tester med [verktøy + språk] for følgende flyt: [flyt].Regler:- Kun data-testing av velgere; Bruker XPath/CSS-klassen. - Ingen blind søvn; Bruk eksplisitt/automatisk venting. - Bruk sideobjektmodell. - La hver påstand verifisere det faktiske brukerresultatet. Kommenter i begynnelsen av hver test hvilke akseptkriterier du validerer.
2) Skjørhetskontroll:
Undersøk følgende UI-test for sprøhet: - Er det en ustabil velger (lang
3) Konvertering til sideobjekt:
Konverter følgende vanlige testkode til sideobjektmodellstruktur. Flytt velgere og handlinger til sideklasser; La testfilen kun lese scenarioflyten. [Verktøy/språk].Kode: [lim inn kode]
4) Pseudo-overgangsbevis:
Bevis at denne UI-testen faktisk validerer: Hvilken enkelt endring gjør jeg i applikasjonskoden som vil gjøre denne testen RØD? Hvis du ikke finner en endring som vil bryte testen, er testen utilstrekkelig; legg til manglende påstander.Test: [lim test]
tre minisaker
Tilfelle 1 — Frigjøring fra skjør velger. Av de 40 testene ett team produserte med AI, ble 70 % ødelagt etter en grensesnittoppdatering; ingen av dem var faktiske feil, de var alle skjøre XPath-velgere. Teamet konverterte testene til en data-testid-base med malen "skjørhetssjekk". I løpet av de neste tre grensesnittoppdateringene falt antallet falske brudd til null; vedlikeholdstiden gikk ned fra 6 timer til 30 minutter per uke.
Tilfelle 2 – falsk bestått UI-test. AI produserte en "legg i handlekurv"-test; testen var grønn. Når malen "falsk-bevis-av-passasje" ble kjørt, så det ut til at testen bare sjekket knappeklikk og sidetittel, og aldri bekreftet om handlekurvetelleren hadde økt eller ikke. Selv om vognlogikken var fullstendig ødelagt, besto testen. Lagt til sann påstand (vognmerket er "1").
Tilfelle 3 — Blind ventefelle. I selentesten produsert av AI var det søvn(2) etter hvert trinn; 60 tester tok 14 minutter og gikk fortsatt i stykker av og til. Etter å ha byttet til åpen vent (vent til elementet er klikkbart) gikk tiden ned til 5 minutter og sprøheten forsvant. Blind venting var både sakte og upålitelig.
Vanlige feil
- Enig med skjøre velgere. Bruke de lange XPathene generert av AI-en som den er; Tester krasjer ved første grensesnittendring.
- Forlater blind 'søvn'. "Løser" timingen med en fast ventetid; både sakte og ubesluttsom.
- Triviell påstand. Bare bekreft at siden er lastet inn; ikke sjekker det faktiske brukerresultatet (fake-pass).
- Vokse uten POM. Fordel velgere til hver test; Manuell oppdatering av dusinvis av filer når grensesnittet endres.
- Spesifiserer ikke verktøyet. Ikke fortelle AI hvilket verktøy/språk du vil ha; blir rotete, ikke-fungerende kode.
- Stoler på når du kjører den genererte koden og pass. Tester ikke ved å knekke koden.
Oppsummert
UI-testautomatisering verifiserer brukeratferd ved å kjøre den faktiske nettleseren med programmet. AI genererer denne koden raskt, men det er to store fallgruver: sprø tester (dårlig velger, blind venter) og falske bestått tester (ufullstendig/triviell påstand). De tre pilarene i solid UI-testing er commit selector (data-testid), eksplisitt avvente og hevde som verifiserer det faktiske brukerresultatet. Å ha tester generert i Page Object Model forenkler vedlikeholdet radikalt. Test hver genererte test med spørsmålet "hvilken endring vil bryte dette?"
Søknadsoppgave
Velg en brukerflyt fra ditt eget prosjekt (f.eks. pålogging eller søk). Få AI til å skrive tester med malen "robust UI-testgenerering". Deretter: (1) kontroller og fikser velgerne og venter med en "skjørhetskontroll", (2) bevis at hver test faktisk validerer med et "pseudo-pass proof", (3) knekk koden og observer at testen blir rød. Rapporter antall tester produsert og korrigert, og antall sårbarheter og pseudo-pass du har funnet.
sjekkliste
- [ ] Jeg ga AI verktøyet, språket, velgerpolitikken og arkitekturen (POM) tydelig.
- [ ] Jeg bekreftet at velgerne er datatestede.
- [ ] Jeg passet på å bruke eksplisitt/automatisk ventetid i stedet for blind søvn.
- [ ] Jeg sjekket at hver påstand bekrefter det faktiske brukerresultatet.
- [ ] Jeg testet hver test ved å bryte koden; Jeg så den ble rød.
- [ ] Jeg samlet testene i sideobjektmodellstrukturen.