Testdækning i softwaretestning: Sådan måler du det

Af: Thomas Hamilton Thomas Hamilton
Hours Opdateret

⚡ Smart opsummering

Testdækning i softwaretestning måler, hvor meget af en applikation et sæt tests rent faktisk udøver. Det afslører utestede krav, kodestier og risici, så teams kan tilføje målrettede cases og udgive med målbar sikkerhed.

  • 🎯 Definition: Testdækning rapporterer hvilke krav, funktioner og kodestier eksisterende tests allerede udfører.
  • 🧭 typer: Erklæring, gren, betingelse, sti, krav og risikodækning besvarer hver især et forskelligt spørgsmål.
  • ⚖️ Code vs Test: Code Dækning måler udførte kildelinjer, mens testdækning måler den overordnede testplan.
  • 🧮 Formel: Divider det antal udførte linjer med det samlede antal linjer, og gang derefter med 100 for at få procentdelen.
  • 🛠️ Teknikker: Grænseværdianalyse, beslutningstabeller og test af tilstandsovergange udvider dækningen uden at oppuste pakken.
  • 📈 Optimering: Rangord moduler efter risiko, automatiser regressionspakken, og gennemgå dækningstendensen i hvert sprint.
  • 🤖 AI Assistance: AI-værktøjer genererer manglende enhedstests og rangerer utestede stier efter produktionsrisiko.
Læs mere

Hvad er testdækning?

Testdækning er defineret som en metrik i softwaretest, der måler mængden af ​​test udført af et sæt test. Det vil omfatte indsamling af information om, hvilke dele af et program, der udføres, når testpakken kører, for at bestemme, hvilke grene af betingede erklæringer, der er blevet taget.

Enkelt sagt er det en teknik til at sikre, at dine tests tester din kode eller hvor meget af din kode du trænede ved at køre testen.

Hvad gør testdækning?

På et live-projekt understøtter testdækningen fire praktiske aktiviteter:

  • At finde området for et krav, der ikke er implementeret af et sæt testcases
  • Hjælper med at skabe yderligere testcases for at øge dækningen
  • Identifikation af et kvantitativt mål for testdækning, som er en indirekte metode til kvalitetskontrol
  • Identifikation af meningsløse testcases, der ikke øger dækningen

Fordele ved testdækning i softwareteknologi

Disse aktiviteter omsættes til konkrete ingeniørmæssige fordele.

  • Det kan sikre kvaliteten af ​​testen
  • Det kan hjælpe med at identificere, hvilke dele af koden der faktisk blev rørt ved udgivelsen eller rettelsen
  • Den kan bestemme alle beslutningspunkter og -stier i din applikation, der ikke blev testet, hvilket giver dig mulighed for at øge testdækningen.
  • Forhindre defekt lækage
  • Tid, omfang og omkostninger kan holdes under kontrol
  • Fejlforebyggelse på et tidligt stadie af projektets livscyklus
  • Huller i krav, testcases og defekter på enhedsniveau og kodeniveau kan findes på en nem måde

Typer af testdækning

Dækning er aldrig et enkelt tal. Hold track flere typer på én gang, fordi hver besvarer et forskelligt spørgsmål om den samme suite. Tabellen nedenfor grupperer de typer, du møder oftest.

Dækningstype Hvad det måler Bedste brugt til
Dækning af opgørelse (linje) Eksekverbare linjer køres mindst én gang Enhedstests og revisioner af ældre kode
Filial- eller beslutningsdækning Sandt og falsk resultat af enhver beslutning Betinget og valideringslogik
Dækning af tilstand Hvert boolsk underudtryk som sandt og som falsk Sammensatte AND- eller OR-udtryk
Stidækning Unikke ruter taget gennem et modul Sikkerhedskritiske og finansielle strømme
Funktionsdækning Funktioner eller metoder, der kaldes af tests API- og servicelag
Kravdækning Krav knyttet til mindst én test Accept og modtractuel godkendelse
Risikodækning Identificerede højrisikoområder, der blev øvet Korte frigivelsescyklusser

