Software Engineering. Produktqualität - Dynamische Testverfahren

Transkript

1 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 Prof. Dr. Andreas Schmietendorf 1

2 Inhaltsübersicht Motivation und Einführung Strukturtests Funktionale Tests Agile Testansätze Leistungstests nach DIN Prof. Dr. Andreas Schmietendorf 2

3 Motivation und Einführung Prof. Dr. Andreas Schmietendorf 3

4 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 ) 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 Prof. Dr. Andreas Schmietendorf 4

5 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) Prof. Dr. Andreas Schmietendorf 5

6 Klassifikation der SW-Tests Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II Prof. Dr. Andreas Schmietendorf 6

7 Testaktivitäten Prof. Dr. Andreas Schmietendorf 7

8 Strukturtests (White Box) Prof. Dr. Andreas Schmietendorf 8

9 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 Prof. Dr. Andreas Schmietendorf 9

10 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 Prof. Dr. Andreas Schmietendorf 10

11 Ü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 Prof. Dr. Andreas Schmietendorf 11

12 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 Prof. Dr. Andreas Schmietendorf 12

13 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 Prof. Dr. Andreas Schmietendorf 13

14 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 Prof. Dr. Andreas Schmietendorf 14

15 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? Prof. Dr. Andreas Schmietendorf 15

16 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 Prof. Dr. Andreas Schmietendorf 16

17 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 Prof. Dr. Andreas Schmietendorf 17

18 Toolunterstützung Beispiel ECLEmma: Java Code Coverage for Eclipse Quelle des Werkzeugs: Prof. Dr. Andreas Schmietendorf 18

19 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 Prof. Dr. Andreas Schmietendorf 19

20 Funktionale Tests (Black Box) Prof. Dr. Andreas Schmietendorf 20

21 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 Prof. Dr. Andreas Schmietendorf 21

22 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 Prof. Dr. Andreas Schmietendorf 22

23 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 Prof. Dr. Andreas Schmietendorf 23

24 Agile Testansätze (Test driven Development) Prof. Dr. Andreas Schmietendorf 24

25 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 Prof. Dr. Andreas Schmietendorf 25

26 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 Prof. Dr. Andreas Schmietendorf 26

27 Zertifizierung CAT Quelle: Prof. Dr. Andreas Schmietendorf 27

28 Leistungstest nach DIN (Black Box) Prof. Dr. Andreas Schmietendorf 28

29 Leistungstests nach DIN 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? Prof. Dr. Andreas Schmietendorf 29

30 Leistungstests nach DIN 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 Prof. Dr. Andreas Schmietendorf 30

31 Einsatzbereiche DIN 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, Prof. Dr. Andreas Schmietendorf 31