Wat is defectdichtheid? Formule om te berekenen met Voorbeeld

Wat is defectdichtheid?

Defectdichtheid Het aantal bevestigde defecten in een softwareonderdeel of module gedurende een specifieke periode van gebruik of ontwikkeling, gedeeld door de omvang van die software of module. Hiermee kan een team bepalen of een softwareonderdeel klaar is om te worden uitgebracht.

De defectdichtheid wordt geteld per duizend regels code, ook wel KLOC genoemd. Omdat de telling is genormaliseerd naar grootte, kunnen een grote module met veel defecten en een kleine module met weinig defecten op dezelfde schaal worden vergeleken, iets wat met een ruwe telling van het aantal bugs nooit mogelijk is.

De meetwaarde wordt normaal gesproken aan het einde van een testcyclus gerapporteerd en tracked release na release, dus het staat naast de rest van de defectbeheerproces in de levenscyclus van softwaretests.

Hoe bereken je de defectdichtheid?

Een formule om de defectdichtheid te meten:

Defect Density = Defect count/size of the release

De omvang van een release kan worden gemeten in termen van een regel code (LOC).

Drie details bepalen of het resulterende getal betekenis heeft:

• De maateenheid. LOC en KLOC zijn de meest gebruikte eenheden. Functiepunten worden gebruikt wanneer teams een maatstaf voor de omvang willen die niet verandert met de programmeertaal, en sommige teams normaliseren in plaats daarvan per module of per component.
• Wat wordt beschouwd als een defect? Alleen bevestigde defecten horen in de teller thuis. Dubbele meldingen, afgewezen rapporten en verbeteringsverzoeken moeten worden uitgesloten, anders loopt het cijfer op zonder dat de codekwaliteit verbetert.
• Het meetvenster. Defecten die tijdens systeemtesten zijn gevonden, tijdens regressietestenEn na de publicatie worden er verschillende dingen beschreven, dus de periode moet met het getal worden aangegeven.

Voorbeeld van defectdichtheid

Stel dat uw softwareproduct drie modules bevat. In elke module zijn het volgende aantal bugs gevonden:

• Module 1 = 10 bugs
• Module 2 = 20 bugs
• Module 3 = 10 bugs

Totaal aantal bugs = 10 + 20 + 10 = 40

Het totale aantal regels code voor elke module is:

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

Totale lijn van Code = 1000+1500+500 = 3000

Defectdichtheid wordt berekend als:

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

Dezelfde berekening per module toegepast is nuttiger dan het gecombineerde cijfer, zoals de onderstaande grafiek laat zien: Module 2 bevat 20 defecten in 1500 regels code en Module 3 bevat 10 defecten in slechts 500 regels code. Module 3 is dus de module met de hoogste foutdichtheid en het grootste risico van de twee, ondanks het feit dat er minder fouten in zijn gerapporteerd.

Een standaard voor defectdichtheid

Er bestaat geen vaste norm voor defectdichtheid. Studies suggereren dat één defect Een aantal fouten per duizend regels code wordt over het algemeen beschouwd als een teken van goede projectkwaliteit, en dat cijfer is de meest geciteerde vuistregel in de branche.

De verwachtingen veranderen met het domein. Voor veiligheidskritische en gereguleerde software, zoals avionica en medische apparatuur, geldt een doelstelling van ruim onder de één defect per KLOC, terwijl gewone bedrijfsapplicaties daar doorgaans boven zitten. Omdat telregels, meeteenheden en testdiepte per organisatie verschillen, is een benchmark uit een gepubliceerde studie alleen vergelijkbaar met een project dat op dezelfde manier meet. Het praktische gebruik van de meetmethode is daarom intern: vergelijk een release met de vorige release van hetzelfde product, die op identieke wijze is gemeten.

Factoren die de defectdichtheid beïnvloeden

Dezelfde codebasis kan zeer verschillende waarden voor de defectdichtheid opleveren, afhankelijk van de volgende factoren:

• Code complexiteit. Diep geneste logica en hoge cyclomatische complexiteit produceert meer fouten per regel dan eenvoudige code.
• Het type gebreken dat in aanmerking wordt genomen. Alleen functionele defecten meetellen, of ook bruikbaarheid, documentatie en niet-functioneel bevindingen, verandert de teller aanzienlijk.
• De beschouwde tijdsduur. Een waarde die is gemeten tijdens een testperiode van twee weken is niet vergelijkbaar met een waarde die is gemeten over zes maanden productiegebruik.
• Ontwikkelaars- en testersvaardigheden. Ervaren ontwikkelaars introduceren minder fouten, terwijl ervaren testers juist meer van de bestaande fouten vinden. Deze twee effecten trekken de meetwaarde dus in tegengestelde richtingen.
• Testdekking. Gebreken waarnaar nooit is gezocht, worden nooit meegeteld, dus test dekking Het beperkt op een stille manier hoe hoog de gemeten dichtheid kan oplopen.

Defectdichtheid versus andere defectstatistieken

