Software Engineering 1 WS 2012/2013 - TU Braunschweig · Pareto-Prinzip Fenton/Ohlsson 2000 und andere empirische Untersuchungen: • 20 % der Module sind verantwortlich für 60 %

Prof. Dr. Ina Schaefer

Institut für Softwaretechnik und Fahrzeuginformatik

Technische Universität Braunschweig

(Folien von Prof. B. Rumpe und Dr. A. Herrmann)

Qualitätsmanagement

Software Engineering 1

WS 2012/2013

Prof. Dr. Ina Schaefer Software Engineering 1 Seite 2

Qualität: Gesamtheit von Eigenschaften und Merkmalen eines

Produkts oder einer Tätigkeit, die sich auf deren Eignung zur

Erfüllung gegebener Erfordernisse bezieht [DIN 55350, Teil 11]

Achtung: bezieht sich auf Produkt und Prozess.

Achtung: Qualitäts-Anforderungen ändern sich mit der Zeit!

Achtung: Qualität muss gegenüber Kosten und Zeit abgewogen

werden

Was ist Qualität?


Funktionalität

• Angemessenheit

• Sicherheit

• Genauigkeit der Berechnung

• Interoperabilität

• Konformanz zu Standards

Zuverlässigkeit

• Reife

• Fehlertoleranz

• Wiederherstellbarkeit

Benutzbarkeit

• Verständlichkeit

• Erlernbarkeit

• Bedienbarkeit

Effizienz

• Zeitverhalten

• Verbrauchsverhalten

Änderbarkeit

• Analysierbarkeit

• Modifizierbarkeit

• Stabilität

• Prüfbarkeit

Übertragbarkeit

• Anpassbarkeit

• Installierbarkeit

• Konformanz zu Standards

• Austauschbarkeit

Qualität nach ISO9216


Benutzer-

erwartungen

Anforderungsdokument Code .....

Verifikation: haben wir es richtig gemacht?

Validierung: haben wir das Richtige gemacht?

Verifikation & Validierung


Übersicht

• Konstruktive Qualitätssicherung

• Qualität von Prozessen

• Reifegradmodelle

• Analytische Qualitätssicherung

• Statische Tests (Reviews)

• Dynamische Tests

• Begriffe und Grundsätze

• Testprozess

• Testmethoden

• Testarten (Unit-, Integrations-, System-, Akzeptanztest)


Produktqualität und Prozessqualität

Software:

• Kaum Qualitätsmängel durch Massenproduktion

• Qualitätsmängel im Herstellungsprozess begründet

Qualitätsmanagement:

• Organisatorische Maßnahmen zur Prüfung und Verbesserung der Prozessqualität

• Beachtung von internen Kunden-/Lieferantenbeziehungen

Konstruktive Qualitätssicherung: Qualität des Prozesses

Analytische Qualitätssicherung: Qualität des Produkts


ISO 9000

Internationales Normenwerk

• ISO 9000: Allgemeiner Leitfaden

• ISO 9000-3: Leitfaden zur Anwendung von ISO 9001 auf Software

• ISO 9001: Modelle zur Darlegung der Qualitätssicherung

insbesondere in Entwurf und Entwicklung

Allgemeingültige Forderungen an die Organisation eines

Unternehmens:

• Regelung von Zuständigkeiten

• Erstellung und korrekte Verwaltung wesentlicher Dokumente

• Existenz eines unabhängigen Qualitätssicherungs-Systems

Zertifizierung:

• durch unabhängige (zertifizierte) Prüforganisationen

• Audit, Prüfsiegel

ISO 9000 prüft nicht die Qualität des Produkts, sondern die Qualität

der Organisation !


Reifegradmodelle: Ziele und Nutzen

messen Reife des gesamten Software-Entwicklungsprozesses

entdecken Schwachstellen und Verbesserungspotenzial

schlagen Maßnahmen zur Qualitätsverbesserung vor

messen die Wirkung dieser Maßnahmen

helfen bei Bewertung von Lieferanten bei Auftragsvergabe


Reifegradmodelle: Beispiele

CMM

CMMI (Weiterentwicklung von CMM, quasi V2.0)

BOOTSTRAP (Erweiterung und Anpassung von CMM für

Europa)

SPICE/ ISO 15504 (Weiterentwicklung von Bootstrap)

DIN ISO 9000

TQM = Total Quality Management


Capability Maturity Model (CMM)

Entwickelt 1987 von Software Engineering Institute (SEI), Vorläufer Mutter vieler späterer Modelle

1991 CMM Version 1.0, 1993 CMM V1.1

2003 CMMI = Capability Maturity Model Integrated, löst CMM ab

