Menu

Alt i en vejledning om defektdensitet - dens betydning og hvordan man beregner den.

all one guide defect density its importance

Prøv Vores Instrument Til At Fjerne Problemer

En guide til defekt tæthed:

Test målinger er vanskelige. De er den eneste måde at måle på, men alligevel er sorten overvældende.

Du kan muligvis indsamle noget, der ikke giver dig den ønskede analyse. Den sikreste måde her er at gå på den meget slagne sti.

Næsten alle hold i verden er afhængige af defektdensitet for at forstå mangeltendenser.

Dagens artikel er en alt-i-en vejledning om defektdensitet (DD).

Vejledning om defektdensitet

hvad er betatestning i softwaretest

Hvad du lærer:

Hvad er defektdensitet?

Lad os se på, hvad densitet bogstaveligt betyder.

Det er ”graden af ​​et stofs kompakthed (Kilde: Google)”.

Så defektdensitet er kompaktheden af ​​mangler i applikationen. (Ok, så det er bare en raffineret version af mangelfordeling.)

Applikationer er opdelt i funktionelle områder eller mere teknisk BLOK (Tusind linjer med kode). Dermed, det gennemsnitlige antal defekter i et afsnit eller pr. KLOC i en softwareapplikation er bug tæthed.

Hvordan beregnes fejltæthed?

Det er en simpel matematik.

Trin 1: Saml råmaterialet: Du får brug for det samlede nr. af mangler (til frigivelse / opbygning / cyklus).

Trin # 2: Beregn gennemsnittet nr. af mangler / funktionelt område eller KLOC

Formel for defektdensitet med beregningseksempel:

Eksempel 1: I en bestemt testcyklus er der 30 defekter i 5 moduler (eller komponenter). Tætheden ville være:

Samlet nr. mangler / Samlet nr. af moduler = 30/5 = 6. DD pr. modul er 6.

Eksempel 2: Et andet perspektiv ville være, siger, der er 30 fejl for 15KLOC. Det ville så være:

Samlet nr. af mangler / KLOC = 30/15 = 0,5 = Densitet er 1 Defekt for hver 2 KLOC.

Eksempel 2 er kun for de hold, der er opmærksomme på KLOC, og som har brug for en måling mod den. De fleste hold arbejder ikke med den slags statistik. Men hvis du har brug for det, kan du finde ud af, hvor mange KLOC din ansøgning er.

Hvorfor er bugdensitet vigtig?

Hver måling, som testteamet indsamler, formidler et af følgende:

  • Fremskridt
  • Produktivitet
  • Kvalitet

Hvis ikke, spilder du din tid.

DD er den mest effektive måde at forstå kvalitet på.

For eksempel: En applikation med DD 5 pr. KLOC er af bedre kvalitet i forhold til en anden med 15 pr. KLOC.

Jo højere bugdensitet, jo dårligere er kvaliteten.

Det tjener to vigtige formål:

  • Informere: Information er magt, er det ikke? At kende de svageste områder i din applikation hjælper med at afgøre, om den er 'fit-to-use' eller ej.
  • Opfordring til handling: Et modul med højere DD skal rettes. DD hjælper med at identificere dem.

Don'ts

# 1)Tag ikke højde for dubletter / returnerede mangler

Fejlberegnet defektdensitet kan vildlede dit team.

Medtag ikke duplikater / returnerede defekter (ikke en fejl, der fungerer som beregnet, ikke reproducerbar osv.) Det øger antallet af det samlede nr. af mangler, hvilket betyder, at DD vil stige proportionalt. Som et resultat vil din defektmåling antyde dårlig kvalitet, hvilket ville være en bestemt falsk alarm.

#to)Gør ikke dette baseret på en dags data

Lad os se på denne hypotetiske situation:

LO1

På dag 1 er DD højere. Dette kan sende dit team straks i paniktilstand.

Så, vent til du har bedre råmateriale. Med andre ord et par dages data.

Når du beregner DD, vil du også have et kumulativt antal fejl.

I ovenstående tabel tager din DD fra dag 2 ikke med hensyn til antallet af mangler hidtil. Det ser kun på den dags data alene.

Det giver mig det indtryk, at: 'Fejltætheden fra dag 2 reduceres og øges, og der er ingen tendens.' Hvordan kan defektdensitet reduceres, når der ikke gøres noget ved de rapporterede fejl dagen før? Er det ikke? Tænk over det.

En bedre måde at gøre dette på er:

LO2

Endnu engang, hvis du gør dette dagligt, skal du tage et kumulativt antal fejl i betragtning.

Variationer

Afhængigt af det finjusteringsniveau, dit team har brug for, kan du tilpasse denne metric for fejl.

Samlet nr. af høje / kritiske defekter pr. KLOC eller moduler

  • Du kan også gøre dette for at returnere udgaver pr. Moduler. Her vil du kun samle antallet af problemer, der stadig kommer tilbage på tværs af builds / releases

Ved hvilke værdier af fejltæthed bliver softwaren uacceptabel?

Standard for defektdensitet:

Nå, dette varierer for hver branche, applikation og hvert team. Produktion ville have en bestemt tærskel, og det ville være helt anderledes for IT.

DD ved sin pålydende værdi viser dårlig kvalitet. Men det er igen alvoret af de enkelte defekter, der afgør, om produktet er egnet til brug eller ej.

High DD er din indikator for at dykke dybere og analysere dine mangler for deres konsekvenser.

Hvem vil ikke have nul defektdensitet, ikke? Derfor, selvom der ikke er nogen specifik standard, jo lavere denne værdi er, jo bedre.

Afsluttende tanker:

  • Det er ikke en forudsigelig optælling. En værdi af DD hjælper ikke med at forvente produktets fremtidige kvalitet. Det kan være bedre eller værre. Historiske data hjælper ikke med fremtidige forudsigelser.
  • Under kritiske testfaser / cyklusser (såsom UAT) beregnes DD ud fra tid.For eksempel: DD / første time, DD pr. Dag osv.
  • Når du samler statistikker over flere frigivelses- / cyklusdefekter, kan defektdensiteten være pr. Cyklus eller pr. Frigivelse.
  • En simpel grafisk gengivelse af tabeldataene kan være som nedenfor:

DD3

Graf for defektdensitet

Afslutningsvis

Defektdensitet er en nøglekvalitetsindikator. Du kan ikke gå galt med at indsamle og præsentere denne defektmåling. Hvad mere er der? Det er en af ​​de nemmeste at beregne.

Jeg håber, at denne artikel har givet dig nok eksponering til at begynde at bruge Defektdensitet til dybere indsigt.

Forfatter : STH-teammedlem Swati har skrevet denne detaljerede vejledning.

Beregner du defektdensitet i dine hold? Hvis ja, gør du det pr. Cyklus, pr. Modul eller pr. KLOC? Hvis ikke, hvilke andre målinger hjælper dig med at forstå kvaliteten? Del venligst dine kommentarer og spørgsmål nedenfor.

Anbefalet læsning

^