Gevinster:
- Evne til å produsere enhets-, integrasjon- og edge-case-tester med meningsfull påstand med AI
- Evne til systematisk å trekke ut testdekning, grenseverdier og negative scenarier med AI-støtte
- Evne til å verifisere at testene produsert av AI faktisk bekrefter atferd og ikke bare gjentar eksisterende kode
Testing er mekanismen som beviser at programvaren faktisk oppfører seg som lovet. En god testpakke forteller deg på sekunder om en endring bryter noe og gir ingeniøren friheten til å handle med selvtillit. AI setter fart på den mest kjedelige og mest hoppede delen av testskriving: genererer en rekke scenarier, bruddpunkter og negative tilfeller. Men det er en lure felle her: AI kan skrive tester som bekrefter kodens nåværende (kanskje feilaktige) oppførsel, ikke dens antatte oppførsel; eller det kan produsere tomme tester som alltid passerer, og som faktisk ikke sjekker noe. Verdien av en test ligger ikke i om den består, men i om den sjekker det rette og blir rød når den er feil.
I denne enheten lærer du hvordan du produserer enhets-, integrasjon- og kant-tilfelletester med meningsfulle påstander; hvordan man systematisk trekker ut testdekning, bruddpunkter og nedsidescenarier; og vi skal se hvordan du kan sjekke at testene AI produserer faktisk validerer atferd.
Konsepter: Enhetstesting: Tester en enkelt funksjon/klasse isolert. Integrasjonstesting: Tester at flere deler fungerer riktig sammen. Påstå: Et utsagn som kontrollerer at et resultat er likt det som var forventet; Dette er kjernen i testen. Dekning: Hvor mye av koden kjøres av tester; Høy dekning garanterer ikke kvalitet.
Produser meningsfulle tester
En god test gjør tre ting tydelig: den etablerer en tilstand, den utfører en handling, den hevder resultatet. Når du skriver ut tester til AI, spesifiser hvilken oppførsel du vil verifisere og hvilke scenarier den skal dekke; Ellers gir det overfladiske tester som alltid består.
- Definer atferden som skal testes. "Hva regnes som rett?" Svar tydelig på spørsmålet.
- Spør etter scenariotyper. Normal, grense, negativ, feiltilstand.
- Importer meningsfull påstand. Det "kastet ikke bare en feil", det "returerte riktig verdi".
- Sjekk nøyaktigheten av testen. Blir testen rød når du bryter koden bevisst?
Omfattende forespørsel om testgenerering: "Skriv enhetstester for følgende funksjon 'applydiscount(amount, coupon)'. Ha MINST ett scenario i følgende kategorier: (1) normal gyldig kupong, (2) bruddpunkter (0 beløp, 100 % rabatt), (3) negativ (ugyldig kupong, negativt beløp), (assert coupon value) (4) testverdi i CONCRE-tilfelle). (ikke bare 'fungerte'). Gi testene et navn: [kode]
Uttak av grenseverdier: "Utfør en grenseverdianalyse for inngangene til denne funksjonen. For hver parameter, trekk ut verdiene 'like ved grensen', 'like under grensen', 'like over grensen' som en tabell. List deretter testscenarioene som dekker disse grensene. Ikke skriv kode ennå, bare analyse og scenarioliste.]" Funksjon: [signaturliste.]
Forsiktig: Høy testdekning (f.eks. 90 %) beviser ikke at koden er riktig. Dekning måler hvor mange rader som ble utført; ikke at disse linjene gir riktig resultat. En test uten meningsfull påstand øker dekningen, men garanterer ingenting. Innholdet i påstanden bestemmer kvaliteten, ikke antallet påstander.
Testing av selve testen: mutasjonens logikk
Den mest praktiske måten å forstå om den AI-genererte testen faktisk fungerer, er å bevisst bryte koden (mutasjonstestingslogikk). Snu en betingelse, lag et +-tegn -; Hvis ingen tester blir røde, opprettholder ikke testene dine den oppførselen.
Spørsmål for jakt på sårbarheter: "Fortell meg hvilke potensielle feil i denne koden de følgende testene KAN IKKE fanger. Foreslå 5 små mutasjoner som kan gjøres i koden (f.eks. >= i stedet for >, - i stedet for +) og angi for hver om eksisterende tester vil fange den. For de som ikke blir fanget, foreslå testing som bør legges til. Kode: [kode]" Tester: [test]
Svak forespørsel / sterk forespørsel
SVAK: "Skriv en test til denne funksjonen." (Resultat: vanligvis ett lykkelig scenario, svak påstand; savner feil.) STERK: "Skriv en test til denne 'passwordStrong'-funksjonen. Regel: minst 8 tegn, 1 stor bokstav, 1 siffer kreves. Dekk følgende scenarier som SEPARATE tester: nøyaktig 8 tegn (grense), 7 tegn (under grensen), ingen for store bokstaver tomme, ingen store bokstaver tomme, ingen store bokstaver. (1000 tegn) Angi eksplisitt den forventede sanne/falske verdien i hver test og navngi testen i henhold til det den sjekker."
Kraftig forespørsel gir regler og fulle grense-scenarier. Grensepar som "nøyaktig 8/7 tegn" er de vanligste stedene å gjøre feil (forvirrende > med >=). Svak melding omgår disse grensene og fører feilen til produksjonen.
Testtyper og bruksområder
Testtype
Hva bekrefter det?
AI-bidrag
Oppmerksomhet
enhet
Enkel funksjon/klasse
Genererer multi-scenarioer raskt
Det kreves meningsfull påstand
integrasjon
Deler som jobber sammen
Scenario og falske datautkast
Ekte vanedannende oppførsel
avslutte/godta
Hele brukerflyten
Trinnliste og forventning
utsatt for sprøhet
regresjon
Gammel feil kommer ikke tilbake
Feilspesifikk testing
Bør legges til hver reparasjon
Minivesker
Case 1 - Testen som alltid består. AI skriver 12 tester til en funksjon, og alle består. Ingeniøren blir mistenksom og forvrenger bevisst returverdien til funksjonen; Kun 3 av testene blir røde. De andre 9 testene inneholder ikke meningsfulle påstander. Testing styrkes av mutasjonsjakt; reell beskyttelse oppnås i 9 scenarier.
Tilfelle 2 — Grensefeil. En aldersbekreftelsesfunksjon skal si "18 og over er gyldig", men >18 er skrevet, noe som betyr at 18 år er avvist. Feilen dukker opp umiddelbart i testing fordi AI genererer "nøyaktig 18"-scenariet gjennom bruddpunktanalyse. En enkelt grensetest forhindrer reelle brukerklager.
Tilfelle 3 — Retting av gjeldende oppførsel. Når AI får beskjed om å "skrive en test basert på denne koden", produserer den en test som aksepterer som "riktig" en avrundingsfeil som allerede eksisterer i koden. Når ingeniøren skriver ut testen i henhold til kravet (forventet riktig verdi) og ikke koden, blir testen rød og den virkelige feilen oppstår. Tester bør utledes fra forventning, ikke fra kode.
Vanlige feil
- Meningsløs påstand. "Skalte ikke en feil" er ikke nok; Riktig verdi må verifiseres.
- Forvirrer omfang med kvalitet. Høy dekning er ingen garanti for nøyaktige resultater.
- Skrive ut testen med kode. Retter gjeldende feil til "true"; Tester bør utledes av forventninger.
- Hopp over grenseverdier. Å forveksle > med >= er den vanligste feilen; grensepar må testes.
- Reviderer ikke selve testen. En test som ikke blir rød når du bryter koden gir ikke beskyttelse.
Oppsummert
En god testpakke er nøkkelen til å gjøre endringer med tillit. AI genererer raskt en rekke scenarier, grenser og negative situasjoner; Men hvis den utleder tester fra kode i stedet for krav, kan den fikse eksisterende feil eller skrive meningsløse tester som alltid består. Angi den konkrete forventede verdien i hver test, inkluder bundne par, og kontroller at testene dine faktisk beskytter ved bevisst å bryte koden. Innholdet i påstanden, ikke antall scopes, bestemmer kvaliteten.
Søknadsoppgave
Velg en funksjon og få den til å generere tester i fire kategorier (normal, grense, negativ, feil) med en omfattende prompt for testgenerering; Ha den konkrete forventede verdien hevdet i hver test. Kjør deretter spørsmålet om testsårbarhetsjakt, foreslå 5 små mutasjoner i koden, og kjør testene for å sjekke hvilke de fanger. Legg til en ny test for minst én mutasjon som ikke ble fanget og vis at den nå er i minus.
sjekkliste
- [ ] Jeg skrev ut testene basert på forventet/riktig oppførsel, ikke koden.
- [ ] Jeg dekket normale, grense, negative og feilscenarier.
- [ ] Jeg hevdet den konkrete forventede verdien i hver test.
- [ ] Jeg testet kantpar (like over-under / like over-under).
- [ ] Ved å bryte koden bevisst bekreftet jeg at testene ble røde.
- [ ] Jeg la til en ny test for uoppdagede mutasjoner.