Übung zur Vorlesung Einführung in Software Engineering

Transkript

1 Übung zur Vorlesung Einführung in Software Engineering Wintersemester 2012/13, Richard Bubel und Martin Hentschel Übungsblatt 5: Testen Abgabeformat: Reichen Sie Ihre Lösung per SVN als eine PDF-Datei ein. Diese muss unter trunk/ex05/solutions.pdf abgelegt werden. Während der Übungsbearbeitung können Sie Ihre Lösungen beliebig oft in das SVN hochladen (per Commit). Wir prüfen die Zeit der Einreichung Ihrer Lösungen unter der Benutzung des SVN Zeitstempels. Hinweis: Sollten die Richtlinien des Abgabeformats nicht eingehalten werden, können wir 0,5 Punkte von den erreichten Punkten abziehen! Verletzungen der Kriterien sind z.b. eine Abgabe per , Dateien im Microsoft Word oder ODT-Format, mehrere Dateien, ein anderer Dateiname oder ein anderes Verzeichnis. Abgabetermin: :00 Uhr Aufgabe 5.1 (13 Punkte) Ziel: Systematisches Testen von komplexen Methoden Aufgabe: Erstellen Sie zu der Methode magic aus Listing 1 je einen minimalen Testplan, um die folgenden Coverage- Kriterien bestmöglich zu erfüllen. Nutzen Sie die Grundstruktur eines Testplans wie sie in Tabelle 1 dargestellt wird und achten Sie auf eine aussagekräftige Erklärung. a) Statement Coverage (SC) anhand des Source-Codes Erklärung: Zeilennummern, z.b. 1, 4 5,... b) Basic Block Coverage (BBC) anhand des Byte-Codes Erklärung: Blöcke im Bytecode, ggf. Grafik wie in der Vorlesung erstellen und Blöcke eindeutig benennen c) Branch Coverage (BC) anhand des Source-Codes Erklärung: Kanten im Kontrollflußgraph, ggf. Grafik wie in der Vorlesung erstellen und Kanten eindeutig benennen d) Path Coverage (PC) anhand des Source-Codes Erklärung: Kanten im Kontrollflußgraph, ggf. Grafik wie in der Vorlesung erstellen und Kanten eindeutig benennen e) Condition Coverage (CC) anhand des Source-Codes Erklärung: Zeilennummer der Condition = boolscher Wert, z.b. 4 = true, 8 = true,... f) Decision Coverage (DC) anhand des Source-Codes Erklärung: Zeilennummern der Decision = boolscher Wert, z.b. 4 5 = false, 8 11 = true g) Modified Condition Decision Coverage (MCDC) anhand des Source-Codes Formen Sie die Bedingungen wenn nötig um, damit MCDC berechnet werden kann Erklärung: Zeilennummer der Condition = boolscher Wert sowie Zeilennummern der Decision = boolscher Wert, z.b. 8 = false, 8 10 = true h) Multiple-Condition Coverage (MCC) anhand des Source-Codes Erklärung: Nicht notwendig Ist eine Methode die erfolgreich zu 100 % mit allen Coverages getestet wurde garantiert fehlerfrei? Begründen Sie Ihre Meinung mit einem minimalen Beispiel. 1

2 Test Case magic(a,b,c) Erwartetes Ergebnis Erklärung (z.b. mit Hilfe von Zeilennummern) Tabelle 1: Grundstruktur eines Testplans Listing 1: Magic 1 public class Magic { 2 public static int magic(boolean a, boolean b, String c) { 3 int result = 1; 4 if (a 5 b) { 6 result ++; 7 } 8 if (a && 9 b 10 (c.isempty() && 11 a)) { 12 return result; 13 } 14 else { 15 return result * -1; 16 } 17 } 18 } Listing 2: Magic Bytecode 1 public static int magic(boolean, boolean, java.lang.string); 2 Code: 3 0: iconst_1 4 1: istore_3 5 2: iload_0 6 3: ifne : iload_1 8 7: ifeq : iinc 3, : iload_ : ifeq : iload_ : ifne : aload_ : invokevirtual #16; // Method java/lang/string.isempty:()z 16 25: ifeq : iload_ : ifeq : iload_ : ireturn 21 34: iload_ : iconst_m : imul 24 37: ireturn LineNumberTable: 27 line 3: 0 28 line 4: 2 29 line 5: 6 30 line 6: line 8: line 9: line 10: line 11: line 12: line 15: 34 2

