Qualitätsmanagement - Technische Universität Braunschweig

Transcription

Qualitätsmanagement
Software Engineering 1
WS 2011/2012
Dr. Ina Schaefer
Software Systems Engineering
Technische Universität Braunschweig
(Folien von Prof. B. Rumpe und Dr. A. Herrmann)
Was ist Qualität?
§  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
Dr. Ina Schaefer
Seite 2
Qualität nach ISO9216
§  Funktionalität
•  Angemessenheit
•  Sicherheit
•  Genauigkeit der
Berechnung
•  Interoperabilität
•  Konformanz zu
Standards
§  Zuverlässigkeit
•  Reife
•  Fehlertoleranz
•  Wiederherstellbarkeit
§  Benutzbarkeit
•  Verständlichkeit
•  Erlernbarkeit
•  Bedienbarkeit
Dr. Ina Schaefer
§  Effizienz
•  Zeitverhalten
•  Verbrauchsverhalten
§  Änderbarkeit
•  Analysierbarkeit
•  Modifizierbarkeit
•  Stabilität
•  Prüfbarkeit
§  Übertragbarkeit
•  Anpassbarkeit
•  Installierbarkeit
•  Konformanz zu
Standards
•  Austauschbarkeit
Seite 3
Verifikation & Validierung
Benutzererwartungen
Anforderungsdokument
.....
Code
Verifikation: haben wir es richtig gemacht?
Validierung: haben wir das Richtige gemacht?
Dr. Ina Schaefer
Seite 4
Ü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)
Dr. Ina Schaefer
Seite 5
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
Dr. Ina Schaefer
Seite 6
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 !
Dr. Ina Schaefer
Seite 7
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
Dr. Ina Schaefer
Seite 8
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
Dr. Ina Schaefer
Seite 9
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.
Dr. Ina Schaefer
Seite 10
Capability Maturity Model (CMM)
Stufe 5:
Optimierend
Stufe 4:
Gesteuert
Stufe 3:
Definiert
Stufe 2:
Wiederholbar
Stufe 1:
Stufe1:
Initialer Prozess
Initial
Dr. Ina Schaefer
Kontrolle über
Prozessqualität
Kontrolle über
Produktqualität
Kosten und Termine
zuverlässig, aber
Qualität schwankend
Terminkontrolle, aber
Kosten und Qualität
schwanken
Kosten, Zeit, Qualität
unvorhersehbar
Seite 11
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.
Dr. Ina Schaefer
Seite 12
5 Stufen in CMMI (2)
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.
Dr. Ina Schaefer
Seite 13
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 BeweisWerkzeuge)
•  Test (Ausprobieren für eine sorgfältig ausgewählte Menge von
Eingaben)
•  Inspektion (systematisches Durchlesen)
•  Metriken (automatische Bestimmung von Charakteristika)
Dr. Ina Schaefer
Seite 14
Statische und Dynamische Tests
§  Statische Tests: Überprüfung nicht-ausführbarer Entwicklungsartefakte (Dokumente) durch Inspektionen und Reviews
§  Dynamische Tests: Überprüfung ausführbarer Artefakte (Prototypen,
Programmcode) durch Testdaten
Dr. Ina Schaefer
Seite 15
Test-Arten im V-Modell
Reviews,
Prototyp der Oberfläche
Reviews,
Konsistenzprüfungen,
Machbarkeitsstudien
Code-Reviews,
Test-Planung
Dr. Ina Schaefer
Seite 16
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
Dr. Ina Schaefer
Seite 17
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)
Dr. Ina Schaefer
Seite 18
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).
Dr. Ina Schaefer
Seite 19
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
Dr. Ina Schaefer
Seite 20
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
Dr. Ina Schaefer
Seite 21
Grundsätze des Testens
Nach: ISTQB Syllabus Certified Tester Foundation Level
§  Grundsatz 1
Vollständiges Testen - Austesten - ist nicht möglich.
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
Dr. Ina Schaefer
Seite 22
Grundsätze des Testens (2)
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.
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.
Dr. Ina Schaefer
Seite 23
Grundsätze des Testens
Tests nur zu wiederholen, bringt keine neuen Erkenntnisse.
Testfälle sind zu prüfen, zu aktualisieren und zu modifizieren.
Testen ist abhängig vom Umfeld. Sicherheitskritische Systeme sind
intensiver zu testen als beispielsweise der Internetauftritt einer
Einrichtung.
Ein System ohne Fehlerwirkungen bedeutet nicht, dass das System
auch den Vorstellungen der späteren Nutzer entspricht.
Dr. Ina Schaefer
Seite 24
Pareto-Prinzip
% der
Fehlfunktionen
100
80
60
40
20
% der betroffenen Module
30
60
90
§  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.
Dr. Ina Schaefer
Seite 25
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
• 
• 
• 
• 
• 
• 
Dr. Ina Schaefer
Zu testende Produkte
Zeitplan für die Tests
Abhängigkeiten der Testphasen
Aufzeichnung der Testergebnisse
Hardware- und Softwareanforderungen
Einschränkungen und Probleme
Seite 26
Testprozess
§  Testspezifikation: Testfälle, Priorisierung, Testdaten und SollErgebnisse
§  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
Dr. Ina Schaefer
Seite 27
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
Dr. Ina Schaefer
Seite 28
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 1 1..n konkreter 1 1..n
Testfall
Testfall
Dr. Ina Schaefer
Testlauf
Seite 29
Testfallspezifikation
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
(nach „IEEE Standard for Software Test Documentation“)
Dr. Ina Schaefer
Seite 30
Testberichte/ Testendekriterium
§  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?
Dr. Ina Schaefer
Seite 31
Fehlerverwaltung
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)
Dr. Ina Schaefer
Seite 32
Testarten
BausteinTest
ModulTest
Bausteintest (unit test):
•  Traditionell: Prozeduren
•  OO: Methoden
Integration
IntegrationsTest
SystemTest
Modultest:
•  Traditionell: Module
•  OO: Klassen
AkzeptanzTest
Integrationstest:
•  OO: Pakete
Dr. Ina Schaefer
Seite 33
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
Dr. Ina Schaefer
Seite 34
Funktionaler Test (black box)
Funktionale"
Spezifikation"
Erwartete"
Ausgabedaten"
Vergleich"
Testfälle"
(Eingabedaten)"
Dr. Ina Schaefer
Programm-"
ausführung"
Ausgabe-"
daten"
Seite 35
Ä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
Dr. Ina Schaefer
Seite 36
Äquivalenzklassentest: Beispiel
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))
§  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:
• 
• 
• 
• 
Dr. Ina Schaefer
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)
Seite 37
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)
Dr. Ina Schaefer
Seite 38
Grenzwertanalyse: Beispiel
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))
§  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
•  a == [11, 23, 0], k == 0, result == 2
Dr. Ina Schaefer
(Kriterien 1B, 2B, 3A+B, 4A, 5B)
(Kriterien 1B, 2B, 3B, 4B, 5A)
Seite 39
Strukturtest (glass-box)
Programm-"
Code"
Testfälle"
(Eingabedaten)"
Programm-"
ausführung"
Ausgabe-"
daten"
Vergleich"
Funktionale"
Spezifikation"
oder"
"Orakel""
Dr. Ina Schaefer
Erwartete"
Ausgabedaten"
Seite 40
Ü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
Dr. Ina Schaefer
Seite 41
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;
}
Dr. Ina Schaefer
Seite 42
Binäre Suche - Kontrollflussgraph
public static final int NOTFOUND = -1;
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)
pos = m;
else
2
3
// 4
// 5
4
if (a[m] < k)
// 6
ug = m + 1;
else
// 7
og = m - 1;
// 8
6
5
7
8
};
return pos;
// 9
}
Dr. Ina Schaefer
9
Seite 43
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
Dr. Ina Schaefer
Seite 44
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]++;
Dr. Ina Schaefer
Seite 45
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
Dr. Ina Schaefer
Seite 46
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
Dr. Ina Schaefer
Seite 47
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
Dr. Ina Schaefer
Seite 48
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
Dr. Ina Schaefer
Seite 49
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
Dr. Ina Schaefer
Seite 50
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
Dr. Ina Schaefer
Seite 51
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
Dr. Ina Schaefer
Seite 52
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.
Dr. Ina Schaefer
Seite 53
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.
Dr. Ina Schaefer
Seite 54
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
Dr. Ina Schaefer
Seite 55
2. Wir entwerfen einen Test
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
Dr. Ina Schaefer
Testmethoden beginnen mit „test“:
Sie führen die getesteten Methoden aus
Seite
Software Engineering 1und prüfen das Ergebnis
56
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:
Dr. Ina Schaefer
Seite 57
5. Wir schreiben gerade soviel Code, dass
der Test erfüllt sein sollte
public class Account {
private String customer;
public Account(String customer) {
this.customer = customer;
}
public String getCustomer() {
return customer;
}
public int getBalance() {
return 0;
}
}
Im Beispiel werden also der Konstruktor und getCustomer umgesetzt
sowie die notwendige Datenstruktur (String customer) definiert.
6. Wir prüfen, ob der Test durchläuft:
Dr. Ina Schaefer
Seite 58
Weiterer Test: Abheben
Mehrere „tests“ in einer Testklasse sind möglich
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) {}
}
@Before }wird vor jedem Test aufgerufen
und erzeugt (gemeinsame) Ausgangsdaten
@After wird nach jedem Test aufgerufen,
um „aufzuräumen“
Dr. Ina Schaefer
Auch erwartete Exceptions
können getestet werden
Seite 59
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.
Dr. Ina Schaefer
Seite 60
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
Dr. Ina Schaefer
Seite 61
Integrationstests
§  Integrationstests betrachten das Zusammenspiel von Komponenten.
§  Falls Komponenten nicht allein lauffähig sind, muss Testrahmen
bereitgestellt werden.
Platzhalter
(Stubs)
Ersetzen
nicht
Vorhandene
Codeteile
Dr. Ina Schaefer
Testobjekt
Laufzeitumgebung,
Monitore (protokollieren Ausgaben)
Testtreiber
(Driver)
Liefern
Testdaten,
Stossen
Ausführung
an
Seite 62
Top-Down Integrationsteststrategie
§  Benötigt viele Stubs, wenige Testtreiber
Level 1
Testing
sequence
Level 2
Level 1
Level 2
Le vel 2
. ..
Level 2
Le vel 2
stubs
Le vel 3
stubs
Dr. Ina Schaefer
Seite 63
Bottom-Up Integrationsteststrategie
§  Benötigt viele Testtreiber, keine Stubs
Test
drivers
Level N
Test
drivers
Dr. Ina Schaefer
Level N
Level Nœ1
Le vel N
Level N
Level Nœ1
Level N
Testing
sequence
Level Nœ1
Seite 64
Inkrementelle Integration
§  Test, dass neue Komponente nicht bisheriges Zusammenspiel stört.
A
T1
T1
A
T1
T2
A
T2
T2
B
B
T3
T3
B
C
T4
T3
C
T4
T5
D
Test sequence
1
Dr. Ina Schaefer
Test sequence
2
Test sequence
3
Seite 65
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.
Dr. Ina Schaefer
Seite 66
Abnahmetest
§  wird vom Kunden vorgenommen
Input:
§  System
§  Abnahmekriterien
§  Testfälle
§ Abnahme
-test
§  Testplan
§  Protokollvorlagen
§  Systemdokumentation
Dr. Ina Schaefer
Output:
§  Testprotokolle
§  Unterschriebenes
Abnahmeprotokoll
§  Abnahme ohne Mängel
§  Abnahme mit Mängeln
§  Abnahme verweigert
Seite 67
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
Dr. Ina Schaefer
Seite 68

Qualitätsmanagement - Technische Universität Braunschweig

Transcription

Documents pareils

SPORTGEMEINSCHAFT GITTERSEE eV

Selbstdarstellungsflyer - Flüchtlingsrat Baden

Arbeit +Kultur MedienProduktion / Berlin

Volker Hünefeldt, Hitzgasse 7, 55270 Sörgenloch

GeMit-Lauftreff

Interior-Design für

Sie kennt die Einzelschicksale

Diplom-Ingenieur Fertigungstechnik (m/w) in Erfurt

1 Fa - Technische Universität München