obsidian/WS2425/SWT D/Notes.md

Softwaretechnik D: Qualitätssicherung und Wartung – Zusammenfassung

1. Motivation und Grundlagen

• Warum Qualität? Software durchdringt unser Leben, Systemkomplexität steigt, Einsatz in sicherheitskritischen Bereichen. In Deutschland: Hohe Arbeitskosten erfordern hohe Qualität zur Wettbewerbsfähigkeit.
• Qualitätsmerkmale: Spezifikationsvollständigkeit, Testbarkeit, Portierbarkeit, Korrektheit, Ressourcenschonung, Einfachheit, Ausfallsicherheit, Rechengenauigkeit, Bedienbarkeit, Dokumentation.
• Wie entsteht Qualität? Durch gezielte Maßnahmen: Was, Wie, Wann, Wer?
• Mittel zur Qualitätssicherung: Reviews, Tests (Unit, Integration, Blackbox, Whitebox), Richtlinien, Standards, Planung, Schulungen, Werkzeuge, Metriken, Prozessqualität.

2. Ziele und Themen

• Ziel: Kenntnisse zur Erzielung eines definierten Qualitätsniveaus und methodisches Vorgehen bei der Softwarewartung.
• Weg: Operationalisierung des Qualitätsbegriffs über Qualitätsmodelle, Differenzierung in organisatorische, analytische und konstruktive Maßnahmen.
• Themen: Qualitätsmodelle, Fehlerquellen, Prozessqualität, konstruktive Maßnahmen, manuelle und dynamische Prüfmethoden (Tests), Testautomatisierung, Testen objektorientierter Programme, statische Prüfmethoden/Metriken, Werkzeuge/Build-Automatisierung, Wartung.

3. Voraussetzungen und Klausur

• Voraussetzungen: Softwaretechnik 1 und 2 (Analyse, Entwurf), Java-Programmiererfahrung.
• Klausur: Inhalte aus Vorlesung (Folien, Tafel), Übungen, Praktikum. Aufgabentypen: Definitionen, Verständnisfragen, Anwendung (Testfälle, Qualitätsmängel).

4. Was ist Software?

• Programme, Abläufe, Dokumentation, Daten.
• Besonderheiten: Immateriell, benötigt Träger, leicht änderbar, schwache Kausalität zwischen Änderung und Wirkung, keine stetige Funktion, schwer zu vermessen, wird entwickelt (nicht gefertigt), verschleißt nicht, altert über die Umgebung.

5. Qualitätsmodelle

• Qualität: Gesamtheit von Eigenschaften und Merkmalen zur Erfüllung gegebener Erfordernisse (DIN 55350).
• Qualitätsmodell: Ableitung von Unterbegriffen (Qualitätsmerkmale) und Teilmerkmalen zur Messbarkeit/Überprüfbarkeit durch Qualitätsindikatoren (Metriken).
• FCM-Qualitätsmodelle: Factor-Criteria-Metrics-Models
  • Schematischer Aufbau: Software-Qualität -> Q-Merkmal (factor) -> Q-Teilmerkmal (criterion) -> Qualitätsindikatoren (metrics)
• Sichtweisen: Produktqualität, Prozessqualität.
• Historische Modelle: Qualitätenbaum (Boehm), ISO/IEC 9126, ISO/IEC 250nn.
• ISO/IEC 25010: Nur Produktqualität. Modelle: Product quality, Quality in use.
  • Product quality: Functional suitability, Reliability, Performance efficiency, Security, Compatibility, Maintainability, Portability, Usability.
  • Quality in use: Effectiveness, Efficiency, Satisfaction, Freedom from risk, Context coverage.
• Qualitätsbewertung: Soll-Ist-Vergleich. Abweichung = Fehler.
• Qualitätsindikatoren (Metriken): Vorgabe eines Ziels (Soll-Wert), Soll-Ist-Vergleich (Qualitätsmessung).

6. Typische Fehlerquellen

• Komplexität, Software-Größe, Fluktuation, falsche Übertragung von Produktionsprozessen.
• Fehlerquellen nach Hof13:
  1. Lexikalische und syntaktische Fehler
  2. Numerische Fehler (Überläufe, Y2K-Bug)
  3. Semantische Fehler
  4. Parallelität (Race conditions, Deadlocks)
  5. Spezifikationsfehler (Unvollständigkeit, Widersprüche)
  6. Portabilitätsfehler
  7. Hardwarefehler

