Formale Methoden

1. Formale Methoden Vorlesung 02: Testen von Software

2. Inhalt • Motivation • Testverfahren • Fehlertests • Black-Box-Tests • Äquivalenzklassen • Strukturelle Tests • Pfadüberdeckungstests • Integrationstests • Top-Down und Buttom-Up-Tests • Testen von Schnittstellen • Belastungstests • Objektorientiertes Testen • Testen von Objektklassen • Objektintegration • Werkzeugsammlung für den Softwaretest • NUnit

3. Motivation • Keine Zeit für einen Test?

4. Motivation • Tests führen zu weniger Stress

5. Testverfahren • Fehlertests • Black-Box-Tests • Äquivalenzklassen • Strukturelle Tests • Pfadüberdeckungstests • Integrationstests • Top-Down und Buttom-Up-Tests • Testen von Schnittstellen • Belastungstests • Tests zeigen das Vorhandensein, nicht die Abwesenheit von Programmfehlern.

6. Fehlertests • Ziel Auffinden von versteckten Fehlern im System vor seiner Auslieferung Testobjekte Softwaresysteme Verlauf • Testfälle erstellen • Testdaten erstellen • Programm mit Daten ausführen • Ergebnisse mit Testfallergebnissen vergleichen • Testprotokoll erstellen • Probleme Automatische Generierung der Testfälle ist nicht möglich. Wirklich vollständige Tests sind auch nicht möglich

7. Black-Box-Tests • Bekannt auch als: Funktionale Tests • Ziel Testen auf die Funktionalität • Testobjekte Funktionen, organisierte und objektorientierte Systeme. • Verlauf Man gibt Daten in das System ein und untersucht die Ausgaben. Wenn die Ausgaben nicht mit den Vorhersagen übereinstimmen, dann hat man erfolgreich ein Problem aufgedeckt. • Probleme Die Auswahl von Eingaben die mit hoher Wahrscheinlichkeit die Fehleingaben auslösen würden.

8. Black-Box-Tests • Unterscheidung der Blackbox-Testfallentwurfsmethoden • Äquivalenzklassenbildung • Ziel der Äquivalenzklassenbildung ist es, durch Bildung von Äquivalenzklassen eine hohe Fehlerentdeckungswahrscheinlichkeit mit einer minimalen Anzahl von Testfällen zu erreichen. Grenzwertanalyse • Ziel der Grenzwertanalyse ist es, Testfälle zu definieren, mit denen Fehler im Zusammenhang mit der Behandlung der Grenzen von Wertebereichen aufgedeckt werden können. Intuitive Testfallermittlung • Zielsetzung der intuitiven Testfallermittlung ist es, systematisch ermittelte Testfälle qualitativ zu verbessern und ergänzende Testfälle zu ermitteln. Funktionsabdeckung • Ziel der Funktionsabdeckung ist es, Testfälle zu identifizieren, mit denen nachgewiesen werden kann, daß die jeweilige Funktion vorhanden und auch ausführbar ist. Hierbei wird der Testfall auf das Normalverhalten und das Ausnahmeverhalten des Prüfgegenstandes ausgerichtet.

9. Äquivalenzklassen • Äquivalenzklassen: • Verschiedene Klassen, die gemeinsame Eigenschaften haben und sich für alle Mitglieder einer Klasse von Eingaben vergleichbar verhalten nennt man manchmal Äquivalenzklassen. • Kurz: Gruppierung nach gemeinsamen Eigenschaften. • Testobjekte: • Programm, System, in sich abgeschlossenes Modul Verlauf: • Analyse der Dateneingabeanforderungen, der Datenausgabeanforderungen und der Bedingungen gemäß den Spezifikationen • Bestimmung der Äquivalenzklassen durch Einteilung der Wertebereiche für Ein- und Ausgabegrößen • Aus jeder Klasse Testfälle auswählen • An den Grenzen von Klassen • In der Mitte der Klassen • System testen

