Testdekning i programvaretesting: Hvordan måle den

Hva er testdekning?

Testdekning er definert som en beregning i Software Testing som måler mengden testing utført av et sett med tester. Det vil inkludere å samle informasjon om hvilke deler av et program som kjøres når testpakken kjøres for å finne ut hvilke grener av betingede setninger som er tatt.

Enkelt sagt er det en teknikk for å sikre at testene dine tester koden din eller hvor mye av koden du trente ved å kjøre testen.

Hva gjør testdekning?

På et live-prosjekt støtter testdekningen fire praktiske aktiviteter:

• Finne området for et krav som ikke er implementert av et sett med testtilfeller
• Hjelper med å lage flere testtilfeller for å øke dekningen
• Identifisere et kvantitativt mål for testdekning, som er en indirekte metode for kvalitetssjekk
• Identifisere meningsløse testtilfeller som ikke øker dekningen

Fordeler med testdekning i programvareteknikk

Disse aktivitetene omsettes til konkrete ingeniørfordeler.

• Det kan kvalitetssikre testen
• Det kan hjelpe med å identifisere hvilke deler av koden som faktisk ble berørt for utgivelsen eller rettelsen
• Den kan bestemme alle beslutningspunktene og -banene i applikasjonen din som ikke ble testet, noe som lar deg øke testdekningen.
• Forhindre defekt lekkasje
• Tid, omfang og kostnader kan holdes under kontroll
• Feilforebygging på et tidlig stadium av prosjektets livssyklus
• Mangler i krav, testtilfeller og mangler på enhetsnivå og kodenivå kan på en enkel måte finnes

Typer testdekning

Dekning er aldri et enkelt tall. Lag track flere typer samtidig, fordi hver av dem svarer på et annet spørsmål om den samme suiten. Tabellen nedenfor grupperer typene du møter oftest.

De fem første typene er målinger på kodenivå og tilhører testing av hvit boks, mens krav og risikodekning ligger på testplannivå.

Hva er de viktigste forskjellene mellom Code Dekning og testdekning?

Code dekning og testdekning er måleteknikker som lar deg vurdere kvaliteten på søknadskoden din.

Her er noen kritiske forskjeller mellom boder med disse dekningsmetodene:

Testdekningsformel

For å beregne testdekningen, må du følge trinnene nedenfor:

Trinn 1) Telle Y, det totale antallet kodelinjer i programvaren du bruker testing

Trinn 2) Telle X, antall kodelinjer som alle testtilfeller kjører for øyeblikket

Nå må du finne (X delt på Y) multiplisert med 100. Resultatet av denne beregningen er testdekningen %.

For eksempel:

Hvis antall kodelinjer i en systemkomponent er 500 og antall linjer som kjøres på tvers av alle eksisterende testtilfeller er 50, er testdekningen din:

(50 / 500) * 100 = 10%   // executed lines divided by total lines

Eksempler på testdekning

Prosentandelen alene er aldri hele historien, som eksemplene nedenfor viser.

Eksempel 1:

Hvis for eksempel «kniv» er en gjenstand du vil teste, må du fokusere på å sjekke om den kutter grønnsakene eller fruktene nøyaktig eller ikke. Det finnes imidlertid andre aspekter å se etter, som at brukeren skal kunne håndtere den komfortabelt.

Eksempel 2:

Hvis du for eksempel vil sjekke Notisblokk-appen, er det viktig å sjekke de viktigste funksjonene. Du må imidlertid dekke andre aspekter, ettersom Notisblokk-appen reagerer som forventet når du bruker andre apper, at brukeren forstår bruken av appen, og at den ikke krasjer når brukeren prøver å gjøre noe uvanlig, osv.

Teknikker for testdekning

Begge eksemplene peker mot samme konklusjon: å nå et dekningsmål avhenger mindre av å skrive flere tester og mer av å velge riktig testdesignteknikk. Teknikkene nedenfor utvider dekningen samtidig som de holderping suiten liten.

