Softwarequalitätssicherung

Beim anforderungsbasierten Test wird getestet, ob alle spezifizierten Funktionen vorhanden und ausführbar sind, d.h. es wird jede Funktion durch einen Testfall erreicht. Die Testfälle sind auf das Normalverhalten des Testobjekts ausgerichtet.

=> Kein Test unerwarteter Eingaben!

Beim anwendungsfallorientierten Test wird getestet, ob alle Use Cases implementiert sind (System- und Abnahmetest). Da das Zusammenwirken unterschiedlicher Komponenten betrachtet wird, können auch Fehler entdeckt werden, die beim Integrationstest entgangen sind.

Der strukturorientierte Test ist eine Ergänzung zum funktionsorientierten Test mit dem Ziel der Abdeckung des Kontrollflusses in einem Programm. Die Testfälle werden folglich aus dem Kontrollfluss des Programms abgeleitet.

• Modultest
  • Testfallableitung zur Anweisungs-, Zweig- bzw. Pfadüberdeckung
  • Testfallableitung nach Datenflusskritierien
• Integrationstest
  • Testfallableitung aus der Aufrufhierarchie

1. Anweisungstest:

• Testziel:
  • mindestens einmal alle Anweisungen ausführen, d.h. Abdeckung aller Knoten im Graph
  • C = Anzahl der ausgeführten Anweisungen / Anzahl der Anweisungen
• Vorteile:
  • findet toten, d.h. nicht erreichbaren Code
• Nachteile:
  • übersieht Fehler in Bedingungen (schwacher Test)

2. Zweigüberdeckungstest:

• Testziel:
  • Ausführung, d.h. Abdeckung aller Zweige im Graph
  • C = (Anzahl ausgeführter Zweige / Anzahl Zweige) = 100 %
• Vorteile:
  • erkennt besonders oft durchlaufende Zweige, die ggf. optimiert werden
• Nachteile:
  • komplexe Beindungen sind nicht ausreichend getestet

3. Pfadüberdeckungstest:

• Testziel:
  • mindestens einmal alle Pfade in einem Graphen durchlaufen
  • C = (Anzahl durchlaufener Pfade / Anzahl der Pfade) = 100 %
• Vorteile:
  • höchste Fehlerfindungsrate
• Nachteile:
  • hoher Aufwand => hohe Überdeckung nicht erreichbar

Beim Boundary-Interior Test werden Grenzen und Innenleben von Schleifen untersucht. Man geht dabei davon aus, dass die meisten Fehler bereits nach wenigen Interationen entdeckt werden, d.h. es wird nach einem Testkritierium mit vertretbarem Aufwand gesucht. Hierzu werden drei Äquivalenzklassen gebildet:

1. Test führt zu keiner Schleifenausführung
   => nur bei abweisenden Schleifen
2. Test führt genau zu einer Schleifenausführung
   => boundary test
3. Test führt mindestens zu zwei Schleifenausführungen
   => interior test (k=2 Pfaddurchläufe)

=> Alternative Pfade in Schleifen beachten!

Vorteile:

• 2 mal höhere Fehlererkennungsrate als bei einer einmaligen Zweigüberdeckung

Bedingungsüberdeckung:

Testziel:

• logische Struktur komplexer, zusammengesetzter Entscheidungen testen durch
  • minimale, einfache Bedingungsüberdeckung (C2-Test)
  • mehrfache Bedingungsüberdeckung (C3-Test)
• oder durch abgewandelte Verfahren (starker C2-Test, schacher C3-Test)

1. Kriterium zur mininmalen Beindungsüberdeckung (C2-Test)

=> in einem Programmabschnitt wird jeder Term (atomare Beindung) innerhalb einer komplexen Bedingunsanweisung mindestens einmal gegen wahr und falsch geprüft.

=> relativ geringer Aufwand

=> Zweigüberdeckung ist nicht sicher

2. Kriterium zur mehrfachen Bedingungsabdeckung (C3-Test)

=> alle Kombinationen atomarer Bedingungen werden getestet, d.h. 2^n Testfälle bei n atomaren Bedingungen

=> gesicherte Zweigüberdeckung