10. Äquivalenzklassen • Beispiel • Suchroutine procedure Search(key, liste, out bool L, out int index) { if(liste.first <= liste.last) // liste hat mindestens ein Element, fortfahren Found: L=true; index=i; not Found and not exists i, liste.first<= i <= liste.last ? L=false; } • Offensichtliche Äquivalenzklassen: • Schlüsselelement ist ein Mitglied der Liste (Found = true) • Schlüsselelement ist kein Mitglied der Liste (Found = false)

11. Array Einzelner Wert Einzelner Wert Mehr als 1 Wert Mehr als 1 Wert Mehr als 1 Wert Mehr als 1 Wert Element In der Liste vorhanden Nicht in der Liste Erstes Element in der Liste Letztes Element in der Liste Mittleres Element in der Liste Nicht in der Liste Äquivalenzklassen Weitere Äquivalenzklassen für die Suchroutine

12. Strukturelle Tests • Bekannt auch als: White-, Glass- oder auch Clear-Box-Test • Testobjekte: • Kleine Programmeinheiten wie Unterroutinen oder die zu einer Klasse gehörende Methoden. • Testverlauf: • Aus dem Testobjekt leitet man die Testdaten ab • Testausgabe wird durch das Testen des Testobjektes mit den Testdaten erzeugt.

13. Strukturelle Tests • Beispiel: Testobjekt: • Binärsuche

14. Pfadüberdeckungstests • Testobjekte: • meist in den Stufen des Einzel- und Modultests eingesetzt • Jeder einzelne unabhängige Pfad Verlauf: • Kontrollflussgraph erstellen • Knoten (Entscheidungen), Kanten (Fluss der Steuerung) • Zuweisungen, Prozeduraufrufe, I/O können ignoriert werden • Feststellen der unabhängige Programmpfade • Entwurf von Testfällen für die einzelnen Programmpfad • Testen • Probleme: • Mögliche Pfade ist Proportional zu seiner Größe. Bei Integration der Module zu Systemen wird Strukturelles Testen praktisch unmöglich. Zyklomatische Komplexität (Cyclomatic Complexity - CC): CC(D)=Anzahl(Kanten)-Anzahl(Knoten)+2

15. Pfadüberdeckungstests • Beispiel • Testobjekt: • Binärsuche Verlauf 1, 2, 3, 8, 9 1, 2, 3, 4, 6, 7, 2 1, 2, 3, 4, 5, 7, 2 1, 2, 3, 4, 6, 7, 2, 8, 9 • Alle Anweisungen mindestens einmal ausgeführt • Jeder Zweig mit wahren und falschen Bedingungen ausgeführt CC(D)=11-9+2=4

16. Integrationstests • Testobjekt: • Zusammengesetzte Programmkomponenten, Teilsysteme. • Vorgehen • Nach Komponententest werden diese Integriert • Zusammengesetze Testobjekt wird getestet • Problem: • Das Auffinden der bei der Integrationstests aufgedeckte Fehler

17. Integrationstests

18. Top-Down und Bottom-Up-Tests • Top-Down-Integrationstests • Ist ein Bestandteil eines Entwicklungsprozesses, bei dem man mit den übergeordneten Komponenten beginnt und sich nach unten durchgearbeitet

19. Top-Down und Bottom-Up-Tests • Bottom-Up-Integrationstests • Integration und Tests der Module finden auf der unteren Ebene der Hierarchie statt und man arbeitet sich aufwärts

20. Top-Down und Bottom-Up-Tests • Top-down- und Bottom-up-Integrationstests im Vergleich

21. Testen von Schnittstellen • Ziel • Entdeckung von Fehlern, die durch Schnittstellenfehler oder ungültige Annahmen über die Schnittstellen in das System geraten sein können • Testobjekt: • größere Systeme die aus Modulen oder Teilsystemen gebildet sind

22. Testen von Schnittstellen • Verschiedene Arten der Schnittstellen • Parameterschnittstellen • Daten, Funktionsreferenzen • Schnittstellen über gemeinsamen Speicher • „shared memory“ • Prozedurschnittstellen • Objekte oder abstrakte Datentypen mit gekapselten Prozeduren • Schnittstellen zur Nachrichtenübertragung • Client-/Server-Architekturen, RPC, RMI, …

23. Testen von Schnittstellen • Fehlerarten bei Schnittstellentests • Falsche Verwendung der Schnittstelle • Aufruf falscher Schnittstellen • Falsche Verwendung der Schnittstellen • Falsche Parametertypen • Schnittstellenmissverständnisse • Falsches Verhalten voraussetzen, Beispiel: Binärsuche in ungeordnetem Array • Synchronisationsfehler • In Echtzeitsysteme wo Konsument und Produzent mit verschiedener Geschwindigkeit arbeiten

24. Belastungstests • Testobjekt: • Fertige Systeme • Verteilte Systeme, Netzwerk von Prozessen Verlauf: • Das System bis zur Entwurfsgrenze belasten • Das System bis zum Systemausfall belasten Gründe: • Für den fall wenn es mal nötig ist • Sanfter Ausfall • Fehler ans Licht bringen Beispiele: • 100 Transaktionen pro Sekunde • System bedienbar mit 200 Terminals

25. Objektorientiertes Testen • Unterschiede zwischen objektorientierten und funktionellen Modellen • Objektklassen sind als Einzelkomponenten oft größer als einzelne Funktionen • Zu Subsystemen integrierte Objekte sind meist nur lose verbunden, und es gibt keine offensichtliche Systemhierarchie • Wenn Objektklassen wiederverwendet werden, steht den Testern zur Analyse möglicherweise kein Quellcode zur Verfügung

26. Objektorientiertes Testen • Testebenen eines objektorientierten Systems • Testen der einzelnen, zu Objekten gehörenden Operationen • Testen einzelner Objektklassen • Testen von Objektclustern • Testen des objektorientierten Systems

27. Testen von Objektklassen • Testobjekt: • Objektklassen Vollständige Testabdeckung von Objektklassen: • Das isolierte Testen aller zum Objekt definierten Operationen • Das Setzen und das Abfragen aller Attribute des Objekts • Die Ausführung des Objekts in allen möglichen Zuständen. Dies bedeutet, dass alle den Zustand des Objekts verändernden Ereignisse simuliert werden sollten Probleme: • Durch Vererbung wird das Testen aller Zustände erschwert, die Oberklassen müssen dann auch getestet werden

28. Testen von Objektklassen • Beispiel: Wetterstation

29. Objektintegration • Top-down- und Bottom-Up-Integrationstests sind in OO- Systemen nicht wirklich angemessen, da es kein offensichtliches „Top“ gibt, welches das Ziel darstellen könnte. • Mögliche Ansätze von Integrationstests für Objektintegration • Anwendungsfall- oder szenariobasierte Tests • Aus den Anwendungsfällen oder Szenarien abgeleitete Tests • Thread-Tests • OO Systeme sind meist Ereignisgesteuert, man muss feststellen, wie die Verarbeitung der Ereignisse ihren Weg durch das System nimmt. • Tests der Wechselwirkung zwischen Objekten • Ansatz von Jorgensen und Erickson(1994)

30. Objektintegration • Jorgens und Erickson (1994) • Eine Zwischenstufe der Integrationstests auf der Feststellung von „Methoden-Nachricht“-Pfaden beruhen können. Dies sind Wege durch eine Abfolge von Wechselwirkungen der Objekte, die dort enden, wo eine Objektoperation keinen weiteren Dienst eines anderen Objekts aufruft. • In diesem Kontext wird ein neues Konstrukt eingeführt, welches „Atomare Systemfunktion“ ASF genannt wird. • ASF besteht aus einem Anfangsereignis, dem mehrere Methode-Nachrichten-Pfade folgen, die mit einem Endereignis abschließen. (Ähnlich der Vorstellung eines Threads in einem Echtzeitsystem)

31. Objektintegration • Beispiel: Wetterstation • szenariobasiertes Testen • KommSteuerung.anfordern() • WetterStation.wetterBerichten() • WetterDaten.zusammenfassen()

32. Objektintegration • Beispiel: Wetterstation • Sequenzdiagramm zur Feststellung der Ein- und Ausgaben: • 1) Anfordern eines Berichtes • Sollte eine Bestätigung auslösen • Am Ende sollte ein Bericht zurückgegeben werden • 2) Beim Eingang einer Berichtsanfrage • Erstellung eines zusammenfassenden Berichts • isoliert testen möglich, indem man die zusammenfassenden Daten vorbereitet 3) Testen des Objekts WetterDaten • Die Rohdaten können hier ebenfalls zum Testen des Objekts verwendet werden.

