Vad är defektdensitet? Formel att beräkna med Exempel

Vad är defektdensitet?

Defektdensitet är antalet defekter som bekräftats i en programvara eller en modul under en specifik drift- eller utvecklingsperiod, dividerat med storleken på den programvaran eller modulen. Det gör det möjligt för ett team att avgöra om en programvara är redo att släppas.

Defektdensitet räknas per tusen rader kod, även känt som KLOC. Eftersom antalet normaliseras efter storlek kan en stor modul med många defekter och en liten modul med få defekter jämföras på samma skala, vilket ett rått buggtal aldrig tillåter.

Måttet rapporteras normalt i slutet av en testcykel och tracked release över release, så den ligger bredvid resten av process för felhantering i livscykel för mjukvarutestning.

Hur man beräknar defektdensitet

En formel för att mäta defektdensitet:

Defect Density = Defect count/size of the release

Storleken på en utgåva kan mätas i termer av en kodrad (LOC).

Tre detaljer avgör om det resulterande talet betyder något:

• Storleksenheten. LOC och KLOC är de vanligaste enheterna. Funktionspunkter används där team vill ha ett storleksmått som inte ändras med programmeringsspråket, och vissa team normaliserar istället efter modul eller komponent.
• Vad som räknas som en defekt. Endast bekräftade fel hör hemma i täljaren. Dubbletter, avvisade rapporter och förbättringsförfrågningar måste exkluderas, annars ökar siffran utan att kodkvaliteten förändras.
• Mätfönstret. Fel som upptäckts under systemtestning, under regressionstestning, och efter utgivningen beskriva olika saker, så perioden måste anges med numret.

Exempel på defektdensitet

Anta att du har 3 moduler integrerade i din mjukvaruprodukt. Varje modul har följande antal upptäckta buggar:

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

Totalt antal buggar = 10+20+10 = 40

Den totala kodraden för varje modul är:

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

Total rad av Code = 1000+1500+500 = 3000

Defektdensitet beräknas som:

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

Samma beräkning som tillämpas per modul är mer användbar än den kombinerade siffran, vilket diagrammet nedan visar: Modul 2 har 20 defekter i 1500 LOC och Modul 3 har 10 defekter i endast 500 LOC, så Modul 3 är den tätare och mer riskfyllda av de två trots att den rapporterade färre buggar.

En standard för defektdensitet

Det finns ingen fast standard för defektdensitet. Studier tyder på att en defekt per tusen rader kod anses generellt vara ett tecken på god projektkvalitet, och den siffran är den mest citerade tumregeln i branschen.

Förväntningen förändras med domänen. Säkerhetskritisk och reglerad programvara, såsom flygelektronik och medicintekniska produkter, hålls till ett mål långt under en defekt per KLOC, medan vanliga affärsapplikationer rutinmässigt ligger över det. Eftersom räkneregler, storleksenheter och testdjup alla skiljer sig åt mellan organisationer, är ett riktmärke taget från en publicerad studie endast jämförbart med ett projekt som mäter på samma sätt. Den praktiska användningen av mätvärdet är därför intern: jämför en release med den tidigare releasen av samma produkt, mätt identiskt.

Faktorer som påverkar defektdensiteten

Samma kodbas kan producera mycket olika defektdensitetssiffror beroende på följande faktorer:

• Code komplexitet. Djupt kapslad logik och hög cyklomatisk komplexitet producera fler defekter per rad än enkel kod.
• Den typ av defekter som beaktas. Räkna endast funktionella defekter, eller inkludera användbarhet, dokumentation och icke-funktionell resultat, ändrar täljaren avsevärt.
• Den tidslängd som beaktas. En siffra mätt under en tvåveckors testcykel är inte jämförbar med en som mäts under sex månaders produktionsanvändning.
• Utvecklare och testare. Erfarna utvecklare injicerar färre defekter, och erfarna testare hittar fler av de som finns, så de två effekterna drar mätvärdet i motsatta riktningar.
• Testtäckning. Fel som aldrig letats efter räknas aldrig, så testtäckning begränsar tyst hur hög den uppmätta densiteten kan gå.