7. Qualitätssicherung und -management

• Maßnahmen:
  1. Organisatorische Maßnahmen (Systematische Entwicklung, Richtlinien, Standards)
  2. Konstruktive Maßnahmen (Fehlervermeidung von Beginn an)
  3. Analytische Maßnahmen (Software-Prüfung)
• Qualitätsmanagement: Festlegung von Qualitätsanforderungen, Überprüfung der Einhaltung, Schaffung geeigneter Rahmenbedingungen.
• Aktivitäten:
  • Qualitätsplanung: Festlegung von Qualitätsanforderungen an Prozess und Produkt.
  • Qualitätslenkung und -sicherung: Umsetzung, Steuerung, Überwachung und Korrektur des Entwicklungsprozesses.
  • Qualitätsprüfung: Durchführung der festgelegten Maßnahmen (Erfassung der Ist-Werte der Qualitätsindikatoren, Überwachung der Umsetzung der konstruktiven Maßnahmen, Tests, Durchsicht, Reviews).
  • Qualitätsverbesserung: Auswertung der Qualitätssicherungsergebnisse und der Prozessverbesserungen.
• Dokumentation: Qualitätssicherungsplan (Prozess-orientiert), Prüfplan (Produkt-orientiert).
• Qualitätsplanung: Festlegung der Aufgaben, Vorgaben und Hilfsmittel, Termine, Verantwortlichkeiten.
• Qualitätslenkung: Reguläre, besondere und finale Aktivitäten.
• Frühe Fehlerentdeckung: Vermeidung von Summationseffekten. Ziele: Keine Fehler machen, Fehler früh entdecken und beseitigen.
• Qualität und Projekt: Qualität, Funktionalität, Kosten und Zeit sind über die Produktivität gekoppelt.

8. Prozessqualität

• Guter Prozess begünstigt gute Software.
• Themen: Softwareprojektmanagement, Vorgehens- und Prozessmodelle, Risikomanagement, Konfigurationsmanagement, Anforderungs- und Änderungsmanagement.

9. Konstruktive Maßnahmen

• Fehlervermeidung von Anfang an.
• Maßnahmen:
  1. Qualifikation und Schulungen
  2. Attraktive Arbeitsumgebung
  3. Geeignetes Prozessmodell
  4. Werkzeuge (CASE: computer-aided software engineering)
     • Operationen: Editieren, Transformieren, Verwalten/Versionieren, Suchen, Nachvollziehen, Messen, Testen, Verbinden, Dokumentieren, Verfolgen/Überwachen.
     • Werkzeug-Grundausstattung: Editor, Compiler/Linker, Versionsverwaltung, Automatisierung (Build, Test), Überdeckungsprüfung, Statische Prüfung/Vermessung, Code Review, Kommunikation/Dokumentation, Aufwandserfassung, Projekt-/Ressourcenplanung, Verfolgen-/Überwachen.
  5. Geeignete Programmiersprache (Passend zur Problemdomäne, Eigenschaften zur Qualitätssteigerung)
  6. Einhalten von Richtlinien (Vereinheitlichung, Fehlerreduktion)
     • Notationskonventionen (Schreibweise von Bezeichnern, Layout des Quelltextes, Aufbau von Kontrollstrukturen)
     • Sprachkonventionen (Regeln für die Formulierung von Anforderungen im Rahmen der Spezifikation, Umgang mit den semantischen Besonderheiten einer Programmiersprache)
  7. Angemessene Dokumentation (Einfluss auf Qualitätsmerkmale)
     • Externe Dokumentation (Pflichtenheft, Vertrag, Handbücher, Online-Hilfe)
     • Spezifikationsdokumentation (zutreffend, vollständig, konsistent, neutral, nachvollziehbar, überprüfbar)
     • Implementierungsdokumentation (Code-Dokumentation, externe Dokumente)
     • Dokumentationsextraktion (JavaDoc)
  8. Angemessene Architektur (Modularisierung, Hierarchisierung, Starker Zusammenhalt und schwache Kopplung, Trennung von Zuständigkeiten, Information Hiding)
  9. Automatisierung (Build-Prozess, Programmtest, Versionierung, Datensicherung, Installation der Umgebungen)