33. Werkzeugsammlung für den Softwaretest • Testen ist eine teure und aufwändige Phase des Softwareprozesses • Daher bedient man sich schon entwickelter Testwerkzeuge: • Testmanager (Verwaltet Programmtests) • Testdatengenerator (Verwendung von Datenbanken/Mustern) • Orakel (Heuristische Voraussagen über Testergebnisse BB-Tests) • Dateivergleichswerkzeug (Unterschiede aufzeigen) • Protokollgenerator (Erzeugung aus Testergebnissen) • Dynamische Analysewerkzeug (Codehinzufügen zum Protokollieren) • Simulator (Handys, Browser)

34. Werkzeugsammlung für den Softwaretest • Eine Werkzeugsammlungfür den Softwaretest

35. Werkzeugsammlung für den Softwaretest • Zum Testen bestimmter Eigenschaften der Anwendung müssen neue Werkzeuge hinzugefügt werden. Einige der schon Vorhandenen Werkzeuge werden hingegen nicht mehr benötigt. • Es müssen Skripts zur Simulierung der Bedienoberfläche geschrieben und Erzeugungsmuster für den Testdatengenerator festgelegt werden. Manchmal ist es außerdem erforderlich, Protokollformate zu definieren. • Wenn keine früheren Protokollversionen als Orakel zur Verfügung stehen, müssen Sätze von erwarteten Ergebnissen manuell vorbereitet werden. • Es müssen besondere Dateivergleichswerkzeuge geschrieben werden, die Wissen über die Struktur der zu vergleichenden Testergebnisse enthalten.