=> hoher Aufwand

3. Kriterium für minimalen Mehrfach-Bedingungstest (Schwacher C3-Test)

=> alle atomaren Bedingungen gegen wahr und falsch testen und alle zusammengesetzten Bedingungen gegen wahr und falsch testen

=> Aufwand geringer

=> Operatorfehler können sich aufheben und der Fehler wird nicht erkannt

4. Kriterium für Bedingungs-Entschiedungs-Testabdeckung (Starker C2-Test)

=> alle atomaren Bedingungen gegen wahr und falsch testen und zeigen, dass jede atomare Bedingung in der Lage ist, die Gesamtentscheidung zu beeinflussen

=> Zweigüberdeckung, relativ geringer Aufwand

=> höherer Aufwand, um die richtigen Testfälle zu finden

Das Aufstellen und Nutzen von Metriken in der Softwareentwicklung verfolgt im Wesentlichen zwei Ziele:

1. Objektiver Vergleich von Eigenschaften von Softwareprodukten
2. Quantitative Bewertung von Entwicklungsprozessen für Software

=> Problem: geeignete Metriken zu finden

Maß: Ein Maß ist ein Messwert, der einem Objekt der realen Welt zugeordnet wird.

Metrik: Eine Metrik ist eine Aussage zum Vergleich von Messwerten bei zwei Objekten aus der realen Welt. Eine Metrik gibt also die Differenz zweier Maße an.

Prozess- und Projektmetriken:

• zur faktenbasierten Entscheidung zur Prozessverbesserung
• für Prognosen zum Projektverlauf
• für Aussagen zur Produktivität

=> Produktivitätsmetriken, Kostenmetriken

Produktmetriken:

• zum Qualitätsnachweis durch erreichte, vorgebene Maße in Projekten
• zur Vergleichbarkeit mit Konkurrenzprodukten

=> Fehlermetriken

Subjektive Metriken:

• qualitativ intuitive Statements
• Interpretation erfolgt erfahrungsbasiert
  • z.B. Maß der Kundenzufriedenheit
  • z.B. Pseudometriken (basieren auf Schätzungen)
  • z.B. Produktivität der Mitarbeiter auf Basis LOC/h

Objektive Metriken:

• quantitativ, gemessene Maße
• Interpretationsverfahren können definiert werden
  • z.B. Programmgröße
  • z.B. Ausfallrate

Auswahl einer Metrik:

1. Was soll gemessen werden?
   • Produkt
   • Prozess
   • Projekt
2. Wie soll gemessen werden?
   • Verfahren
   • Werkzeuge
   • Ressourcen

=> Aufwand gegen Nutzen abschätzen

Gütekritierien von Metriken:

1. Objektivität
   => Prüfer kann keinen Einfluss nehmen
2. Validität (Tauglichkeit)
   => eindeutiger Rückschluss auf die Qualitätseigenschaft
3. Normierbarkeit
   => es existiert eine Vergleichbarkeitsskala
4. Wirtschaftlichkeit
   => Messung ist mit relativ niedrigem Aufwand möglich
5. Nützlichkeit
   => Aussage kann praktisch genutzt werden

1. Kostenmetriken, Produktivitätsmetriken
   => Aussagen über Kosten, Personal, Entwicklungszeit
2. Fehler- und Testmetriken
   => Aussagen über gefundene bzw. erwartete Fehler
   => Testüberdeckungsmaße
3. Volumenmetriken
   => Aussagen zur Größe einer Software
4. Qualitätsmetriken
   => Aussagen über ein SW-Qualitätsmerkmal

Lines of Code (LOC)

• einfachste Metrik zur Berechnung der Programmkomplexität (Programmgröße)
• einfaches Aufsummieren der Quellcodezeilen

=> Abschätzung des Aufwands und der Produktivität

Non Comment Source Statements (NCSS)

• LOC ohne Kommentare
• Abschätzung des Dokumentationsgrades NCSS/LOC

Probleme:

• mangelnde Vergleichbarkeit bei Verwendung unterschiedlicher Programmiersprachen
  => Korrektur mit Sprachfaktor SLOC
