Fachbereich Informatik – AG Datenbanken ... · oder Campus Management :-) (Programmfehler!) ......

03.07.2008 – Softwaretest Ingo Dageförde 1

Algorithmen und Programmierung II – SS 2008

Fachbereich Informatik – AG Datenbanken & Informationssysteme

Algorithmen und Programmieren II – SS 2008Objektorientierte Programmierung

Softwaretest




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




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.





● 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.





● 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.





● 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




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




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!




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“)




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!




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




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.




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)




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]




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




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




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.

http://download.sourceforge.net/junit/




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

http://sourceforge.net/projects/junit/




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)




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.)




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)




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




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.




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);

}




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




Beispiel: Bankkonto mit Überziehungsrahmen

BankAccount

int balanceint limit

BankAccount(int b, int l)void deposit (int amount)void withdraw (int amount)double getBalance ()int getLimit ()boolean transferTo (BankAccount o, int amount)

Setzt Limit auf Wert l <= 0 undAnfangskontostand auf b >= 0

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()




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;

}





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;

}





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;

}}




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);




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);




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 werdenb2 = null;

}}




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;

}




Allgemeines Schema für eine Testklasse (2)

@Test public void testZZZMethod () {z. ZZZMethod();assertTrue(<Boole'scherWert>);assertEquals(expected, actual);

}}




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.




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 inTestsuitestaticTest suite() gibt eine Instanz von TestSuite

oder von TestCase zurückaddTestSuite(ZZZTest.class) fügt eine Testklasse zu einer Suite hinzu




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-Diagramm2. Entwerfe einen Test für eine Methode3. 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.




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.




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

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

Fachbereich Informatik – AG Datenbanken ... · oder Campus Management :-) (Programmfehler!) ......

Documents

Transcript of Fachbereich Informatik – AG Datenbanken ... · oder Campus Management :-) (Programmfehler!) ......