Gevinster:
- Evne til å gjenkjenne de tre ansiktene til pseudo-tillit (ikke-påståelig, selvhevdende, triviell påstand) og bruke motgift
- Evne til å bruke mutasjonstesting og mutasjonsscore som et mer nøyaktig mål på kvalitet enn prosent dekning med verktøy eller hånd
- Evne til å posisjonere AI som et rødt lag mot testing og jakte på teste smutthull uten å falle i rosfellen
I hjertet av denne modulen er en gjentakende advarsel: et grønt glødende testpanel er ikke bevis på kvalitet. Hvis testene dine gir deg selvtillit, må du vite om denne selvtilliten er ekte eller falsk. I en tidsalder med kunstig intelligens (AI) er dette spørsmålet mer kritisk enn noen gang, fordi AI er dyktig til å produsere flytende, glatte, men hule tester. Falsk tillit – å tro at programvaren er riktig fordi testene er grønne, mens testene faktisk ikke bekrefter noe – er det farligste som kan skje med et QA-team; fordi det ikke skjuler at det ikke er feil, men at du ikke kan se feilene. Denne enheten samler valideringsfilosofien til hele modulen i én disiplin: å teste testene dine.
Gullstandarden for å måle kvaliteten på testing: mutasjonstesting
Den kraftigste måten å forstå om en test faktisk beskytter eller ikke er mutasjonstesting (mutasjonstesting – en teknikk som produserer tilsiktede små forvrengninger/mutasjoner i kildekoden og måler om testene oppdager disse forvrengningene). Logikken er enkel: hvis du med vilje bryter koden (gjør et + til -, en > til >=, en sann til usann), bør en god testpakke fange opp den korrupsjonen og bli rød. Hvis den ikke gjør det, er den forstyrrelsen en overlevd mutant - så testene dine bevarer faktisk ikke den oppførselen.
Mutasjonsscore = mutasjon drept / total mutasjon. En pakke med 90 % linjedekning kan ha en mutasjonsscore på 40 %; Dette indikerer at linjene fungerer, men atferden er ikke bekreftet. Mutasjonsscore er et mye mer ærlig mål på kvalitet enn prosentvis dekning.
Tips: Det finnes automatiske mutasjonsverktøy (PIT/Pitest for Java, Stryker for JavaScript/TypeScript, Stryker.NET for .NET, mutmut for Python). Disse genererer og tester automatisk hundrevis av mutasjoner. Hvis du ikke har et verktøy, er til og med den manuelle "bryt kodetesten"-metoden uvurderlig for kritiske funksjoner.
De tre ansiktene til pseudo-tillit og dens motgift
Pseudo-tillit form
symptom
motgift
Test uten påstand
Koden fungerer, ingenting er validert
Ekte påstand i hver test; test med mutasjon
selvbekreftende test
Forventet = utgang av kode
Beregn forventet verdi uavhengig
Triviell påstand
"ikke null", "200 returnert"
Validere forretningsregel/faktisk resultat
Feilslutning med stort omfang
90 % linjer, lav beskyttelse
Se på mutasjonspoengene
Skjør testtoleranse
"Sitter fast igjen, pass"
Rotårsak + deterministisk testing
Bruker AI som et "rødt lag"
AI kan både generere pseudo-tillit og være en mektig alliert i jakten på den. Bruk AI som et rødt lag mot dine egne tester: spør "skriv kode som består disse testene, men er feil" eller "finn en undergraving som vil lure disse testene." Hvis AI finner smutthull i testene dine, er disse smutthullene reelle risikoer.
Forsiktig: Ikke spør AI "Er testkvaliteten min god?" og ta svaret "ja, flott" som forsikring. AI har en tendens til å være snill. Utfordre i stedet AI til en konkret oppgave: "produser en feil som består disse testene." Hvis det kan produsere det, er testene dine blinde for den feilen.
Ekvivalente mutasjoner og grenser for poengsummen
Mutasjonstesting er kraftig, men den har en hake: noen mutasjoner endrer ikke oppførselen til koden i det hele tatt. Disse kalles ekvivalente mutasjoner (ekvivalent mutant - ødelagt kode, mutasjon som gir nøyaktig samme resultat som originalen). For eksempel, endring av startverdien til en variabel som aldri brukes, påvirker ikke utdataene; Ingen test kan og bør ikke fange dette. Derfor er en 100 % mutasjonsscore ofte uoppnåelig i praksis og er ikke målet. Å luke ut tilsvarende mutasjoner for hånd er arbeidskrevende; Så ikke les mutasjonsskåren som en absolutt eksamensscore, men som en ærlig indikator på "beskytter testene mine virkelig?"
Den praktiske tilnærmingen er denne: i stedet for konstant å kjøre mutasjonstesting over hele kodebasen, kjør den på modulene som inneholder høyest risiko og mest komplekse forretningsregler. Undersøk de overlevende mutasjonene i disse modulene én etter én; Hvis det er et reelt gap, legg til en test; hvis det er en tilsvarende mutasjon, merk den med begrunnelse og bestå. AI kan utføre initial screening for å vurdere om en overlevende mutasjon er ekvivalent; men den endelige avgjørelsen tas av deg som vet hva koden gjør.
Forsiktig: Mutasjonstesting er beregningsmessig dyrt (alle relevante tester kjøres på nytt for hver mutasjon). Så en vanlig og rimelig strategi er å planlegge det som en ukentlig eller pre-release dyp sjekk for kritiske moduler, i stedet for hver fusjon.
Svak forespørsel / Sterk forespørsel
Svak: "Er testene mine tilstrekkelige?"
Sterk: "Funger som et rødt team for denne funksjonen og testpakken. (1) Generer 8 mutasjoner i koden som kan drepes (operatorsubstitusjon, grenseforskyvning, tilstandsinversjon, returverdierstatning). (2) For hver mutasjon, angi hvilken av de eksisterende testene som vil fange den og hvilke som IKKE vil fange den. (3) For hver mutasjon som overlever, skriv en ny test som kan vise alle disse (4) kan også vise en kode. tester, men bryter forretningsregelen Kode+tester: [lim inn].
Kraftig ledetekst; Den posisjonerer AI som en testbrytende eksaminator, ikke en rosmaskin.
Fire kopierbare maler
1) Manuell mutasjonskontroll:
Generer 8 signifikante mutasjoner (mindre tilsiktede forstyrrelser) for denne koden: aritmetisk operatorsubstitusjon, sammenligningsgrense (> vs >=), logisk inversjon, retur/konstant substitusjon, betingelseshopping. For hver mutasjon, forutsi hvilke av de tilgjengelige testene som vil fange den eller ikke. Kode+tester: [lim inn]
2) Å drepe den overlevende mutasjonen:
Følgende mutasjonstestrapport inneholder overlevende (ufangede) mutasjoner: [liste/rapport]. For hver, skriv en minimal test som vil drepe den mutasjonen (koden blir rød når den brytes på den måten). Kommenter hvilken oppførsel testen bekrefter.
3) Rødt lag - blodprøven:
Kan du skrive kode som BESTÅR ALLE følgende tester, men som bryter med følgende forretningsregel: [forretningsregel]. Hvis ja, hvilket smutthull i disse testene tillater dette? Legg til testen som vil lukke smutthullet. Tester: [lim inn]
4) Testkvalitetsinspeksjon:
Sjekk denne testpakken for kvalitet. Kryss av for hver test:- Er det en sann påstand eller er det rekvisitter?- Er forventet verdi uavhengig, avledet fra kode?- Verifiserer den forretningsregelen eller noe trivielt? Gi til slutt en estimert "true assert score" og de 3 svakeste testene. Tester: [lim inn]
tre minisaker
Tilfelle 1 — Dekning 92 %, mutasjonsscore 38 %. Ett team stolte på høy dekning. Når mutasjonstesting ble kjørt med Stryker, var poengsummen 38 %: de fleste av de produserte mutasjonene overlevde. Dette var et bevis på at testene ikke kjørte linjene og bekreftet atferden. Teamet investerte tre uker i testing av kvalitet; Mutasjonspoengene økte til 81 %, og to reelle beregningsfeil ble fanget opp av disse forsterkede testene i neste utgivelse.
Tilfelle 2 - AI lurte testen. Med en "rødt lag"-mal ba en ekspert AI om kode som besto eksisterende tester, men brøt med rabattregelen. AI skrev en kode som alltid returnerte en rabatt på null - og alle tester forble grønne fordi ingen tester bekreftet den faktiske rabattverdien. Gap sett, reelle hevder lagt til.
Case 3 - Rosfellen. En juniortester spurte AI: "Er testene mine gode?" og var lettet over å høre svaret "Veldig omfattende." Hans seniorkollega fikk de samme testene revidert ved å bruke malen "testkvalitetsrevisjon"; Det viste seg at 12 av 20 tester var dekor (uten påstand eller useriøs). Det riktige spørsmålet ga det riktige svaret.
Vanlige feil
- Tar feil av muligheter for kvalitet. Stoler på høy raddekning og ser ikke på mutasjonspoengene i det hele tatt.
- Stoler på AIs ros. Spør "Er testene dine gode?" og vurderer det positive svaret som forsikring.
- Utlede forventet verdi fra kode. Selvverifiserende tester som bekrefter feil kode.
- Vær fornøyd med trivielle påstander. Sjekker som ikke validerer selve regelen, for eksempel "ikke null", "200 returnert".
- Ignorerer overlevende mutasjoner. Ignorerer det som ikke ble fanget opp i mutasjonsrapporten.
- Ikke engang prøver å manuelt mutere kritisk kode. Hopp over trinnet "bryt koden og test" hvis verktøyet ikke er tilgjengelig.
Oppsummert
Pseudo-trust er å tro at programvare er riktig fordi testene er grønne; mens testene kanskje ikke bekrefter noe. Gullstandarden for å måle dette er mutasjonstesting: bevisst knekke koden og måle om testene fanger den. Mutasjonsscore er et mye mer ærlig mål på kvalitet enn prosentvis dekning. AI både produserer pseudo-tillit og blir et mektig rødt lag i jakten på den - spør "produser en feil som består disse testene." Test testene dine: ekte påstand, uavhengig forventet verdi, validering av forretningsregler og drepte mutasjoner.
Søknadsoppgave
Importer en funksjon som inneholder en forretningsregel og dens tester fra ditt eget prosjekt. Hvis mulig, kjør et mutasjonsverktøy (Stryker/Pitest/mutmut) og mål mutasjonsskåren; Hvis det ikke er noe verktøy, generer minst 8 mutasjoner med malen "manuell mutasjonskontroll" og prøv dem manuelt. For hver overlevende mutasjon, skriv en ny test med malen "drep overlevende mutasjon". Til slutt, med "rødt lag"-mønsteret, se om AI kan produsere kode som lurer testene dine. Rapporter start- og sluttmutasjonspoengsummen din (eller fanget/total mutasjonsrate).
sjekkliste
- [ ] Jeg evaluerte testkvaliteten etter mutasjonsscore, ikke dekning.
- [ ] Jeg kjørte mutasjonstesting (enten med verktøy eller manuelt) for kritisk kode.
- [ ] Jeg skrev nye tester for hver overlevende mutasjon.
- [ ] Jeg brukte AI som det røde laget og søkte etter smutthull i testene mine.
- [ ] Jeg tok ikke AIs "testene dine er gode"-ros som en forsikring.
- [ ] Jeg sjekket at hver test bekrefter den faktiske påstanden, uavhengig forventet verdi og forretningsregel.