Fragebögen mit ja/nein-Fragen

5 Reifegrad-Stufen

Um Stufe x+1 zu erreichen, müssen alle Bedingungen von Stufe x erfüllt sein.


Capability Maturity Model (CMM)

Stufe 1: Initialer Prozess

Stufe1: Initial

Stufe 2: Wiederholbar

Stufe 3: Definiert

Stufe 4: Gesteuert

Stufe 5: Optimierend

Kosten, Zeit, Qualität unvorhersehbar

Terminkontrolle, aber Kosten und Qualität

schwanken

Kosten und Termine zuverlässig, aber

Qualität schwankend

Kontrolle über Produktqualität

Kontrolle über Prozessqualität


5 Stufen in CMMI

1. Ad hoc (Initial)

• Keine formelle Planung und Kontrolle

• Kein oder schlechtes Konfigurationsmanagement

2. Wiederholbar (Repeatable)

• Etabliertes Projektmanagement

• Abwicklung von Standardprojekten wird beherrscht.

• bei neuartigen Projekten größere Risiken

• Prozess ist abhängig von den Personen, die ihn durchführen.

• Keine etablierten Maßnahmen zur Verbesserung des Prozesses

3. Definiert (Defined)

• Der Prozess ist klar definiert und läuft definitionsgemäß ab.

• Es existiert eine Gruppe mit der Aufgabe, den Software Engineering Prozess zu lenken und zu verbessern.


4. Geführt (Managed)

• Eine Mindestmenge an Qualitäts- und Produktivitätsmessgrößen wird erhoben und ausgewertet.

• Es gibt eine Datenbank, in der alle relevanten Daten über den Prozess abgelegt werden und Mittel zur Pflege und Auswertung dieser Daten.

5. Optimierend (Optimizing)

• Etablierter Regelkreis für Messung und Verbesserung des Prozesses

• Datenerhebung und Erkennung von Schwachstellen weitgehend automatisiert.

• Durchgeführte Maßnahmen aus dem erhobenen Datenmaterial begründet.

• Etablierte Ursachenanalyse für alle Fehler und zugehörige Fehlerpräventionsmaßnahmen.

5 Stufen in CMMI (2)


Analytische Qualitätssicherung

Ziel: Überprüfen, ob Produkt die Aufgabenspezifikation erfüllt

Prüfmethoden:

• Beweis (mathematischer Nachweis, nur bei einfachen

Programmen händisch möglich, ansonsten komplexe Beweis-

Werkzeuge)

• Test (Ausprobieren für eine sorgfältig ausgewählte Menge von

Eingaben)

• Inspektion (systematisches Durchlesen)

• Metriken (automatische Bestimmung von Charakteristika)


Statische und Dynamische Tests

Statische Tests: Überprüfung nicht-ausführbarer Entwicklungs-

artefakte (Dokumente) durch Inspektionen und Reviews

Dynamische Tests: Überprüfung ausführbarer Artefakte (Prototypen,

Programmcode) durch Testdaten


Test-Arten im V-Modell

Reviews, Prototyp der Oberfläche

Reviews, Konsistenzprüfungen, Machbarkeitsstudien

Code-Reviews, Test-Planung


Qualitätssicherung für Analyse und Entwurf

Hohe Bedeutung früher Phasen für Produktqualität !

• Deshalb: Alle Dokumente frühzeitig überprüfen ("Validation").

Techniken:

• Anforderungskatalog-Begutachtung

• Echte Benutzer einbeziehen

• Anforderungskatalog auf Vollständigkeit und Korrektheit prüfen

• Use-Case-Szenarien


• "Funktionsfähigkeit" der abstrakten Modelle demonstrieren

• Prototyping

• Prototyp auf der Basis der Analyse/Entwurfs-Dokumente


• Vorgezogener Akzeptanztest

• Abgleich des Entwurfs mit Use-Cases/Anforderungskatalog

• Erste verifizierende Tätigkeiten


Begutachtung (Review)

Produkt wird von Expertengremium begutachtet

• Anwendbar auf fast alle Phasen der Entwicklung

Was wird begutachtet?

• Genau definiertes Dokument (Art, Status, Prozesseinbindung)

• Teil der Gesamtplanung des Projekts (Termin)

Wer begutachtet?

• Teammitglieder (Peer-Review)

• Externe Spezialisten

• Echte Benutzer

• Moderator, Manager

Wie läuft die Begutachtung ab?

• Einladung

• Vorbereitung, Sammlung von Kommentaren

• Begutachtungssitzung(en), Protokolle

• Auswertung und Konsequenzen (Wiederholung, Statusänderung)


