Was ist Fehlerdichte? Formel zur Berechnung mit Beispiel
Redaktion
⚡ Intelligente Zusammenfassung
Die Fehlerdichte misst die Anzahl der bestätigten Fehler in einem Softwaremodul geteilt durch die Größe dieses Moduls, üblicherweise ausgedrückt pro tausend Codezeilen, und signalisiert, ob ein Build zur Veröffentlichung bereit ist.
Was ist Fehlerdichte?
Defektdichte Die Fehlerquote gibt die Anzahl der in einer Software oder einem Modul während eines bestimmten Betriebs- oder Entwicklungszeitraums bestätigten Fehler an, geteilt durch die Größe dieser Software oder dieses Moduls. Sie ermöglicht es einem Team zu entscheiden, ob eine Software zur Veröffentlichung bereit ist.
Die Fehlerdichte wird pro tausend Codezeilen (KLOC) angegeben. Da die Anzahl größenbezogen normalisiert wird, lassen sich ein großes Modul mit vielen Fehlern und ein kleines Modul mit wenigen Fehlern auf derselben Ebene vergleichen, was mit einer reinen Fehlerzählung nicht möglich ist.
Diese Kennzahl wird normalerweise am Ende eines Testzyklus gemeldet und tracked release over release, so it is inside the rest of the Fehlermanagementprozess in England, Lebenszyklus von Softwaretests.
Wie berechnet man die Defektdichte?
Eine Formel zur Messung der Fehlerdichte:
Defect Density = Defect count/size of the release
Die Größe eines Releases kann in Zeilen von Code (LOC) gemessen werden.
Drei Details entscheiden darüber, ob das Ergebnis überhaupt eine Aussage hat:
- Die Größenangabe. LOC und KLOC sind die gebräuchlichsten Einheiten. Funktionspunkte werden verwendet, wenn Teams ein Größenmaß wünschen, das sich nicht mit der Programmiersprache ändert; manche Teams normalisieren stattdessen nach Modul oder Komponente.
- Was gilt als Mangel? Nur bestätigte Fehler gehören in den Zähler. Duplikate, abgelehnte Berichte und Verbesserungsvorschläge müssen ausgeschlossen werden, da sonst die Zahl ohne Verbesserung der Codequalität unnötig ansteigt.
- Das Messfenster. Fehler, die während der Systemtests festgestellt wurden, während Regressionstestsund nach der Veröffentlichung werden unterschiedliche Dinge beschrieben, daher muss der Zeitraum mit der Zahl angegeben werden.
Beispiel für die Fehlerdichte
Angenommen, Ihr Softwareprodukt enthält drei Module. In jedem Modul wurden die folgenden Fehler entdeckt:
- Modul 1 = 10 Fehler
- Modul 2 = 20 Fehler
- Modul 3 = 10 Fehler
Gesamtzahl der Käfer = 10+20+10 = 40
Die Gesamtanzahl der Codezeilen für jedes Modul beträgt:
- Modul 1 = 1000 LOC
- Modul 2 = 1500 LOC
- Modul 3 = 500 LOC
Gesamtzeile Code = 1000+1500+500 = 3000
Die Fehlerdichte wird wie folgt berechnet:
Defect Density = 40/3000 = 0.013333 defects/loc = 13.333 defects/Kloc
Die gleiche Berechnung pro Modul ist aussagekräftiger als die kombinierte Zahl, wie die folgende Grafik zeigt: Modul 2 weist 20 Fehler in 1500 LOC auf, Modul 3 hingegen nur 10 Fehler in 500 LOC. Somit ist Modul 3 das dichter bestückte und risikoreichere der beiden, obwohl es weniger Fehler meldet.
Ein Standard für die Defektdichte
Es gibt keinen festgelegten Standard für die Defektdichte. Studien deuten darauf hin, dass… Defekt Die Anzahl der Codezeilen pro tausend Zeilen wird allgemein als Zeichen guter Projektqualität angesehen, und diese Zahl ist die am häufigsten zitierte Faustregel in der Branche.
Die Erwartungshaltung variiert je nach Anwendungsbereich. Sicherheitskritische und regulierte Software, wie beispielsweise Avionik und Medizinprodukte, unterliegt einem Zielwert von deutlich unter einem Fehler pro KLOC, während gängige Geschäftsanwendungen diesen Wert regelmäßig überschreiten. Da Zählregeln, Größeneinheiten und Testtiefe zwischen Organisationen variieren, ist ein Benchmark aus einer veröffentlichten Studie nur mit einem Projekt vergleichbar, das nach denselben Kriterien gemessen wird. Die praktische Anwendung dieser Kennzahl beschränkt sich daher auf interne Zwecke: Man vergleicht eine neue Version mit der vorherigen Version desselben Produkts, die nach denselben Kriterien gemessen wurde.
Faktoren, die die Defektdichte beeinflussen
Dieselbe Codebasis kann je nach folgenden Faktoren sehr unterschiedliche Fehlerdichtewerte erzeugen:
- Code Komplexität. Tief verschachtelte Logik und hohe zyklomatische Komplexität erzeugen mehr Fehler pro Zeile als unkomplizierter Code.
- Die Art der berücksichtigten Defekte. Zählen Sie nur funktionale Mängel oder beziehen Sie auch Benutzerfreundlichkeit, Dokumentation und nicht funktionsfähig Die Ergebnisse verändern den Zähler erheblich.
- Die betrachtete Zeitdauer. Ein Wert, der über einen zweiwöchigen Testzyklus ermittelt wurde, ist nicht vergleichbar mit einem Wert, der über sechs Monate Produktionsnutzung ermittelt wurde.
- Entwickler- und Testerfähigkeiten. Erfahrene Entwickler bauen weniger Fehler ein, und erfahrene Tester finden mehr der vorhandenen Fehler, sodass die beiden Effekte die Kennzahl in entgegengesetzte Richtungen ziehen.
- Testabdeckung. Mängel, nach denen nie gesucht wurde, werden nie gezählt, daher Testabdeckung begrenzt stillschweigend, wie hoch die gemessene Dichte maximal sein kann.
Fehlerdichte im Vergleich zu anderen Fehlerkennzahlen
Die Fehlerdichte beantwortet eine Frage: Wie konzentriert sind die bekannten Fehler? Drei ergänzende Kennzahlen beantworten die Fragen, die sie nicht beantworten kann, und die meisten Teams berichten diese gemeinsam.
| Metrisch | Was es misst | Fragen, die es beantwortet |
| Defektdichte | Bestätigte Fehler nach Größe aufgeteilt (KLOC oder Funktionspunkte) | Welche Module weisen im Verhältnis zu ihrer Größe die meisten Defekte auf? |
| Defektleckage | Anteil der nach der Veröffentlichung festgestellten Mängel an allen Mängeln | Wie viel davon entging dem Testprozess und erreichte die Nutzer? |
| Effizienz der Fehlerbeseitigung | Vor der Veröffentlichung behobene Mängel als Anteil aller Mängel | Wie effektiv waren die Tests bei der rechtzeitigen Erkennung von Fehlern? |
| Schweregradindex für Defekte | Fehler werden nach Schweregrad gewichtet und nicht gleich gezählt | Wie gravierend sind die Mängel, nicht nur wie viele? |
Zusammengenommen ergeben die vier ein umfassenderes Bild: Eine niedrige Fehlerdichte bei gleichzeitig hoher Fehlerleckage deutet eher auf oberflächliche Tests als auf sauberen Code hin, was genau die Fehlinterpretation ist, vor der im nächsten Abschnitt gewarnt wird.
Vorteile der Defektdichte
Im Folgenden werden die Vorteile der Defektdichte aufgeführt:
- Es hilft dabei, die Effektivität von Tests zu messen.
- Es hilft dabei, die Fehlerkonzentration zwischen Komponenten und Softwaremodulen zu differenzieren.
- Es ist hilfreich, um die Bereiche zu identifizieren, die Korrekturen oder Verbesserungen benötigen.
- Es ist hilfreich, um auf risikoreiche Komponenten hinzuweisen, was sich direkt auf Folgendes auswirkt: risikobasiertes Testen.
- Es hilft dabei, den Schulungsbedarf verschiedener Ressourcen zu ermitteln.
- Es kann hilfreich sein, den durch Fehler verursachten Aufwand für Tests und Nacharbeiten abzuschätzen.
- Es kann die verbleibenden Fehler in der Software abschätzen.
- Vor der Veröffentlichung hilft es festzustellen, ob die bisher durchgeführten Tests ausreichend sind.
- Es schafft eine historische Basis, an der spätere Veröffentlichungen gemessen werden können.
Grenzen der Defektdichte
Die Kennzahl ist leicht zu berechnen, aber auch leicht falsch zu interpretieren. Die folgenden Einschränkungen bestimmen, wie viel Gewicht ihr bei einer Freigabeentscheidung zukommt:
- Unentdeckte Mängel sind unsichtbar. Im Zähler werden nur die Fehler berücksichtigt, die bei den Tests tatsächlich gefunden wurden. Daher liefert ein nur unzureichend getestetes Modul einen schmeichelhaften Wert.
- Der Schweregrad wird ignoriert. Ein Fehler, der eine Zahlung beeinträchtigt, und ein kosmetisches Ausrichtungsproblem werden gleich gezählt, weshalb zusätzlich eine nach Schweregrad gewichtete Betrachtung erforderlich ist.
- Die Definitionen von Defekten variieren. Zwei Teams, die unterschiedlich zählen, liefern Zahlen, die selbst innerhalb derselben Organisation nicht vergleichbar sind.
- Die Anzahl der Codezeilen ist ein schwacher Indikator für die Codegröße. Ausführlicher Code verringert die Dichte, ohne irgendetwas zu verbessern, und die Einheit ist nicht über verschiedene Programmiersprachen hinweg vergleichbar.
- Diese Kennzahl kann manipuliert werden. Das Ablehnen von Grenzwertberichten oder das Aufblähen der Zeilenanzahl verbessern zwar die Kennzahl, aber nicht das Produkt.
Nichts davon macht die Fehlerdichte nutzlos. Sie dient lediglich als Trendindikator für ein einzelnes Produkt, der kontinuierlich gemessen wird, anstatt als Vergleichswert für verschiedene Teams.
Wie man die Defektdichte reduziert
Die tatsächliche Reduzierung der Fehlerdichte, nicht nur auf dem Papier, bedeutet, Fehler frühzeitig zu erkennen und die verbleibenden Fehler vor der Veröffentlichung zu finden. Die folgenden Vorgehensweisen werden in den veröffentlichten Leitlinien immer wieder genannt:
- Die Tests werden vorgezogen. Durch die Einbindung von Testern bereits in der Anforderungs- und Entwurfsphase werden Unklarheiten aufgedeckt, bevor sie zu Code werden, und genau dort lassen sich Fehler am günstigsten beheben.
- RevÜberprüfen Sie den Code vor dem Zusammenführen. Die Peer-Review deckt Logikfehler, falsch interpretierte Anforderungen und Designmängel auf, die sonst niemandem auffallen würden. Gerätetest wurde geschrieben, um danach zu suchen.
- Automatisieren Sie die Regressionssuite. Durchführen von Prüfungen bei jedem Commit kontinuierliche integration verhindert, dass alte Fehler während der Entwicklung neuen Codes wieder auftreten.
- Schreiben Sie zuerst die Tests. Testgetriebene Entwicklung erzwingt, dass jedes Verhalten vor seiner Implementierung spezifiziert werden muss, und Mutationstests Man kann dann überprüfen, ob die resultierenden Tests tatsächlich etwas aussagen.
- Verwenden Sie statische Analyse. Die automatisierte Codeanalyse erkennt Null-Dereferenzierungen, Ressourcenlecks und Komplexitätsschwerpunkte, bevor überhaupt ein Testlauf ausgeführt wird.
- Refaktorieren Sie die dichten Module. Sobald die Fehlerdichteanalyse die problematischsten Komponenten identifiziert hat, führt deren Aufteilung und Vereinfachung in der Regel zu einer Verringerung sowohl der Komplexität als auch der Fehleranzahl.
- Fehler werden wieder in den Prozess eingespeist. Die Ursachenanalyse im Rahmen von Retrospektiven wandelt einzelne Fehler in Prozesskorrekturen um, anstatt nur einmalige Ausbesserungen vorzunehmen.
Tracked release over release along Softwaretesttechniken Anhand von Abdeckungsdaten wird die Defektdichte eher zu einem Frühwarnsystem als zu einer Leistungsbewertung.