Defectdichtheid beantwoordt één vraag: hoe geconcentreerd zijn de bekende defecten? Drie aanvullende meetwaarden beantwoorden de vragen die defectdichtheid niet kan beantwoorden, en de meeste teams rapporteren deze samen.

Samen geven de vier aspecten een completer beeld: een lage defectdichtheid met een hoge defectlekkage wijst op oppervlakkige tests in plaats van schone code, en dat is precies de verkeerde interpretatie waar in het volgende gedeelte voor wordt gewaarschuwd.

Voordelen van defectdichtheid

De voordelen van defectdichtheid zijn als volgt:

• Het helpt om de effectiviteit van tests te meten.
• Het helpt om de concentratie van defecten te onderscheiden tussen componenten en softwaremodules.
• Het is nuttig om de gebieden te identificeren die correctie of verbetering behoeven.
• Het is nuttig om risicovolle onderdelen aan te wijzen, wat direct van invloed is op risicogebaseerd testen.
• Het helpt bij het vaststellen van de trainingsbehoeften van verschillende medewerkers.
• Het kan nuttig zijn bij het inschatten van de test- en herstelwerkzaamheden die door defecten worden veroorzaakt.
• Het kan de resterende defecten in de software inschatten.
• Vóór de release helpt het om te bepalen of de tot nu toe uitgevoerde tests voldoende zijn.
• Het creëert een historische basislijn waaraan latere publicaties kunnen worden afgemeten.

Beperkingen van de defectdichtheid

De meetwaarde is eenvoudig te berekenen, maar ook eenvoudig verkeerd te interpreteren. De volgende beperkingen bepalen hoeveel gewicht deze waarde heeft bij een beslissing over een release:

• Niet-opgemerkte defecten zijn onzichtbaar. De teller bevat alleen defecten die daadwerkelijk tijdens de tests zijn gevonden, waardoor een module die onvoldoende is getest een gunstiger cijfer rapporteert.
• De ernst van de situatie wordt genegeerd. Een defect dat een betaling verstoort en een cosmetisch uitlijningsprobleem tellen hetzelfde mee, daarom is een beoordeling op basis van ernst noodzakelijk.
• De definities van defecten variëren. Twee teams die op verschillende manieren tellen, produceren cijfers die niet met elkaar te vergelijken zijn, zelfs niet binnen dezelfde organisatie.
• Het aantal regels code is een zwakke maatstaf voor de omvang. Overdreven code verlaagt de dichtheid zonder iets te verbeteren, en de eenheid is niet vergelijkbaar tussen programmeertalen.
• De meetmethode kan gemanipuleerd worden. Het afwijzen van twijfelachtige rapporten of het overdrijven van het aantal regels verbetert zowel het cijfer als het product zelf.

Dit alles maakt de defectdichtheid niet nutteloos. Het maakt het eerder een trendindicator voor één product, consistent gemeten, in plaats van een score om teams met elkaar te vergelijken.

Hoe verlaag je de defectdichtheid?

Het daadwerkelijk verlagen van de defectdichtheid, en niet alleen op papier, betekent het vroegtijdig voorkomen van defecten en het opsporen van de overige defecten vóór de release. De onderstaande werkwijzen komen steeds terug in gepubliceerde richtlijnen:

• Verplaats de tests naar een eerder tijdstip. Door testers al in de fase van de vereisten en het ontwerp te betrekken, worden onduidelijkheden opgespoord voordat ze in de code terechtkomen. In die fase zijn defecten het goedkoopst te verhelpen.
• RevBekijk de code voordat deze wordt samengevoegd. Peer review brengt logische fouten, verkeerd geïnterpreteerde eisen en ontwerpfouten aan het licht die anders niet zouden voorkomen. hoofdstuk toets werd geschreven om naar te zoeken.
• Automatiseer de regressietestsuite. Het uitvoeren van controles op elke commit via continue integratie Voorkomt dat oude fouten terugkeren tijdens het schrijven van nieuwe code.
• Schrijf eerst de tests. Test gedreven ontwikkeling dwingt elk gedrag af om gespecificeerd te worden voordat het wordt geïmplementeerd, en mutatie testen Dan kan men bevestigen dat de resultaten van de tests daadwerkelijk iets aantonen.
• Gebruik statische analyse. Geautomatiseerde codescans signaleren null-dereferenties, resourcelekken en complexe knelpunten nog voordat er ook maar één test is uitgevoerd.
• Herstructureer de complexe modules. Zodra Defect Density de slechtste componenten heeft geïdentificeerd, leidt het opsplitsen en vereenvoudigen ervan doorgaans tot een vermindering van zowel de complexiteit als het aantal defecten.
• Voer defecten terug in het proces. Een oorzaakanalyse tijdens retrospectieve evaluaties zet individuele defecten om in procesverbeteringen in plaats van eenmalige lapmiddelen.

Tracked release over release alongside software testtechnieken En met behulp van dekkingsgegevens wordt de defectdichtheid een vroegtijdig waarschuwingssysteem in plaats van een rapportcijfer.

Veelgestelde vragen