Gevinster:
- Evne til at producere robust UI-testkode med kunstig intelligens, inklusive data-testid, åben ventetid og påstand, der verificerer det rigtige brugerresultat
- Evne til at undgå skrøbelige tests (dårlig vælger, blind ventetid) og gøre test nemme at vedligeholde i sideobjektmodelstrukturen
- Evne til at teste hver UI-test, der er produceret ved at bryde koden og opdage og rette falske beståede tests
Hvert klik, hver formularudfyldning, hver sideovergang, en bruger foretager i en browser, kan ikke testes igen og igen i hånden - det er grunden til, at UI-testautomatisering (brugergrænseflade; disse tests efterligner brugeradfærd ved programmæssigt at drive en rigtig browser) eksisterer. Selen, dramatiker og cypres er de mest almindelige værktøjer til dette job. Kunstig intelligens (AI) er meget dygtig til at skrive koden til disse værktøjer: du beskriver en testcase, AI giver dig et udkast til et brugbart automatiseringsscript. Men her kommer den centrale advarsel fra dette modul i spil igen: UI-testkode, som AI producerer, kan ofte være skrøbelige tests, der "lyser grønt, men verificerer det forkerte" eller klapper i vinden. Dit job er ikke at køre denne kode, men at sørge for, at den faktisk robust verificerer det rigtige.
I denne enhed sigter vi efter at producere robuste, vedligeholdelige og virkelig validerende UI-tests med AI; Du lærer at undgå skrøbelige tests.
De tre søjler i solid UI-testning
1. Korrekt elementplacering. En test bruger en vælger til at finde elementet på siden. AI producerer ofte sprøde vælgere: lange XPath-stier (adresse alt for afhængig af sidestruktur), vælgere baseret på CSS-klassenavne (brud, når designet ændres). Den robuste måde er stabile attributter som data-testid, som udvikleren tilføjede til test. Påtving dette eksplicit på AI.
2. Eksplicit ventetid. Den største kilde til sårbarhed i UI-test er timing. Den konstante søvn(3) (blind ventetid) er dårlig praksis: nogle gange er det ikke nok, nogle gange spilder det tid. Den korrekte måde er at bruge eksplicit vente, som siger "vent indtil dette element vises". Dramatiker gør dette stort set automatisk; I Selen skal du udtrykkeligt anmode om det.
3. Meningsfuld påstand. Testen skal verificere det resultat, brugeren rent faktisk vil se - som "ordrenummeret dukkede op på skærmen", ikke kun "siden indlæst." Hvis testen produceret af AI ikke har en påstand eller er ligegyldig, producerer den test et pseudo-pas (1. enhed).
Forsigtig: Når du første gang ser en AI-genereret UI-test, skal du højst kontrollere tre ting: er vælgerne forpligtet (data-testid), venter der (ingen blind søvn), og bekræfter påstanden det faktiske brugerresultat? Hvis disse tre er OK, er testen sandsynligvis solid.
Sideobjektmodel
Efterhånden som testene vokser sig større, bliver det at skrive vælgere i hver test et vedligeholdelsesmareridt. Sideobjektmodel (POM — designmønster, der samler vælgere og handlinger for hver side/skærm i en enkelt klasse) holder vælgeren ét sted; Når grænsefladen ændres, opdaterer du den i en enkelt fil. Få AI til at producere testene i en POM-struktur i stedet for direkte; Dette gør vedligeholdelsen radikalt lettere.
Svag prompt / Stærk prompt
Svag: "Skriv en Selenium-test til login-siden."
Stærkt: "Skriv en login-flowtest med Playwright (TypeScript). Vælgere bruger kun data-testid; brug ikke kontrol, hvad brugeren ser, ikke sidetitlen."
Kraftig prompt; Værktøjet giver sproget, vælgerpolitikken, ventestrategien, arkitekturen (POM) og den ekspressive hævde forventning.
Test data og miljøuafhængighed
En solid UI-test er ikke kun skrevet korrekt, men opbygger og renser også sine egne testdata. AI-genererede tests linker ofte til en bruger eller post, der antages at eksistere allerede i miljøet ("log ind som admin-bruger"). Denne antagelse bryder, når testen kører i et andet miljø eller efter en anden test (ordreafhængighedsproblem i enhed 9). Sandheden er, at hver test opretter de data, den har brug for i begyndelsen af testen (eller forbereder den med et API-kald) og renser dem til sidst. Instruer AI eksplicit om at "konfigurere alle data, som denne test afhænger af i testen; antag ikke færdige data udefra."
Et andet kritisk punkt er ikke at lave UI-test med rigtige brugerdata. Hvis en kopi af produktionsdatabasen bruges i testmiljøet, er disse optegnelser data fra virkelige personer; skærmbilleder og testoptagelser kan afsløre disse data. Brug syntetiske (fiktive) testkonti; det både beskytter fortroligheden og gør tests reproducerbare. At udføre en "ordreannulleringstest" med en rigtig kundekonto er både en etisk og operationel fejl.
Tip: Hold brugergrænsefladetest så få som muligt; Overlad selve verifikationen til API'en og enhedstesten, som er hurtige og stabile. UI-test er dyrt og skrøbeligt – brug det kun til at validere virkeligt end-to-end brugerflow (testpyramidelogik).
Sammenligning af køretøjer
funktion
selen
dramatiker
cypres
sprog
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
automatisk standby
Nej (i hånden)
Ja (stærk)
Ja
Multi browser
bred
Chromium/Firefox/WebKit
Chrom-dominerende
tendens til skørhed
Høj (manuel standby)
lav
lav
Nem at lære
medium
let
let
parallel drift
Gitter påkrævet
indbygget
Fastboende/betalt
Når du anmoder om en kode fra AI, skal du tydeligt angive hvilket køretøj den tilhører; Ellers kan det producere forvirrende, ikke-fungerende kode.
Fire kopierbare skabeloner
1) Solid UI-testgenerering:
Din rolle: senior testautomatiseringsingeniør.Skriv test med [værktøj + sprog] for følgende flow: [flow].Regler:- Kun udvælgere data-testid; Bruger XPath/CSS-klassen. - Ingen blind søvn; Brug eksplicit/automatisk ventetid. - Anvend sideobjektmodel. - Lad hver påstand bekræfte det faktiske brugerresultat. Kommenter i begyndelsen af hver test, hvilke acceptkriterier du validerer.
2) Skrøbelighedskontrol:
Undersøg følgende UI-test for skørhed: - Er der en ustabil vælger (lang
3) Konvertering til sideobjekt:
Konverter følgende almindelige testkode til sideobjektmodelstruktur. Flyt vælgere og handlinger til sideklasser; Lad testfilen kun læse scenariet flow. [Værktøj/sprog].Kode: [indsæt kode]
4) Pseudo-overgangsbevis:
Bevis, at denne UI-test faktisk validerer: Hvilken enkelt ændring skal jeg foretage i applikationskoden, der vil gøre denne test RØD? Hvis du ikke kan finde en ændring, der vil bryde testen, er testen utilstrækkelig; tilføj manglende påstande.Test: [indsæt test]
tre minisager
Case 1 — Befrielse fra skrøbelig vælger. Af de 40 tests, som et team producerede med AI, blev 70 % ødelagt efter en interfaceopdatering; ingen af dem var egentlige fejl, de var alle skrøbelige XPath-vælgere. Holdet konverterede testene til en data-testid-base med skabelonen "fragility check". I løbet af de næste tre grænsefladeopdateringer faldt antallet af falske brud til nul; vedligeholdelsestiden faldt fra 6 timer til 30 minutter om ugen.
Case 2 — Falsk bestået UI-test. AI producerede en "tilføj til kurv"-test; testen var grøn. Da "fake-proof-of-passage"-skabelonen blev kørt, så testen ud til kun at kontrollere knapklik og sidetitel, og aldrig bekræfte, om vogntælleren var steget eller ej. Selvom vognlogikken var fuldstændig brudt, bestod testen. Tilføjet ægte påstand (indkøbskurvmærket er "1").
Case 3 - Blind ventefælde. I selentesten produceret af AI var der søvn(2) efter hvert trin; 60 test tog 14 minutter og gik stadig i stykker af og til. Efter at have skiftet til åben vent (vent til elementet kan klikkes) gik tiden ned til 5 minutter, og skørheden forsvandt. Blind venten var både langsom og upålidelig.
Almindelige fejl
- Accepterer skrøbelige vælgere. Brug af de lange XPaths, der genereres af AI, som de er; Testene går ned ved den første grænsefladeændring.
- Efterlader blind 'søvn'. "Løsning" af timingen med en fast ventetid; både langsom og ubeslutsom.
- Triviel påstand. Bare bekræft, at siden er indlæst; ikke kontrollere det faktiske brugerresultat (falsk-pass).
- Dyrk uden POM. Fordel vælgere til hver test; Manuel opdatering af snesevis af filer, når grænsefladen ændres.
- Angiver ikke værktøjet. Ikke at fortælle AI hvilket værktøj/sprog du ønsker; bliver rodet, ikke-fungerende kode.
- Tillidsfuld, når du kører den genererede kode og pass. Tester ikke ved at bryde koden.
Sammenfattende
UI-testautomatisering verificerer brugeradfærd ved at køre den faktiske browser med programmet. AI genererer denne kode hurtigt, men der er to store faldgruber: skøre tests (dårlig vælger, blind afventer) og falske beståede tests (ufuldstændig/triviel påstand). De tre søjler i solid UI-testning er commit-vælgeren (data-testid), eksplicit afvent, og påstand, der verificerer det faktiske brugerresultat. At have test genereret i Page Object Model forenkler vedligeholdelsen radikalt. Test hver genereret test med spørgsmålet "hvilken ændring vil bryde dette?"
Ansøgningsopgave
Vælg et brugerflow fra dit eget projekt (f.eks. login eller søgning). Få AI til at skrive test med skabelonen "robust UI-testgenerering". Derefter: (1) kontroller og fikser vælgerne og venter med et "skrøbelighedstjek", (2) bevis, at hver test faktisk validerer med et "pseudo-pass proof", (3) knæk koden og observer, at testen bliver rød. Rapportér antallet af tests, der er produceret og rettet, og antallet af sårbarheder og pseudo-pass, du har fundet.
tjekliste
- [ ] Jeg gav AI'en klart værktøjet, sproget, vælgerpolitikken og arkitekturen (POM).
- [ ] Jeg bekræftede, at vælgerne er data-testede.
- [ ] Jeg sørgede for at bruge eksplicit/automatisk ventetid i stedet for blind søvn.
- [ ] Jeg kontrollerede, at hver påstand verificerer det faktiske brugerresultat.
- [ ] Jeg testede hver test ved at bryde koden; Jeg så den blive rød.
- [ ] Jeg samlede testene i sideobjektmodelstrukturen.