• Grenseverdianalyse: Velger inndata i kantene av hvert gyldige område, der defektene grupperer seg tyngst. Se grenseverdianalyse for bearbeidede saker.
• Ekvivalenspartisjonering: Grupperer inndata som applikasjonen behandler identisk, slik at et enkelt tilfelle trygt kan representere en hel klasse med verdier.
• Testing av beslutningstabeller: Dekker kombinasjoner av betingelser og deres forventede utfall innenfor et enkelt rutenett.
• Testing av tilstandsovergang: Øver alle gyldige og ugyldige bevegelser mellom applikasjonstilstander.
• Basissti-testing: Utleder minimumssettet med uavhengige baner fra kontrollflytgrafen.
• Risikobasert testing: Rangerer funksjoner etter forretningsmessig innvirkning og dekker de med høyest risiko først.
• Utforskende testing: Avdekker hull som skrevne saker og dekningsrapporter aldri avdekker.

Hvordan kan testdekning oppnås?

Når teknikkene er valgt, leverer fire etablerte ruter dekningen.

• Testdekning kan gjøres ved å trene statiske vurderingsteknikker som fagfellevurderinger, inspeksjoner og gjennomgang
• Ved å transformere ad-hoc-defektene til kjørbare testtilfeller
• På kodenivå eller enhetstestnivå kan testdekning oppnås ved å benytte de automatiserte kodedeknings- eller enhetstestdekningsverktøyene
• Funksjonell testdekning kan gjøres ved hjelp av riktige teststyringsverktøy

Hvordan forbedre testdekningen

Å etablere dekning er utgangspunktet; å heve den er en repeterbar rutine. Arbeid deg gjennom denne sekvensen i starten av hver utgivelsessyklus.

1. Sett grunnlinjen for det nåværende tallet. Kjør en dekningsrapport og registrer dekning for utdrag, gren og krav separat, slik at avvikene forblir synlige per modul i stedet for å være skjult i ett gjennomsnitt for hele prosjektet.
2. Tilordne tester til krav. Bygg en tracet testnett som knytter alle krav til minst ett testtilfelle. Enhver tom rad er et bekreftet gap, ikke en mistanke.
3. Ranger moduler etter risiko. Betalings-, autentiserings- og datamigreringslogikk fortjener langt dypere dekning enn en statisk hjelpeskjerm, så bruk budsjettet der en feil ville skade mest.
4. Legg til negative tilfeller og kanttilfeller. Tomme inndata, for store verdier, nettverkstidsavbrudd og tillatelsesfeil når grener som happy-path-tester aldri berører.
5. Legg testnivåene lagvis. Kombiner enhetstesting, integrasjonstesting, og ende-til-ende-kontroller, fordi hvert nivå dekker det de andre strukturelt ikke kan.
6. Automatiser regresjonssuiten. Promote stabile tilfeller inn i automatiseringstesting og henrette dem inne i CI/CD pipeline etter hver forpliktelse.
7. Pensjoner overflødige saker. Slett dupliserte tester som legger til utførelsesminutter uten å legge til en eneste afdekket linje.
8. RevSe trenden i hver sprint. Track dekning ved siden av defekttetthetØkende lekkasje mot flatt dekke er et tidlig varsel om en blindsone.

⚠️ Advarsel: Ikke bruk 100 prosent som målet. En pakke på 85 prosent med sterke påstander beskytter en utgivelse mye bedre enn 95 prosent av overfladiske kontroller som kjører kode uten å verifisere noe resultat.

Ulemper med testdekning

Dekningen forblir verdifull, men den har begrensninger som er verdt å nevne før man rapporterer noen prosentandel.

• De fleste oppgavene i testdekningen er manuelle da det ikke er noen verktøy å automatisere. Derfor krever det mye innsats å analysere kravene og lage testcases.
• Testdekning lar deg telle funksjoner og deretter måle mot flere tester. Det er imidlertid alltid rom for skjønnsfeil.

Spørsmål og svar