1 Implementierung eines Werkzeugs zur Kombination von Testfällen mit EingabedatenBetreuer: Dipl.-Wirt.-Inf. Michael Linschulte Projektteam: Axel Balke Benedikt Krüger Christian Menke Heinrich Drobin Jahn Heymann Magnus Kortenjann Simon Waloschek
2 Inhalt Einleitung Realisierung Test der Implementierung FallstudieFazit & Ausblick Projektgruppe 4 Inhaltsverzeichnis
3 Projektdefinition HTML XML Testcase generator tool HTML SeleniumTestdatengenerator „ETES“ HTML TC1 HTML TC2 HTML TC3 HTML TC.. HTML Testcase manuelle Bearbeitung HTML Testcase Template XML Testdaten Testcase generator tool Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
4 Einleitung – Realisierung – Test – Fallstudie – FazitProjektdefinition Html Xml select arrival $XML[Arrival]
5 Designentscheidungenals Framework Programmaufbau Oberfläche Thread SAX DOM QXmlSimpleReader GUI ReaderThread XMLHandler TestController TestCaseWriter Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
6 Einleitung – Realisierung – Test – Fallstudie – FazitDie GUI Pfadangaben Fortschrittsbalken Startet die Bearbeitung Beendet das Programm Eingabefeld für Errortyp Statistik Debug Ausgabe Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
7 Einleitung – Realisierung – Test – Fallstudie – FazitReaderThread GUI ReaderThread QXmlSimpleReader XMLHandler TestController TestCaseWriter Oberfläche Thread SAX DOM Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
8 Einleitung – Realisierung – Test – Fallstudie – FazitReaderThread Selbständiger Prozess Über Signals & Slots mit der GUI verbunden Qt System (ähnlich Events) Stellt Methoden bereit Debug Statistik Fortschritt Status Initialisiert XML Handler & QXmlSimpleReader Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
9 Einleitung – Realisierung – Test – Fallstudie – FazitXML Handler GUI ReaderThread QXmlSimpleReader XMLHandler TestController TestCaseWriter Oberfläche Thread SAX DOM Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
10 Einleitung – Realisierung – Test – Fallstudie – FazitXML Handler Eventhandler für QXmlSimpleReader Liest XML-Datei elementweise ein Baut XML-Teilbaum auf Beim Ende eines Actions-Block Überprüfen des erstellten Teilbaums Übergabe an TestController Löschen des Blocks Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
11 Einleitung – Realisierung – Test – Fallstudie – FazitTestController GUI ReaderThread QXmlSimpleReader XMLHandler TestController TestCaseWriter Oberfläche Thread SAX DOM Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
12 Klasse TestControllerAufgaben des TestControllers HTML Template als QDomDocument einlesen Teilbäume vom XML Handler für die Klasse TestCase kombinieren Wichtige Funktionen des TestControllers setTemplate liest das HTML Template ein setActions erstellt Testfälle Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
13 Klasse TestControllerXML-Reader TestController TestCase 1 TestCase 2 TestCase 3 Funktionsweise:
14 Einleitung – Realisierung – Test – Fallstudie – FazitTestcasewriter GUI ReaderThread QXmlSimpleReader XMLHandler TestController TestCaseWriter Oberfläche Thread SAX DOM Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
15 Klasse TestcasewriterAufgabe des Testcasewriters XML Daten in HTML Template einfügen HTML Testfälle im Ausgangsordner abspeichern Aufbau des Testcasewriters Konstruktor erzeugt neuen Testfall Zwei private Unterfunktionen replaceData (QDomNodeList pList) getXMLData (QString pFieldName) Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
16 Klasse TestcasewriterFür alle Elemente in der Liste Liste erstellen Liste durchlaufen Enthält Element Text mit $XML[…] Enthält Element Kinder $XML Feld Ersetzen ja nein Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
17 Einleitung – Realisierung – Test – Fallstudie – FazitTestumgebung Unittests: Test von einzelnen Methoden im Programmcode → White Box Test, hier nicht realisierbar Anwendung von Black Box Test Code-Coverage: Messung des Abdeckungsgrades des Codes → Kein wirklicher Test, sondern nur Maß für die Güte des Tests Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
18 Einleitung – Realisierung – Test – Fallstudie – FazitCode Coverage Überwachung der Ausführung pro Zeile (Anweisungsüberdeckung; C0 Test) Finden von nicht ausgeführtem Code 100%ige Überdeckung bedeutet nicht Fehlerfreiheit Fehlende Überdeckung bedeutet unzureichende Tests Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
19 Code Coverage 14 Testfälle wurden aufgestellt und durchgeführtMethode: Überdeckungsgrad: main.cpp 100.00% mainwindow.cpp 94,44% readerthread.cpp 88,64% testcasewriter.cpp 93,59% testcontroller.cpp 98,11% xmlhandler.cpp 98,33% Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
20 Einleitung – Realisierung – Test – Fallstudie – FazitCode Coverage Die Testfälle wurden soweit modifiziert, dass Errors auftreten und somit die Abfangmethoden ebenfalls durchgeführt werden müssen Beispiel eines nicht ausgeführten Codefragments: #####: 76:void ReaderThread::statusTxt(QString statusTxt) -: 77:{ #####: 78: emit writeStatus(statusTxt); #####: 79:} Inkorrekte Pfadangaben werden beim Template nicht abgefangen. Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
21 Einleitung – Realisierung – Test – Fallstudie – FazitFallstudie in Iselta Nutzen des Tools beim Testen von Webseiten mittels „Selenium“ Alle Testfälle werden im optimalen Fall positiv abgeschlossen Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
22 Fallstudie - Szenario 1 gültige Eingaben ZeichenkettenZeichenketten nach speziellem Schema Zahlen Buchungsdaten – Formular in Iselta Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
23 Einleitung – Realisierung – Test – Fallstudie – FazitFallstudie - Szenario 1 Demonstration Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
24 Fallstudie - Szenario 1 fehlerhafte Eingabenicht aufgetretene Fehlermeldung Ergebnis des ersten Szenarios in Selenium Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
25 Einleitung – Realisierung – Test – Fallstudie – FazitFallstudie - Szenario 1 Alle negativ abgeschlossen Tests haben die gleiche Ursache: Zeichenketten, welche nur Sonderzeichen beinhalten werden als valide Eigennamen von Iselta akzeptiert Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
26 Fallstudie - Szenario 2 gültige Eingaben Zeichenketten Ganze ZahlenKommazahlen Hoteldaten – Formular in Iselta Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
27 Fallstudie - Szenario 2 fehlerhafte Eingabenicht aufgetretene Fehlermeldung Hoteldaten – Formular in Iselta Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
28 Einleitung – Realisierung – Test – Fallstudie – FazitFallstudie - Szenario 2 Alle negativ abgeschlossen Tests haben wieder die gleiche Ursache: Zeichenketten, welche nur Sonderzeichen beinhalten werden als valide Bezeichnungen (bzw. Eigennamen) von Iselta akzeptiert Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
29 Einleitung – Realisierung – Test – Fallstudie – FazitIselta prüft bei beiden getesteten Szenarien Zeichenketten nicht auf semantische Korrektheit Das Tool kann Testfälle generieren, welche Fehler entdecken und lokalisieren können Projektgruppe 4 Einleitung – Realisierung – Test – Fallstudie – Fazit
30 Einleitung – Realisierung – Test – Fallstudie – FazitFazit & Ausblick Tool erleichtert das Erstellen von Testfällen Problem: Nur für eine Formularseite Lösung: Erweiterte Platzhalter z.B. $XML.
31 Vielen Dank für Ihre Aufmerksamkeit!Projektgruppe 4 Ende