Algorithmen und Programmieren II SS 2008 Objektorientierte Programmierung Softwaretest 03.07.2008 Softwaretest Ingo Dageförde 1
Agenda VL Softwaretest am 03.07.2008 Qualitätssicherung in der Softwareentwicklung Softwaretests warum und wieso? Arten von Softwaretests Einführung in Softwaretests mit JUnit Beispiel in JUnit Zusammenfassung 03.07.2008 Softwaretest Ingo Dageförde 2
Qualitätssicherung in der Softwareentwicklung (1) Wiederverwendung: Bestehende Software darf nicht unbesehen für eine neue Aufgabe wiederverwendet werden. Vorher muss geprüft werden, ob ihre Fähigkeiten den Anforderungen der neuen Aufgabe entsprechen Spezifikation: Die Fähigkeiten einer Software sowie alle Annahmen, die sie über ihre Umgebung macht, müssen sauber spezifiziert sein. Andernfalls ist die Prüfung auf Wiederverwendbarkeit extrem aufwendig. Dokumentation: Kooperieren zwei Software-Komponenten miteinander, so müssen eindeutige Zusammenarbeitsregeln definiert, dokumentiert und eingehalten werden: Wer liefert wem was unter welchen Bedingungen. 03.07.2008 Softwaretest Ingo Dageförde 3
Qualitätssicherung in der Softwareentwicklung (2) Fehlerbehandlung: Jede potentielle Fehlersituation in einer Software muss entweder behandelt werden oder die Gründe für die Nichtbehandlung müssen so dokumentiert werden, dass die Gültigkeit der dabei getroffenen Annahmen überprüfbar ist. Fehlertoleranz: Mehrfache identische Auslegung von Systemen hilft nicht gegen Entwurfsfehler. Sicherer Zustand: Bei Störungen in sicherheitskritischen Systemen ist Abschalten nur dann eine zulässige Maßnahme, wenn dadurch wieder ein sicherer Zustand erreicht wird. 03.07.2008 Softwaretest Ingo Dageförde 4
Qualitätssicherung in der Softwareentwicklung (3) Systemtest: Beim Test von Software, die aus mehreren Komponenten besteht, genügt es nicht, jede Komponente nur isoliert für sich zu testen. Umfangreiche Systemtests unter möglichst realistischen Bedingungen sind notwendig. Review: Jedes Programm muss - neben einem sorgfältigen Test durch kompetente Fachleute inspiziert werden, weil insbesondere die Erfüllbarkeit und Adäquatheit von Annahmen und Ergebnissen häufig nicht testbar ist. Effektivität: Software, die nicht benötigt wird, sollte auch nicht eingesetzt werden. 03.07.2008 Softwaretest Ingo Dageförde 5
Qualitätssicherung in der Softwareentwicklung (4) Risikomanagement: Die Risiken erkennen, angemessene technische Maßnahmen planen, durchsetzen und überprüfen. Kostenmanagement: Die Kosten einer vorbeugenden Maßnahme in Relation zu den Kosten eines Fehlers sehen Qualitätsmanagement: Integriertes Qualitätsmanagement für alle Phasen des Systementwurfs -> Vertiefung in VL zur Softwaretechnik 03.07.2008 Softwaretest Ingo Dageförde 6
Tests warum und wieso? Softwareprodukte werden heutzutage immer komplexer wie z.b. Ariane 5 oder Campus Management :-) (Programmfehler!) Die meisten Programme enthalten Fehler (sic!), da komplexe Software in begrenzter Zeit nur unvollständig erfassbar und realisierbar ist Programme sollten getestet werden, um Fehler aufzudecken, um so ein Mindestmaß an Softwarequalität sicherzustellen Ein Test ist erfolgreich, wenn ein Fehler gefunden wurde Durch Testen kann man nicht die Korrektheit eines Programms beweisen, sondern nur seine Fehlerhaftigkeit Fehlermeldungen und anschliessendes Debugging sind zu spät und kosten viel Zeit und Geld und führen nur Nichtabnahme oder Nichtakzeptanz beim Kunden/Nutzer 03.07.2008 Softwaretest Ingo Dageförde 7
Tests was sollte er, was sollte er nicht? Fehler so früh wie möglich finden Unabhängig erfolgen Mehr bringen als kosten Automatisiert wiederholbar sein Möglichst zeitnah zur Programmierung sein Spaß machen Er sollte NICHT -> keine Fehler finden! 03.07.2008 Softwaretest Ingo Dageförde 8
Arten von Tests Unit-Test bzw. Modul-Test Verifikation der Korrektheit einzelner Softwarebausteine (Module bzw. Klassen Ausführbarer Code spielt Testfälle durch und vergleicht die Ergebnisse mit den erwarteten Werten Zeitnah zur Programmierung und nach jeder Modifikation Integrationstest Test der korrekten Interaktion mehrerer voneinander abhängiger Module bzw. Komponenten nach deren erfolgreich abgeschlossenen Unit-Test für fehlerfreie isolierte Funktionalität Systemtest Test des Gesamtsystems (im Labor ) 03.07.2008 Softwaretest Ingo Dageförde 9
Arten von Tests Performance-Tests Test des Verhaltens einzelner Module oder Systeme bezüglich einer definierten Hardwareumgebung Test, ob vom Kunden gewünschte Reaktionszeit eingehalten wird und auch unter hoher Auslastung keine Fehler produziert werden Funktionale bzw. Feldtest Test der vom Kunden gewünschten Funktionalität des Systems unter Real-Bedingungen Test, ob das entwickelte System den Anforderungen des Auftraggebers oder späteren Benutzers entspricht -> Pflichtenheft! 03.07.2008 Softwaretest Ingo Dageförde 10
Unit-Tests Beim Unit-Test wird jede Methode einer Klasse systematisch getestet und zwar bzgl. der gegebenen (informellen oder formalen) Spezifikation Logischer Unit-Test Überprüft nur einzelne Methoden bestimmter Klassen Integrations Unit-Test Überprüft das Zusammenspiel zwischen den einzelnen Komponenten Funktionaler Unit-Test Erweitert die Grenzen des logischen Unit-Tests und Integrations Unit- Tests so, dass Arbeitsabläufe getestet werden können Die einzelnen Arten von Unit-Tests können als White-Box-Test oder Black- Box-Test durchgeführt werden 03.07.2008 Softwaretest Ingo Dageförde 11
Whitebox-Test Test des Rumpfes der Methode Es soll eine möglichst repräsentative und vollständige Menge von Fällen getestet werden Beim Whitebox-Test sind das z.b. alle möglichen unterschiedlichen Fälle von Abläufen eines Programms Beispiel: Das Programmfragment while(b) {A C besitzt die unterschiedlichen Abläufe C und AC, AAC,... Man sollte zumindest den Abbruchfall testen, sowie einen Schleifendurchlauf und dann Abbruch (als Grenzfall) sowie mehrere Schleifendurchläufe und dann Abbruch. 03.07.2008 Softwaretest Ingo Dageförde 12
Whitebox-Test Beispiel Quersumme Int quersumme(int x) { int qs = 0; while(x > 0) { qs= qs + x % 10; x = x / 10; return qs; Wahl der Testfälle aufgrund der Codestruktur Mögliche Testfälle: Abbruchfall: x<=0 Wähle x=0 und z.b. x=-1 1 und mehrere Schleifendurchläufe: (x=1, x=9, x=12, x=352) 03.07.2008 Softwaretest Ingo Dageförde 13
Blackbox-Test Beim Blackbox-Test werden für jede Methode Spezialfälle der Spezifikation getestet. Die Implementierung der Methoden wird NICHT und darf NICHT berücksichtigt werden Für jede Methode werden nur deren Parameter und deren Datentypen betrachtet. Um eine möglichst vollständige Testabdeckung zu erreichen, sollte für jeden Parameter im Kopf der Methode gewählt werden: Ein Standardwert in der Mitte des Datenbereichs Grenzwerte des Datenbereichs bzw. des Definitionsbereichs Bei induktiven Datentypen Werte für jeden Konstruktor Beispiel:Für einen Parameter int p mit Def.bereich{0,..., 100 testet man z.b. die Werte 1, 0, 38, 100, 101. Analog testet man bei einem Array int[] a die Werte a[0], a[length/2],, a[length-1] 03.07.2008 Softwaretest Ingo Dageförde 14
Herleitung der Testfälle - Äquivalenzklassenmethode Wichtig sind richtige Testfälle, die nicht das selbe Verhalten abprüfen, sondern möglichst jedes Verhalten Bei der Äquivalenzklassenmethode werden Eingabeparameter einer Methode, die das gleiche Verhalten haben, in Klassen eingeteilt Die Spezifikation schreibt z.b. vor, dass nur Werte von 0,01 bis 500 verarbeitet werden sollen Man bildet daraus 3 Äquivalenzklassen, die das gleiche Verhalten aufweisen sollen 0,01 <= x <= 500 x <= 0 x > 500 03.07.2008 Softwaretest Ingo Dageförde 15
Herleitung der Testfälle - Grenzwertanalyse Grenzwertanalyse ist eine Erweiterung der Äquivalenzklassenmethode Hierbei werden zusätzlich besonders die Grenzen der Spezifikation betrachtet Unser Beispiel schrieb vor, dass nur Werte von 0,01 bis 500 verarbeitet werden sollen Man würde die 3 Testfälle für die Äquivalenzklassen, um folgende Testfälle erweitern: - 0,01 0,00 0,01 500,00 500,01 03.07.2008 Softwaretest Ingo Dageförde 16
JUnit JUnit ist ein Open Source Framework zur Durchführung und Automatisierung von Unit-Tests für Java als Black-Box-Tests Entwickelt (um 1998) von Kent Beck und Erich Gamma auf der Basis von SUnit (Beck, 1994) zum Testen von Smalltalk-Programmen Die aktuellste Version ist 4.4 (vielfach wird noch 3.8 verwendet, die Notation ist unterschiedlich) In Eclipse ab Version 3.2 bereits integriert (sonst unter http://download.sourceforge.net/junit/ herunterladen und zum Classpath hinzufügen) Ein JUnit-Test kennt nur zwei Ergebnisse: Entweder der Test gelingt ( grün ) oder er misslingt ( rot ). Das Misslingen kann als Ursachen einen Fehler (Error) oder ein falsches Ergebnis (Failure) haben. 03.07.2008 Softwaretest Ingo Dageförde 17
Installation von JUnit und Integration in Eclipse Ab Eclipse 3.2 bereits integriert Bis Eclipse 3.1 JUnit von http://sourceforge.net/projects/junit/ runterladen und das jar zum Classpath hinzufügen Menü: Window->Preferences->Java->Build Path->Classpath Variables überprüfen... Testklassen können dann im Package-Explorer selektiert werden und anschliessend Run As und JUnit Test im Kontextmenü auswählen 03.07.2008 Softwaretest Ingo Dageförde 18
Entwicklung eines Testfalls in JUnit Eine Testklasse enthält eine Menge von Testmethoden, die die verschiedenen Methoden der Ausgangsklasse testet Jede Testklasse muss die benötigten JUnit-Klassen importieren : import static org.junit.assert.* import org.junit.* Die Testklasse selber ist dann genau so aufgebaut wie jede andere Javaklasse auch (Optional) Definiere eine main() Methode, die den Testfall startet. (Nicht nötig im Rahmen von Entwicklungsumgebungen wie Eclipse) 03.07.2008 Softwaretest Ingo Dageförde 19
JUnit - @Before / @After @Before-Methoden werden vor jedem Testfall ausgeführt Dadurch kann man Objekte initialisieren, die in jedem Testfall benötigt werden, ohne dies für jeden Testfall jedes Mal einzeln zu initialisieren Syntax: @Before public void setup() { i = new Test(5, bla ) @After-Methoden werden nach jedem Testfall ausgeführt (z.b. Aufräumen der Datenbanken etc.) 03.07.2008 Softwaretest Ingo Dageförde 20
JUnit Einzelner Testfall Jeder Test muss einzeln implementiert werden durch folgende Zeile: @Test public void hierdertestname() Es ist sinnvoll, den Namen des Tests an die zu testende Methode anzupassen Die einzelnen Tests sind voneinander unabhängig für jeden Test werden die Testumgebungen neu initialisiert (durch @Before und @After) 03.07.2008 Softwaretest Ingo Dageförde 21
JUnit Asserts Um die einzelnen Ergebnisse überprüfen zu können, muss jede Bedingung mit Asserts definiert werden Mit einem Assert wird geprüft, ob z.b. ein Attribut der zu testenden Klasse mit vorher festgelegten Werten übereinstimmt Je nach Ergebnis ist der Test bestanden oder nicht bestanden In JUnit gibt es folgende Asserts: assertequals asserttrue und assertfalse assertnull und assertnotnull assertsame und assertnotsame 03.07.2008 Softwaretest Ingo Dageförde 22
JUnit Assert - Beispiel Neben dem zu prüfenden Wert kann den einzelnen Assets noch ein Name gegeben werden Analyse wird vereinfacht, da als Rückgabe der Name des fehlgeschlagenen Test erhalten wird Beispiel: @Test public void testgetvalue() { assertequals( getvalue 100, object.getvalue (), 100.00); Hier wird geprüft, ob das Objekt den Wert 100.00 zurückgibt, den es zuvor bei der Initialisierung mittels @Before erhalten hat. 03.07.2008 Softwaretest Ingo Dageförde 23
JUnit Exceptions Test, ob die Klasse auch mit Fehlern umgehen kann Im Testcode wird absichtlich eine Exception erzeugt und geprüft, ob die zu testende Klasse auch die entsprechende Exception zurückgibt Sollte keine oder eine nicht zu erwartende Exception zurückkommen, gilt der Test als nicht bestanden @Test ( expected = IndexOutOfBoundsException.class) public void testindexoutofboundsexception() { ArrayList emptylist = new ArrayList(); @SuppressWarnings( unused ) Object o = emptylist.get(0); 03.07.2008 Softwaretest Ingo Dageförde 24
Weiteführende Tests als Erweiterung von JUnit Integrationstest (Cactus) Integrationstests von Servlets und JSPs in der Laufzeitumgebung z.b. im Webbrowser -> Ergebnis als XML-Zusammenfassung Funktionale Tests (HTTPUnit) Automatisierte Website-Test (z.b. Formulare u. Javascript ausführen) Surfverhalten von Usern kann simuliert werden Load/Performance Testing (Jmeter) Große Anzahl von Threads werden erzeugt, um Last zu testen Latenzzeit und Datendurchsatz werden gemessen Load Testing (JunitPerf) Reaktionszeiten messen und testen 03.07.2008 Softwaretest Ingo Dageförde 25
Beispiel: Bankkonto mit Überziehungsrahmen BankAccount Setzt Limit auf Wert l <= 0 und Anfangskontostand auf b >= 0 int balance int limit BankAccount(int b, int l) void deposit (int amount) void withdraw (int amount) double getbalance () int getlimit () boolean transferto (BankAccount o, int amount) Fügt den Betrag amount > 0 zum Kontostand hinzu Hebt den Betrag amount > 0 vom Konto ab, falls Limit nicht überschritten wird. d.h. falls nach Ausführung gilt: getbalance() >= getlimit() Überweist den Betrag amount > = vom aktuellen Konto auf das Konto o und gibt true zurück, wenn das Limit dabei nicht überschritten wird. d.h. falls nach Ausführung gilt: getbalance() >= getlimit() 03.07.2008 Softwaretest Ingo Dageförde 26
Beispiel: Bankkonto Klasse (1) public class BankAccount { private int balance; private int limit; // Invariante: balance >= limit public BankAccount (int b, int l) { balance = b; limit = l; public void deposit (int amount) { if (!(amount > 0)) throw new IllegalArgumentException("Negativer Betrag"); balance = balance + amount; 03.07.2008 Softwaretest Ingo Dageförde 27
Beispiel: Bankkonto Klasse (2) public void withdraw (int amount) { if (!(amount > 0)) throw new IllegalArgumentException("NegativerBetrag"); if (!(balance - amount >= limit)) throw new IllegalArgumentException("Kontolimit ueberschritten"); balance = balance - amount; public String tostring () { return "BankAccount [balance= " + balance + "limit = " +limit+"]"; public int getbal () { return balance; public int getlimit () { return limit; 03.07.2008 Softwaretest Ingo Dageförde 28
Beispiel: Bankkonto Klasse (3) public boolean transferto (BankAccount other, int amount) { try { if (!(amount > 0)) throw new IllegalArgumentException("NegativerBetrag"); if (!(balance - amount >= limit)) throw new IllegalArgumentException("Kontolimit ueberschritten"); withdraw(amount); other.deposit(amount); catch (IllegalArgumentException e) { return false; return true; 03.07.2008 Softwaretest Ingo Dageförde 29
Beispiel: Einfacher Testfall für Bankkonto @Test public void testdeposit () { BankAccount b1 = new BankAccount(100, -50); b1.deposit(100); assertequals(200, b1.getbalance()); asserttrue(b1.getbalance() >= b1.getlimit()); Zusätzlich benötigt man noch Tests für die Grenzfälle und die Ausnahmen, z.b. b1.deposit(1); b1.deposit(0); b1.deposit(-10); 03.07.2008 Softwaretest Ingo Dageförde 30
Beispiel: Weiterer Testfall für Bankkonto @Test public void testwithdraw() { BankAccount b1 = newbankaccount (100,-50); b1.withdraw(100); assertequals(0, b1.getbalance()); asserttrue(b1.getbalance() >= b1.getlimit()); Zusätzlich benötigt man noch Tests für - die Grenzfälle von amount z.b. b1.withdraw(1); b1.withdraw(0); - die Invariante balance amount >= limit z.b. b1.withdraw(150); b1.withdraw(149); b1.withdraw(200); 03.07.2008 Softwaretest Ingo Dageförde 31
Beispiel: Testklasse für Bankkonto import org.junit.*; public class BankAccountTest { private BankAccount b1; private BankAccount b2; public BankAccountTest (String arg0) { super(arg0); @Before public void setup () { b1 = new BankAccount(100, -50); b2 = new BankAccount(100, -50); @After public void teardown() { //ohne Effekt bei BankAccount, b1 = null; //da immer neue Testobjekte erzeugt werden b2 = null; 03.07.2008 Softwaretest Ingo Dageförde 32
Allgemeines Schema für eine Testklasse (1) import org.junit.*; public class ZZZTest { private ZZZ z; public ZZZTest (String name) { super(name); @Before protected void setup() { z = newzzz(); @After protected void teardown() { z = null; 03.07.2008 Softwaretest Ingo Dageförde 33
Allgemeines Schema für eine Testklasse (2) @Test public void testzzzmethod () { z. ZZZMethod(); asserttrue(<boole'scherwert>); assertequals(expected, actual); 03.07.2008 Softwaretest Ingo Dageförde 34
Testfixture Eine Fixture (JUnit-Jargon) ist eine Menge von Objekten, die den gemeinsamen Ausgangszustand für die Testfälle einer Testklasse darstellt. Durch eine Testfixture vermeidet man Codeduplikation der gemeinsamen Testobjekte mehrerer Testmethoden einer Testklasse. Tests können die Objekte einer Testfixture gemeinsam benutzen, wobei jeder Test unterschiedliche Methoden aufrufen und unterschiedliche Resultate erwarten kann. Jeder Test einer Testklasse verwendet seine eigene Fixture, um die Tests von den Änderungen anderer Tests zu isolieren. Deshalb können die Tests einer Testklasse in jeder Reihenfolge ausgeführt werden. Eine Testfixture wird durch die setup()methode erzeugt; durch die teardown() Methode werden diese Objekte wieder beseitigt. JUnit ruft die setup-methode automatisch vor jedem Test und die teardown-methode automatisch nach jedem Test auf. 03.07.2008 Softwaretest Ingo Dageförde 35
Testsuite Eine Testsuite ist eine Menge von Testfällen, die gemeinsam ausgeführt und betrachtet werden. Typischerweise testet man in einer Testsuite mehrere Klassen oder ein gesamtes Package. Wichtige Operationen der Klasse TestSuite: TestSuite (ZZZTest.class) Konstruktor konvertiert Testklasse intestsuite statictest suite() gibt eine Instanz von TestSuite oder von TestCase zurück addtestsuite(zzztest.class) fügt eine Testklasse zu einer Suite hinzu 03.07.2008 Softwaretest Ingo Dageförde 36
Test-gesteuerter Entwurf Neue Software-Entwurfstechniken stellen das Testen vor das Implementieren des Programms: ExtremeProgramming, Test-first Programming, Agile Software Development Schritte des Test-gesteuerten Entwurfs: 1. Erstelle UML-Diagramm 2. Entwerfe einen Test für eine Methode 3. Schreibe möglichst einfachen Code, bis der Test nicht mehr fehlschlägt 4. Wiederhole 2. und 3. bis alle Methoden des Klassendiagramms implementiert sind. Dabei wird häufig der Code (und manchmal der Test) restrukturiert ( Refactoring ). Jedes Mal werden alle Tests durchgeführt, um sicher zu stellen, dass die Coderestrukturierung nicht zu Fehlern im alten Code geführt hat. 03.07.2008 Softwaretest Ingo Dageförde 37
Zusammenfassung Beim Testen unterscheidet man zwischen Unit-, Modul-, Integrations-, System-, Performance und Funktionalen Tests. Beim Whitebox-Test werden Tests anhand der Programmstruktur entworfen, beim Blackbox-Test zählt nur die Spezifikation. JUnit ist ein Framework zur automatischen Ausführung von Unit-Tests Beim Test-gesteuerten Entwurf werden zuerst die UML-Diagramme und die Tests entworfen und dann die Programme geschrieben. 03.07.2008 Softwaretest Ingo Dageförde 38
Links http://www.junit.org/ http://de.wikipedia.org/wiki/junit http://www.frankwestphal.de/unittestingmitjunit.html http://junit.sourceforge.net/doc/cookbook/cookbook.htm http://junit.sourceforge.net/doc/faq/faq.htm http://junit.sourceforge.net/doc/testinfected/testing.htm 03.07.2008 Softwaretest Ingo Dageförde 39