3 Aufgabe 5.2 (2 Punkte) Ziel: Systematisches Testen erlernen Aufgabe: Schreiben Sie JUnit 4 Tests für die Klasse Category der Anwendung TheQuiz. Implementieren Sie diese innerhalb der Klasse CategoryTest aus dem vorgegebenen Test-Projekt verfügbar auf der Webseite Sie können die vorgegebene JUnit 4 TestSuite (AllTestsSuite) nutzen, um alle Tests der Anwendung in einem Durchlauf zu starten. Stellen Sie mit Hilfe von EclEmma sicher, dass Ihre Tests für die Klasse Category 100 % Statement-Coverage erreichen. Testen Sie die gesamte implementierte Funktionalität der Klasse, also auch die geworfenen Ereignisse. Es empfiehlt sich vorhandene Funktionalität aus dem Package de.tud.se.test wiederzuverwenden. Die zu testende Klasse darf selbverständlich nicht editiert werden. Integrieren Sie den Quellcode der Klasse CategoryTest als Lösung in die Lösungsdatei (solutions.pdf). Hinweis JUnit 4: JUnit ist ein Framework zum automatischen Testen von Java-Programmen. Listing 3 enthält die beispielhaft zu testende Methode sub. Der zugehörige Test ist in Listing 4 implementiert. Test-Methoden besitzen keine Parameter, dürfen Exceptions werfen und sind mit der versehen. Erwartete Sollwerte werden mit aktullen Istwerte durch statische Methoden der Klasse org.junit.assert verglichen. Diese beginnen für gewöhnlich mit dem Prefix assert. In Eclipse wird der geöffnete JUnit Tests über Run, Run As, JUnit Test, wie Abbildung 1 zeigt, gestartet. Das Ergebnis der Testausführung wird anschließend in der View JUnit dargestellt. Nähere Informationen zu JUnit 4 finden Sie unter Listing 3: IntegerUtil 1 2 public class IntegerUtil { 3 public static int sub(int minuend, 4 int subtrahend) { 5 return minuend - subtrahend; 6 } 7 } Listing 4: IntegerUtilTest 1 import static org.junit.assert. assertequals; 2 3 import org.junit.test; 4 5 public class IntegerUtilTest { 7 public void testsub() { 8 assertequals(3, IntegerUtil.sub(5, 2)); 9 } 10 } Hinweis EclEmma: EclEmma ist ein Werkzeug um Code-Coverage von Java-Programmen zu bestimmen. Installieren Sie das Werkzeug zunächst über den Eclipse Marketplace, wie in Abbildung 2 gezeigt. Anschließend können Sie den geöffneten JUnit Test, wie in Abbildung 3 gezeigt, über Run, Coverage As, JUnit Test starten. Wie Abbildung 4 zeigt, färbt EclEmma den Quellcode gemäß der im Test erreichten Coverage ein. Nähere Informationen zu EclEmma finden Sie unter Achtung: EclEmma zeigt Basic Block Coverage (BBC) sowie Condition Coverage (CC) an! 3

4 Abbildung 1: JUnit Tests in Eclipse starten Abbildung 2: EclEmma über den Eclipse Marketplace installieren 4

5 Abbildung 3: JUnit Test mit EclEmma starten 5

6 Abbildung 4: Ergebnis von EclEmma betrachten 6