Regeln für wirkungsvolle Begutachtung

"Checklisten" für die Gutachter vorbereiten

• z.B. "Enthält das Dokument alle laut Firmenstandard vorgesehenen Informationen?" - "Gibt es für jede Klasse eine informelle Beschreibung?" - "Sind Kardinalitäten im Klassendiagramm vollständig und korrekt?" - "Sind alle Klassen kohärent?" - ...

Das Dokument wird begutachtet, nicht die Autoren!

Richtige Vorkenntnisse der Gutachter sind wesentlich.

Die Rolle des Moderators ist anspruchsvoll:

• Vermittlung in persönlichen Konflikten und Gruppenkonflikten

• Fachlicher Gesamtüberblick

Das Ziel ist Einigkeit, nicht ein Abstimmungsergebnis!

Ergebnisse von Begutachtungen müssen Auswirkungen haben.

Wesentliche Beiträge von Gutachtern müssen Anerkennung finden.

Begutachtung ist auch anwendbar auf Programm-Code (Code-Inspektion).


Dynamisches Testen: Begriffe

Testgegenstand (Testling, Prüfling):

Programm bzw. Komponente, die zu testen ist

Testfall:

Satz von Eingabedaten, der die (vollständige) Ausführung des Testgegenstands bewirkt

Testdaten:

Daten, die für den Testfall benötigt werden

Testtreiber:

Rahmenprogramm für Ausführung von Tests

Attrappe (Stub, Dummy):

Ersatz für ein (noch) nicht vorhandenes Unterprogramm

Regressionstest:

Nachweis, dass eine geänderte Version des Testgegenstands früher durchgeführte Tests erneut besteht

Alphatest: Test experimenteller Vorversion durch Benutzer

Betatest: Test funktional vollständiger Software durch Benutzer


Fehlfunktionen

Fehlfunktion (fault): Unerwartete Reaktion des Testlings

Unterscheidung zwischen dem fehlerhaften Code (error, bug) und dem Auftreten des Fehler (fault):

• Ein „fault“ kann aufgrund mehrerer „bugs“ auftreten.

• Ein „bug“ kann mehrere „faults“ hervorrufen.

Arten von Fehlfunktionen:

• Falsches oder fehlendes Ergebnis

• Nichtterminierung

• Unerwartete oder falsche Fehlermeldung

• Inkonsistenter Speicherzustand

• Unnötige Ressourcenbelastung (z.B. von Speicher)

• Unerwartetes Auslösen einer Ausnahme, "Abstürze"

• Falsches Abfangen einer Ausnahme


Grundsätze des Testens

Nach: ISTQB Syllabus Certified Tester Foundation Level

Grundsatz 1 Vollständiges Testen - Austesten - ist nicht möglich.

Grundsatz 2 Mit Testen wird die Anwesenheit von Fehlerwirkungen nachgewiesen. Dass keine Fehlerzustände im Testobjekt vorhanden sind, kann durch Testen nicht gezeigt werden.

„Program testing can be used to show the presence of bugs, but never to

show their absence!“ Edsger Dijkstra


Grundsätze des Testens (2)

Grundsatz 3

Testen ist keine späte Phase in der Softwareentwicklung, es soll

damit so früh wie möglich begonnen werden. Durch frühzeitiges

Prüfen (z.B. Reviews) werden früher Fehler(zustände) erkannt und

somit Kosten gesenkt.

Grundsatz 4

Fehlerzustände sind in einem Testobjekt nicht gleichmäßig verteilt,

vielmehr treten sie gehäuft auf. Dort wo viele Fehlerwirkungen

nachgewiesen wurden, finden sich vermutlich auch noch weitere.


Grundsätze des Testens

Grundsatz 5 Tests nur zu wiederholen, bringt keine neuen Erkenntnisse. Testfälle sind zu prüfen, zu aktualisieren und zu modifizieren.

Grundsatz 6 Testen ist abhängig vom Umfeld. Sicherheitskritische Systeme sind intensiver zu testen als beispielsweise der Internetauftritt einer Einrichtung.

Grundsatz 7 Ein System ohne Fehlerwirkungen bedeutet nicht, dass das System auch den Vorstellungen der späteren Nutzer entspricht.


Pareto-Prinzip

Fenton/Ohlsson 2000 und andere empirische Untersuchungen:

• 20 % der Module sind verantwortlich für 60 % der Fehler

• Diese 20 % der Module entsprechen 30 % des Codes

Testmuster: "Scratch'n sniff"

• Fehlerhafte Stellen deuten oft auf weitere Fehler in der Nähe hin.

% der Fehlfunktionen

% der betroffenen Module