• Richtlinien:
  • Notationsstile für Bezeichner (Pascal Case, Camel Case, Upper Case, Lower Case, Ungarische Notation)
  • Coding Style (Schreibweise von Bezeichnern, Anweisungen, Einrückungstiefe, maximale Zeilenlänge, Umbrüche/Leerzeichen, Deklarationsschemata, Dateiorganisation und -namen, Programmierpraktiken)
  • Sprachkonventionen (MISRA-C)
  • Regeln für natürlichsprachliche Spezifikationen

10. Manuelle Prüfmethoden

• Diagnostische Verfahren zur Ermittlung des Qualitätsniveaus.
• Ziele: Feststellung von Mängeln, Fehlern, Inkonsistenzen, Unvollständigkeiten, Verstößen gegen Vorgaben, formale Abnahme.
• Voraussetzungen: Aufwand und Zeit müssen eingeplant sein, Schulung der Prüfer, keine Beurteilung von Mitarbeitern, Dokumentation der Prüfmethode.
• Methoden:
  1. Durchsicht (Entwickler alleine)
  2. Stellungnahme (Autor gibt Artefakt an Dritte weiter)
  3. Review (Formalisierter Prozess)
     • Rollen: Moderator, Autor, Gutachter, Notar, Review-Team.
     • Ablauf: Antrag, Planung, Festlegung der Aspekte, Auswahl der Prüfer, Eingangsprüfung, Verteilung des Prüfobjekts, Vorbereitung, Review-Sitzung, Entscheidung über Nacharbeit, Durchführung der Nacharbeiten, erneutes Review.
     • Review-Regeln: Sitzungsdauer, Fokus auf Resultat, Rollenverteilung, keine Stilfragen, keine Lösungsentwicklung, angemessene Präsentation der Befunde, Protokollierung.
     • Gewichtung der Befunde: Kritischer Fehler, Hauptfehler, Nebenfehler, Gut.
     • Empfehlungen: Akzeptieren ohne Änderung, Akzeptieren mit Änderung, Nicht akzeptieren.
  4. Structured Walkthrough (Einfachere Variante des Review)

11. Programmtest (Dynamische Prüfung)

• Ziel: Finden möglichst vieler Fehler.
• Vorgehen: Ausführung des Programms mit konkreten Werten, Vergleich der Ausgaben (Ist-Werte) mit den Soll-Werten.
• Systematischer Test: Randbedingungen definiert, Eingaben systematisch ausgewählt, Soll-Werte festgelegt, Testverlauf dokumentiert, Test und Korrektur getrennt.
• Teststufen:
  • Unit-Test (Modultest, Komponententest): Test von Programmteilen (Funktionen/Methoden, Klassen, Komponenten).
  • Integrationstest: Test des Zusammenspiels der integrierten Module/Komponenten.
    • Ablauf: Big-Bang-Integration, Inkrementelle Integration (Top-down, Bottom-up, Outside-In, Kontinuierliche Integration).
  • Systemtest: Test des komplett integrierten Systems aus Anwendersicht.
  • Abnahmetest: Letzter Test vor der Inbetriebnahme, Abnahmekriterien im Entwicklungsvertrag.
• Grenzen von Programmtests: Vollständiger Test in der Praxis nicht möglich.
• Testfall: Ausgangssituation, Testdaten, Sollwerte.
• Eigenschaften eines guten Testfalls: Fehlersensitiv, repräsentativ, redundanzarm.

12. Black-Box-Test (Funktionstest)

• Testfälle auf Basis der Spezifikation.
• Verfahren zur Bestimmung von Testfällen:
  1. Funktionale Äquivalenzklassenbildung: Aufteilung der Eingaben in Äquivalenzklassen, Test eines Repräsentanten pro Klasse.
  2. Grenzwertanalyse: Test von Elementen an den Grenzen von Äquivalenzklassen.
  3. Zustandsbezogener Test: Modellierung des Systems mit Zustandsautomaten, Test aller Zustände und Zustandsübergänge.
  4. Test spezieller Werte: Test mit Eingaben, die häufig Fehler aufdecken.
  5. Zufallstest: Zufällige Generierung von Testfällen.
• Property-based Testing: Prüfung, ob ein Prädikat erfüllt ist: \forall x.P(x, f_{SUT}(x)).

13. Testautomatisierung

