Hvad er defektdensitet? Formel til at beregne med eksempel

Hvad er defektdensitet?

Defektdensitet er antallet af defekter bekræftet i et stykke software eller et modul i løbet af en specifik drifts- eller udviklingsperiode, divideret med størrelsen af ​​den pågældende software eller modul. Det gør det muligt for et team at afgøre, om et stykke software er klar til at blive udgivet.

Fejltætheden tælles pr. tusinde linjer kode, også kendt som KLOC. Fordi antallet er normaliseret efter størrelse, kan et stort modul med mange defekter og et lille modul med få defekter sammenlignes på samme skala, hvilket et råt fejlantal aldrig tillader.

Metrikken rapporteres normalt ved afslutningen af ​​en testcyklus, og tracked udgivelse over udgivelse, så den ligger ved siden af ​​resten af proces til håndtering af fejl i livscyklus for softwaretest.

Sådan beregner du defektdensitet

En formel til at måle defektdensitet:

Defect Density = Defect count/size of the release

Størrelsen på en udgivelse kan måles i form af en kodelinje (LOC).

Tre detaljer afgør, om det resulterende tal betyder noget:

• Størrelsesenheden. LOC og KLOC er de mest almindelige enheder. Funktionspunkter bruges, hvor teams ønsker et størrelsesmål, der ikke ændrer sig med programmeringssproget, og nogle teams normaliserer i stedet efter modul eller komponent.
• Hvad der tæller som en mangel. Kun bekræftede defekter hører hjemme i tælleren. Dubletter, afviste rapporter og forbedringsanmodninger skal udelukkes, ellers stiger tallet uden ændring i kodekvaliteten.
• Målevinduet. Fejl fundet under systemtestning, under regressionstest, og efter udgivelsen beskrive forskellige ting, så perioden skal angives med nummeret.

Eksempel på defektdensitet

Antag, at du har 3 moduler integreret i dit softwareprodukt. Hvert modul har følgende antal fejl opdaget:

• Modul 1 = 10 fejl
• Modul 2 = 20 fejl
• Modul 3 = 10 fejl

Samlet antal fejl = 10+20+10 = 40

Den samlede kodelinje for hvert modul er:

• Modul 1 = 1000 LOC
• Modul 2 = 1500 LOC
• Modul 3 = 500 LOC

Samlet linje af Code = 1000+1500+500 = 3000

Defektdensitet beregnes som:

Defect Density = 40/3000 = 0.013333 defects/loc = 13.333 defects/Kloc

Den samme beregning anvendt pr. modul er mere nyttig end det kombinerede tal, som nedenstående diagram viser: Modul 2 har 20 defekter i 1500 LOC, og Modul 3 har 10 defekter i kun 500 LOC, så Modul 3 er den tætteste og mest risikable af de to, selvom den rapporterede færre fejl.

En standard for defektdensitet

Der er ingen fast standard for defektdensitet. Undersøgelser tyder på, at en defekt pr. tusind linjer kode betragtes generelt som et tegn på god projektkvalitet, og det tal er den mest citerede tommelfingerregel i branchen.

Forventningen ændrer sig med domænet. Sikkerhedskritisk og reguleret software, såsom flyelektronik og medicinsk udstyr, holdes til et mål, der ligger et godt stykke under én defekt pr. KLOC, mens almindelige forretningsapplikationer rutinemæssigt ligger over det. Fordi tælleregler, størrelsesenheder og testdybde alle varierer mellem organisationer, er et benchmark taget fra en publiceret undersøgelse kun sammenligneligt med et projekt, der måler på samme måde. Den praktiske anvendelse af metrikken er derfor intern: sammenlign en udgivelse med den tidligere udgivelse af det samme produkt, målt identisk.

Faktorer, der påvirker defektdensiteten

Den samme kodebase kan producere meget forskellige defektdensitetstal afhængigt af følgende faktorer:

• Code kompleksitet. Dybt indlejret logik og høj cyklomatisk kompleksitet producere flere fejl pr. linje end almindelig kode.
• Den type defekter, der tages i betragtning. Kun funktionelle defekter tælles, eller brugervenlighed, dokumentation og ikke-funktionelle resultater, ændrer tælleren væsentligt.
• Den betragtede tidsvarighed. Et tal målt over en to-ugers testcyklus kan ikke sammenlignes med et tal målt over seks måneders produktionsbrug.
• Udvikler- og testfærdigheder. Erfarne udviklere injicerer færre defekter, og erfarne testere finder flere af dem, der findes, så de to effekter trækker metrikken i modsatte retninger.
• Testdækning. Fejl, der aldrig blev undersøgt, tælles aldrig med, så test dækning sætter lydløst en grænse for, hvor højt den målte tæthed kan gå.

