Vinster:
- Möjlighet att producera robust UI-testkod med artificiell intelligens, inklusive data-testid, öppen vänta och påstå som verifierar det verkliga användarresultatet
- Möjlighet att undvika ömtåliga tester (dålig väljare, blind väntan) och göra tester lätta att underhålla i sidobjektmodellstrukturen
- Möjlighet att testa varje UI-test som produceras genom att bryta koden och upptäcka och fixa falska godkända tester
Varje klick, varje formulärfyllning, varje sidövergång en användare gör i en webbläsare kan inte testas om och om igen för hand – det är därför UI-testautomatisering (användargränssnitt; dessa tester efterliknar användarbeteende genom att programmässigt driva en riktig webbläsare) existerar. Selen, dramatiker och cypress är de vanligaste verktygen för detta jobb. Artificiell intelligens (AI) är mycket skicklig på att skriva koden för dessa verktyg: du beskriver ett testfall, AI ger dig ett utkast till ett fungerande automatiseringsskript. Men här kommer den centrala varningen för denna modul in i bilden igen: UI-testkod som AI producerar kan ofta vara ömtåliga tester som "lyser grönt men verifierar fel sak" eller flaxar i vinden. Ditt jobb är inte att köra den här koden, utan att se till att den verkligen verifierar rätt sak.
I den här enheten strävar vi efter att producera robusta, underhållbara och verkligt validerande UI-tester med AI; Du lär dig undvika ömtåliga tester.
De tre pelarna för solid UI-testning
1. Korrigera elementlokalisering. Ett test använder en väljare för att hitta elementet på sidan. AI producerar ofta spröda väljare: långa XPath-vägar (adressen är alltför beroende av sidstrukturen), väljare baserade på CSS-klassnamn (bryter när designen ändras). Det robusta sättet är stabila attribut som data-testid som utvecklaren lade till för testning. Tvinga detta uttryckligen på AI.
2. Explicit väntan. Den främsta källan till sårbarhet i UI-testning är timing. Den ständiga sömnen(3) (blind väntan) är dålig praxis: ibland räcker det inte, ibland slösar det bort tid. Det korrekta sättet är att använda explicit vänta, som säger "vänta tills detta element visas". Dramatiker gör detta till stor del automatiskt; I Selenium måste du uttryckligen begära det.
3. Meningsfullt påstående. Testet bör verifiera resultatet som användaren faktiskt kommer att se - som "ordernummer visades på skärmen", inte bara "sidan laddad." Om testet som produceras av AI inte har ett påstående eller är oviktigt, ger det testet ett pseudo-pass (första enheten).
Varning: När du först ser ett AI-genererat UI-test, kontrollera högst tre saker: är väljarna inkopplade (data-testid), väntar på (ingen blind sömn) och verifierar påståendet det faktiska användarresultatet? Om dessa tre är OK, är testet förmodligen solid.
Sidobjektsmodell
När testerna växer sig större blir det en underhållsmardröm att skriva väljare i varje test. Sidobjektsmodell (POM — designmönster som samlar väljare och åtgärder för varje sida/skärm i en enda klass) håller väljaren på ett ställe; När gränssnittet ändras uppdaterar du det i en enda fil. Låt AI producera testerna i en POM-struktur, snarare än direkt; Detta underlättar underhållet radikalt.
Svag prompt / Stark prompt
Svag: "Skriv ett Selenium-test för inloggningssidan."
Starkt: "Skriv ett inloggningsflödestest med Playwright (TypeScript). Väljare använder bara data-testid; använd inte kontroll vad användaren ser, inte sidtiteln."
Kraftfull uppmaning; Verktyget ger språk, väljarpolicy, väntestrategi, arkitektur (POM) och uttrycksfulla förväntningar.
Testa data och miljöoberoende
Ett solidt UI-test skrivs inte bara korrekt, utan bygger och rensar också sina egna testdata. AI-genererade tester länkar ofta till en användare eller post som antas redan existera i miljön ("logga in som adminanvändare"). Detta antagande bryts när testet körs i en annan miljö eller efter ett annat test (orderberoendeproblem i enhet 9). Sanningen är att varje test skapar den data som behövs i början av testet (eller förbereder den med ett API-anrop) och rensar den i slutet. Instruera uttryckligen AI:n att "ställa in alla data som detta test beror på inom testet; anta inte färdiga data utifrån."
En annan kritisk punkt är att inte göra UI-testning med riktiga användardata. Om en kopia av en produktionsdatabas används i testmiljön är dessa register data om verkliga personer; skärmdumpar och testinspelningar kan avslöja dessa data. Använd syntetiska (fiktiva) testkonton; det både skyddar konfidentialitet och gör tester reproducerbara. Att genomföra ett "orderavbokningstest" med ett riktigt kundkonto är både ett etiskt och operativt misstag.
Tips: Håll UI-tester så få som möjligt; Överlåt själva verifieringen till API och enhetstester, som är snabba och stabila. Användargränssnittstestning är dyrt och skört – använd det bara för att validera verkligt användarflöde från slut till slut (testpyramidlogik).
Jämförelse av fordon
funktion
selen
dramatiker
cypress
språk
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
automatisk standby
Nej (för hand)
Ja (stark)
Ja
Flera webbläsare
bred
Chromium/Firefox/WebKit
Kromdominant
tendens till sprödhet
Hög (manuell standby)
låg
låg
Lätt att lära
medium
lätt
lätt
parallelldrift
Rutnät krävs
inbyggd
Bosatt/betald
När du begär en kod från AI, ange tydligt vilket fordon den tillhör; Annars kan det skapa förvirrande kod som inte fungerar.
Fyra kopierbara mallar
1) Solid UI-testgenerering:
Din roll: senior testautomationsingenjör. Skriv tester med [verktyg + språk] för följande flöde: [flöde].Regler:- Endast väljare data-testid; Använder XPath/CSS-klass. - Ingen blind sömn; Använd explicit/automatisk väntan. - Använd sidobjektmodell. - Låt varje påstående verifiera det faktiska användarresultatet. Kommentera i början av varje test vilka acceptanskriterier du validerar.
2) Bräcklighetskontroll:
Undersök följande UI-test för sprödhet: - Finns det en instabil väljare (lång
3) Konvertering till sidobjekt:
Konvertera följande vanliga testkod till sidobjektmodellstruktur. Flytta väljare och åtgärder till sidklasser; Låt testfilen endast läsa scenarioflödet. [Verktyg/språk]. Kod: [klistra in kod]
4) Pseudoövergångsbevis:
Bevisa att detta UI-test faktiskt validerar: Vilken enstaka ändring gör jag i applikationskoden som gör det här testet RÖTT? Om du inte kan hitta en förändring som kommer att bryta testet är testet otillräckligt; lägg till saknade påståenden.Test: [klistra in test]
tre minifodral
Fall 1 — Befrielse från bräcklig väljare. Av de 40 testerna som ett team producerade med AI, bröts 70 % efter en uppdatering av gränssnittet; ingen av dem var verkliga buggar, de var alla ömtåliga XPath-väljare. Teamet konverterade testerna till en data-testtidbas med mallen "bräcklighetskontroll". Under de kommande tre gränssnittsuppdateringarna sjönk antalet falska avbrott till noll; underhållstiden minskade från 6 timmar till 30 minuter per vecka.
Fall 2 – Falskt godkänd UI-test. AI producerade ett "lägg till i kundvagn"-test; testet var grönt. När mallen "fake-proof-of-passage" kördes verkade testet bara kontrollera knappklicket och sidtiteln, utan att verifiera om varukorgsräknaren hade ökat eller inte. Även om vagnlogiken var helt trasig gick testet igenom. Lagt till sant påstående (vagnmärket är "1").
Fall 3 — Blind väntfälla. I selentestet som producerats av AI, var det sömn(2) efter varje steg; 60 tester tog 14 minuter och gick ändå sönder ibland. Efter att ha gått över till öppen vänta (vänta tills elementet är klickbart) gick tiden ner till 5 minuter och sprödheten försvann. Blind väntan var både långsam och opålitlig.
Vanliga misstag
- Går med på ömtåliga väljare. Använda de långa XPaths som genereras av AI:n som de är; Tester kraschar vid första gränssnittsändringen.
- Lämna blind "sömn". "Lösa" timingen med en fast väntan; både långsam och obeslutsam.
- Trivialt påstående. Kontrollera bara att sidan har laddats; inte kontrollera det faktiska användarresultatet (fake-pass).
- Väx utan POM. Fördela väljare till varje test; Manuell uppdatering av dussintals filer när gränssnittet ändras.
- Anger inte verktyget. Att inte berätta för AI vilket verktyg/språk du vill ha; blir rörig, icke-fungerande kod.
- Tillförlitlig när du kör den genererade koden och pass. Testar inte genom att bryta koden.
Sammanfattningsvis
UI-testautomatisering verifierar användarens beteende genom att köra den faktiska webbläsaren med programmet. AI genererar den här koden snabbt, men det finns två stora fallgropar: sköra tester (dålig väljare, blind väntar) och falska godkända tester (ofullständiga/triviala påstående). De tre pelarna för solid UI-testning är commit selector (data-testid), explicit await och assert som verifierar det faktiska användarresultatet. Att ha tester genererade i Page Object Model förenklar underhållet radikalt. Testa varje genererat test med frågan "vilken förändring kommer att bryta detta?"
Applikationsuppgift
Välj ett användarflöde från ditt eget projekt (t.ex. logga in eller sök). Få AI att skriva tester med mallen "robust UI-testgenerering". Sedan: (1) kontrollera och fixa väljaren och vänta med en "bräcklighetskontroll", (2) bevisa att varje test faktiskt validerar med ett "pseudo-pass proof", (3) bryt koden och observera att testet blir rött. Rapportera antalet tester som producerats och korrigerats, och antalet sårbarheter och pseudo-pass du hittat.
checklista
- [ ] Jag gav AI:n verktyget, språket, väljarpolicyn och arkitekturen (POM) tydligt.
- [ ] Jag verifierade att väljarna är datatestade.
- [ ] Jag såg till att använda explicit/automatisk väntan istället för blind sömn.
- [ ] Jag kontrollerade att varje påstående verifierar det faktiska användarresultatet.
- [ ] Jag testade varje test genom att bryta koden; Jag såg den bli röd.
- [ ] Jag samlade testerna i Sidobjektsmodellstrukturen.