Gevinster:
- Evne til at producere enheds-, integrations- og edge case-tests med meningsfuld påstand med AI
- Evne til systematisk at udtrække testdækning, grænseværdier og negative scenarier med AI-understøttelse
- Evne til at verificere, at testene produceret af AI faktisk verificerer adfærd og ikke bare gentager eksisterende kode
Test er den mekanisme, der beviser, at softwaren faktisk opfører sig som lovet. En god testsuite fortæller dig på få sekunder, om en ændring bryder noget og giver ingeniøren frihed til at handle med tillid. AI fremskynder den mest kedelige og mest springede del af testskrivning: genererer en lang række scenarier, brudpunkter og negative tilfælde. Men der er en lusket fælde her: AI kan skrive test, der bekræfter kodens aktuelle (måske fejlbehæftede) adfærd, ikke dens formodede adfærd; eller det kan producere tomme tests, der altid består, uden faktisk at kontrollere noget. Værdien af en test ligger ikke i, om den består, men i om den tjekker for det rigtige og bliver rød, når den er forkert.
I denne enhed lærer du, hvordan du producerer enheds-, integrations- og kanttilfælde-tests med meningsfulde påstande; hvordan man systematisk uddrager testdækning, breakpoints og downside-scenarier; og vi vil se, hvordan du kan kontrollere, at de test, AI producerer, faktisk validerer adfærd.
Koncepter: Enhedstest: Tester en enkelt funktion/klasse isoleret. Integrationstest: Tester, at flere dele fungerer korrekt sammen. Påstå: En erklæring, der kontrollerer, at et resultat er lig med det forventede; Dette er hjertet i testen. Dækning: Hvor meget af koden køres af tests; Høj dækning garanterer ikke kvalitet.
Fremstilling af meningsfulde tests
En god test gør tre ting klart: den etablerer en tilstand, den udfører en handling, den hævder resultatet. Når du udskriver test til AI'en, skal du angive, hvilken adfærd du vil verificere, og hvilke scenarier det skal dække; Ellers giver det overfladiske tests, der altid består.
- Definer den adfærd, der skal testes. "Hvad tæller som rigtigt?" Besvar spørgsmålet klart.
- Spørg efter scenarietyper. Normal, grænse, negativ, fejltilstand.
- Importer meningsfuld påstand. Det "smed ikke bare en fejl", det "returerede den korrekte værdi".
- Kontroller nøjagtigheden af testen. Bliver testen rød, når du knækker koden bevidst?
Omfattende testgenereringsprompt: "Skriv enhedstests for følgende 'anvend rabat(beløb, kupon)'-funktion. Hav MINDST ét scenarie i følgende kategorier: (1) normal gyldig kupon, (2) brudpunkter (0 beløb, 100 % rabat), (3) negativ (ugyldig kupon, negativt beløb), (assert kuponværdien), (4) test i hvert tilfælde af CONCRE fejl). (ikke bare 'fungerede'). Navngiv testene, der kan læses.
Grænseværdiudtrækningsprompt: "Udfør en grænseværdianalyse for denne funktions input. For hver parameter skal du udtrække værdierne 'lige ved grænsen', 'lige under grænsen', 'lige over grænsen' som en tabel. Angiv derefter de testscenarier, der dækker disse grænser. Skriv ikke kode endnu, bare analyse og scenarieliste.]" Funktion: [signaturliste.]"
Forsigtig: Høj testdækning (f.eks. 90%) beviser ikke, at koden er korrekt. Dækning måler, hvor mange rækker der blev udført; ikke at disse linjer giver det korrekte resultat. En test uden meningsfuld påstand øger dækningen, men garanterer ikke noget. Indholdet af påstanden bestemmer kvaliteten, ikke antallet af påstande.
Test af selve testen: Mutationens logik
Den mest praktiske måde at forstå, om den AI-genererede test faktisk virker, er at bryde koden bevidst (mutationstestlogik). Vend en betingelse, lav et +-tegn -; Hvis ingen test bliver rød, opretholder dine test faktisk ikke denne adfærd.
Test sårbarhedsjagt prompt: "Fortæl mig, hvilke potentielle fejl i denne kode, de følgende tests MÅSKE IKKE fanger. Foreslå 5 små mutationer, der kan laves i koden (f.eks. >= i stedet for >, - i stedet for +), og angiv for hver, om eksisterende tests ville fange det. For dem, der ikke fanges, foreslå test, der bør tilføjes. Kode: [kode]" Tests: [test]
Svag prompt / stærk prompt
SWAG: "Skriv en test til denne funktion." (Resultat: normalt et lykkeligt scenarie, svag påstand; savner fejl.) STÆRK: "Skriv en test til denne 'passwordStrong'-funktion. Regel: mindst 8 tegn, 1 stort bogstav, 1 ciffer påkrævet. Dæk følgende scenarier som SEPARATE tests: nøjagtigt 8 tegn (grænse), 7 tegn (under grænsen), ingen for store bogstaver, ingen streng, kun lange bogstaver (1000 tegn) Angiv eksplicit den forventede sand/falske værdi i hver test, og navngiv testen i henhold til det, den kontrollerer."
Kraftfuld prompt giver regler og fulde grænsescenarier. Grænsepar som "præcis 8/7 tegn" er de mest almindelige steder at lave fejl (forvirrende > med >=). Svag prompt omgår disse grænser og fører fejlen til produktionen.
Testtyper og hvor de skal bruges
Testtype
Hvad bekræfter det?
AI-bidrag
Opmærksomhed
enhed
Enkelt funktion/klasse
Genererer hurtigt multiscenarier
Der kræves meningsfuld påstand
integration
Dele arbejder sammen
Scenarie og hånlig dataudkast
Ægte vanedannende adfærd
afslutte/acceptere
Hele brugerflowet
Trinliste og forventning
udsat for skørhed
regression
Gammel fejl vender ikke tilbage
Fejlspecifik test
Bør tilføjes til hver rettelse
Mini sager
Case 1 — Testen, der altid består. AI skriver 12 test til en funktion, og de består alle. Ingeniøren bliver mistænksom og forvrænger bevidst funktionens returværdi; Kun 3 af testene bliver røde. De øvrige 9 tests indeholder ikke meningsfulde påstande. Testning styrkes af mutationsjagt; reel beskyttelse opnås i 9 scenarier.
Tilfælde 2 — Grænsefejl. En aldersbekræftelsesfunktion skal sige "18 og derover er gyldig", men >18 er skrevet, hvilket betyder, at 18 år er afvist. Fejlen dukker op med det samme i test, fordi AI'en genererer "præcis 18"-scenariet gennem breakpoint-analyse. En enkelt grænsetest forhindrer reelle brugerklager.
Case 3 — Afhjælpning af nuværende adfærd. Når AI får besked på at "skrive en test baseret på denne kode", producerer den en test, der accepterer en afrundingsfejl, der allerede eksisterer i koden, som "korrekt". Når teknikeren udskriver testen i henhold til kravet (forventet korrekt værdi) og ikke koden, bliver testen rød, og den reelle fejl opstår. Tests bør udledes af forventning, ikke fra kode.
Almindelige fejl
- Meningsløst påstand. "Skast ikke en fejl" er ikke nok; Den korrekte værdi skal verificeres.
- Forvirrer omfang med kvalitet. Høj dækning er ingen garanti for nøjagtige resultater.
- Udskrivning af testen med kode. Retter den aktuelle fejl til "sand"; Tests bør udledes af forventninger.
- Overspringsgrænseværdier. At forveksle > med >= er den mest almindelige fejl; grænsepar skal testes.
- Revision ikke selve testen. En test, der ikke bliver rød, når du bryder koden, giver ikke beskyttelse.
Sammenfattende
En god testpakke er nøglen til at foretage ændringer med tillid. AI genererer hurtigt et væld af scenarier, grænser og negative situationer; Men hvis den udleder test fra kode i stedet for krav, kan den rette eksisterende fejl eller skrive meningsløse tests, der altid består. Hævd den konkrete forventede værdi i hver test, medtag bundne par, og bekræft, at dine test faktisk beskytter ved bevidst at bryde koden. Indholdet af påstanden, ikke antallet af scopes, bestemmer kvaliteten.
Ansøgningsopgave
Vælg en funktion og få den til at generere test i fire kategorier (normal, grænse, negativ, fejl) med en omfattende testgenereringsprompt; Få den konkrete forventede værdi hævdet i hver test. Kør derefter testsårbarhedsjagtprompten, foreslå 5 små mutationer i koden, og kør testene for at kontrollere, hvilke de fanger. Tilføj en ny test for mindst én mutation, der ikke blev fanget, og vis, at den nu er i minus.
tjekliste
- [ ] Jeg udskrev testene baseret på den forventede/korrekte adfærd, ikke koden.
- [ ] Jeg dækkede normal-, limit-, negative- og fejlscenarier.
- [ ] Jeg hævdede den konkrete forventede værdi i hver test.
- [ ] Jeg testede kantpar (lige over-under / lige over-under).
- [ ] Ved bevidst at bryde koden bekræftede jeg, at testene blev røde.
- [ ] Jeg tilføjede en ny test for uopdagede mutationer.