20

40

60

80

100

30 60 90


Testplanung und Testkonzept

Testen ist aufwändig, deshalb ist gute Planung nötig!

Testplanung sollte bereits mit der Anforderungsanalyse beginnen

und im Entwurf verfeinert werden (V-Modell, Test-First-Ansatz)!

Typische Bestandteile eines Testkonzepts:

• Phasenmodell des Testprozesses

• Zusammenhang zur Anforderungsspezifikation

• z.B. dort festgelegte Qualitätsziele

• Zu testende Produkte

• Zeitplan für die Tests

• Abhängigkeiten der Testphasen

• Aufzeichnung der Testergebnisse

• Hardware- und Softwareanforderungen

• Einschränkungen und Probleme


Testspezifikation: Testfälle, Priorisierung, Testdaten und Soll-

Ergebnisse

Testplanung: Ressourcen, Aufwand, Termine

Testdurchführung: sowie Testprotokollierung und Meldung des

Fehlers an den Entwickler (Fehlerverwaltung)

Testmanagement: Prüfen der Testberichte und Entscheidung über

Testende

Testprozess


Details der Teststrategie

Pro Dokument und Entwicklungsergebnis

• Festlegung der Testmethode

• Festlegung des Abdeckungsgrades

Priorisierung der einzelnen Tests

• Eintrittswahrscheinlichkeit eines Fehlers (z.B. häufig vom

Kunden genutztes Prüfobjekt, intern kritisches Prüfobjekt,

komplexes Prüfobjekt)

• Fehlerschwere

• Für Kunden: Schaden beim Auftreten bzw. Zufriedenheit

• Für Hersteller: Größe des Behebungsaufwandes

• Priorität der Anforderungen


Testfälle

Logischer Testfall: abstrakte Beschreibung eines Testfalls

Konkreter Testfall: Konkretisierung eines logischen Testfalls durch

Testdaten

Testlauf: Protokoll einer Durchführung eines konkreten Testfalls

Logischer

Testfall Testlauf

konkreter

Testfall 1 1..n 1 1..n


Inhalt einer „Test case specification“:

• Test case specification identifier

• Test items

• Input specifications

• Output specifications

• Environmental needs (hardware, software, others)

• Special procedural requirements

• Intercase dependencies

Testfallspezifikation

(nach „IEEE Standard for Software Test Documentation“)


Testberichte: Welche Tests wurden mit welchem Ergebnis

durchgeführt?

• Testabdeckung = Anzahl der durchgeführten Tests / Anzahl

der durchzuführenden Tests

• Anzahl der noch offenen Fehler

• Priorisierung von Testfällen und Fehlern

Testendekriterium: Wann wird die QS beendet?

• Alle Testfälle durchgeführt?

• Alle Fehler behoben?

• Alle schweren Fehler behoben?

• Nimmt Fehlerfindungsrate ab?

• Termin erreicht?/ Budget verbraucht?

Testberichte/ Testendekriterium


Informationen pro Fehler:

Testfall, Testdurchführung, Eingabedaten und Ergebnis

Zuständiger Tester

Zuständiger Entwickler (für Fehlerbehebung)

Status

• Offen (von Tester entdeckt, Entwickler zuständig)

• in Bearbeitung (durch Entwickler)

• Behoben (durch Entwickler, Tester wieder zuständig)

• Erledigt (=Bestätigung durch Tester)

Schwere. z.B.:

• „schwer“ = Arbeit unmöglich + kein Workaround vorhanden

• „mittel“ = Arbeit erschwert + Workaround vorhanden

• „leicht“ = stört nicht beim Arbeiten)

Fehlerverwaltung


Testarten

Akzeptanz-

Test

Baustein-

Test

Modul-

Test

Integrations-

Test

System-

Test

Integration

Bausteintest (unit test): • Traditionell: Prozeduren • OO: Methoden Modultest: • Traditionell: Module • OO: Klassen Integrationstest: • OO: Pakete


Testmethoden

Funktionaler Test (black box test):Testfallauswahl beruht auf

Spezifikation)

• Äquivalenzklassentest, Grenzwerte, Test spezieller Werte

• Zustandstest auf Spezifikationsbasis

Strukturtest (white box test, glass box test):Testfallauswahl beruht

auf Programmstruktur

• Kontrollflussorientierter Test

• Anweisungsüberdeckung, Zweigüberdeckung, Pfadüberdeckung

• Datenflussorientierter Test: Definition/Verwendung von Variablen

Weitere Testmethoden (Beispiele)

• Zufallstest ("monkey test")

• Stress-, Lasttest


Funktionaler Test (black box)

Funktionale Spezifikation