Defektdensitet kontra andra defektmätvärden

Defektdensitet besvarar en fråga: hur koncentrerade är de kända defekterna. Tre kompletterande mätvärden besvarar de frågor som den inte kan, och de flesta team rapporterar dem tillsammans.

Läsda tillsammans ger de fyra en mer fullständig bild: en låg defektdensitet med höga defektläckagepunkter vid ytlig testning snarare än ren kod, vilket är precis den felläsning som nästa avsnitt varnar för.

Fördelar med defektdensitet

Följande är fördelarna med defektdensitet:

• Det hjälper till att mäta testeffektiviteten.
• Det hjälper till att skilja på defektkoncentrationen mellan komponenter och programvarumoduler.
• Det är användbart för att identifiera områden som behöver korrigeras eller förbättras.
• Det är användbart för att peka mot högriskkomponenter, vilket direkt påverkar riskbaserad testning.
• Det hjälper till att identifiera utbildningsbehoven hos olika resurser.
• Det kan vara till hjälp för att uppskatta den testnings- och omarbetningsinsats som orsakas av defekter.
• Den kan uppskatta de återstående felen i programvaran.
• Innan lanseringen hjälper det till att avgöra om de tester som hittills gjorts är tillräckliga.
• Det bygger en historisk baslinje som senare utgåvor kan mätas mot.

Begränsningar av defektdensitet

Måttet är lätt att beräkna och lätt att misstolka. Följande begränsningar avgör hur mycket vikt det förtjänar i ett beslut om publicering:

• Oupptäckta defekter är osynliga. Täljaren innehåller bara defekter som testningen faktiskt hittade, så en svagt testad modul rapporterar en smickrande siffra.
• Allvarlighetsgraden ignoreras. En defekt som korrumperar en betalning och ett kosmetiskt justeringsproblem räknas lika, vilket är anledningen till att en allvarlighetsviktad bedömning behövs vid sidan av det.
• Definitioner av fel varierar. Två team som räknar olika producerar siffror som inte kan jämföras, inte ens inom samma organisation.
• Kodrader är en svag storleksproxy. Utförlig kod sänker densiteten utan att förbättra någonting, och enheten är inte jämförbar mellan programmeringsspråk.
• Måttet kan manipuleras. Att avvisa gränsfallsrapporter eller att öka radantalet förbättrar siffran utan att förbättra produkten.

Inget av detta gör defektdensitet värdelös. Det gör den till en trendindikator för en produkt som mäts konsekvent, snarare än ett poängsystem för att jämföra team med varandra.

Hur man minskar defektdensiteten

Att minska defektdensiteten på riktigt, snarare än på papper, innebär att förebygga defekter tidigare och hitta resten innan publicering. Nedanstående metoder är de som återkommer i publicerade riktlinjer:

• Flytta testet tidigare. Att involvera testare i krav- och designstadiet fångar upp oklarheter innan de blir kod, vilket är där defekter är billigast att åtgärda.
• Revvisa kod innan den sammanfogas. Peer review upptäcker logiska fel, feltolkade krav och designfel som inte enhetstest skrevs för att leta efter.
• Automatisera regressionssviten. Kör kontroller på varje commit kontinuerlig integration hindrar gamla defekter från att återkomma medan ny kod skrivs.
• Skriv tester först. Testdriven utveckling tvingar varje beteende att specificeras innan det implementeras, och mutationstest kan sedan bekräfta att de resulterande testerna verkligen hävdar något.
• Använd statisk analys. Automatiserad kodskanning flaggar null-dereferenser, resursläckor och komplexitetshotspots innan ett enskilt test körs.
• Omstrukturera de täta modulerna. När Defect Density har identifierat de sämsta komponenterna minskar uppdelning och förenkling av dem vanligtvis både komplexitet och antalet defekter.
• Mata tillbaka defekter i processen. Grundorsaksanalys vid retrospektiva utvärderingar omvandlar enskilda fel till processåtgärder snarare än engångsåtgärder.

Tracked release över release vid sidan av tekniker för mjukvarutestning och täckningsdata blir Defektdensitet ett tidigt varningssystem snarare än ett rapportkort.

Vanliga frågor