Software Engineering Produktqualität - Dynamische Testverfahren Die Inhalte der Vorlesung wurden primär auf Basis der jeweils angegebenen Literatur erstellt. Darüber hinaus finden sich ausgewählte Beispiele zur Softwareentwicklung aus dem Bereich der Telekommunikation. 25.09.2013 Prof. Dr. Andreas Schmietendorf 1
Inhaltsübersicht Motivation und Einführung Strukturtests Funktionale Tests Agile Testansätze Leistungstests nach DIN 25.09.2013 Prof. Dr. Andreas Schmietendorf 2
Motivation und Einführung 25.09.2013 Prof. Dr. Andreas Schmietendorf 3
Motivation zum Softwaretest Fehlgeschlagene Projekte - Gepäckabfertigungssystem des Flughafen Denver - Verlust der Ariane 5 Rakete - 1h Systemausfall im Börsenhandel Verlust von 7,8 Mio. US-$ (FAZ 17.01.2002) Unzufriedene Benutzer - Bananen-Software reift beim Kunden - Verspätete Einführungen der Software - Hohe Kosten für Support-Organisationen Hohe Aufwände für spätere Anpassungen - Beispiel Jahr 2000 oder die Euroumstellung 25.09.2013 Prof. Dr. Andreas Schmietendorf 4
Fehler und Fehlerfreiheit Ein Fehler ist jede Abweichung der tatsächlichen Ausprägung einer Qualitätseigenschaft (z.b. Funktionalität, Übertragbarkeit, Effizienz) von einer explizit oder implizit geforderten Eigenschaft. Program testing can be used to show the presence of bugs, but never to show their absence. (E. Dijkstra) 25.09.2013 Prof. Dr. Andreas Schmietendorf 5
Klassifikation der SW-Tests Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II 25.09.2013 Prof. Dr. Andreas Schmietendorf 6
Testaktivitäten 25.09.2013 Prof. Dr. Andreas Schmietendorf 7
Strukturtests (White Box) 25.09.2013 Prof. Dr. Andreas Schmietendorf 8
Testabdeckung coverage level Anweisungsüberdeckungstest, jede Anweisung (d.h. alle Knoten des Kontrollflussgraphen) wird einmal ausgeführt. Zweigüberdeckungstest, jeder Zweig (d.h. alle Kanten des Kontrollflussgraphen) wird einmal durchlaufen. Pfadüberdeckungstest, jeder Pfad im Kontrollflussgrafen muss einmal durchlaufen werden. Der Überdeckungsgrad (coverge level c0 bis c7) gibt an, wie viele Anweisungen / Zweige / Pfade durchlaufen wurden. Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II 25.09.2013 Prof. Dr. Andreas Schmietendorf 9
Aufgabenstellung float Wurzel(float Zahl) { float Wert = 0.0; if (Zahl > 0) { Wert = 2.0; while (abs(wert * Wert - Zahl) > 0.01) { Wert = Wert - ((Wert * Wert - Zahl)/(2.0 * Wert)); } //end while } //end if return Wert; } Gegeben ist das folgende Programm. Es berechnet für nicht negative reelle Radikanden die reelle Quadratwurzel, die als Funktionswert zurückgeliefert wird. Werden negative Werte übergeben, so wird als Ergebnis der Wert 0 zurückgegeben. Quelle: H. Balzert: Lehrbuch der Software-Technik 25.09.2013 Prof. Dr. Andreas Schmietendorf 10
Überführung in ein Kontrollflussplan float Wurzel(float Zahl) { float Wert = 0.0; if (Zahl > 0) { Wert = 2.0; while (abs(wert * Wert - Zahl) > 0.01) { Wert = Wert - ((Wert * Wert - Zahl)/(2.0 * Wert)); } //end while } //end if return Wert; } Knoten Kante n1 n2 n3 n4 n5 n6 n Start float Wert = 0.0; if (Zahl > 0) { Wert = 2.0; while {abs(wert*wert-zahl) > 0.01) { Wert = Wert - ((Wert*Wert- Zahl)(2.0*Wert)); } end while Pfad Knoten stellen ausführbare Anweisungen dar. n7 } end if Eine gerichtete Kante von einem Knoten i zu einem Knoten j beschreibt einen möglichen Kontrollfluss. n8 return Wert; Eine abwechselnde Folge von Knoten und Kanten, die mit einem Startknoten beginnt und mit einem Endeknoten endet, heißt Pfad. n Final 25.09.2013 Prof. Dr. Andreas Schmietendorf 11
Aufgabenstellung 9-1 Erstellen Sie einen Kontrollflussgraph für die folgende Prozedur zur Berechnung des größten gemeinsamen Teilers: int berechneggt(int zahla, int zahlb){ if (zahla > 0 && zahlb > 0){ while (zahla!= zahlb){ while (zahla > zahlb){ zahla -= zahlb; } while (zahlb > zahla){ zahlb -= zahla; } } } else{ zahla = 0; } return zahla; } Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II 25.09.2013 Prof. Dr. Andreas Schmietendorf 12
Anweisungsüberdeckungstest C 0 -Test float Wurzel(float Zahl) { float Wert = 0.0; if (Zahl > 0) { Wert = 2.0; while (abs(wert * Wert - Zahl) > 0.01) { Wert = Wert - ((Wert * Wert - Zahl)/(2.0 * Wert)); } //end while } //end if return Wert; } Übung: Welcher Testfall stellt für die gegebene Beispielprozedur einen Anweisungsüberdeckungstest dar? Wie sieht der dabei durchlaufene Pfad aus? Zwei von n2 nach n7 wird nicht zwingend durchlaufen 25.09.2013 Prof. Dr. Andreas Schmietendorf 13
Bewertung Bewertung des Anweisungsüberdeckungstests - 100%ige Anweisungsüberdeckung stellt sicher, dass im Prüfling keine Anweisungen existieren, die niemals ausgeführt werden. - Weder Kontrollstrukturen noch Datenabhängigkeiten zwischen Programmteilen werden berücksichtigt. - Jede Anweisung wird gleichgewichtig gewertet. Konsequenzen: - Notwendiges, aber nicht hinreichendes Testkriterium - Nicht ausführbarer Code kann gefunden werden - Kein eigenständiges Testverfahren; Bestandteil anderer Tests Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II 25.09.2013 Prof. Dr. Andreas Schmietendorf 14
Zweigüberdeckungstest C 1 -Test float Wurzel(float Zahl) { float Wert = 0.0; if (Zahl > 0) { Wert = 2.0; while (abs(wert * Wert - Zahl) > 0.01) { Wert = Wert - ((Wert * Wert - Zahl)/(2.0 * Wert)); } //end while } //end if return Wert; } Übung: Welcher Testfall stellt hier einen Zweigüberdeckungstest dar? Wie sieht der dabei durchlaufene Pfad aus? 25.09.2013 Prof. Dr. Andreas Schmietendorf 15
Bewertung Bewertung des Zweigüberdeckungstests - Sicherstellung, dass keine Zweige existieren, die niemals ausgeführt werden. - Schleifen werden nicht ausreichend getestet, da ein einziger Durchlauf zur Erfüllung der Zweigüberdeckung ausreicht. - Kann durch Werkzeugeinsatz (Instrumentierung) unterstützt werden. Konsequenzen: - minimales Testkriterium - Nicht ausführbare Programmzweige können gefunden werden. - Korrektheit des Kontrollflusses kann überprüft werden. - Oft durchlaufene Programmteile können erkannt und optimiert werden. - Unzureichend für den Test von Schleifen und komplexen Bedingungen. Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II 25.09.2013 Prof. Dr. Andreas Schmietendorf 16
Pfadüberdeckungstest float Wurzel(float Zahl) { float Wert = 0.0; if (Zahl > 0) { Wert = 2.0; while (abs(wert * Wert - Zahl) > 0.01) { Wert = Wert - ((Wert * Wert - Zahl)/(2.0 * Wert)); } //end while } //end if return Wert; } Konsequenz: Aufgrund der hohen Anzahl von Testpfaden und der damit verbundenen eingeschränkten Durchführbarkeit hat der Pfadüberdeckungstest in dieser Form keine praktische Bedeutung. 25.09.2013 Prof. Dr. Andreas Schmietendorf 17
Toolunterstützung Beispiel ECLEmma: Java Code Coverage for Eclipse Quelle des Werkzeugs: http://www.eclemma.org/index.html 25.09.2013 Prof. Dr. Andreas Schmietendorf 18
Weitere Strukturtests Boundary-Interior-Pfadtest (eingeschränkter Pfadüberdeckungstests) - Schleifen werden dabei maximal einmal wiederholt - Zwei Gruppen von Pfaden werden betrachtet Grenztest-Gruppe (boundary test) Gruppe zum Test des Schleifeninneren (interior test) Bedingungsüberdeckungstest - Alle atomaren Bedingungen müssen mind. einmal wahr und falsch sein. - Problem: Es werden Zweige nicht erfasst! Minimaler Mehrfach-Bedingungsüberdeckungstest Datenflussorientierte Strukturtestverfahren 25.09.2013 Prof. Dr. Andreas Schmietendorf 19
Funktionale Tests (Black Box) 25.09.2013 Prof. Dr. Andreas Schmietendorf 20
Funktionale Testverfahren Test gegen die Spezifikation - Interne Programmstruktur bleibt unberücksichtigt - Betrachtung des Programms als geschlossene Einheit - Bedarf einer vollständigen und widerspruchsfreien Spezifikation Prinzipien zur Ableitung von Testdaten - Orientierung auf Normalwerte - Orientierung auf Extremwerte - Orientierung auf Falschwerte Problem: Testvollständigkeit schwierig zu messen 25.09.2013 Prof. Dr. Andreas Schmietendorf 21
Bildung von Äquivalenzklassen Zusammenhängende Werte: Eine gültige und 2 ungültige Äquivalenzklassen (ÄK) Bsp: Eingabe: 1<= Tage <= 31 gültige ÄK: 1<= Tage <= 31, ungültige ÄK: Tage <1, Tage > 31 Anzahl von Werten: Eine gültige und 2 ungültige Äquivalenzklassen Bsp.: Auto hat 1 bis 6 Besitzer gültige ÄK: 1 bis 6 Besitzer, ungültige ÄK: Kein Besitzer, mehr als 6 Besitzer Menge von unterschiedlich zu verarbeitenden Werten: Für jeden Wert eine gültige und insgesamt eine ungültige ÄK Bsp.: Tasteninstrumente: Klavier, Cembalo, Spinett, Orgel gültige ÄK: Klavier, Cembalo, Spinett, Orgel; ungültige ÄK: Violine Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II 25.09.2013 Prof. Dr. Andreas Schmietendorf 22
Grenzwertanalyse Die Grenzwertanalyse basiert auf einer Äquivalenzklassenbildung Es werden Werte gesucht, die sich auf die Ränder einer Äquivalenzklasse zubewegen. Eine Annäherung ist von einem gültigen Bereich, als auch von einem ungültigen Bereich möglich. Notwendig zur Durchführung einer Grenzwertanalyse ist die Möglichkeit, die Elemente einer Äquivalenzklasse auf natürliche Weise zu ordnen. 25.09.2013 Prof. Dr. Andreas Schmietendorf 23
Agile Testansätze (Test driven Development) 25.09.2013 Prof. Dr. Andreas Schmietendorf 24
Verwendete Testtypen Modul- und Integrationstests (Unit-Tests) - Testtreiber für implementierte Klassen - Schnelles Feedback zur Funktionsweise - Wichtiges Element während des Refactorings Akzeptanztests - Tests des Systems aus Sicht des Anwenders - Bezugnahme auf GUI und/oder Fachlogik - Beteiligung des Kunden/Anwenders 25.09.2013 Prof. Dr. Andreas Schmietendorf 25
Notwendige Testautomation Implementierung und Ausführung der Testfälle Verwaltung des Testerfolgs und Testfortschritts Bereitstellung/Konfiguration von Testdaten Dokumentation von Tests Beispiele für Testwerkzeuge (Frameworks): JUnit soapui WinRunner 25.09.2013 Prof. Dr. Andreas Schmietendorf 26
Zertifizierung CAT Quelle: http://www.agile-tester.org/syllabus.html 25.09.2013 Prof. Dr. Andreas Schmietendorf 27
Leistungstest nach DIN (Black Box) 25.09.2013 Prof. Dr. Andreas Schmietendorf 28
Leistungstests nach DIN 66273 Für den Anwender sind im wesentlichen endbenutzerorientierte Größen relevant, da nur diese eine Antwort auf die zentrale Frage der Anwender geben können [Dirlewanger 1994b]: Ist das betrachtete DV System imstande, die Menge der ihm insgesamt von der Benutzerschaft übertragenen Aufträge zu bewältigen und dabei jeden einzelnen Auftrag in so kurzer Zeit auszuführen, daß der vom jeweiligen Auftraggeber benötigte betriebliche Nutzen voll eintritt? 25.09.2013 Prof. Dr. Andreas Schmietendorf 29
Leistungstests nach DIN 66273 erster nationaler Standard für die Leistungsbewertung Bezug auf konkrete Anwendung unabhängig von konkreter Rechnerarchitektur Endbenutzerorientierte Leistungswerte Verwendung der gesamten Benutzerschaft Lasttreiber verwendete Bewertungen/Maße - Durchsatz L1 als Anzahl der pro Zeiteinheit bearbeiteten Aufträge, - Durchlaufzeit L2 als Mittelwert der Auftragsdurchlaufzeiten (Antwortzeit), - Termintreue L3 Durchsatz pünktlich erledigter Aufträge 25.09.2013 Prof. Dr. Andreas Schmietendorf 30
Einsatzbereiche DIN 66273 Vergleich und Bewertung von Rechnersystemen zur leistungsgerechtenauswahl bei der Anschaffung, Vergleich und Bewertung von kompletten Rechnersystemen inklusive Betriebssystem, Systemsoftware und Anwendungssoftware, Vergleich und Bewertung der Effizienzeigenschaften von Anwendungssoftware bei Auswahl und Anschaffung, Abnahmeprüfung auf Erreichung der zugesicherten Leistungseigenschaften, 25.09.2013 Prof. Dr. Andreas Schmietendorf 31