7 Aufgabe 5.3 (2 Punkte) Ziel: Systematisches Testen erlernen Aufgabe: a) Erstellen Sie in der Testklasse ArrayUtilIndexOfStatementCoverageTest minimale JUnit 4 Test(s), die 100 % Statement Coverage für die Methode ArrayUtil#indexOf(Object[], Object, Comparator) erreichen. b) Erstellen Sie in der Testklasse ArrayUtilIndexOfConditionCoverageTest minimale JUnit 4 Test(s), die 100 % Condition Coverage für die Methode ArrayUtil#indexOf(Object[], Object, Comparator) erreichen. Integrieren Sie den Quellcode der Testklassen als Lösung in die Lösungsdatei (solutions.pdf). Hinweis: Nutzen Sie die in Aufgabe Aufgabe 5.2 vorgestellten Werkzeuge. Aufgabe 5.4 (Gruppenaufgabe) Ziel: Testen von Benutzeroberflächen Aufgabe: Testen Sie das von Ihnen in Aufgabe 4.3 implementierte AbstractQuestionGamePanel mit Hilfe von JUnit 4. Das Ziel ist es, die gesamte Funktionalität bestmöglich zu testen. Überlegen Sie sich ein Konzept, damit Ihre Tests trotz dem zufälligen Anzeigen von Antworten stabil das selbe Ergebnis (erfolgreich, fehlgeschlagen) in jedem Testdurchlauf liefern und dokumentieren Sie dieses. Versuchen Sie, 100 % Condition-Coverage zu erreichen und auch Sonderfälle, wie z.b. dass die maximal Anzahl richtiger Antworten kleiner als die minimale ist, zu testen. Sollten Sie die Aufgabe 4.3 nicht gelöst haben, können Sie alternativ die Klasse MultipleChoiceQuestionGamePanel des Lösungsvorschlags testen. Benutzeroberflächen können weitestgehend wie normale Objekte getestet werden. In Java können geöffnete Fenster von AWT oder Swing dank der statischen Methode Window.getWindows() im Test gefunden werden. Einzelne Komponenten in einem Fenster können mit den Utility-Methoden aus SwingTestUtil abgefragt werden. Benutzereingaben in einer Komponente können anschließend durch die Verwendung der normalen API simuliert werden. Beispielsweise kann die Eingabe eines Textes auf einem JTextField durch atextfield.settext("userinput") simuliert werden. Zu beachten ist, dass der Zugriff auf die UI-Komponenten stets innerhalb des Threads der Benutzeroberfläche erfolgen muss. Daher bietet die Klasse SwingTestUtil zusätzlich Methoden für den sicheren Zugriff auf gängige API-Methoden. Im Beispiel des Ändern eines Textes auf einem JTextField sollte SwingTestUtil.setText(aTextField, "UserInput") anstelle des direkten Methodenaufrufs von settext(...) verwendet werden. Diskutieren Sie in der Gruppen diesen Ansatz zum Testen von Swing basierten Anwendungen. Welche Vorteile bietet er? Welche Unterschiede gibt es im Vergleich zu echten Benutzereingaben? Welche Komponenten können nicht getestet werden? Wann ist es nötig den Test in einem separaten Thread auszuführen? Welche Alternativen gibt es zum Testen von Benutzeroberflächen? Vorgehensweise: Verwenden Sie das verwendete SVN-Repository aus Aufgabe 4.3 erneut. Sollten Sie die Aufgabe 4.3 nicht gelöst haben, bestimmen Sie ein Gruppenmitglied unter dessen SVN-Repository Sie die Lösung der Gruppe abgeben möchten. Importieren Sie das Projekt de.tud.se.quiz.test in Eclipse. Den Quellcode finden Sie auf der Vorlesungs-Webseite Committen Sie das unveränderte Projekt nur bei dem ausgewählten Gruppenmitglied unter trunk/de.tud.se.quiz.test bevor Sie mit der Implementierung beginnen! 7

8 Nutzen Sie FindBugs und EclEmma. Erstellen Sie gemeinsam die Lösung der Aufgabe und diskutieren Sie diese (Review). Abgabe Hinweise: Das Gruppenmitglied unter dessen SVN-Account das Projekt committed wurde nennt in der Lösungs-Datei trunk/ex05/solutions.pdf alle Gruppenmitglieder und dokumentiert das Konzept sowie die Antworten zu den Fragen bezüglich des Ansatzes zum Testen von Benutzeroberflächen. Alle anderen Gruppenmitglieder nennen in trunk/ex05/solutions.pdf lediglich den Namen des Studenten, dessen SVN-Repository den Quellcode und die Bewertung enthält. Orientieren Sie sich an dem Test FreeAnswerQuestionGamePanelTest. Nutzen Sie die Test-Utility-Klassen SwingTestUtil und TheQuizTestUtil. Erweitern Sie deren Funktionalität falls nötig. 8