Hva er mutasjonstesting? (Eksempel)
Thomas Hamilton
⚡ Smart oppsummering
Mutasjonstesting introduserer bevisst små feil i kildekoden og kjører deretter den eksisterende testsuiten mot hver feilaktige versjon, for å måle om disse testene er sterke nok til å oppdage endringen.
Hva er mutasjonstesting?
Mutasjonstesting er en type programvaretesting der visse utsagn i kildekoden endres eller muteres for å sjekke om testtilfellene er i stand til å finne feil i kildekoden. Målet med mutasjonstesting er å sikre kvaliteten på testtilfellene når det gjelder robusthet, slik at de ikke klarer å motstå den muterte kildekoden.
Endringen som gjøres i et mutantprogram må holdes ekstremt liten, slik at den ikke påvirker programmets overordnede mål. Mutasjonstesting kalles også en feilbasert teststrategi, fordi den innebærer å bevisst lage en feil i programmet. Det er en form for Hvit Box Testing som hovedsakelig brukes under Enhetstesting.
Mutasjonstesting ble foreslått i 1971 i en studentartikkel av Richard Lipton og formalisert i artikkelen «Hints on Test Data Selection» fra 1978 av DeMillo, Lipton og Sayward. Den mistet momentum på grunn av datidens datakostnad og har siden gjenvunnet terreng for språk som Java, C#, Python, JavaSkript og XML.
Hvordan utføre mutasjonstesting?
Følgende er trinnene for å utføre mutasjonstesting, også kjent som mutasjonsanalyse:
Trinn 1: Feil introduseres i programmets kildekode ved å opprette mange versjoner kalt mutanter. Hver mutant skal inneholde én enkelt feil, og målet er å forårsake at mutantversjonen feiler, noe som demonstrerer effektiviteten til testtilfellene.
Trinn 2: Testtilfeller brukes på det opprinnelige programmet og også på mutantprogrammet. Testsak skal være tilstrekkelig, og den er tilpasset for å oppdage feil i et program.
Trinn 3: Sammenlign resultatene fra det opprinnelige og mutantprogrammet.
Trinn 4: Hvis det originale programmet og mutantprogrammet genererer ulik utdata, blir mutanten drept av testtilfellet. Derfor er testtilfellet godt nok til å oppdage endringen mellom det originale og mutantprogrammet.
Trinn 5: Hvis det opprinnelige programmet og mutantprogrammet genererer samme utdata, holdes mutanten i live. I slike tilfeller må det lages mer effektive testtilfeller som dreper alle mutantene.
Diagrammet nedenfor tracfølger de samme fem trinnene, fra det opprinnelige programmet gjennom mutantgenerering til den drepte eller overlevende dommen.
Hvordan lage mutantprogrammer?
En mutasjon er ikke annet enn en enkelt syntaktisk endring som gjøres i en programsetning. Hvert mutantprogram skal avvike fra det opprinnelige programmet med nøyaktig én mutasjon.
| Originalt program | Mutant program |
| Hvis (x>y) Skriv ut "Hei" Else Skriv ut "Hei" |
Hvis (x Skriv ut "Hei" Else Skriv ut "Hei" |
I paret ovenfor er bare sammenligningsoperatoren endret, men et testtilfelle der x er større enn y skriver nå ut «Hei» i stedet for «Hallo». Illustrasjonen viser den ene syntaktiske redigeringen.
Hva skal endres i et mutantprogram?
Det finnes flere teknikker som kan brukes til å generere mutantprogrammer. De tre familiene nedenfor dekker de fleste mutasjonsoperatorene som verktøy leveres med.
| Operand erstatningsoperatører | Operatorer for modifisering av uttrykk | Operatorer for modifisering av setninger |
| Erstatt operanden med en annen operand (x med y, eller y med x) eller med en konstant verdi. | Erstatt en operator, eller sett inn en ny operator, i en programsetning. | Programmatiske utsagn er modifisert for å lage mutante programmer. |
| Eksempel: If(x>y) erstatte x- og y-verdier If(5>y) erstatt x med konstant 5 |
Eksempel: Hvis(x==y) Vi kan erstatte == med >= og få mutantprogrammet som If(x>=y) og sette inn ++ i setningen If(x==++y) |
Eksempel: Slett den andre delen i en if-else-setning Slett hele if-else-setningen for å sjekke hvordan programmet oppfører seg |
Noen eksempler på mutasjonsoperatorer:
- GOTO etiketterstatning
- Returerklæringserstatning
- Sletting av erklæring
- Innsetting av unær operator (som – og ++)
- Utskifting av logisk kontakt
- Sammenlignbar erstatning for arraynavn
- Fjerne else-delen av en if-else-setning
- Legge til eller erstatte operatorer
- Erstatning av erklæring ved å endre dataene
- Datamodifisering for variablene
- Endring av datatyper i programmet
OperaTorer som berører en grensebetingelse overlever oftest, så mutasjonsresultater peker ofte tilbake på hull i grenseverdianalyse.
Typer mutasjonstesting
In Engineering programvareMutasjonstesting er grunnleggende kategorisert i tre typer – utsagnsmutasjon, verdimutasjon og beslutningsmutasjon.
- Uttalelsesmutasjon – en setning klippes ut, limes inn eller slettes, så resultatet kan bli at noen linjer med kode fjernes.
- Verdimutasjon – verdiene til primære parametere og konstanter endres, for eksempel endring av en løkkegrense eller en terskel.
- Beslutningsmutasjon – kontrollsetninger endres, for eksempel flipping en relasjonsoperator eller negerer en betingelse.
Verktøy grupperer operatorene sine under disse tre overskriftene, slik at familien som produserte en overlevende mutant forteller testeren hvilken type påstand som mangler. En overlevende beslutningsmutant markerer vanligvis en uprøvd gren, som overlapper med løkketesting.
Automatisering av mutasjonstesting
Mutasjonstesting er ekstremt tidkrevende og komplisert å utføre manuelt, så det anbefales å bruke automatiseringsverktøy, som også reduserer kostnadene. Et mutasjonsverktøy samler mutantene, planlegger kjøringene, registrerer hvilken mutant hver mislykkede test drepte, og rapporterer poengsummen.
Liste over tilgjengelige verktøy:
- Stryker — et rammeverk for mutasjonstesting med åpen kildekode med utgaver for JavaManus og TypeScript (StrykerJS), C# og .NET (Stryker.NET), og Scala (Stryker4s).
- PIT, også skrevet PITest — et mutasjonstestingssystem for Java og JVM-en som muterer kompilert bytekode og kobles til Maven og Gradle bygger ved siden av JUnit.
Begge kjører som et byggesteg, så de hører hjemme i samme kontinuerlig integrering rørledningen som resten av automatiseringstesting på.
Mutasjonspoeng
Mutasjonsskåren er definert som prosentandelen drepte mutanter av det totale antallet mutanter.
Mutasjonspoeng = (drepte mutanter / totalt antall mutanter) * 100
Formelen vises nedenfor i den formen de fleste verktøy rapporterer den.
Testtilfeller beskrives som mutasjonstilstrekkelige når poengsummen når 100 prosent. I praksis må nevneren ekskludere ekvivalente mutanter — mutanter hvis endrede syntaks oppfører seg nøyaktig som originalen, slik at ingen test kan drepe dem. Verktøy rapporterer derfor drepte mutanter delt på drepte pluss overlevende ikke-ekvivalente mutanter, og lar testeren flagge ekvivalenter.
Eksperimentelle resultater har vist at mutasjonstesting er en effektiv måte å måle tilstrekkeligheten av testtilfeller. Den største ulempen er kostnaden ved å generere mutantene og utføre hvert testtilfelle mot hver enkelt.
Mutasjonstesting vs. Code Dekning
Høyt testdekning beviser ikke sterke tester. Linje- og grendekning registrerer hvilke utsagn som ble kjørt, ikke om noe ble verifisert etterpå, så en test som kaller en metode og ikke hevder noe teller fortsatt som dekket. Mutasjonstesting tetter dette gapet, fordi en mutant bare dør når en påstand faktisk mislykkes.
| Aspekt | Code dekning | Mutasjonspoengsum |
| Hva den måler | Hvilke linjer eller grener testene ble utført | Hvilke injiserte feil testene oppdaget |
| Følsom for påstander | Nei – en test med null påstander gir fortsatt dekning | Ja – en mutant overlever når ingen påstand feiler |
| Kostnaden for en løpetur | Én instrumentert testkjøring | Én testkjøring per overlevende mutant, så langt tregere |
| Typisk bruk | En rask gate på hver commit | En grundigere periodisk kontroll av kritiske moduler |
| Feil modus | 100 prosent dekning uten reell verifisering | Ekvivalente mutanter som aldri kan drepes |
De to målingene er komplementære. Dekningen navngir koden som aldri ble nådd; mutasjonspoengsummen navngir den nådde koden som aldri ble sjekket. Begge gir samme informasjon. prosess for feilhåndtering, sammen med tiltak som defekttetthet.
Fordeler med mutasjonstesting
Følgende er fordelene med mutasjonstesting:
- Det er en kraftig tilnærming for å oppnå høy dekning av kildeprogrammet.
- Den tester selve testsuiten, noe ingen andre teknikk for programvaretesting gjør direkte.
- Mutasjonstesting gir programvareutvikleren et godt nivå av feildeteksjon.
- Metoden avdekker uklarheter i kildekoden og har kapasitet til å avdekke feil som vanlige kjøringer aldri når.
- Overlevende mutanter er handlingsrettede: hver av dem navngir en spesifikk linje og en spesifikk endring som suiten ikke la merke til.
- Kunder drar nytte av denne testingen ved å motta et mer pålitelig og stabilt system.
Ulemper med mutasjonstesting
På den annen side er følgende ulemper med mutasjonstesting:
- Mutasjonstesting er ekstremt kostbart og tidkrevende, fordi et stort antall mutantprogrammer må genereres og kompileres.
- Siden det er tidkrevende, er det rimelig å si at denne testingen ikke kan gjøres uten et automatiseringsverktøy.
- Hver mutant utøves av samme antall testtilfeller som det opprinnelige programmet, så en stor mutantpopulasjon må kjøres mot hele testsuiten.
- Ekvivalente mutanter kan ikke drepes av noen test, og å skille dem fra ekte overlevende krever vanligvis manuell gjennomgang.
- Fordi metoden endrer kildekoden, er den ikke anvendelig for Svart Box Testing.
Når man skal bruke mutasjonstesting
Kostnadsprofilen ovenfor betyr at mutasjonstesting sjelden kjøres over en hel kodebase på hver commit. Det betaler seg selv der en uoppdaget feil er dyr og koden som testes er liten nok til å mutere raskt.
- Sikkerhetskritisk eller økonomisk logikk — betalingsberegning, skatteregler og autorisasjonskontroller, der et stille feil svar er verre enn et krasj.
- Suiter med mistenkelig høy dekning — når dekningen er nær 100 prosent, men feilene fortsatt slippes unna.
- Eldre kode blir refaktorert — mutasjonsresultater avslører om de eksisterende testene ville fange opp en regresjon.
- Biblioteker og delte komponenter — en feil i en gjenbrukt komponent multipliseres på tvers av hver innringer.
- Lag som øver testdrevet utvikling — poengsummen kontrollerer at testene som ble skrevet først gjør et ordentlig arbeid.
Det er vanligvis ikke verdt å kjøre på engangsprototyper, på tynt lim eller generert kode uten forgreningslogikk, eller på pakker dominert av trege integrasjonstester som allerede tar timer for én passering.
De fleste teamene skal derfor avgrense kjøringen til endrede filer, sette en terskel for modulene som er viktige, og la det bredere Regresjonstesting suiten bærer resten av livssyklus for programvaretesting.