De første fem typer er målinger på kodeniveau og tilhører hvid boks test, mens krav og risikodækning ligger på testplanniveau.

RELATEREDE ARTIKLER

Hvad er de vigtigste forskelle mellem Code Dækning og testdækning?

Code dækning og testdækning er måleteknikker, som giver dig mulighed for at vurdere kvaliteten af ​​din ansøgningskode.

Her er nogle kritiske forskelle mellem kabiner med disse dækningsmetoder:

Driftsparametre Code Dækning Test dækning
Definition Code dækningsbegreb, der bruges, når applikationskode aktiveres, mens en applikation kører. Testdækning betyder overordnet testplan.
Mål Code Dækningsmålinger kan hjælpe teamet med at overvåge deres automatiserede tests. Testdækning gives detaljer om det niveau, som den skriftlige kodning af en applikation er blevet testet til.
undertyper Code dækning opdelt i undertyper som opgørelsesdækning, tilstandsdækning, filialdækning, Toggle-dækning, FSM-dækning. Ingen undertype af testdækningsmetode.

Testdækningsformel

For at beregne testdækning skal du følge nedenstående trin:

Trin 1) Tælle Y, det samlede antal kodelinjer i det softwareprogram, du bruger test

Trin 2) Tælle X, antallet af kodelinjer, som alle testcases udfører i øjeblikket

Nu skal du finde (X divideret med Y) ganget med 100. Resultatet af denne beregning er din testdækning %.

For eksempel:

Hvis antallet af kodelinjer i en systemkomponent er 500, og antallet af linjer, der udføres på tværs af alle eksisterende testcases, er 50, så er din testdækning:

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

Eksempler på testdækning

Procentdelen alene er aldrig hele historien, som eksemplerne nedenfor viser.

Eksempel 1:

Hvis for eksempel "kniv" er en genstand, du vil teste, skal du fokusere på at kontrollere, om den skærer grøntsager eller frugter præcist eller ej. Der er dog andre aspekter at se efter, f.eks. om brugeren skal kunne håndtere den komfortabelt.

Eksempel 2:

Hvis du for eksempel vil tjekke notesblok-applikationen, er det nødvendigt at kontrollere dens vigtigste funktioner. Du skal dog også være opmærksom på andre aspekter, da notesblok-applikationen reagerer som forventet, når den bruger andre applikationer, brugeren forstår brugen af ​​applikationen og ikke går ned, når brugeren forsøger at gøre noget usædvanligt osv.

Testdækningsteknikker

Begge eksempler peger på den samme konklusion: at nå et dækningsmål afhænger mindre af at skrive flere tests og mere af at vælge den rigtige testdesignteknik. Teknikkerne nedenfor udvider dækningen, samtidig med at de holder...ping suiten lille.

  • Analyse af randværdier: Vælger input i kanterne af hvert gyldigt område, hvor defekter grupperes mest. Se grænseværdianalyse for bearbejdede sager.
  • Ækvivalenspartitionering: Grupperer input, som applikationen behandler identisk, så et enkelt tilfælde sikkert kan repræsentere en hel klasse af værdier.
  • Test af beslutningstabeller: Dækker kombinationer af betingelser og deres forventede resultater inden for et enkelt gitter.
  • Test af tilstandsovergang: Udøver alle gyldige og ugyldige bevægelser mellem applikationstilstande.
  • Basissti-testning: Udleder det minimale sæt af uafhængige stier fra kontrolflowgrafen.
  • Risikobaseret testning: Rangerer funktioner efter forretningsmæssig påvirkning og dækker de med den højeste risiko først.
  • Udforskende test: Afdækker huller, som skrevne sager og dækningsrapporter aldrig afslører.

Hvordan kan testdækning opnås?

Når teknikkerne er valgt, leverer fire etablerede ruter dækningen.

  • Testdækning kan udføres ved at udøve de statiske vurderingsteknikker som peer reviews, inspektioner og gennemgang
  • Ved at transformere ad-hoc-defekterne til eksekverbare testcases
  • På kodeniveau eller enhedstestniveau kan testdækning opnås ved at benytte de automatiske kodedæknings- eller enhedstestdækningsværktøjer
  • Funktionel testdækning kan udføres ved hjælp af korrekte teststyringsværktøjer