• Programmierstil kann hohe Leistung vortäuschen

Praxisbedeutung:

• Metrik geht in komplexere Metriken ein, z.B. zur Aufwandsschätzung
• einfach zu ermitteln, daher weit verbreitet

These: Programmkomplexität ist abhängig von der Anazahl der Operatoren und Operanden im Programmtext.

Operatoren: alle Schlüsselwörter, vordefinierte Operatoren, Prä-Prozessoranweisungen, etc.

Operanden: Bezeichner für Variablen und Konstanten

Durch Programmtextanalyse werden ermittelt:

• n1: Anzahl der verschiedenen Operatoren
• n2: Anzahl der verschienen Operanden
• N1: Gesamtanzahl der verwendeten Operatoren
• N2: Gesamtanzahl der verwendeten Operanden

=> n = n1 + n2 (Größe des Vokabulars)
=> N = N1 + N2 (Länge des Programms)

Metrik für Programmvolumen:

V = N log2 n (Anzahl der Bits auf Binärebene)

Metrik für das erwartete Fehleraufkommen:

Im Mittel tritt nach ca. 3000 Elementaroperationen im Gehirn ein Programmierfehler auf

β = V/3000

Metrik für Programmieraufwand, Schwierigkeit:

difficulty = D = (n1*N2)/(2*n2)
=> Maß zur Bewertung von Programmiersprachen

effort = E = D*V
=> Maß zum Aufwand der Programmierung und des Programmverstehens

Qualitätsmerkmal: Wartbarkeit

Strukturkomplexität: je mehr Pfade desto schwerer verständlich

Datenkomplexität: je mehr Daten und je größer die Entfernung ihrer Referenzierung desto schwerer verständlich und desto mehr fehleranfällig

Das Produkt-Qualitätsmodell enthält Anforderungen zur Qualitätsbewertung von (Software-)Produkten. Diese beziehen sich auf eine Menge von Eigenschaften (Merkmale) und deren Ausprägung (Kenngrößen).

Die Produkt-Qualitätsmerkmale sind somit wesentlicher Bestandteil der Produkt-Spezifikation und ist eine Basis für die Produkt-Abnahme.

Folgende Produkt-Qualitätsmerkmalse sind nach DIN definiert:

1. Funktionalität:
2. Effizienz:
3. Zuverlässigkeit:
4. Benutzbarkeit:
5. Übertragbarkeit:
6. Wartbarkeit:

• Umfang:
  Menge der angebotenen Funktionen entsprechend der Spezifikation
• Korrektheit:
  Erzeugen korrekter Ergebnisse
• Verträglichkeit:
  Arbeit mit anderen Systemen und Komponenten

Probleme:

• Software ist immer fehlerhaft, d.h. absolute Reife wird bei neuer Software nicht erwartet
• Korrektheit von Software kann nie endgültig nachgewiesen werden!

• Zeitverhalten (Zeitdauer für das Ergebnis)
• Betriebsmittel (Prozessorauslasung, Speicherbedarf, Übertragungskapazität)

Beispiele:

• Speicherbedarf für den Programmcode
• Antwortzeiten auf Reaktionen aus der Umgebung

• Reife:
  Wahrscheinlichkeit für korrekte Arbeit bei Normalbedingungen
• Robustheit:
  Wahrscheinlichkeit für korrekte Arbeit unter fehlerhaften Bedingungen
• Wiederanlauf:
  Aufwand und Zeitbedarf
• Integrität:
  Sicherheit, Reaktion auf Verfälschungen oder Verlust von Daten

Beispiele:

• Anzahl der Ausfälle pro Zeitraum im Betrieb
• Testabdeckungsgrad

• Verständlichkeit:
  Aufwand zum Verstehen des funktionalen Konzepts
• Handhabbarkeit:
  Aufwand für die Steuerung des Ablaufs
• Erlernbarkeit:
  Aufwand zum Erlenen der Bedienung

• Installierbarkeit:
  Aufwand auf einer definierten Umgebung
• Anpassbarkeit:
  Aufwand für andere Umgebungen
• Schnittstellen-Verträglichkeit:
  Einhaltung einschlägiger Normen