Testfälle

(Eingabedaten)

Erwartete

Ausgabedaten

Programm- ausführung

Ausgabe-

daten

Vergleich


Äquivalenzklassentest

Äquivalenzklasse:

• Teilmenge der möglichen Datenwerte der Eingabeparameter

• Annahme: Programm reagiert für alle Werte aus der

Äquivalenzklasse prinzipiell gleich

• Test je eines Repräsentanten jeder Äquivalenzklasse

Finden von Äquivalenzklassen:

• Kriterien für Werte entwickeln und diese wo sinnvoll kombinieren

• Zulässige und unzulässige Teilbereiche der Datenwerte

• Unterteilung der zulässigen Bereiche nach verschiedenen

Ausgabewerten


Äquivalenzklassentest: Beispiel

Kriterien für Äquivalenzklassen:

• Kriterium 1A: a.length == 0

• Kriterium 1B: a.length > 0

• Kriterium 2A: k in a

• Kriterium 2B: k nicht in a

Äquivalenzklassen / Testfälle:

• drei Äq.-Klassen, da 1A und 2A nicht kompatibel • a == [], k == 17, result == undef. (1A, 2B) • a == [11, 17, 45], k == 17, result == 1 (1B, 2A) • a == [11, 23, 45], k == 17, result == -1 (1B, 2B)

int search (int[] a, int k)

Vorbedingung: a.length >= 0

Nachbedingung: (result ≥ 0 a[result] == k)

(result == –1 ( i . 0 ≤ i < a.length a[i] == k))


Grenzwertanalyse und Test spezieller Werte

Grenzwerte: Randfälle der Spezifikation

• Werte, bei denen "gerade noch" ein gleichartiges Ergebnis zum

Nachbarwert erzielt wird, bzw. "gerade schon" ein andersartiges

• Beispiele:

• Ränder von Zahl-Intervallen

• Schwellenwerte

Spezielle Werte:

• Zahlenwert 0

• Leere Felder, Sequenzen und Zeichenreihen

• Einelementige Felder, Sequenzen und Zeichenreihen

• Null-Referenzen

• Sonderzeichen (Steuerzeichen, Tabulator)


Grenzwertanalyse: Beispiel

Weitere Kriterien für Äquivalenzklassen: • 3A: Element am linken Rand a[0]==k • 3B: Element am rechten Rand a.last==k • 3C: Element an keinem Rand ... • 4A: a einelementig a.length==1 • 4B: a nicht einelementig a.length!=1 • 5A: k ist 0 k==0 • 5B: k ist nicht 0 k!=0

Neue Testfälle:

• a == [17], k == 17, result == 0 (Kriterien 1B, 2B, 3A+B, 4A, 5B) • a == [11, 23, 0], k == 0, result == 2 (Kriterien 1B, 2B, 3B, 4B, 5A)

int search (int[] a, int k)

Vorbedingung: a.length > 0

Nachbedingung: (result ≥ 0 a[result] == k)

(result == –1 ( i . 0 ≤ i < a.length a[i] == k))


Strukturtest (glass-box)

Programm-

Code

Testfälle

(Eingabedaten)

Funktionale Spezifikation

oder "Orakel"

Programm- ausführung

Ausgabe-

daten

Vergleich

Erwartete

Ausgabedaten


Überdeckungsgrad (coverage)

Maß für die Vollständigkeit eines Tests

Welcher Anteil des Programmtexts wurde ausgetestet?

Messung der Überdeckung:

• Instrumentierung des Programmcodes

• Ausgabe statistischer Informationen

Planung der Überdeckung:

• gezielte Anlage der Tests auf volle Überdeckung

Überdeckungsarten:

• Anweisungsüberdeckung: Anteil ausgeführter Anweisungen

• Zweigüberdeckung: Anteil ausgeführter Anweisungen und Verzweigungen

• Pfadüberdeckung: Anteil ausgeführter Programmablaufpfade

Hilfsmittel:

• Kontrollflussgraph


Beispielprogramm: Binäre Suche

public static final int NOTFOUND = -1; // Binaere Suche auf Array a. // Annahme: a ist sortiert // Ergebnis ist NOTFOUND, wenn k nicht in A enthalten ist. // Ergebnis ist i falls a[i] gleich k ist. public static int binSearch (int[] a, int k) { int ug = 0, og = a.length-1, m, pos = NOTFOUND; while (ug <= og && pos == NOTFOUND) { m = (ug + og) / 2; if (a[m] == k) pos = m; else if (a[m] < k) ug = m + 1; else og = m - 1; }; return pos; }


Binäre Suche - Kontrollflussgraph

