Softwaretest. Algorithmen und Programmieren II SS 2008 Objektorientierte Programmierung. Algorithmen und Programmierung II SS 2008

Transkript

1 Algorithmen und Programmieren II SS 2008 Objektorientierte Programmierung Softwaretest Softwaretest Ingo Dageförde 1

2 Agenda VL Softwaretest am Qualitätssicherung in der Softwareentwicklung Softwaretests warum und wieso? Arten von Softwaretests Einführung in Softwaretests mit JUnit Beispiel in JUnit Zusammenfassung Softwaretest Ingo Dageförde 2

3 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 Softwaretest Ingo Dageförde 3

4 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 Softwaretest Ingo Dageförde 4

5 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 Softwaretest Ingo Dageförde 5

6 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 Softwaretest Ingo Dageförde 6

7 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 Softwaretest Ingo Dageförde 7

8 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! Softwaretest Ingo Dageförde 8

9 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 ) Softwaretest Ingo Dageförde 9

10 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! Softwaretest Ingo Dageförde 10

11 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 Softwaretest Ingo Dageförde 11

12 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 Softwaretest Ingo Dageförde 12

13 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) Softwaretest Ingo Dageförde 13

14 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] Softwaretest Ingo Dageförde 14

15 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 > Softwaretest Ingo Dageförde 15

16 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, Softwaretest Ingo Dageförde 16

17 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 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 Softwaretest Ingo Dageförde 17

18 Installation von JUnit und Integration in Eclipse Ab Eclipse 3.2 bereits integriert Bis Eclipse 3.1 JUnit von 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 Softwaretest Ingo Dageförde 18

19 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) Softwaretest Ingo Dageförde 19

20 JUnit / 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 public void setup() { i = new Test(5, bla werden nach jedem Testfall ausgeführt (z.b. Aufräumen der Datenbanken etc.) Softwaretest Ingo Dageförde 20

21 JUnit Einzelner Testfall Jeder Test muss einzeln implementiert werden durch folgende 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 Softwaretest Ingo Dageförde 21

22 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 Softwaretest Ingo Dageförde 22

23 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 public void testgetvalue() { assertequals( getvalue 100, object.getvalue (), ); Hier wird geprüft, ob das Objekt den Wert zurückgibt, den es zuvor bei der Initialisierung erhalten hat Softwaretest Ingo Dageförde 23

24 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 ( expected = IndexOutOfBoundsException.class) public void testindexoutofboundsexception() { ArrayList emptylist = new unused ) Object o = emptylist.get(0); Softwaretest Ingo Dageförde 24

25 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 Softwaretest Ingo Dageförde 25

26 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() Softwaretest Ingo Dageförde 26

27 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; Softwaretest Ingo Dageförde 27

28 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; Softwaretest Ingo Dageförde 28

29 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; Softwaretest Ingo Dageförde 29

30 Beispiel: Einfacher Testfall für 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); Softwaretest Ingo Dageförde 30

31 Beispiel: Weiterer Testfall für 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); Softwaretest Ingo Dageförde 31

32 Beispiel: Testklasse für Bankkonto import org.junit.*; public class BankAccountTest { private BankAccount b1; private BankAccount b2; public BankAccountTest (String arg0) { public void setup () { b1 = new BankAccount(100, -50); b2 = new BankAccount(100, public void teardown() { //ohne Effekt bei BankAccount, b1 = null; //da immer neue Testobjekte erzeugt werden b2 = null; Softwaretest Ingo Dageförde 32

33 Allgemeines Schema für eine Testklasse (1) import org.junit.*; public class ZZZTest { private ZZZ z; public ZZZTest (String name) { protected void setup() { z = protected void teardown() { z = null; Softwaretest Ingo Dageförde 33

34 Allgemeines Schema für eine Testklasse public void testzzzmethod () { z. ZZZMethod(); asserttrue(<boole'scherwert>); assertequals(expected, actual); Softwaretest Ingo Dageförde 34

35 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 Softwaretest Ingo Dageförde 35

36 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 Softwaretest Ingo Dageförde 36

37 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 Softwaretest Ingo Dageförde 37

38 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 Softwaretest Ingo Dageförde 38

39 Links Softwaretest Ingo Dageförde 39