• Änderbarkeit (Aufwand für definierte Änderungen)
• Transparenz (Klarheit, Aufwand für das Verstehen)
• Stabilität (Risiko unerwünschter Nebeneffekte)
• Testbarkeit (Aufwand für den Test von Änderungen)

=> Die Wartbarkeit kann dadurch verbessert werden, indem im Entwurf so wenig wie möglich Relationen zwischen den Komponenten definiert werden.

1. Führungsebene erkennt die Notwendigkeit:
   • zur Senkung der Softwarewartungskosten und Reklamationen
   • zur Erhöhung von Produktivität und Qualität
2. Akzeptanz durch Mitarbeiter:
   • realistische Aktionspläne
   • realistische Situationseinschätzung
   • Ermittlung von Kompetenz und Schulungsbedarf
3. Technische Unterstützung:
   • geeignete neue Technologien und Werkzeuge (Achtung: Mitarbeiterakzeptanz beachten!)
4. Qualitätssicherung:
   • Einführung eines Qualitätsmanagementsystems
   • Beachtung qualitätssichernder Führung
     => TQM-Prinzipien beachten!

TQM ist eine auf der Mitwirkung aller Mitarbeiter beruhende Führungsmethode, die die Qualität in den Mittelpunkt stellt und durch Zufriedenheit der Kunden auf den langfristigen Geschäftserfolg sowie den Nutzen für die Mitglieder der Organisation zielt.

1. Prinzip der Kundenorientierung:

• Einbeziehung der Kunden bei der Abnahme von Zwischenprodukten zwecks Nachbesserung
• SW-Entwickler verstehen, unter welchen Bedingungen der Kunde die Software einsetzen möchte

=> Kundenverantwortung erhöhen

2. Prinzip der Prozessorientierung:

• Fehlervermeidung durch evolutionäre Prozessverbesserung
• faktenbegründete Entscheidungen

=> Prozessmetriken etablieren

3. Prinzip der Mitarbeiterverantwortung:

• SW-Entwickler prüfen auch die Kundenanforderungen und kennen den Einfluss der eigenen Leistungen
• Entwickler werden in Entscheidungen miteinbezogen

=> Motivation und Verantwortung der Mitarbeiter steigern

Faktoren zur Wertermittlung:

1. Quantität (LOC, Funktionsumfang)
2. Kundenbedürfnis und Kundenzufriedenheit
3. Qualität (Übereinstimmung mit dem Qualitätsmodell)

Faktoren zur Kostenermittlung:

1. Personalkosten
2. Investive und laufende Kosten (z.B. Werkzeuge oder Schulungen)
3. Qualitätskosten (Fehlervermeidung,Fehlerfindung, Fehlerbehebung, Gewährleistung, Nachbesserungen)

Schlechte Qualität erhöht die Kosten für die Fehlererkennung und Fehlerbeseitigung, d.h. das Vermeiden von Fehlern erhöht die Produktivität und führt mittelfristig zur Kostensenkung!

1. Produktabhängige Faktoren:

• Stabilität der Produktanforderungen
• Möglichkeit zur Wiederverwendung
• Komplexität, Schwierigkeit der Aufgabenstellung

2. Personenabhängige Faktoren:

• physiche und psychische Arbeitsumgebung
• Fähigkeiten, Erfahrungen, Ausbildungsstand
• Einstellung und Haltung zur Arbeit

3. Prozessabhängige Faktoren:

• Vorgehensmodell und Werkzeuge

1. Leistungserhöhung der Mitarbeiter:

• Qualifikation
• Führung und Motivation

2. Effizienzerhöhung der Arbeitsschritte:

• Softwarewerkzeuge
• Produktionsumgebungen

3. Vermeidung von Überarbeitungsschritten:

• Unterstützung früher Phasen
• Prototyping

4. Produktvereinfachung:

• Produktmodelle

5. Wiederverwendung:

• Abstrakte Klassen
• Module
• Komponenten

Qualitätssicherung ist die Gesamtheit aller notwendigen Maßnahmen, um die Anforderungen an ein Entwicklungsprozess bzw. ein Software-Produkt zu erreichen.