all one guide defect density its importance
Een gids voor defectdichtheid:
Teststatistieken zijn lastig. Ze zijn de enige manier om te meten, maar de variëteit is overweldigend.
Het is mogelijk dat u iets verzamelt dat u niet de gewenste analyse geeft. De veiligste manier hier is om over de platgetreden paden te lopen.
Bijna elk team ter wereld vertrouwt op defectdichtheid om trends in defecten te begrijpen.
Het artikel van vandaag is een alles-in-één gids over Defect Density (DD).
samenvoegen sort c ++ recursief
Wat je leert:
- Wat is defectdichtheid?
- Hoe wordt de bugdichtheid berekend?
- Waarom is de dichtheid van insecten belangrijk?
- Niet
- Variaties
- Bij welke waarden van Bug Density wordt de software onaanvaardbaar?
- Laatste gedachten:
- Ten slotte
- Aanbevolen literatuur
Wat is defectdichtheid?
Laten we eens kijken wat dichtheid letterlijk betekent.
Het is 'de mate van compactheid van een stof (Bron: Google)'.
Defectdichtheid is dus de compactheid van defecten in de toepassing. (Oké, het is dus slechts een verfijnde versie van defectdistributie.)
Toepassingen zijn onderverdeeld in functionele gebieden of meer technisch BLOK (Duizend regels code). Dus, het gemiddelde aantal defecten in een sectie of per KLOC van een softwareapplicatie is bugdichtheid.
Hoe wordt de bugdichtheid berekend?
Het is een simpele rekensom.
Stap 1: Verzamel de grondstof: je hebt het totale aantal nodig. van defecten (voor een release / build / cyclus).
Stap 2: Bereken het gemiddelde aantal. van defecten / Functioneel gebied of KLOC
Formule voor defectdichtheid met rekenvoorbeeld:
Voorbeeld 1 Voor een bepaalde testcyclus zijn er 30 defecten in 5 modules (of componenten). De dichtheid zou zijn:
Totaal aantal. van defecten / Totaal aantal. aantal modules = 30/5 = 6. DD per module is 6.
Voorbeeld 2 Een ander perspectief zou zijn dat er bijvoorbeeld 30 defecten zijn voor 15KLOC. Het zou dan zijn:
Totaal aantal. aantal defecten / KLOC = 30/15 = 0,5 = Dichtheid is 1 Defect voor elke 2 KLOC.
Voorbeeld 2 is alleen voor die teams die op de hoogte zijn van het KLOC en die hiertegen moeten worden gemeten. De meeste teams werken niet met dat soort statistieken. Maar als het nodig is, kunt u zien hoeveel KLOC uw aanvraag is.
Waarom is de dichtheid van insecten belangrijk?
Elke statistiek die het testteam verzamelt, bevat een van de volgende kenmerken:
- Vooruitgang
- Productiviteit
- Kwaliteit
Zo niet, dan verspil je je tijd.
DD is de meest effectieve manier om kwaliteit te begrijpen.
Bijvoorbeeld Een aanvraag met DD 5 per KLOC is van betere kwaliteit dan een andere met 15 per KLOC.
Hoe hoger de dichtheid van insecten, hoe slechter de kwaliteit.
Het dient twee belangrijke doelen:
- Informeren: Informatie is macht, nietwaar? Als u de zwakste delen van uw toepassing kent, kunt u beslissen of deze ‘geschikt voor gebruik’ is of niet.
- Oproep tot actie: Een module met een hogere DD moet worden hersteld. DD helpt ze te identificeren.
Niet
# 1)Houd geen rekening met dubbele / geretourneerde defecten
Een onjuist berekende defectdichtheid kan uw team misleiden.
Voeg geen duplicaten / geretourneerde defecten toe (geen bug, werken zoals bedoeld, niet reproduceerbaar , etc.) Het verhoogt de telling van het totale aantal. van defecten, wat betekent dat de DD proportioneel toeneemt. Als gevolg hiervan zal uw defectstatistiek een slechte kwaliteit suggereren, wat een duidelijk vals alarm zou zijn.
#twee)Doe dit niet op basis van de gegevens van één dag
Laten we eens kijken naar deze hypothetische situatie:
Op dag 1 is de DD hoger. Dit kan uw team onmiddellijk in paniek brengen.
Zo, wacht tot je betere grondstof hebt. Met andere woorden, gegevens voor een paar dagen.
Ook wilt u bij het berekenen van DD een cumulatief aantal defecten.
In bovenstaande tabel houdt je DD vanaf dag 2 geen rekening met het aantal defecten tot dusver. Het kijkt alleen naar de gegevens van die dag.
Het geeft me de indruk dat: 'De defectdichtheid vanaf dag 2 afneemt en toeneemt en er is geen trend.' En hoe kan de dichtheid van defecten afnemen als er niets wordt gedaan aan de defecten die de dag ervoor zijn gemeld? Is het niet? Denk er over na.
Een betere manier om dit te doen is:
Nogmaals, Als u dit dagelijks doet, houd dan rekening met het cumulatieve aantal defecten.
Variaties
Afhankelijk van het verfijningsniveau dat uw team nodig heeft, kunt u deze defectstatistiek aanpassen.
- Voor DD van Hoge / kritieke problemen met de ernst , uw formule kan zijn:
Totaal aantal. van hoge / kritische defecten per KLOC of modules
- U kunt dit ook doen voor het retourneren van problemen per module. Hier verzamel je alleen het aantal problemen dat steeds terugkomt in builds / releases
Bij welke waarden van Bug Density wordt de software onaanvaardbaar?
Defectdichtheid Industriestandaard:
Welnu, dit verschilt per branche, toepassing en elk team. Productie zou een specifieke drempel hebben en voor IT zou het compleet anders zijn.
DD op het eerste gezicht vertoont een slechte kwaliteit. Maar het is op zijn beurt de ernst van de individuele defecten die bepalen of het product geschikt is voor gebruik of niet.
Hoge DD is uw indicator om dieper te graven en uw gebreken te analyseren op hun gevolgen.
Wie wil er nou niet de dichtheid van nul defecten? Dus ook al is er geen specifieke norm, hoe lager deze waarde, hoe beter.
Laatste gedachten:
- Het is geen voorspellende telling. Een waarde van DD helpt niet om de toekomstige kwaliteit van het product te verwachten. Het kan beter of slechter zijn. Historische gegevens helpen niet bij toekomstige voorspellingen.
- Tijdens kritische testfasen / cycli (zoals UAT) wordt DD berekend op basis van tijd.Bijvoorbeeld: DD / eerste uur, DD per dag, etc.
- Bij het verzamelen van statistieken over meerdere release / cyclusdefecten kan de defectdichtheid per cyclus of per release zijn.
- Een eenvoudige grafische weergave van de tabelgegevens kan er als volgt uitzien:
Ten slotte
Defectdichtheid is een belangrijke kwaliteitsindicator. U kunt niet fout gaan met het verzamelen en presenteren van deze defectstatistiek. Bovendien? Het is een van de gemakkelijkst te berekenen.
Ik hoop dat dit artikel je voldoende bekendheid heeft gegeven om Defect Density te gaan gebruiken voor diepere inzichten.
Auteur : STH-teamlid Swati heeft deze gedetailleerde tutorial geschreven.
Berekent u de defectdichtheid in uw teams? Zo ja, doe je het per cyclus, per module of per KLOC? Zo nee, welke andere statistieken helpen u kwaliteit te begrijpen? Deel uw opmerkingen en vragen hieronder.
Aanbevolen literatuur
- Wat is een op defecten gebaseerde testtechniek?
- Alfatesten en bètatesten (een complete gids)
- Beste QA-softwaretestservices van SoftwareTestingHelp
- Soorten softwaretests: verschillende testtypen met details
- Bij softwaretests draait alles om ideeën (en hoe u ze kunt genereren)
- Perfect Software Testing CV-gids (met Software Tester CV-voorbeeld)
- Functioneel testen versus niet-functioneel testen
- Wat is de levenscyclus van defecten / bugs bij het testen van software? Zelfstudie over de levenscyclus van een defect