software engineering 1 ws 2012/2013 - tu braunschweig · pareto-prinzip fenton/ohlsson 2000 und...
Post on 18-Sep-2018
215 Views
Preview:
TRANSCRIPT
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?
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 3
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 4
Benutzer-
erwartungen
Anforderungsdokument Code .....
Verifikation: haben wir es richtig gemacht?
Validierung: haben wir das Richtige gemacht?
Verifikation & Validierung
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 5
Ü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)
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 6
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 7
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 !
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 8
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 9
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 10
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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 11
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 12
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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 13
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)
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 14
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)
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 15
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 16
Test-Arten im V-Modell
Reviews, Prototyp der Oberfläche
Reviews, Konsistenzprüfungen, Machbarkeitsstudien
Code-Reviews, Test-Planung
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 17
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
• Echte Benutzer einbeziehen
• "Funktionsfähigkeit" der abstrakten Modelle demonstrieren
• Prototyping
• Prototyp auf der Basis der Analyse/Entwurfs-Dokumente
• Echte Benutzer einbeziehen
• Vorgezogener Akzeptanztest
• Abgleich des Entwurfs mit Use-Cases/Anforderungskatalog
• Erste verifizierende Tätigkeiten
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 18
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)
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 19
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).
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 20
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 21
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 22
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 23
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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 24
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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 25
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 26
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 27
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 28
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 29
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 30
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“)
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 31
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 32
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 33
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 34
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 35
Funktionaler Test (black box)
Funktionale Spezifikation
Testfälle
(Eingabedaten)
Erwartete
Ausgabedaten
Programm- ausführung
Ausgabe-
daten
Vergleich
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 36
Ä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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 37
Ä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))
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 38
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)
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 39
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))
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 40
Strukturtest (glass-box)
Programm-
Code
Testfälle
(Eingabedaten)
Funktionale Spezifikation
oder "Orakel"
Programm- ausführung
Ausgabe-
daten
Vergleich
Erwartete
Ausgabedaten
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 41
Ü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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 42
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; }
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 43
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 44
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 45
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]++;
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 46
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 47
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 48
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 49
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 50
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 51
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 52
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 53
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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 54
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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 55
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 56
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 57
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:
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 58
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:
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 59
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“
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 60
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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 61
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 62
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)
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 63
Top-Down Integrationsteststrategie
Level 2Level 2Level 2Level 2
Level 1 Level 1Testing
sequence
Level 2stubs
Level 3stubs
. . .
Benötigt viele Stubs, wenige Testtreiber
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 64
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 65
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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 66
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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 67
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 68
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
top related