Qualitätsmanagement Software Engineering 1 WS 2010/2011 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 Software Engineering 1 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 Effizienz Zeitverhalten Verbrauchsverhalten Änderbarkeit Analysierbarkeit Modifizierbarkeit Stabilität Prüfbarkeit Übertragbarkeit Anpassbarkeit Installierbarkeit Konformanz zu Standards Austauschbarkeit Dr. Ina Schaefer Software Engineering 1 Seite 3
Verifikation & Validierung Benutzererwartungen Anforderungsdokument... Code Verifikation: haben wir es richtig gemacht? Validierung: haben wir das Richtige gemacht? Dr. Ina Schaefer Software Engineering 1 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 Software Engineering 1 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 Software Engineering 1 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 Software Engineering 1 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 Software Engineering 1 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 Software Engineering 1 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 Software Engineering 1 Seite 10
Capability Maturity Model (CMM) Stufe 4: Gesteuert Stufe 5: Optimierend Kontrolle über Produktqualität Kontrolle über Prozessqualität Stufe 3: Definiert Kosten und Termine zuverlässig, aber Qualität schwankend Stufe 2: Wiederholbar Stufe 1: Stufe1: Initialer Prozess Initial Terminkontrolle, aber Kosten und Qualität schwanken Kosten, Zeit, Qualität unvorhersehbar Dr. Ina Schaefer Software Engineering 1 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 Software Engineering 1 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 Software Engineering 1 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 Beweis- Werkzeuge) Test (Ausprobieren für eine sorgfältig ausgewählte Menge von Eingaben) Inspektion (systematisches Durchlesen) Metriken (automatische Bestimmung von Charakteristika) Dr. Ina Schaefer Software Engineering 1 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 Software Engineering 1 Seite 15
Test-Arten im V-Modell Reviews, Prototyp der Oberfläche Reviews, Konsistenzprüfungen, Machbarkeitsstudien Code-Reviews, Test-Planung Dr. Ina Schaefer Software Engineering 1 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 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 Dr. Ina Schaefer Software Engineering 1 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 Software Engineering 1 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 Software Engineering 1 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 Software Engineering 1 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 Software Engineering 1 Seite 21
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 Dr. Ina Schaefer Software Engineering 1 Seite 22
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. Dr. Ina Schaefer Software Engineering 1 Seite 23
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. Dr. Ina Schaefer Software Engineering 1 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 Software Engineering 1 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 Zu testende Produkte Zeitplan für die Tests Abhängigkeiten der Testphasen Aufzeichnung der Testergebnisse Hardware- und Softwareanforderungen Einschränkungen und Probleme Dr. Ina Schaefer Software Engineering 1 Seite 26
Testprozess 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 Dr. Ina Schaefer Software Engineering 1 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 Software Engineering 1 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 Testfall 1 1..n konkreter 1 1..n Testfall Testlauf Dr. Ina Schaefer Software Engineering 1 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 Software Engineering 1 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 Software Engineering 1 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 Software Engineering 1 Seite 32
Testarten Baustein- Test Modul- Test Integration Bausteintest (unit test): Traditionell: Prozeduren OO: Methoden Modultest: Traditionell: Module OO: Klassen Integrations- Test System- Test Akzeptanz- Test Integrationstest: OO: Pakete Dr. Ina Schaefer Software Engineering 1 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 Software Engineering 1 Seite 34
Funktionaler Test (black box) Funktionale Spezifikation Erwartete Ausgabedaten Vergleich Testfälle (Eingabedaten) Programmausführung Ausgabedaten Dr. Ina Schaefer Software Engineering 1 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 Software Engineering 1 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: 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) Dr. Ina Schaefer Software Engineering 1 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 Software Engineering 1 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 (Kriterien 1B, 2B, 3A+B, 4A, 5B) a == [11, 23, 0], k == 0, result == 2 (Kriterien 1B, 2B, 3B, 4B, 5A) Dr. Ina Schaefer Software Engineering 1 Seite 39
Strukturtest (glass-box) Programm- Code Testfälle (Eingabedaten) Programmausführung Ausgabedaten Vergleich Funktionale Spezifikation oder "Orakel" Erwartete Ausgabedaten Dr. Ina Schaefer Software Engineering 1 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 Software Engineering 1 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 Software Engineering 1 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) // 4 2 3 pos = m; // 5 else if (a[m] < k) // 6 ug = m + 1; // 7 else 5 4 6 7 8 og = m - 1; // 8 }; return pos; // 9 } Dr. Ina Schaefer Software Engineering 1 Seite 43 9
Anweisungsüberdeckender Test Überdeckung aller Anweisungen: C 0 -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 Software Engineering 1 Seite 44
Zweigüberdeckender Test Überdeckung aller Zweige: C 1 -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) Beispiel: y = true; // kein else-fall 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 Software Engineering 1 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 Software Engineering 1 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 Software Engineering 1 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 Software Engineering 1 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 Software Engineering 1 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 Software Engineering 1 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 Software Engineering 1 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 Software Engineering 1 Seite 52
Integrationstests Integrationstests betrachten das Zusammenspiel von Komponenten. Falls Komponenten nicht allein lauffähig sind, muss Testrahmen bereitgestellt werden. Platzhalter (Stubs) Ersetzen nicht Vorhandene Codeteile Testobjekt Laufzeitumgebung, Monitore (protokollieren Ausgaben) Testtreiber (Driver) Liefern Testdaten, Stossen Ausführung an Dr. Ina Schaefer Software Engineering 1 Seite 53
Top-Down Integrationsteststrategie Benötigt viele Stubs, wenige Testtreiber Testing Level 1 Level 1 sequence... Level 2 Level 2 Level 2 Level 2 Level 2 stubs Level 3 stubs Dr. Ina Schaefer Software Engineering 1 Seite 54
Bottom-Up Integrationsteststrategie Benötigt viele Testtreiber, keine Stubs Test drivers Level N Level N Level N Level N Level N Testing sequence Test drivers Level N 1 Level N 1 Level N 1 Dr. Ina Schaefer Software Engineering 1 Seite 55
Inkrementelle Integration Test, dass neue Komponente nicht bisheriges Zusammenspiel stört. A T1 A T1 A T1 T2 B T2 T2 B T3 B T3 C T3 T4 C T4 D T5 Test sequence 1 Test sequence 2 Test sequence 3 Dr. Ina Schaefer Software Engineering 1 Seite 56
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 Software Engineering 1 Seite 57
Abnahmetest wird vom Kunden vorgenommen Input: System Abnahmekriterien Testfälle Testplan Protokollvorlagen Systemdokumentation Abnahme -test Output: Testprotokolle Unterschriebenes Abnahmeprotokoll Abnahme ohne Mängel Abnahme mit Mängeln Abnahme verweigert Dr. Ina Schaefer Software Engineering 1 Seite 58
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 Software Engineering 1 Seite 59