• Wiederholung von Tests (Fehlernachtest, Regressionstests) erfordert Testautomation.
• JUnit-Framework: Unterstützung bei der Erstellung und Durchführung von Programmtests.
• JUnit 5: Testplattform (Platform, Jupiter, Vintage, Extensions).
• JUnit 5 - Testklasse:
  • Testmethoden werden durch die Annotation @Test ausgezeichnet.
  • Vor der Ausführung jeder Testmethode wird eine neue Instanz der Testklasse erzeugt.
  • Umfangreichere Initialisierungen können in eine mit @BeforeEach annotierte Methode ausgelagert werden.
  • Die Freigabe von Ressourcen kann dann in einer mit @AfterEach annotierten Methode erfolgen.
• Wichtige JUnit 5-Annotationen: @Test, @BeforeEach, @AfterEach, @BeforeAll, @AfterAll, @DisplayName("").
• Assert-Methoden: assertEquals(), assertSame(), assertTrue(), assertNotNull().
• Erwartete Ausnahmen: Test mit assertThrows().
• Test-Suite: Zusammenfassung von Testfällen (mit @Test annotierte Methoden) einer Testklasse.
• Parametrisierte Testmethoden: Mehrfacher Aufruf einer Testmethode mit unterschiedlichen Parametern.
• Testbarkeit:
  • Dependency Injection (DI): Assoziationen zu anderen Objekten werden von außen injiziert.
  • Stubs vs Mocks:
    • Stubs: Entkopplung der zu testenden Einheiten von der Umgebung, Simulation der Fachlogik, Zustandstest.
    • Mocks: Entkopplung, Kontrolle der Anzahl und Abfolge der Methodenaufrufe, keine/begrenzte Simulation der Fachlogik, Verhaltenstest.
• EasyMock-Framework: Generierung von Mock-Objekten aus Interfaces zur Testlaufzeit.

14. Build-Automatisierung

• Automatisierung des Build-Prozesses.
• Build-Tools: make, Ant, Maven.
• make: Bedingungsgesteuerte Ausführung von Shell-Skript-Kommandos.
• Ant: Plattformunabhängigkeit, Konfigurationsdatei build.xml im XML-Format.
• Maven: Deklarativer Ansatz, Standardisierung, Management von Abhängigkeiten, Erweiterungen über Plug-ins.
  • Konfigurationsdatei pom.xml (Project Object Model).
  • Maven-Verzeichnisstruktur.
  • Management von Abhängigkeiten (groupId, artifactId, version, type).
  • Life Cycle und Phasen (Default, Clean, Site).
  • Projektvorlagen (Archetypes).
  • Grundeinstellungen (Compiler-Plugin, Surefire-Plugin).
  • Reports für die Qualitätssicherung (Javadoc, Surefire-Report, Project-Info).

15. Glass-Box-Test (White-Box-Test) / Strukturtest

• Überdeckung des Codes durch die Testfälle analysiert.
• Kontrollflussgraph: Anweisungen als Knoten, Kontrollfluss als Kanten.
• Überdeckungskriterien:
  1. Anweisungsüberdeckung (statement coverage) / C0-Test: Jede Anweisung im Programm muss im Test mindestens einmal ausgeführt werden.gg im Programm wird im Test mindestens einmal ausgeführt.
  2. Bedingungsüberdeckung: Überprüfung der Bedingungen im Test.
     • Einfache Bedingungsüberdeckung: Alle atomaren Teilbedingungen müssen während des Tests einmal true und einmal false ergeben.
     • Mehrfach-Bedingungsüberdeckung: Alle Variationen der Belegung der atomaren Teilbedingungen werden getestet.
     • Minimale-Mehrfach-Bedingungsüberdeckung: Jede Teilbedingung muss mindestens einmal true und einmal false sein.
  3. Datenflussbasierte Überdeckung (Defs-Uses-Überdeckung): Verwendung von Variablen wird analysiert.
     • Definition (def) einer Variablen / Wertzuweisung.
     • Verwendung einer Variablen in einem Ausdruck zur Berechnung eines Wertes (berechnende Benutzung, computational-use, c-use).
     • Verwendung einer Variablen in Bedingungen bzw. Prädikaten zur Berechnung von Wahrheitswerten (prädikative Benutzung, predicate-use, p-use).
     • All Definitions (All-defs): Die Testfälle durchlaufen für jede Definition einer Variablen einen definitionsfreien Pfad zu mindestens einem p-use oder c-use.
     • All c-uses: Die Testfälle durchlaufen für jede Definition einer Variablen einen Pfad zu allen definitionsfrei erreichbaren c-uses.
     • All p-uses: Die Testfälle durchlaufen für jede Definition einer Variablen einen Pfad zu allen definitionsfrei erreichbaren p-uses.
     • All uses: Die Testfälle durchlaufen für jede Definition einer Variablen einen Pfad zu allen definitionsfrei erreichbaren p- und c-uses.
     • All c, some p: Die Testfälle erfüllen das All-c-uses-Kriterium. Existiert zu einer Definition keine berechnende Nutzung, so wird zusätzlich mindestens ein definitionsfreier Pfad zu einer prädikativen Nutzung hinzugenommen.
     • All p, some c: Analog zu All-c-some-p-Kriterium mit vertauschten Rollen.