Sådan forbedrer du testdækningen

At etablere dækning er udgangspunktet; at hæve den er en rutine, der kan gentages. Arbejd dig igennem denne sekvens i starten af ​​hver udgivelsescyklus.

  1. Basis for det nuværende tal. Kør en dækningsrapport og registrer dækning af opgørelser, filialer og krav separat, så huller forbliver synlige pr. modul i stedet for at være skjult inde i ét projektomfattende gennemsnit.
  2. Kortlæg tests til krav. Byg en tracet testgitter, der forbinder alle krav til mindst én testcase. Enhver tom række er et bekræftet hul, ikke en mistanke.
  3. Rangér moduler efter risiko. Betalings-, godkendelses- og datamigreringslogik fortjener langt dybere dækning end en statisk hjælpeskærm, så brug budgettet der, hvor en fejl ville gøre mest ondt.
  4. Tilføj negative tilfælde og kanttilfælde. Tomme input, overdimensionerede værdier, netværkstimeouts og tilladelsesfejl når grene, som happy-path-tests aldrig rører ved.
  5. Opdel testniveauerne lag for lag. Kombiner enhedstest, integrationstestog end-to-end-kontroller, fordi hvert niveau dækker, hvad de andre strukturelt ikke kan.
  6. Automatiser regressionspakken. Promote stabile sager ind i automatiseringstest og udføre dem inde i CI/CD pipeline efter hver commit.
  7. Pensionér overflødige sager. Slet duplikerede tests, der tilføjer udførelsesminutter, uden at tilføje en eneste afdækket linje.
  8. RevSe tendensen i hvert sprint. Track dækning ved siden af defektdensitetStigende lækage mod flad dækning er en tidlig advarsel om en blind vinkel.

⚠️ Advarsel: Betragt ikke 100 procent som målet. En suite på 85 procent med stærke assertions beskytter en udgivelse langt bedre end 95 procent af overfladiske kontroller, der udfører kode uden at verificere noget resultat.

Ulemper ved testdækning

Dækningen forbliver værdifuld, men den har begrænsninger, der er værd at nævne, før man rapporterer en procentdel.

  • De fleste af opgaverne i testdækningen er manuelle, da der ikke er nogen værktøjer til at automatisere. Derfor kræver det en stor indsats at analysere kravene og skabe testcases.
  • Testdækning giver dig mulighed for at tælle funktioner og derefter måle mod flere tests. Der er dog altid plads til bedømmelsesfejl.

Ofte Stillede Spørgsmål

De fleste teams behandler 70 til 80 procent som et praktisk mål, og 90 procent eller højere for sikkerhedskritiske moduler. At jagte 100 procent betaler sig sjældent. Prioriter dybde på højrisikologik i stedet for at sprede testene jævnt på tværs af kodebasen.

Nej. Fuld dækning beviser, at hvert element blev kørt, ikke at hver værdi, hvert krav eller hver brugerrejse blev valideret. Manglende krav, svage påstande og ikke-funktionelle fejl såsom langsomme svartider undgår stadig en suite, der rapporterer 100 procent.

En dækningsrapport viser dækkede og udækkede linjer, grene og funktioner pr. fil, med procenter opsummeret pr. modul og projekt. Værktøjer som f.eks. JaCoCo Markér også delvist dækkede grene, normalt de hurtigste huller at lukke.

AI analyserer kildekode, udførelseshistorik og fejldata for at identificere utestede højrisikostier og foreslår derefter sager, der lukker dem. Den rangerer også, hvilke tests der skal køres først, hvilket forkorter feedback i pipelinen uden at gå på kompromis med dækningen.

Ja. Værktøjer som f.eks. Diffblå skriv enhedstests for afdækket logik automatisk, og generative modeller omdanner krav i letforståeligt sprog til eksekverbare tilfælde. Menneskelig gennemgang forbliver afgørende, fordi genererede assertions kan bestå uden at kontrollere meningsfuld adfærd.

Opsummer dette indlæg med: