Software Engineering Testen von Software (2)

Software Engineering Testen von Software (2) Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik Hochschule Kaiserslautern, Standort Zweibrücken Prof. A. Müller, FH KL Software Engineering 2015 1

Wiederholung: Die unterschiedlichen Testarten Quelle: http://de.wikipedia.org/wiki/kontrollflussorientierte_testverfahren Kurzname erfüllte Bedingung Durchführbarkeit Anweisungsüberdeckungstest C 0 Zweigüberdeckungstest C 1 Pfadüberdeckungstest C 2 Vollständig C 2 a Boundary-Interior C 2 b Strukturiert C 2 c jede Anweisung wird mindestens einmal ausgeführt jede Kante im KFG wird mindestens einmal durchlaufen Alle möglichen Pfade werden durchlaufen wie C 2 a, Schleifen werden jedoch nach speziellen Regeln durchlaufen wie C 2 b, Schleifen werden jedoch genau n-mal durchlaufen relativ einfach realistische Mindestanforderung, vertretbarer Aufwand unmöglich bei Schleifen aufwendig aufwendig Bedingungsüberdeckungstest C 3 Einfachbedingung C 3 a jede atomare Bedingung wird einmal mit true und false getestet Mehrfachbedingung C 3 b jede true/false Kombination der atomaren Bedingungen wird getestet sehr hoher Aufwand jede atomare Bedingung und Minimale Mehrfachbedingung C 3 c die Gesamtbedingung wird mit hoher Aufwand Prof. A. Müller, FH KL Software Engineering true und Sommer'14 false getestet 2

Zusammenhang verschiedener kontrollflussgraphen-orientierter Testverfahren Quelle: http://commons.wikimedia.org/wiki/file:teststrategien.svg 3

Wiederholung Lasttest Performance Test Volumen-/Massentest Stresstest Was passiert bei Überlastung? Test der Sicherheit Z. B. gegen unberechtigten Systemzugang Test der Stabilität/Zuverlässigkeit Im Dauerbetrieb Test auf Robustheit Gegenüber Fehlbedienung, Hardwareausfall, Wiederanlauf, Test auf Kompabilität/Datenkonversion Test unterschiedlicher Konfigurationen Z. B. Sprachen, Betriebssysteme Test auf Benutzungfreundlichkeit Prüfung der Dokumentation Prüfung auf Änderbarkeit/Wartbarkeit 4

Testplan Gliederung nach IEEE 829 1. Bezeichnung 2. Einführung 3. Testobjekte 4. Zu testende Leistungsmerkmale 5. Leistungsmerkmale, die nicht getestet werden 6. Teststrategie 7. Abnahmekriterien 8. Kriterien für Testabbruch und Testfortsetzung 9. Testdokumentation 10. Testaufgaben 11. Testinfrastruktur 12. Verantwortlichkeiten 13. Personal, Einarbeitung, Ausbildung 14. Zeitplan 15. Planungsrisiken und Unvorhergesehenes 16. Genehmigung Bemerkungen Bei großen Projekten mit hohen Qualitätsanforderungen und Risiken sind die genannten Punkte ausführlich auszuarbeiten Bei kleinen, weniger kritischen Projekten können einzelne Punkte ggf. auch sehr kurz beschrieben werden oder in andere Dokumente mit aufgenommen werden (z. B. im Projektplan) Unabhängig von Art und Umfang der Dokumentation sollte man prinzipiell festlegen, was man wie welchem Ziel testet Da am Anfang noch nicht alle Einzelheiten des Systems bekannt sind, muss der Testplan ständig weiterentwickelt werden 7

Testplan Gliederung nach IEEE 829 1. Bezeichnung 2. Einführung 3. Testobjekte 4. Zu testende Leistungsmerkmale 5. Leistungsmerkmale, die nicht getestet werden 6. Teststrategie 7. Abnahmekriterien 8. Kriterien für Testabbruch und Testfortsetzung 9. Testdokumentation 10. Testaufgaben 11. Testinfrastruktur 12. Verantwortlichkeiten 13. Personal, Einarbeitung, Ausbildung 14. Zeitplan 15. Planungsrisiken und Unvorhergesehenes 16. Genehmigung 1. Bezeichnung Eindeutiger Dokumentname, Version, Freigabestatus 2. Einführung Kurze Darstellung des Projekthintergrundes Liste aller Dokumente, die das Testkonzept umsetzen muss, z. B. Pflichtenheft, Entwurfsdokumente 8

TestplanGliederung nach IEEE 829 1. Bezeichnung 2. Einführung 3. Testobjekte 4. Zu testende Leistungsmerkmale 5. Leistungsmerkmale, die nicht getestet werden 6. Teststrategie 7. Abnahmekriterien 8. Kriterien für Testabbruch und Testfortsetzung 9. Testdokumentation 10. Testaufgaben 11. Testinfrastruktur 12. Verantwortlichkeiten 13. Personal, Einarbeitung, Ausbildung 14. Zeitplan 15. Planungsrisiken und Unvorhergesehenes 16. Genehmigung 3. Testobjekte Auflistung, was getestet werden soll, z. B. Klassen Komponenten Schnittstellen Oberflächen Abläufe Datenbank Installationsroutinen Build-Files Zusammenspiel mit Drittsystemen 9

Testplan Gliederung nach IEEE 829 1. Bezeichnung 2. Einführung 3. Testobjekte 4. Zu testende Leistungsmerkmale 5. Leistungsmerkmale, die nicht getestet werden 6. Teststrategie 7. Abnahmekriterien 8. Kriterien für Testabbruch und Testfortsetzung 9. Testdokumentation 10. Testaufgaben 11. Testinfrastruktur 12. Verantwortlichkeiten 13. Personal, Einarbeitung, Ausbildung 14. Zeitplan 15. Planungsrisiken und Unvorhergesehenes 16. Genehmigung 4. Zu testende Leistungsmerkmale Aufführen, welche Merkmale konkret getestet werden sollen, insbesondere Funktionalität gemäß Anforderungsspezifikation (möglichst vollständig) Qualitätsmerkmale gemäß Anforderungsspezifikation Zuordnung zu Teststufen (Unit-, Integrations-, Systemtest) 5. Leistungsmerkmale, die nicht getestet werden Merkmale nennen, die aus technischen Gründen oder wegen zu hohen Aufwandes nicht getestet werden Z. B. Verzicht auf Test von Schnittstellen, die vom Kunden bereitgestellt werden 10

Testplan Gliederung nach IEEE 829 1. Bezeichnung 2. Einführung 3. Testobjekte 4. Zu testende Leistungsmerkmale 5. Leistungsmerkmale, die nicht getestet werden 6. Teststrategie 7. Abnahmekriterien 8. Kriterien für Testabbruch und Testfortsetzung 9. Testdokumentation 10. Testaufgaben 11. Testinfrastruktur 12. Verantwortlichkeiten 13. Personal, Einarbeitung, Ausbildung 14. Zeitplan 15. Planungsrisiken und Unvorhergesehenes 16. Genehmigung 6. Teststrategie Testziele sowie Vorgehensweise und Reihenfolge beim Testen Testmethoden, mit denen die verschiedenen Merkmale in den einzelnen Teststufen getestet werden sollen. Beispiele: Unit-Tests der einzelnen Klassen und Methoden durch die Entwickler Automatisierte Tests für alle öffentlichen Methoden Manuell durchgeführte Tests für jeden Use Case Lasttest, Performance-Test, Integrationstest mit Top Down- oder Bottom Up-Integration Welche Tests werden als Regressionstests wiederholt? Beschreibung der einzelnen Methoden, ggf. Verweis auf Testfallspezifikationen u. ä. Umfangreichster Teil des Testplans 11

Teststrategie 12

Testen: Instrumentierung PoC: Point of Control, PoO: Point of Observation Quelle: Spillner/Linz, Basiswissen Softwaretest. dpunkt 2003. 13