public static final int NOTFOUND = -1;

public static int binSearch (int[] a, int k) {

int ug = 0, og = a.length-1,

m, pos = NOTFOUND; // 1

while (ug <= og && pos == NOTFOUND) { // 2

m = (ug + og) / 2; // 3

if (a[m] == k) // 4

pos = m; // 5

else

if (a[m] < k) // 6

ug = m + 1; // 7

else

og = m - 1; // 8

};

return pos; // 9

}

1

2

5

7 8

3

4

6

9


Anweisungsüberdeckender Test

Überdeckung aller Anweisungen: C0-Test

• Jede Anweisung (numerierte Zeile) des Programms wird

mindestens einmal ausgeführt.

Beispiel:

a = {11, 22, 33, 44, 55}, k = 33

überdeckt Anweisungen: 1, 2, 3, 4, 5, 9

a = {11, 22, 33, 44, 55}, k = 15

überdeckt Anweisungen: 1, 2, 3, 4, 6, 7, 8, 9

Beide Testfälle zusammen erreichen volle Anweisungsüberdeckung.

Messen der Anweisungsüberdeckung:

• "Instrumentieren" des Codes (durch Werkzeuge)

• Einfügen von Zählanweisungen bei jeder Anweisung


Zweigüberdeckender Test

Überdeckung aller Zweige: C1-Test

• Bei jeder Fallunterscheidung (einschließlich Schleifen) werden

beide Zweige ausgeführt (Bedingung=true und Bedingung=false).

• Zweigtest zwingt auch zur Untersuchung "leerer" Alternativen:

if (x >= 1)

y = true; // kein else-Fall

Beispiel:

• Die beiden Testfälle der letzten Folie überdecken alle Zweige.

Messung/Instrumentierung von Anweisung i:

• Fallunterscheidung:

if (...) { bT[i]++; ... } else { bF[i]++; ... }

• While-Schleife:

while (...) { bT[i]++; ... } bF[i]++;


Pfadüberdeckung

Pfad =

Sequenz von Knoten im Kontrollflussgraphen,

so dass in der Sequenz aufeinanderfolgende Knoten

im Graphen direkt miteinander verbunden sind.

Anfang = Startknoten, Ende = Endknoten.

Theoretisch optimales Testverfahren

Explosion der Zahl von möglichen Pfaden, deshalb

nicht praxisrelevant. (Schleifen haben unendliche Pfad-Anzahlen)

Praktikablere Varianten, z.B. bounded-interior-Pfadtest:

Alle Schleifenrümpfe höchstens n-mal (z.B. einmal) wiederholen


Testen objektorientierter Programme

Klassische Verfahren anwendbar für einzelne Methoden

• aber: Methoden vergleichsweise kurz und einfach

Komplexität liegt zum großen Teil in der Kooperation.

Probleme mit Vererbung: Tests der Oberklassen müssen u.U. für

alle Unterklassen wiederholt werden:

• Beeinflussung von Variablen der Oberklasse

• Redefinition von Methoden der Oberklasse


Klassentest

Festlegung einer Testreihenfolge für einzelne Methoden

• Konstruktoren

• Get-Methoden

• Boolsche Methoden (is…)

• Set-Methoden

• Iteratoren

• Komplexe Berechnung oder Ablaufsteuerung in einer Klasse

• Sonstige Methoden

• Destruktoren


Klassentest (2)

Festlegung einer Testreihenfolge für das Zusammenspiel der Methoden

Berücksichtige Abhängigkeiten zwischen den Methodenaufrufen

• Nicht-modal: keine (z.B. Sortierung)

• Testfälle müssen internen Zustand nicht berücksichtigen

• Uni-modal: feste Reihenfolge (z.B. Ampel)

• Testfälle testen alle zulässigen und unzulässigen Reihenfolgen

• Quasi-modal: inhaltsabhängige Reihenfolge (z.B. Stack)

• Testfälle für alle Zustände und Zustandsübergänge

• Modal: fachliche Reihenfolge (z.B. Konto)

• Wie quasi-modal

• Zusätzliche Berücksichtigung fachlicher Zusammenhänge


Zustandstests

Spezifikationsbezogen ("black box"):

• Verwendung von Zustandsdiagrammen (z.B. UML) aus Analyse

und Entwurf

• Abdeckungskriterien:

• alle Zustände

• alle Übergänge

• für jeden Übergang alle Folgeübergänge der Länge n

• Praxistauglich

Programmbezogen ("glass box"):

• Automatische Berechnung eines Zustandsdiagramms

• Zustand = Abstraktion einer Klasse zulässiger Attributwerte

• Bestimmung der Übergänge erfordert symbolische Auswertung

