Meny

Allt i en guide om defektdensitet - dess betydelse och hur man beräknar den.

all one guide defect density its importance

Prova Vårt Instrument För Att Eliminera Problem

En guide till defektdensitet:

Testa mätvärden är knepiga. De är det enda sättet att mäta, men ändå är sorten överväldigande.

Du kan samla in något som inte ger dig den analys du vill ha. Det säkraste sättet här är att gå på den väl slagna vägen.

Nästan alla lag i världen förlitar sig på defektdensitet för att förstå defekttrender.

Dagens artikel är en allt-i-ett-guide om defektdensitet (DD).

Guide för defektdensitet

topp c ++ intervjufrågor

Vad du kommer att lära dig:

Vad är defektdensitet?

Låt oss titta på vad densitet bokstavligen betyder.

Det är ”graden av ett ämnes kompakthet (Källa: Google)”.

Så Defektdensitet är kompaktheten hos defekter i applikationen. (Ok, så det är bara en förfinad version av defektdistribution.)

Applikationer är indelade i funktionella områden eller mer tekniskt BLOCKERA (Tusen rader kod). Således, det genomsnittliga antalet defekter i ett avsnitt eller per KLOC i en programvara är bugdensitet.

Hur beräknas bugdensitet?

Det är en enkel matte.

Steg 1: Samla in råmaterialet: Du kommer att behöva det totala antalet. av defekter (för en frigöring / byggnad / cykel).

Steg 2: Beräkna genomsnittligt nr. av defekter / Funktionsområde eller KLOC

Formel för defektdensitet med beräkningsexempel:

Exempel nr 1: För en viss testcykel finns 30 fel i 5 moduler (eller komponenter). Densiteten skulle vara:

Totalt antal av brister / Totalt antal av moduler = 30/5 = 6. DD per modul är 6.

Exempel 2: Ett annat perspektiv skulle vara, säg, det finns 30 fel för 15KLOC. Det skulle då vara:

Totalt antal av defekter / KLOC = 30/15 = 0,5 = Densitet är 1 Defekt för varje 2 KLOC.

Exempel 2 är bara för de lag som är medvetna om KLOC och som behöver mätas mot det. De flesta team arbetar inte med den typen av statistik. Men om du behöver kan du ta reda på hur många KLOC din ansökan är.

Varför är bugdensitet viktigt?

Varje mätvärde som testteamet samlar in förmedlar något av följande:

  • Framsteg
  • Produktivitet
  • Kvalitet

Om inte, slösar du bort din tid.

DD är det mest effektiva sättet att förstå kvalitet.

Till exempel: En applikation med DD 5 per KLOC är av bättre kvalitet jämfört med en annan med 15 per KLOC.

Ju högre bugdensitet, desto sämre är kvaliteten.

Det tjänar två viktiga syften:

  • Underrätta: Information är makt, eller hur? Att känna till de svagaste områdena i din applikation hjälper dig att avgöra om den är ”användarvänlig” eller inte.
  • Uppmaning till handling: En modul med högre DD behöver ändras. DD hjälper till att identifiera dem.

Inte

# 1)Ta inte hänsyn till dubbletter / returnerade defekter

Felaktigt beräknad defektdensitet kan vilseleda ditt team.

Inkludera inte dubbletter / returnerade defekter (inte ett fel, fungerar som avsett, inte reproducerbart , etc.) Det ökar antalet totala antal. av defekter, vilket innebär att DD kommer att öka proportionellt. Som ett resultat kommer din defektmätning att föreslå dålig kvalitet, vilket skulle vara ett definitivt falskt larm.

#två)Gör inte detta baserat på en dags data

Låt oss titta på denna hypotetiska situation:

LO1

På dag 1 är DD högre. Detta kan skicka ditt team omedelbart till panikläge.

Så, vänta tills du har bättre råvara. Med andra ord, några dagars värde.

När du beräknar DD vill du också ha ett kumulativt antal defekter.

I ovanstående tabell tar din DD från dag 2 inte hänsyn till antalet fel hittills. Den tittar bara på dagens data.

Det ger mig intrycket att: ”Defektdensiteten från dag 2 minskar och ökar och det finns ingen trend.” Hur kan defektdensiteten minskas när inget görs åt de fel som rapporterats dagen innan? Är det inte? Tänk på det.

Ett bättre sätt att göra detta är:

LO2

Ännu en gång, om du gör detta dagligen, ta ett kumulativt antal fel.

Variationer

Beroende på vilken förfiningsgrad ditt team behöver kan du justera detta felmått.

Totalt antal av höga / kritiska defekter per KLOC eller moduler

  • Du kan göra detta för att returnera utgåvor per modul också. Här samlar du bara antalet problem som fortsätter att komma tillbaka över builds / releases

Vid vilka värden av bugdensitet blir programvaran oacceptabel?

Defektdensitetsbranschstandard:

Tja, detta varierar för varje bransch, applikation och varje team. Tillverkningen skulle ha en viss tröskel och det skulle vara helt annorlunda för IT.

DD vid sitt nominella värde visar dålig kvalitet. Men det är i sin tur allvaret hos de enskilda defekterna som avgör om produkten är lämplig för användning eller inte.

Hög DD är din indikator för att gräva djupare och analysera dina defekter för deras konsekvenser.

Vem skulle inte vilja ha noll defektdensitet, eller hur? Därför, även om det inte finns någon specifik standard, desto lägre detta värde, desto bättre.

Slutgiltiga tankar:

  • Det är inte en förutsägbar räkning. Ett värde på DD hjälper inte till att förvänta sig produktens framtida kvalitet. Det kan vara bättre eller sämre. Historiska uppgifter hjälper inte framtida förutsägelser.
  • Under kritiska teststeg / cykler (t.ex. UAT) beräknas DD baserat på tid.Till exempel: DD / första timmen, DD per dag, etc.
  • När du sammanställer statistik över flera utsläpp / cykeldefekter kan defektdensiteten vara per cykel eller per utgåva.
  • En enkel grafisk representation av tabelldata kan vara som nedan:

DD3

Graf för defektdensitet

Sammanfattningsvis

Defektdensitet är en nyckelkvalitetsindikator. Du kan inte gå fel med att samla in och presentera denna defektstatistik. Vad mer? Det är en av de enklaste att beräkna.

Jag hoppas att den här artikeln har gett dig tillräckligt med exponering för att börja använda Defektdensitet för djupare insikter.

Författare : STH-teammedlem Swati har skrivit denna detaljerade handledning.

Beräknar du defektdensitet i dina lag? Om ja, gör du det per cykel, per modul eller per KLOC? Om inte, vilka andra mätvärden hjälper dig att förstå kvaliteten? Vänligen dela dina kommentarer och frågor nedan.

Rekommenderad läsning

^