16. Test objektorientierter Programme

• Berücksichtigung zusätzlicher Eigenschaften: Zustand des Objekts, Objekte als Parameter und Rückgabewerte, Vererbung, Assoziationen, Polymorphismus.
• Arten von Klassen: Normale Klassen, abstrakte Klassen und Schnittstellen, parametrisierte (generische) Klassen, Unterklassen.
• Testen normaler Klassen: Test zustandsverändernder Methoden, Test des Objektlebenszyklus.
• Testen von Unterklassen: Systematischer Test aller Methoden der Oberklasse und der Unterklassen.
• Testen abstrakter Klassen: Test einer möglichst einfachen Unterklasse, die die abstrakte Klasse implementiert.
• Testen nicht sichtbarer Bestandteile: Test privater Methoden und Attribute über die öffentliche Schnittstelle, Lockerung der Sichtbarkeit auf Paketebene, Extra Testzugang, Zugriff über Reflection.

17. Statische Prüfung / Metriken

• Finden von Fehlern oder fehlerträchtigen Stellen in einem Dokument durch Werkzeuge.
• Beispiele: Rechtschreib- und Grammatikprüfung, UML-Syntaxprüfung, Syntaxanalyse, Konformitäts-/Konventionsanalyse, Prüfung auf Kontrollfluss- und Datenflussanomalien.
• Softwaremetriken: Quantitative Bewertung von Software-Systemen mit Hilfe von Kenngrößen.
• Unterteilung: Quantitätsmetriken, Komplexitätsmetriken, Qualitätsmetriken.
• Objekte der Softwaremessung: Anforderungsdokumentation/Spezifikation, Entwurfsdokumentation, Code, Testware, Benutzerhandbücher.
• Sichten auf die Objekte: Sicht der Typen, Sicht des Zwecks, Sicht des Anwenders.
• Quantitätsmetriken: Entwurfsgrößen, Codegrößen.
• Codekomplexität:
  • Halstead-Metriken:
    • Operatoren: Schlüsselwörter, Operatoren, Präprozessoranweisungen.
    • Operanden: Variablen, Konstanten, Bezeichner.
    • Basisparameter: t (Anzahl der unterschiedlichen Operatoren), d (Anzahl der unterschiedlichen Operanden), nt (Gesamtzahl aller Operatoren im Programm), nd (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
  • McCabe-Metrik:
    • Kontrollflussgraph.
    • Zyklomatische Komplexität: V(G) = |E| - |N| + 2
• Objektorientierte Metriken: OV (Object Variables), CV (Class Variables), NOA (Number of Attributes), WAC (Weighted Attribute per Class), WMC (Weighted Method per Class), DOI (Depth Of Inheritance), NOD (Number of Descandants), NORM (Number of Redefined Methods).
• Konformitäts-/Konventionsanalyse: Prüfung auf Einhaltung von Codierungsrichtlinien.
• Datenflussanomalieanalyse: Prüfung auf unstimmige Variablenzugriffe.
• Statische Analyse mit Werkzeugen: PMD, Checkstyle, CodePro Audit/Metrik.

18. Build-Automatisierung / CI

• Kontinuierliche Integration (CI): Häufige Integration neuer Artefakte/Komponenten durch einen vollautomatischen Build-Prozess.
• Ziele: Reduzierung von Risiken, Verbesserung der Produktqualität, Transparenz/Übersicht.
• CI-Server: Laufzeitumgebung zur Durchführung des kompletten Integrationsprozesses.
• Build-Prozess: Vorbereitende Maßnahmen, Übersetzen, Statische Prüfungen, Dynamische Prüfungen, Paketierung, Erzeugung von Berichten und Dokumentation, Bereitstellung/Verteilung.
• CI-Praktiken: Gemeinsame Codebasis im SCM, Automatisierte Builds, Automatisierte Durchführung von dynamischen und statischen Prüfungen, Automatisches Berichtswesen, Häufige Integration, Schnelle Build-Zyklen, Einfacher Zugriff auf Build-Ergebnisse und Berichte, Automatische Verteilung.

19. Konfigurationsmanagement

• Aktive Verwaltung eines sich ändernden Softwaresystems mit Hilfe von Richtlinien, Prozessen und Werkzeugen.
• Bereiche: Änderungs-Management, Versions-Management, Build-Management, Release-Management.

20. Wartung

• Arbeit an einem bestehenden Software-System, die nicht von Beginn der Entwicklung an geplant war.
• Arten der Wartung: Adaptive Wartung (Anpassung), Korrektive Wartung (Korrektur).
• Systematisches Vorgehen: Dokumentation des Ausgangszustands, Identifizierung des zu modifizierenden Teils, Testfälle, Entnahme, Bearbeitung und lokale Prüfung der Komponenten, Integration und Test, Dokumentation des neuen Zustands, Erfassung des Aufwands.
• Change Management: Verwaltung von Änderungen mit Hilfe von Problemmeldungen (Software Problem Report, SPR) und Änderungsanträgen (Change Request, CR).
• Logging: Erzeugung von Kontrollausgaben zur Erleichterung der Wartung.
  • Log-Level: DEBUG, INFO, WARN, ERROR, FATAL.
  • Logging-Frameworks: log4j.

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: S.223 Kontrollflussgraph:

• Ein Glass-Box-Test orientiert sich am Kontrollflussgraphen einer Code- Sequenz
• Anweisungen werden im Kontrollflussgraphen als Knoten dargestellt
• Der Kontrollfluss zwischen den Anweisungen wird über die Kanten repräsentiert

Überdeckung

1. Anweisungsüberdeckung (statement coverage) / C0-Test
   • Jede Anweisung im Programm muss im Test mindestens einmal ausgeführt werden (100% Anweisungsüberdeckung)
2. Zweigüberdeckung (Entscheidungsüberdeckung) / C1-Test
   • Jeder Zweig im Programm wird im Test mindestens einmal ausgeführt (100% Zweigüberdeckung)
   • Die Zweigüberdeckung ist strenger, als die Anweisungsüberdeckung, wenn das Programm leere Zweige enthält (z.B. if-then ohne else- Zweig)
3. Bedingungsüberdeckung
   • Die Zweigüberdeckung stellt sicher, dass eine logische Bedingung während des Tests mindestens einmal true und einmal false ist
   • Wenn die Bedingung zusammengesetzt ist, wird damit aber nicht sichergestellt, dass die Teilbedingungen korrekt formuliert sind
   • Eine Bedingung ist eine Verknüpfung von Teilbedingungen mit den logischen Operatoren AND, OR und NOT
   • Eine (atomare) Teilbedingung enthält keine logischen Operatoren, sondern höchstens Relationssymbole (<,>,==)
   • Mehr: S.230f.
4. Datenflussbasierte Überdeckung (Defs-Uses-Überdeckung
   • S. 233f.

Metriken: S.258f.

• Unterteilung von Software-Metriken
  • Quantitätsmetriken
  • Komplexitätsmetriken
  • Qualitätsmetriken
• Halstead
  • S.264f.
  • Größe des Vokabulars: G = t + d
  • Länge des Programms: N = nt + nd
  • Volumen des Programms: V = N x log2 G
  • Eine untere Schranke für die Operanden ist die Anzahl der Ein- und Ausgabeoperanden: d*
  • Größe des Minimalvokabulars: G* = d* + 2
  • V* = G* x log2 G*
  • L = V* / V
  • D = 1 / L
  • E = V x D
  • E = V x D = V / L = V / (V* / V) = V2 / V*
• McCabe-Metrik
  • V(G) = |E| - |N| + 2
    • Kontrollflussgraph
  • V(G) = |E| - |N| + 1
    • stark zusammenhängender Graph
  • !