von Methoden (problematisch bei Schleifen und Rekursion)

• Im Forschungsstadium


Test-driven Development

Programmierer testen meist nicht gerne.

• „Testen ist zerstörerische Tätigkeit.“

• Zu spätes Testen führt zu komplizierten Fehlersuchen!

Test-First-Ansatz:

Tests entstehen parallel zum Code (oder sogar vor dem Code)

Programmierer schreiben Tests für praktischen Nutzen:

• Klare Spezifikation von Schnittstellen

• Beschreibung kritischer Ausführungsbedingungen

• Dokumentation von Fehlerbeseitigung

• Festhalten von notwendigem Verhalten vor größerem Umbau

("Refaktorisierung")

Tests werden archiviert und sind automatisch ausführbar.

Weitere Information:

• K. Beck, E. Gamma: Programmers love writing tests (JUnit)

• K. Beck: Extreme programming explained, Addison-Wesley 2000


Wohin mit dem Test-Code?

Zur Durchführung von Tests entsteht zusätzlicher Code:

• Testtreiber

• Testattrappen (Stubs)

• Testsuiten

Testcode muss aufbewahrt werden, da Tests nach allen größeren Änderungen wiederholt werden.

Alternativen:

• Testcode als Bestandteil der Klassen

• einfach zu verwalten, vergrößert Code

• "Spiegelbildliche" Hierarchie von Testklassen

• Redundanzproblem

• Erleichtert Verwendung von Test-Frameworks (z.B. JUnit)

• Testskripten in eigenen Sprachen

• klassischer Ansatz, keine Vererbung von Testfällen möglich

• Test-Unterklassen

• problematisch wegen Mehrfachvererbung


Testfallerzeugung mit JUnit