Integrationstest Integrationsstrategien Top-down-Integration Test beginnt mit der "obersten" Komponente, die selbst nicht von anderen Komponenten aufgerufen wird. Untergeordnete Komponenten werden zunächst durch Platzhalter ersetzt und später nach und nach gegen die richtigen Komponenten ausgetauscht Wenige verschiedene Testtreiber, aber Platzhalter programmieren Bottom-up-Integration Beginn mit elementaren Komponenten, nach und nach Zusammensetzen zu größeren Komponenten Keine Platzhalter, aber viele Testtreiber Ad-hoc-Integration Integration in der (zufälligen) Reihenfolge der Fertigstellung Zeitgewinn, aber sowohl Platzhalter als auch Treiber benötigt Big bang-integration Vermeiden, da großer Testaufwand am Ende, Fehler treten geballt auf und sind schwer zu lokalisieren. 14

Testplan Gliederung nach IEEE 829 1. Bezeichnung 2. Einführung 3. Testobjekte 4. Zu testende Leistungsmerkmale 5. Leistungsmerkmale, die nicht getestet werden 6. Teststrategie 7. Abnahmekriterien 8. Kriterien für Testabbruch und Testfortsetzung 9. Testdokumentation 10. Testaufgaben 11. Testinfrastruktur 12. Verantwortlichkeiten 13. Personal, Einarbeitung, Ausbildung 14. Zeitplan 15. Planungsrisiken und Unvorhergesehenes 16. Genehmigung 7. Abnahmekriterien Auch Test-Ende-Kriterien genannt Legen fest, wann man fertig ist, z. B. 100% aller öffentlichen Methoden getestet 90% Zweigüberdeckung in allen Klassentests 100% aller Use Cases getestet Keine Fehler der Klasse 1 (Systemabsturz, Datenverlust) und Klasse 2 (Wesentliche Funktion ist fehlerhaft) mehr bekannt und 90% der gefundenen Fehler der Klasse 3 sind behoben 8. Kriterien für Testabbruch und Testfortsetzung Falls Tests zu schlecht ausfallen, werden sie abgebrochen und die Software-Elemente zur Überarbeitung zurückgegeben. Hierfür und die Fortsetzung des Tests sind Kriterien zu definieren. 15

Beispiel für Fehlerklassifikation Klasse Bedeutung 1 Systemabsturz mit ggf. Datenverlust. Das Testobjekt ist in dieser Form nicht einsetzbar. 2 Wesentliche Funktion ist fehlerhaft; Anforderung nicht beachtet oder falsch umgesetzt. Das Testobjekt ist nur mit großen Einschränkungen einsetzbar. 3 Funktionale Abweichung bzw. Einschränkung ( normaler Fehler ); Anforderung fehlerhaft oder nur teilweise umgesetzt. Das Testobjekt kann mit Einschränkungen genutzt werden. 4 Geringfügige Abweichung. Das Testobjekt kann ohne Einschränkung genutzt werden. 5 Schönheitsfehler (z. B. Rechtschreibfehler oder Mangel im Maskenlayout). Das Testobjekt kann ohne Einschränkung genutzt werden. Quelle: Spillner/Linz, Basiswissen Softwaretest. dpunkt 2003. 16

Testplan Gliederung nach IEEE 829 1. Bezeichnung 2. Einführung 3. Testobjekte 4. Zu testende Leistungsmerkmale 5. Leistungsmerkmale, die nicht getestet werden 6. Teststrategie 7. Abnahmekriterien 8. Kriterien für Testabbruch und Testfortsetzung 9. Testdokumentation 10. Testaufgaben 11. Testinfrastruktur 12. Verantwortlichkeiten 13. Personal, Einarbeitung, Ausbildung 14. Zeitplan 15. Planungsrisiken und Unvorhergesehenes 16. Genehmigung 9. Testdokumentation Wie werden die Testergebnisse dokumentiert? Testprotokolle, automatisch erzeugte Reports, Berichte Fehlerstatusliste, Bug- Tracking-System 10. Testaufgaben Notwendige Tätigkeiten zur Vorbereitung, Durchführung und Auswertung der Tests 11. Testinfrastruktur Hardware, Software (z. B. Test-Tools) 12. Verantwortlichkeiten Verantwortliche für die einzelnen Teststufen 17

Fehlerstatusliste Verfolgung der Fehler und ihrer Behebung: Einfach: Liste mit Fehlerbeschreibung, Status, Zuständigkeiten Mächtig: Bug Tracking-System, Beispiel: Bugzilla (Open Source) Screenshot von landfill.bugzilla.org 18