36. Beispiel mit NUnit • Durch Unit-Tests ist es möglich, Testklassen zu schaffen, die automatisiert andere, vorhandene Klassen testen. • Verschiedene Unit-Test-Werkzeuge: • SUnit für Smalltalk • JUnit für Java • CPPUnit für C++ • NUnit für .NET • So werden pro Testklasse folgende Dinge der zu testenden Klasse angegeben und getestet: • alle Methoden • alle Überladungen • in allen erdenklichen Übergabeparametern (auch sinnlosen Varianten)

37. Beispiel mit NUnit • [TestFixture] • public class MyTest • { • protected int fValue1; • [SetUp] public void Init() • { • fValue1= 2; • } • [Test] public void Add() • { • double result= fValue1 + fValue1; • Assert.AreEqual(4, result, "ok"); • } • [Test] public void Equals() • { • Assert.AreEqual(12, 13, "Expected Failure (Integer)"); • } • }

38. Beispiel mit NUnit

39. Beispiel mit NUnit • Nutzung mit VisualStudio .Net 2005 • NUnit • http://www.nunit.org • AddOnhttp://www.testdriven.net

40. Literatur • Software Engineering 6. Auflage(Ian Sommerville, 2001, Pearson Education) • www.informatik.uni-bremen.de/uniform/gdpa_d/methods_d/m-bbtd.htm • http://de.wikipedia.org/wiki/Test_(Informatik) • www.Nunit.org • www.TestDriven.net • www.comp.lancs.ac.uk/computing/resources/IanS/SE6/Slides/index.html • ScreenShots mit Hilfe von DarkShot2www.darkleo.com/darkleo/download/darkshot.htm