JUnit (http://www.junit.org/, aktuellw Version 4.0)

• kleines Test Framework

• hat für Java schnell weite Verbreitung gefunden

• Testfälle werden in Java codiert (kein Sprachwechsel für Tests)

• Framework kümmert sich um automatisierte Testfallausführung

• Testausführung ist wiederholbar.

http://www.junit.org/

http://www.junit.org/


JUnit & Test-First

Test-First ist Grundsatz von XP (eXtreme Programming)

„Test a little, code a little“

0. Wir überlegen uns erste Testfälle für die geforderte Funktionalität.

Wiederholung der Schritte 1-6:

1. Auswahl des nächsten Testfalls.

2. Wir entwerfen einen Test, der zunächst fehlschlagen sollte.

3. Wir schreiben gerade soviel Code, dass sich der Test übersetzen lässt (Signatur).

4. Wir prüfen, ob der Test fehlschlägt.

5. Wir schreiben gerade soviel Code, dass der Test erfüllt sein sollte.

6. Wir prüfen, ob der Test durchläuft.

7. Die Entwicklung ist abgeschlossen, wenn uns keine weiteren Tests mehr einfallen, die fehlschlagen können.


Anwendungsbeispiel: Konto

0. Wir überlegen uns erste Testfälle

• Erzeuge neues Konto (Account) für Kunden

• Mache eine Einzahlung (deposit)

• Mache eine Abhebung (withdraw)

• Überweisung zwischen zwei Konten, ...

1. Auswahl des nächsten Testfalls: Erzeuge Konto


2. Wir entwerfen einen Test

Testmethoden beginnen mit „test“: Sie führen die getesteten Methoden aus

und prüfen das Ergebnis

import static org.junit.Assert.*;

import org.junit.Test;

@Test

public class AccountTest {

public void testCreateAccount() {

Account account = new Account("Customer");

assertEquals("Customer", account.getCustomer());

assertEquals(0, account.getBalance());

}

}

assertX-Methoden werden genutzt, um Ergebnisse zu prüfen


3. Wir schreiben gerade soviel Code, dass

sich der Test übersetzen lässt

public class Account {

public Account(String customer) {

}

public String getCustomer() {

return null;

}

public int getBalance() {

return 0;

}

}

Die zu testende Klasse kennt die Testklasse nicht und kann daher auch ohne Tests eingesetzt werden. Übersetzbarkeit bedeutet: Signaturen + Default-Return-Werte sind vorhanden

4. Wir prüfen, ob der Test fehlschlägt:


5. Wir schreiben gerade soviel Code, dass

der Test erfüllt sein sollte

Im Beispiel werden also der Konstruktor und getCustomer umgesetzt sowie die notwendige Datenstruktur (String customer) definiert.

public class Account {

private String customer;

public Account(String customer) {

this.customer = customer;

}

public String getCustomer() {

return customer;

}

public int getBalance() {

return 0;

}

}

6. Wir prüfen, ob der Test durchläuft:


Weiterer Test: Abheben

Auch erwartete Exceptions können getestet werden

public class AccountTest {

...

private Account account;

@Before

protected void setUp() {

account = new Account("Customer");

}

public void testWithdraw() throws Exception {

account.deposit(100);

account.withdraw(50);

assertEquals(50, account.getBalance());

try {

account.withdraw(51);

fail("AmountNotCoveredException expected");

} catch (Exception expected) {}

}

}

Mehrere „tests“ in einer Testklasse sind möglich

@Before wird vor jedem Test aufgerufen und erzeugt (gemeinsame) Ausgangsdaten @After wird nach jedem Test aufgerufen, um „aufzuräumen“


TestSuite – Testfälle organisieren

import org.junit.runner.JUnitCore;

public class AllTests {

public static void main(String[] args) {

JUnitCore.runClasses(AccountTest.class);

}

}

Alle Tests in einer Testklassen können nacheinander ausgeführt werden.


Neuerungen von JUnit 3 zu JUnit 4

Man braucht nicht mehr von TestCase ableiten.

Die Test-Methoden benötigen nicht mehr den Präfix test,

stattdessen kann die Annotation @Test verwendet werden.

Statt setUp() nun auch @Before

Statt tearDown() nun auch @After

Einfaches Testen von Exception-Auslösung durch die Annotation @Test(expected=NullPointerException).

Weitere Annotationen: @BeforeClass, @AfterClass, @Timeout,

@Ignore

Alte JUnit-Testfälle können problemlos mit JUnit4 verwendet werden

JUnit4-Testfälle können mit Hilfe des JUnit4TestAdapters auch

in alten JUnit-Version ausgeführt werden


Integrationstests

Integrationstests betrachten das Zusammenspiel von Komponenten.

Falls Komponenten nicht allein lauffähig sind, muss Testrahmen

bereitgestellt werden.

Testobjekt

Platzhalter

(Stubs)

Ersetzen

nicht

Vor-

handene

Code-

teile

Testtreiber

(Driver)

Liefern

Testdaten,

Stossen

Ausführung

an

Laufzeitumgebung,

Monitore (protokol-

lieren Ausgaben)


Top-Down Integrationsteststrategie

Level 2Level 2Level 2Level 2

Level 1 Level 1Testing

sequence

Level 2stubs

Level 3stubs

. . .

Benötigt viele Stubs, wenige Testtreiber


Bottom-Up Integrationsteststrategie

Level NLevel NLevel NLevel NLevel N

Level N–1 Level N–1Level N–1

Testingsequence

Testdrivers

Testdrivers

Benötigt viele Testtreiber, keine Stubs


Inkrementelle Integration

T3

T2

T1

T4

T5

A

B

C

D

T2

T1

T3

T4

A

B

C

T1

T2

T3

A

B

Test sequence1

Test sequence2

Test sequence3

Test, dass neue Komponente nicht bisheriges Zusammenspiel stört.


Systemtest

Testet ob Kunden-Anforderungen richtig umgesetzt wurden

(Verifikation)

Testumgebung sollte Produktiv-Umgebung möglichst nahe kommen

(also keine Stubs und Testtreiber)

Produktiv-Umgebung oft selbst nicht geeignet wegen

Schadensrisiko und mangelnder Kontrolle

Einzelne Funktionen, aber auch Funktionssequenzen (für

Geschäftsprozesse) testen

Sollte Test von nicht-funktionalen Anforderungen beinhalten, wie

Performanz, Sicherheit.


Abnahmetest

Input:

System

Abnahmekriterien

Testfälle

Testplan

Protokollvorlagen

Systemdokumentation

Output:

Testprotokolle

Unterschriebenes

Abnahmeprotokoll

Abnahme ohne Mängel

Abnahme mit Mängeln

Abnahme verweigert

Abnahme

-test

wird vom Kunden vorgenommen


Zusammenfassung: Qualitätsmanagement

Qualitätsmanagement umfasst Qualität der Prozesse und der

Produkte (konstruktive vs. analytische Qualitätssicherung).

Analytische Qualitätssicherung:

• Statisches Testen: Reviews, Inspektionen

• Dynamisches Testen:

• Unittests

• Integrationstests

• Systemtests

• Akzeptanztests

Testmethoden: Black Box vs. White Box Testen, Coveragekriterien

Documents

Software Engineering 1 WS 2012/2013 - TU Braunschweig · Pareto-Prinzip Fenton/Ohlsson 2000 und andere empirische Untersuchungen: • 20 % der Module sind verantwortlich für 60 %