Bugzilla: Einzelner Fehler und Auswertungen Screenshot von landfill.bugzilla.org 19

Testplan Gliederung nach IEEE 829 1. Bezeichnung 2. Einführung 3. Testobjekte 4. Zu testende Leistungsmerkmale 5. Leistungsmerkmale, die nicht getestet werden 6. Teststrategie 7. Abnahmekriterien 8. Kriterien für Testabbruch und Testfortsetzung 9. Testdokumentation 10. Testaufgaben 11. Testinfrastruktur 12. Verantwortlichkeiten 13. Personal, Einarbeitung, Ausbildung 14. Zeitplan 15. Planungsrisiken und Unvorhergesehenes 16. Genehmigung 9. Personal, Einarbeitung, Ausbildung 10. Zeitplan Beteiligte Mitarbeiter, Qualifikationen, Schulungen Verteilung der Aufgaben Zeitliche Planung der einzelnen Aufgaben 11. Planungsrisiken und Unvorhergesehenes Risiken bzgl. des Testens, z. B. wenn bestimmte Testwerkzeuge nicht funktionieren und es nicht gelingt, wichtige Merkmale zu testen Maßnahmen zur Vermeidung und Notfallpläne für den Eintrittsfall 12. Genehmigung 20

Manuelle Tests - Testfallspezifikation Testfallbeschreibung Nr Bezeichnung Verantwortlicher Durchzuführen von (Rolle) Umgebung Voraussetzungen Zu testende Funktion Schritte (inkl. Eingaben) 1. 2. 3. 4. 5. Erwartetes Ergebnis Qualitätsmerkmale und Testkriterien Schnittstellen zu anderen Tests und Arbeitspaketen Anmerkungen Die Inhalte orientieren sich an Reiss/Reiss: Praxisbuch IT- Dokumentationen. Pearson 2008. 21

Manuelle Tests: Testprotokoll Nutzung der Testfallbeschreibung als Schablone für das Testprotokoll wird bei der Testdurchführung ausgefüllt. Testfall Nr Bezeichnung Verantwortlicher Durchzuführen von (Rolle) Umgebung Voraussetzungen Protokoll Nr Datum Uhrzeit Tester Weitere Mitwirkende Tatsächlich vorhandene Umgebung Tatsächlich vorhandene Voraussetzungen Zu testende Funktion Schritte Erwartetes Ergebnis Tatsächliches Ergebnis 1. OK Nicht OK 2. OK Nicht OK 3. OK Nicht OK 4. OK Nicht OK 5. OK Nicht OK OK Nicht OK Qualitätsmerkmale und Testkriterien Schnittstellen zu anderen Tests und Arbeitspaketen Tatsächlich beobachtete Merkmale und Kriterien Anmerkungen zu Schnittstellen zu anderen Tests und Arbeitspaketen Genaue Fehlerbeschreibung, wenn nicht OK Anmerkungen Anmerkungen Änderungen an der Testumgebung aufgrund der Tests inkl. erforderliche Wiederherstellungsaktionen Unterschrift Die Prof. Inhalte A. Müller, orientieren FH KL sich an Reiss/Reiss: Praxisbuch Software Engineering Sommer'14 IT-Dokumentationen. Pearson 2008. 22

Aufgabe Gegeben ist die folgende Use Case-Beschreibung Erstellen Sie eine Testfallspezifikation zum Testen der beschriebenen Funktionalität Name Fahrzeug suchen Vorbed. Keine Nachbed. Ein Fahrzeug ausgewählt Erfolg Nachbed. Kein Fahrzeug gefunden Fehlschlag Akteure Mitarbeiter Ausl. Ereignis Mitarbeiter wählt Fahrzeug suchen Beschreibung 1. Der Mitarbeiter gibt Fahrzeugklasse und Zeitraum an 2. Das System zeigt verfügbare Modelle und Preise an 3. Der Mitarbeiter wählt das gewünschte Modell aus Erweiterungen a) Es ist jederzeit ein Abbruch möglich /Alternativen b) Zu Schritt 2: Kein geeignetes Fahrzeug gefunden, die Eingaben können geändert werden. Treffen Sie Annahmen für nicht angegebene Informationen 23