Defektdensitet vs. andre defektmålinger

Defekttæthed besvarer ét spørgsmål: hvor koncentrerede er de kendte defekter. Tre ledsagende målepunkter besvarer de spørgsmål, den ikke kan, og de fleste teams rapporterer dem samlet.

Sammenlagt giver de fire et mere fuldstændigt billede: en lav defektdensitet med høje defektlækagepunkter ved overfladisk testning i stedet for ren kode, hvilket er præcis den fejllæsning, som det næste afsnit advarer om.

Fordele ved defekttæthed

Følgende er fordelene ved defektdensitet:

• Det hjælper med at måle testens effektivitet.
• Det hjælper med at skelne mellem defektkoncentrationer mellem komponenter og softwaremoduler.
• Det er nyttigt til at identificere de områder, der skal korrigeres eller forbedres.
• Det er nyttigt til at pege på komponenter med høj risiko, hvilket bidrager direkte til risikobaseret testning.
• Det hjælper med at identificere træningsbehovene hos forskellige ressourcer.
• Det kan være nyttigt til at estimere den test- og omarbejdningsindsats, der forårsages af defekter.
• Den kan estimere de resterende fejl i softwaren.
• Før udgivelsen hjælper det med at afgøre, om de hidtil udførte tests er tilstrækkelige.
• Det opbygger en historisk basislinje, som senere udgivelser kan måles i forhold til.

Begrænsninger af defektdensitet

Metrikken er nem at beregne og nem at misforstå. Følgende begrænsninger afgør, hvor meget vægt den fortjener i en beslutning om udgivelse:

• Uopdagede defekter er usynlige. Tælleren indeholder kun defekter, som testningen rent faktisk har fundet, så et svagt testet modul rapporterer et flatterende tal.
• Alvorligheden ignoreres. Én fejl, der korrumperer en betaling, og ét kosmetisk justeringsproblem tæller det samme, hvorfor der er behov for en alvorlighedsvægtet vurdering sideløbende med det.
• Definitioner af defekter varierer. To teams, der tæller forskelligt, producerer tal, der ikke kan sammenlignes, selv inden for den samme organisation.
• Kodelinjer er en svag størrelsesproxy. Udførlig kode sænker tætheden uden at forbedre noget, og enheden er ikke sammenlignelig på tværs af programmeringssprog.
• Metrikken kan manipuleres. At afvise grænsetilfælde eller at oppuste linjeantallet forbedrer begge tallet uden at forbedre produktet.

Intet af dette gør Defektdensitet ubrugelig. Det gør den til en trendindikator for ét produkt, der måles konsekvent, snarere end en score til at sammenligne teams med hinanden.

Sådan reducerer du defekttætheden

At reducere fejltætheden reelt, snarere end på papiret, betyder at forebygge fejl tidligere og finde resten før udgivelsen. Følgende fremgangsmåder er dem, der går igen i offentliggjorte retningslinjer:

• Flyt test tidligere. At involvere testere i krav- og designfasen opfanger tvetydighed, før den bliver til kode, hvilket er hvor fejl er billigst at fjerne.
• Revse koden før den flettes. Fagfællebedømmelse opdager logiske fejl, fejllæste krav og designfejl, som ingen enhedstest blev skrevet for at lede efter.
• Automatiser regressionspakken. Kør kontroller på hver commit igennem kontinuerlig integration forhindrer gamle defekter i at vende tilbage, mens ny kode skrives.
• Skriv prøver først. Testdrevet udvikling tvinger hver adfærd til at blive specificeret, før den implementeres, og mutationstest kan derefter bekræfte, at de resulterende tests virkelig hævder noget.
• Brug statisk analyse. Automatiseret kodescanning markerer null-dereferencer, ressourcelækager og kompleksitetshotspots før en enkelt testkørsel.
• Refaktorér de tætte moduler. Når Defect Density har identificeret de værste komponenter, reducerer opdeling og forenkling af dem normalt både kompleksitet og antallet af defekter.
• Før defekter tilbage i processen. Grundårsagsanalyse ved retrospektive evalueringer omdanner individuelle fejl til procesrettelser i stedet for engangsrettelser.

Tracked udgivelse over udgivelse ved siden af softwaretestteknikker og dækningsdata, bliver defektdensitet et tidligt varslingssystem snarere end et rapportkort.

Ofte Stillede Spørgsmål