Was ist Fehlerdichte? Formel zur Berechnung mit Beispiel
Thomas Hamilton
โก 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.