Testautomatisierung Manuelle Test sind aufwändig und fehleranfällig Insbesondere Regressionstests (Testwiederholungen nach Änderungen) lassen sich manuell nicht in größerem Umfang durchführen Einsatz von Testframeworks Hier verwendet: JUnit Zum Testen von Java-Programmen. Die Tests werden selbst ebenfalls in Java geschrieben. JUnit ist Open Source. In Eclipse ist es bereits integriert. Vergleichbare Tools gibt es auch für andere Sprachen 24

JUnit-Test Beispiel Die zentralen Junit-Klassen liegen im Paket org.junit import org.junit.assert; import org.junit.test; Konvention zur Benennung von Testklassen: Name der getesteten Klasse + Test Konvention zur Benennung von Testfällen: Der Name beginnt mit test, enthält häufig Namen der zu testenden Methode Alle mit @Test annotierten Methoden werden von Junit als Testfälle interpretiert und beim Testen ausgeführt Assertion (Zusicherung) public class Mitarbeiter1Test { @Test public void testkonstruktor(){ Mitarbeiter m = new Mitarbeiter("Ute","Mai"); Assert.assertTrue("korrekter Vorname", m.getvorname().equals("ute")); Assert.assertTrue("korrekter Nachname", m.getnachname().equals("mai")); @Test public void testeindeutigeid(){ Assert.assertTrue("unterschiedliche ID", new Mitarbeiter("Ute","Mai").getId()!= new Mitarbeiter("Ute","Mai").getId()); Boolescher Wert, der überprüft wird Dieser String wird ausgegeben, wenn die Zusicherung nicht erfüllt ist. Ein Test kann mehrere Assertions enthalten. Sobald allerdings eine negativ ausfällt, werden die weiteren nicht mehr ausgeführt. Daher ist es häufig sinnvoll, nur eine Assertion pro Test zu verwenden. Quelle: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. 25

Nutzung mit statischem Import Statischer Import der Klassenmethoden von Assert import static org.junit.assert.*; import org.junit.test; public class Mitarbeiter1Test { @Test public void testkonstruktor(){ Mitarbeiter m = new Mitarbeiter("Ute","Mai"); asserttrue("korrekter Vorname", m.getvorname().equals("ute")); asserttrue("korrekter Nachname", m.getnachname().equals("mai")); Dann kann man die assert-methoden ohne Angabe der Klasse Assert aufrufen @Test public void testeindeutigeid(){ asserttrue("unterschiedliche ID", new Mitarbeiter("Ute","Mai").getId()!= new Mitarbeiter("Ute","Mai").getId()); 26

Junit Testausführung in Eclipse Alle Tests erfolgreich ausgeführt 27

Junit Negatives Ergebnis 1 Test ist fehlgeschlagen. Erfolgreicher Test Fehlgeschlagener Test Ausgabe des bei der Zusicherung angegebenen Strings Zeilenangabe der fehlgeschlagenen Zusicherung 28

Fehler im Test Ein fehlgeschlagener Test muss nicht durch einen Fehler im Programm verursacht sein auch der Test kann fehlerhaft sein 29

Assert-Methoden (Auswahl) assertarrayequals(object[] expecteds, Object[] actuals) Asserts that two object arrays are equal. assertequals(object expected, Object actual) Asserts that two objects are equal assertequals(double expected, double actual, double delta) Asserts that two doubles or floats are equal to within a positive delta. assertfalse(boolean condition) Asserts that a condition is false. assertnotnull(object object) Asserts that an object isn't null. assertnull(object object) Asserts that an object is null. assertsame(object expected, Object actual) Asserts that two objects refer to the same object. asserttrue(boolean condition) Asserts that a condition is true. fail() Fails a test with no message. Alle Methoden gibt es auch noch mit einem String- Parameter für eine Ausgabe beim Scheitern des Tests. Hat gegenüber asserttrue den Vorteil, dass bei einem Fehlschlag der erwartete und der tatsächliche Wert ausgegeben werden. Maximale Differerenz, bis zu der die double-werte als gleich gelten sollen. Sorgt dafür, dass der Test garantiert scheitert (um Zeilen zu markieren, die nicht erreicht werden sollen, z. B. wenn vorher eine Exception erwartet wird. Quelle: http://kentbeck.github.com/junit/javadoc/latest/ 30

Test-Fixtures Test-Fixture (Fixture = Einrichtung, Ausstattung ) Gemeinsame Grundlage für alle Tests, z. B. Anlegen von Objekten, Initialisieren von Daten import org.junit.assert; import org.junit.before; import org.junit.test; public class Mitarbeiter2Test { Mitarbeiter m1; Wird vor jedem der beiden Tests ausgeführt @Before public void setup() throws Exception { m1 = new Mitarbeiter("Uwe","Mey"); m1.addfachgebiet(fachgebiet.analyse); m1.addfachgebiet(fachgebiet.c); m1.addfachgebiet(fachgebiet.java); @Test public void testhatfaehigkeit1(){ Assert.assertTrue("vorhandene Faehigkeit",m1.hatFachgebiet(Fachgebiet.C)); @Test public void testhatfaehigkeit2(){ Assert.assertTrue("nicht vorhandene Faehigkeit",!m1.hatFachgebiet(Fachgebiet.TEST)); Quelle: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. 31

Test Fixtures Annotationen @Before @After Wird vor jedem einzelnen Test ausgeführt, z. B. Anlegen von Objekten oder Datensätzen in einer Datebank. Wird nach jedem einzelnen Test ausgeführt, z. B. Änderungen der Testdaten in der Datenbank rückgängig machen, damit sie für den nächsten Test wieder unverändert zur Verfügung stehen. @BeforeClass Statische Methode, wird einmalig ganz am Anfang durchgeführt (nicht vor jedem Test wiederholt). Objekte und Daten, die für alle Tests zur Verfügung stehen sollen können in statischen Attributen gespeichert werden. Die Werte gewöhnlicher Instanzattribute der Testklasse stehen nur innerhalb des jeweiligen Tests zur Verfügung, da bei jedem Test ein neues Objekt angelegt wird. @AfterClass Statische Methode, wird einmalig ganz am Ende durchgeführt, um z. B. Änderungen rückgängig zu machen. 32

Exceptions in Tests Tritt eine unerwartete Exception auf, so wird diese als Error gemeldet (im Gegensatz zu einem Failure, der ein nicht erwartetes Ergebnis anzeigt). @Test public void testkonstruktor(){ new Mitarbeiter(null,null); @Test(expected=IllegalArgumentException.class) public void testaddfaehigkeit1(){ m1.addfachgebiet(fachgebiet.test); @Test(expected=IllegalArgumentException.class) public void testaddfaehigkeit2(){ m1.addfachgebiet(fachgebiet.c); @Test public void testaddfaehigkeit3(){ try{ m1.addfachgebiet(fachgebiet.test); Assert.fail("fehlende Exception"); catch(illegalargumentexception e){ Assert.assertNotNull(e.getMessage()); catch(exception e){ Assert.fail("unerwartet "+e); Quelle: Stephan Kleuker, Qualitätssicherung durch Prof. Softwaretests. A. Müller, FH KL Springer Vieweg 2013. Software Engineering Sommer'14 @Test public void testaddfaehigkeit4(){ try{ 33

Explizit Testen, ob Exceptions richtig geworfen werden (a) Angabe, welche Exception bei diesem Test erwartet wird. @Test public void testkonstruktor(){ new Mitarbeiter(null,null); Hier trat die erwartete Exception auf @Test(expected=IllegalArgumentException.class) public void testaddfaehigkeit1(){ m1.addfachgebiet(fachgebiet.test); @Test(expected=IllegalArgumentException.class) public void testaddfaehigkeit2(){ m1.addfachgebiet(fachgebiet.c); @Test public void testaddfaehigkeit3(){ try{ m1.addfachgebiet(fachgebiet.test); Assert.fail("fehlende Exception"); catch(illegalargumentexception e){ Assert.assertNotNull(e.getMessage()); catch(exception e){ Assert.fail("unerwartet "+e); Quelle: Stephan Kleuker, Qualitätssicherung durch Prof. Softwaretests. A. Müller, FH KL Springer Vieweg 2013. Software Engineering Sommer'14 @Test public void testaddfaehigkeit4(){ Hier trat die erwartete Exception nicht auf, d. h. der Test ist fehlgeschlagen. 34

Explizit Testen, ob Exceptions richtig geworfen werden (b) @Test public void testkonstruktor(){ new Mitarbeiter(null,null); @Test(expected=IllegalArgumentException.class) public void testaddfaehigkeit1(){ m1.addfachgebiet(fachgebiet.test); @Test(expected=IllegalArgumentException.class) public void testaddfaehigkeit2(){ m1.addfachgebiet(fachgebiet.c); @Test public void testaddfaehigkeit3(){ try{ m1.addfachgebiet(fachgebiet.test); Assert.fail("fehlende Exception"); catch(illegalargumentexception e){ Assert.assertNotNull(e.getMessage()); catch(exception e){ Assert.fail("unerwartet "+e); @Test public void testaddfaehigkeit4(){ try{ m1.addfachgebiet(fachgebiet.c); catch(exception e){ Assert.fail("unerwartet "+e); Hier wird eine IllegalArgumentException erwartet. Tritt keine oder eine andere Exception auf, wird dies als Failure behandelt.. Hier wird keine Exception erwartet. Ein Auftreten wird daher als Failure behandelt. Quelle: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. 35

Testautomatisierung Mit Hilfe von JUnit lassen sich vor allem Unit-Tests gut unterstützen Durch Einsatz von Fixtures können auch Integrationsund Systemtests automatisiert werden Schwieriger: Automatisiertes Testen der Oberfläche Auch hierfür gibt es Tools (eg. Capture-and-Replay ) Oberflächentests sind aufwändiger, da z. B. die verschiedenen Eingabelemente eindeutig identifiziert und im Rahmen eines Tests in der richtigen Reihenfolge mit Eingaben versehen und betätigt werden müssen 36

Aufgabe Gegeben ist die folgende Klasse: public class Rechner { public int berechnerestguthaben(int guthaben, int ausgabe) { int restguthaben = guthaben - ausgabe; if(guthaben < 0 restguthaben < 0){ throw new NegativesGuthabenException("Negatives Guthaben unzulässig"); return restguthaben; Schreiben Sie eine Klasse mit Junit-Tests Zu Beginn soll ein von allen Tests genutztes Rechner-Objekt angelegt und in einem statischen Attribut gespeichert werden Schreiben Sie einen Test, der das normale Verhalten der Methode prüft Schreiben Sie einen Test, der das Werfen der Exception überprüft 37

Wiederholung: Test-Driven Development 39

Mischung von Testen, Vorgehensmodell und SW-Design: TDD Quelle: en.wikipedia.org Test-driven development 1. Add a test 2. Run all tests and see if the new one fails 3. Write some code 4. Run the automated tests and see them succeed 5. Refactor code Voraussetzungen Vor- und Nachteile 40

Test Driven Development Quelle: Objektorientiertes Testen und Testautomatisierung in der Praxis, Vigenschow, 2004 41

Test Driven Development Quelle: Objektorientiertes Testen und Testautomatisierung in der Praxis, Vigenschow, 2004 42

Test Driven Development Quelle: Objektorientiertes Testen und Testautomatisierung in der Praxis, Vigenschow, 2004 43

Test Driven Development Quelle: Objektorientiertes Testen und Testautomatisierung in der Praxis, Vigenschow, 2004 44

Anhang 45

Testautomatisierung Quelle: http://de.wikipedia.org/wiki/testroboter Am Markt stehen eine Reihe von Testrobotern zur Verfügung. Ihr Umfang bezüglich ihrer Funktionalität variiert jedoch sehr stark. Einige Werkzeuge sind reine Testroboter. Bei anderen wiederum ist die Roboterfunktion nur ein Teil ihrer Gesamtfunktionalität. Selenium: Selenium ist ein Open Source Testframework zur Durchführung funktionsorientierter Tests von Webapplikationen. CitraTest: CitraTest ist eine Lösung der Firma Tevron. CitraTest ist ein Testroboter, der für Funktions- und Lasttests als auch zum End-to-End Monitoring (auch unter Terminalservices wie z.b. Citrix) eingesetzt werden kann. JStudio SiteWalker: JStudio SiteWalker ist ein Testwerkzeug für webbasierte Anwendungen zur Durchführung von automatisierten funktionsorientierten Tests. IBM Rational Robot: Rational Robot von IBM ist ein Testroboter zur Durchführung von Funktions-, Rückfall- und Konfigurationstests für.net-, Java-, Web- und andere GUI-basierte Anwendungen. Ranorex: Ranorex ist ein GUI Testautomatisierungsframework zur Generierung automatisierter Tests für Desktop-, Web-Applikationen und mobile Anwendungen. Es wird vom gleichnamigen Unternehmen entwickelt und vertrieben. TestPartner: TestPartner wurde ursprünglich von der Firma Compuware entwickelt und wird zurzeit von der Firma Micro Focus vertrieben. Bei TestPartner werden zwei verschiedene Modi zur Erstellung von Testfällen angeboten. Mit Visual Test wird ein Storyboard-basierter Ansatz verwendet und mit Test Script werden die Testfälle mit Hilfe eines VBA Codes generiert. HP QuickTest Professional: HP QuickTest Professional ist der aktuelle Testroboter von der Firma HP. Er ersetzt den Testroboter der bislang unter WinRunner vertrieben wurde. Der vollständige Support von WinRunner wird am 1. August 2009 eingestellt. Ein eingeschränkter Support ist bis zum 1. Januar 2011 limitiert. Von der Firma HP wird eine Migration der Testfälle von WinRunner auf HP QuickTest Professional angeboten. Borland SilkTest: Die Firma Borland bietet mit SilkTest eine umfangreiche Lösung zum Testen der Softwarefunktionalitäten von Anwendungen, die über eine grafische Benutzeroberfläche gesteuert werden, an. QF-Test: Mit dem Tool QF-Test der Firma Quality First Software lassen sich u. a. via Capture / Replay Aufzeichnungen zur Automatisierung von Java und Web GUI Funktions-, Regressions- und Lasttests durchführen. Watij: Bei Watij (Web Application Testing in Java) handelt es sich um ein Open-Source-Framework in Java. Es besitzt weder eine grafische Bedienoberfläche noch wird Capture & Replay unterstützt. Die Tests müssen manuell codiert und danach compiliert werden. Yawet: Yawet ist ein Testroboter von der Firma InforMatrix GmbH. Das Werkzeug ist sehr einfach gehalten und unterstützt daher nur grundlegende Funktionalitäten. Badboy: Badboy ist eine von der Firma Badboy Software entwickelte, schlanke Capture & Replay Testsoftware. Da sie einen eignen Browser zur Ausführung der Testfälle besitzt, kann keine Browserkompatibilität garantiert werden. evalid: evalid von der Firma Software Research, Inc. unterstützt nur Tests mittels Microsoft Internet Explorer, da es in den installierten Internet Explorer integriert wird. Daher können auch alle Funktionen, die der Internet Explorer bietet, genützt werden. QA Wizard Pro: Die Firma Seapine Software bietet in ihrem Portfolio unter anderem dem QA Wizzard Pro für Funktions- und Regressionstests an. Da sie weitere Produkte im Test-Lifecycle anbietet, können Daten aus anderen Produkten in den Testfällen wiederverwendet werden. Test4Q: Test4Q ist ein Host-orientiertes Capture-/Replay Tool, das speziell CICS-Transaktionen verarbeiten kann. Eine Fülle weiterer Funktionalitäten auch für den Batchablauf stehen ebenfalls zur Verfügung. Unter bestimmten Voraussetzungen ist auch eine (Teil)automatisierung zur Erstellung der Testscripte (ohne eine vorherige Aufzeichnung) möglich. 46

http://www.stickyminds.com/ Welcome to StickyMinds.com one of the first and most popular online communities for software development professionals. StickyMinds.com is dedicated to improving software quality throughout the software development lifecycle. Written by industry experts, StickyMinds.com covers topics ranging from agile testing to mobile and cloud computing and everything in between. You ll also find blog postings, software testing jobs, Q&A and more. Membership is free and includes a complimentary digital subscription to Better Software magazine. To get started, simply click Join in the upper right corner, and you ll be plugged in for the latest in software testing and quality assurance 47