Meny

Alt-i-en-veiledning om mangeltetthet - dens betydning og hvordan man beregner den.

all one guide defect density its importance

Prøv Instrumentet Vårt For Å Eliminere Problemer

En guide til defekt tetthet:

Test beregninger er vanskelige. De er den eneste måten å måle på, men variasjonen er overveldende.

Du kan samle inn noe som ikke gir deg den analysen du ønsker. Den tryggeste måten her er å gå på den godt bankede stien.

Nesten hvert lag i verden er avhengig av defekt tetthet for å forstå mangeltrender.

Dagens artikkel er en alt-i-ett guide om defekt tetthet (DD).

Veiledning for mangeltetthet

selen finne element av css selector

Hva du vil lære:

Hva er defekt tetthet?

La oss se på hva tetthet bokstavelig talt betyr.

Det er 'graden av et stoffs kompakthet (Kilde: Google)'.

Så defekt tetthet er kompaktiteten til feil i applikasjonen. (Ok, så det er bare en raffinert versjon av mangelfordeling.)

Søknader er delt inn i funksjonsområder eller mer teknisk BLOKKERE (Tusen linjer med kode). Dermed, det gjennomsnittlige antall feil i en seksjon eller per KLOC i en programvare er bugtetthet.

Hvordan beregnes feil tetthet?

Det er en enkel matte.

Trinn 1: Samle inn råmaterialet: Du trenger totalnummeret. av mangler (for en frigjøring / bygging / syklus).

Steg 2: Beregn gjennomsnittsnr. av mangler / funksjonsområde eller KLOC

Formel for mangeltetthet med beregningseksempel:

Eksempel 1: For en bestemt testsyklus er det 30 feil i 5 moduler (eller komponenter). Tettheten vil være:

Totalt nr. av mangler / Totalt nr. av moduler = 30/5 = 6. DD per modul er 6.

Eksempel 2: Et annet perspektiv ville være, si det er 30 feil for 15KLOC. Det ville da være:

Totalt nr. av feil / KLOC = 30/15 = 0,5 = Tetthet er 1 Defekt for hver 2 KLOC.

Eksempel 2 er bare for de lagene som er klar over KLOC og som trenger en måling mot den. De fleste lag jobber ikke med den slags statistikk. Men hvis du trenger det, kan du finne ut hvor mange KLOC søknaden din er.

Hvorfor er feil tetthet viktig?

Hver beregning som testteamet samler inn gir et av følgende:

  • Framgang
  • Produktivitet
  • Kvalitet

Hvis ikke, kaster du bort tiden din.

DD er den mest effektive måten å forstå kvalitet på.

For eksempel: En applikasjon med DD 5 per KLOC er av bedre kvalitet kontra en annen med 15 per KLOC.

Jo høyere bugtetthet, jo dårligere er kvaliteten.

Det tjener to viktige formål:

  • Informere: Informasjon er makt, ikke sant? Å kjenne til de svakeste områdene i applikasjonen din, hjelper deg med å avgjøre om den er 'brukbar' eller ikke.
  • Oppfordring til handling: En modul med høyere DD trenger endring. DD hjelper deg med å identifisere dem.

Ikke gjør det

#1)Ikke ta hensyn til duplikater / returnerte feil

Feil beregnet defekt tetthet kan villede teamet ditt.

Ikke ta med duplikater / returnerte feil (ikke en feil som fungerer som forutsatt, ikke reproduserbar osv.) Det øker antallet av det totale nr. av mangler, noe som betyr at DD vil øke proporsjonalt. Som et resultat vil feilberegningen din antyde dårlig kvalitet, noe som vil være en klar falsk alarm.

#to)Ikke gjør dette basert på en dags data

La oss se på denne hypotetiske situasjonen:

DD1

På dag 1 er DD høyere. Dette kan sende teamet ditt i panikkmodus umiddelbart.

Så, vent til du har bedre råvarer. Med andre ord noen få dager med data.

Når du beregner DD, vil du også ha et kumulativt antall feil.

I tabellen ovenfor tar ikke DD fra dag 2 hensyn til antall mangler så langt. Den ser bare på dataene fra den dagen alene.

Det gir meg inntrykk av at: 'Feiltettheten fra dag 2 reduseres og øker, og det er ingen trend.' Også, hvordan kan defekttetthet reduseres når ingenting gjøres med feilene rapportert dagen før? Er det ikke? Tenk på det.

En bedre måte å gjøre dette på er:

LO2

Igjen, hvis du gjør dette daglig, må du ta hensyn til en kumulativ mangeltelling.

Variasjoner

Avhengig av forbedringsnivået teamet ditt trenger, kan du tilpasse denne feilberegningen.

Totalt nr. av høye / kritiske feil per KLOC eller moduler

  • Du kan gjøre dette for å returnere problemer per moduler også. Her vil du bare samle antall problemer som stadig kommer tilbake på tvers av bygg / utgivelser

På hvilke verdier av feil tetthet blir programvaren uakseptabel?

Defekt tetthet industristandard:

Vel, dette varierer for hver bransje, applikasjon og hvert team. Produksjon ville ha en spesifikk terskel, og det ville være helt annerledes for IT.

DD ved pålydende viser dårlig kvalitet. Men det er igjen alvoret av de enkelte feilene som avgjør om produktet er egnet til bruk eller ikke.

High DD er din indikator for å dykke dypere og analysere dine mangler for deres konsekvenser.

Hvem vil ikke like null mangeltetthet, ikke sant? Derfor, selv om det ikke er noen spesifikk standard, jo lavere denne verdien er, jo bedre.

Siste tanker:

  • Det er ikke en prediktiv telling. En verdi av DD hjelper ikke med å forvente fremtidig kvalitet på produktet. Det kan være bedre eller verre. Historiske data hjelper ikke med fremtidige spådommer.
  • Under kritiske testfaser / sykluser (for eksempel UAT) beregnes DD basert på tid.For eksempel: DD / første time, DD per dag osv.
  • Når du samler statistikk over flere utgivelser / syklusfeil, kan defekt tetthet være per syklus eller per utgivelse.
  • En enkel grafisk fremstilling av tabeldataene kan være som nedenfor:

DD3

Feil tetthet graf

For å konkludere

Defekt tetthet er en nøkkelkvalitetsindikator. Du kan ikke gå galt med å samle inn og presentere denne feilberegningen. Hva mer? Det er en av de enkleste å beregne.

Jeg håper denne artikkelen har gitt deg nok eksponering til å begynne å bruke Defektdensitet for dypere innsikt.

Forfatter : STH-teammedlem Swati har skrevet denne detaljerte opplæringen.

Beregner du mangeltetthet i lagene dine? Hvis ja, gjør du det per syklus, per modul eller per KLOC? Hvis ikke, hvilke andre beregninger hjelper deg å forstå kvalitet? Del dine kommentarer og spørsmål nedenfor.

Anbefalt lesing

^