vault backup: 2025-02-21 16:16:30
This commit is contained in:
@@ -265,6 +265,144 @@
|
||||
|
||||
|
||||
|
||||
**Softwaremetriken: Detaillierte Betrachtung**
|
||||
|
||||
**1. Was sind Softwaremetriken?**
|
||||
|
||||
* **Definition:** Softwaremetriken sind quantitative Messungen, die verwendet werden, um verschiedene Aspekte von Softwareprodukten, -prozessen und -ressourcen zu bewerten und zu verfolgen. Sie liefern Einblicke in die Qualität, Komplexität, Größe, Effizienz und andere wichtige Eigenschaften von Software.
|
||||
* **Zweck:**
|
||||
* **Verstehen:** Metriken helfen, die Eigenschaften von Software besser zu verstehen und zu quantifizieren.
|
||||
* **Vergleichen:** Sie ermöglichen den Vergleich verschiedener Softwareprodukte, -versionen oder -projekte.
|
||||
* **Vorhersagen:** Metriken können verwendet werden, um zukünftige Entwicklungen, Kosten oder Risiken vorherzusagen.
|
||||
* **Steuern:** Sie unterstützen die Steuerung von Softwareentwicklungsprozessen und die Optimierung von Ressourcen.
|
||||
* **Kommunizieren:** Metriken dienen als Kommunikationsmittel zwischen Entwicklern, Managern und anderen Stakeholdern.
|
||||
|
||||
**2. Kategorien von Softwaremetriken**
|
||||
|
||||
* **Quantitätsmetriken:** Messen die Größe und den Umfang von Software.
|
||||
* **Beispiele:**
|
||||
* *Lines of Code (LOC):* Anzahl der Codezeilen in einem Programm.
|
||||
* *Function Points (FP):* Messung der Funktionalität, die ein Softwaresystem bietet.
|
||||
* *Number of Classes/Modules:* Anzahl der Klassen oder Module in einem System.
|
||||
* **Komplexitätsmetriken:** Bewerten die Komplexität von Software.
|
||||
* **Beispiele:**
|
||||
* *Cyclomatic Complexity (McCabe):* Messung der Anzahl unabhängiger Pfade durch ein Programm.
|
||||
* *Halstead Metrics:* Messung der Komplexität basierend auf der Anzahl der Operatoren und Operanden.
|
||||
* *Coupling and Cohesion:* Messung der Abhängigkeiten zwischen Modulen und des Zusammenhalts innerhalb von Modulen.
|
||||
* **Qualitätsmetriken:** Bewerten die Qualität von Software.
|
||||
* **Beispiele:**
|
||||
* *Defect Density:* Anzahl der Fehler pro Codezeile oder Funktionseinheit.
|
||||
* *Mean Time To Failure (MTTF):* Durchschnittliche Zeit zwischen Ausfällen eines Systems.
|
||||
* *Maintainability Index:* Messung der Wartbarkeit von Software.
|
||||
* *Code Coverage:* Prozentsatz des Codes, der durch Tests abgedeckt wird.
|
||||
|
||||
**3. Anwendungsbereiche von Softwaremetriken**
|
||||
|
||||
* **Anforderungsanalyse:** Messung der Vollständigkeit und Konsistenz von Anforderungen.
|
||||
* **Entwurf:** Bewertung der Qualität des Softwaredesigns.
|
||||
* **Codierung:** Überwachung der Codequalität und -komplexität.
|
||||
* **Testen:** Messung der Testabdeckung und Fehlerdichte.
|
||||
* **Wartung:** Bewertung der Wartbarkeit und Änderungsfreundlichkeit von Software.
|
||||
* **Projektmanagement:** Verfolgung des Projektfortschritts und der Ressourcennutzung.
|
||||
|
||||
**4. Beispiele für Softwaremetriken und ihre Berechnung**
|
||||
|
||||
* **Lines of Code (LOC):**
|
||||
* *Berechnung:* Zählen der Anzahl der Codezeilen in einem Programm.
|
||||
* *Interpretation:* Höhere LOC kann auf größere Komplexität hindeuten, aber auch auf Redundanz.
|
||||
* **Cyclomatic Complexity (McCabe):**
|
||||
* *Berechnung:* $V(G) = E - N + 2$, wobei E die Anzahl der Kanten und N die Anzahl der Knoten im Kontrollflussgraphen ist.
|
||||
* *Interpretation:* Höhere zyklomatische Komplexität deutet auf komplexeren Code hin, der schwieriger zu testen und zu warten ist.
|
||||
* **Halstead Metrics:**
|
||||
* *Basisparameter:*
|
||||
* $t$: Anzahl der unterschiedlichen Operatoren
|
||||
* $d$: Anzahl der unterschiedlichen Operanden
|
||||
* $n_t$: Gesamtzahl aller Operatoren im Programm
|
||||
* $n_d$: Gesamtzahl aller Operanden im Programm
|
||||
* *Berechnungen:*
|
||||
* Größe des Vokabulars: $G = t + d$
|
||||
* Länge des Programms: $N = n_t + n_d$
|
||||
* Volumen des Programms: $V = N \times log_2 G$
|
||||
* Level: $L = V^* / V$
|
||||
* Schwierigkeit: $D = 1 / L$
|
||||
* Aufwand: $E = V \times D$
|
||||
* *Interpretation:* Höheres Volumen und höherer Aufwand deuten auf komplexeren Code hin.
|
||||
* **Weighted Method per Class (WMC):**
|
||||
* *Berechnung:* $WMC = \sum_{i=1}^{M} v(m_i)$, wobei $v(m_i)$ die Komplexität der Methode $m_i$ ist (z.B. zyklomatische Komplexität).
|
||||
* *Interpretation:* Höherer WMC deutet auf eine komplexere Klasse hin, die schwieriger zu verstehen und zu testen ist.
|
||||
|
||||
**5. Herausforderungen bei der Verwendung von Softwaremetriken**
|
||||
|
||||
* **Interpretation:** Metriken müssen im Kontext interpretiert werden. Eine hohe LOC ist nicht immer schlecht, und eine niedrige zyklomatische Komplexität garantiert keine hohe Qualität.
|
||||
* **Manipulation:** Metriken können manipuliert werden, um ein gewünschtes Ergebnis zu erzielen.
|
||||
* **Kosten:** Die Erfassung und Analyse von Metriken kann kostspielig sein.
|
||||
* **Akzeptanz:** Entwickler können Metriken als Bedrohung empfinden, was zu Widerstand führen kann.
|
||||
|
||||
**6. Best Practices für die Verwendung von Softwaremetriken**
|
||||
|
||||
* **Definieren Sie klare Ziele:** Was soll mit den Metriken erreicht werden?
|
||||
* **Wählen Sie relevante Metriken:** Welche Metriken sind für die spezifischen Ziele am besten geeignet?
|
||||
* **Automatisieren Sie die Erfassung:** Verwenden Sie Werkzeuge, um Metriken automatisch zu erfassen.
|
||||
* **Analysieren Sie die Daten:** Interpretieren Sie die Metriken im Kontext und identifizieren Sie Trends und Muster.
|
||||
* **Kommunizieren Sie die Ergebnisse:** Teilen Sie die Ergebnisse mit den Stakeholdern und verwenden Sie sie, um Entscheidungen zu treffen.
|
||||
* **Überprüfen und passen Sie die Metriken an:** Stellen Sie sicher, dass die Metriken weiterhin relevant und nützlich sind.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**Black-Box-Testing (Funktionstests)**
|
||||
|
||||
* **Konzept:**
|
||||
* Der Tester betrachtet das System als "Black Box", d.h. er hat keine Kenntnisse über die interne Struktur, den Code oder die Implementierung des Systems.
|
||||
* Die Testfälle werden ausschließlich auf Basis der Spezifikation, der Anforderungen oder der Dokumentation des Systems entwickelt.
|
||||
* Das Ziel ist es, die Funktionalität des Systems aus der Sicht des Endbenutzers zu überprüfen.
|
||||
* **Vorteile:**
|
||||
* **Unabhängigkeit:** Tester benötigt keine Programmierkenntnisse.
|
||||
* **Benutzerperspektive:** Testfälle spiegeln die tatsächliche Nutzung des Systems wider.
|
||||
* **Frühe Testphase:** Kann bereits in frühen Phasen des Entwicklungsprozesses durchgeführt werden, sobald die Spezifikationen vorliegen.
|
||||
* **Objektivität:** Tester ist nicht durch die Implementierung voreingenommen.
|
||||
* **Nachteile:**
|
||||
* **Begrenzte Abdeckung:** Es ist unmöglich, alle möglichen Eingabekombinationen und Pfade zu testen.
|
||||
* **Redundanz:** Testfälle können sich überschneiden oder redundante Funktionalität abdecken.
|
||||
* **Nicht entdeckte Fehler:** Fehler in nicht spezifizierten oder selten genutzten Bereichen können unentdeckt bleiben.
|
||||
* **Schwierige Testfallerstellung:** Erfordert ein tiefes Verständnis der Spezifikationen und Anforderungen.
|
||||
* **Gängige Techniken:**
|
||||
* **Äquivalenzklassenbildung:** Aufteilung der Eingabewerte in Äquivalenzklassen, von denen angenommen wird, dass sie sich gleich verhalten.
|
||||
* **Grenzwertanalyse:** Testen von Werten an den Grenzen der Äquivalenzklassen.
|
||||
* **Entscheidungstabellentests:** Erstellung von Tabellen, die alle möglichen Kombinationen von Eingabebedingungen und den entsprechenden Ausgaben auflisten.
|
||||
* **Zustandsübergangstests:** Modellierung des Systems als Zustandsautomat und Testen aller Zustandsübergänge.
|
||||
* **Use-Case-Tests:** Entwicklung von Testfällen basierend auf den Use Cases des Systems.
|
||||
* **Zufallstests:** Generierung von zufälligen Eingabewerten und Überprüfung der Ausgaben.
|
||||
* **Property-based Testing:** Prüfung, ob ein Prädikat erfüllt ist: $\forall x.P(x, f_{SUT}(x))$.
|
||||
|
||||
**Glass-Box-Testing (White-Box-Testing, Strukturtests)**
|
||||
|
||||
* **Konzept:**
|
||||
* Der Tester hat vollen Einblick in die interne Struktur, den Code und die Implementierung des Systems.
|
||||
* Die Testfälle werden auf Basis des Codes entwickelt, um sicherzustellen, dass alle Teile des Codes ausgeführt werden.
|
||||
* Das Ziel ist es, die interne Logik des Systems zu überprüfen und Fehler in der Implementierung zu finden.
|
||||
* **Vorteile:**
|
||||
* **Vollständige Abdeckung:** Kann sicherstellen, dass alle Teile des Codes getestet werden.
|
||||
* **Effiziente Fehlerfindung:** Kann Fehler in der Implementierung, wie z.B. Logikfehler oder Datenflussfehler, aufdecken.
|
||||
* **Codeoptimierung:** Kann helfen, ineffizienten oder unnötigen Code zu identifizieren.
|
||||
* **Nachteile:**
|
||||
* **Hoher Aufwand:** Erfordert detaillierte Kenntnisse des Codes und der Implementierung.
|
||||
* **Komplexität:** Kann sehr komplex und zeitaufwendig sein, insbesondere bei großen Systemen.
|
||||
* **Entwicklerperspektive:** Testfälle spiegeln möglicherweise nicht die tatsächliche Nutzung des Systems wider.
|
||||
* **Nicht entdeckte Spezifikationsfehler:** Kann keine Fehler in den Spezifikationen oder Anforderungen aufdecken.
|
||||
* **Gängige Techniken:**
|
||||
* **Anweisungsüberdeckung (Statement Coverage):** Sicherstellen, dass jede Anweisung im Code mindestens einmal ausgeführt wird.
|
||||
* **Zweigüberdeckung (Branch Coverage):** Sicherstellen, dass jeder Zweig (z.B. if-else) im Code mindestens einmal ausgeführt wird.
|
||||
* **Bedingungsüberdeckung (Condition Coverage):** Sicherstellen, dass jede Bedingung in einem Zweig mindestens einmal true und einmal false ist.
|
||||
* **Pfadüberdeckung (Path Coverage):** Sicherstellen, dass jeder mögliche Pfad durch den Code mindestens einmal ausgeführt wird.
|
||||
* **Datenflussanalyse (Data Flow Analysis):** Analyse des Datenflusses durch den Code, um sicherzustellen, dass Variablen korrekt definiert, verwendet und gelöscht werden.
|
||||
|
||||
|
||||
|
||||
# Note Notes
|
||||
|
||||
**Glass-Box-Test (White-Box-Test) / Strukturtest:**
|
||||
|
||||
Reference in New Issue
Block a user