Visuell-unterstütztes Programmieren Visuelles Testen von Programmen

Visuell-unterstütztes Programmieren Visuelles Testen von Programmen
Vortragende: Dennis Kalkofen, Carsten Takac TU Darmstadt, Fachbereich Informatik Seminar: Visuell unterstütztes Programmieren SS 2002 Vortrag am , betreut von Prof. em. Dr. H.-J. Hoffmann

Gliederung Wofür testet man Programme? Testen des Syntax
Testen einzelner Programmteile Integrationstests Tests nach Programmänderungen

Wofür testet man Programme?
Weshalb Testen | Syntax | Programmteile | Integrationstests | Programmänderung Wofür testet man Programme? Fehlersuche, -korrektur Erkennen konzeptioneller Probleme Verständnis Zusammenspiel der Bestandteile Test auf bestimmte Eigenschaften Laufzeitanalyse

Formatieren von Quelltext
Weshalb Testen | Syntax | Programmteile | Integrationstests | Programmänderung Formatieren von Quelltext Übersichtlichkeit Lesbarkeit Verständnis mehr als nur Schönschrift erleichtert Teamarbeit

Formatierungsmittel Anordnung des Codes Namen von Bezeichnern
Weshalb Testen | Syntax | Programmteile | Integrationstests | Programmänderung Formatierungsmittel Anordnung des Codes Namen von Bezeichnern farbcodierter Text Kommentierungen Linien zur Unterteilung

Weshalb Testen | Syntax | Programmteile | Integrationstests | Programmänderung

Worauf ist zu achten? die ganze Programmierergruppe muß damit zurecht kommen nicht gegen gängige Konventionen Unterstützung des Editors und der IDE Richtlinien regelmäßig überprüfen

Animierte Algorithmen
Weshalb Testen | Syntax | Programmteile | Integrationstests | Programmänderung Animierte Algorithmen zeigen den dynamischen Programmablauf dienen zum Programmverständnis finden von Fehlern Abstraktion

Beispiel: Quicksort Größe des Elementes Array

Bewertung der Animation
Weshalb Testen | Syntax | Programmteile | Integrationstests | Programmänderung Bewertung der Animation mit einfachen Mitteln die Funktionsweise von Bubblesort gezeigt abstrahiert auf rote/grüne Balken dennoch das Wesentliche ersichtbar => ein Fehler wäre mit dieser Animation leicht zu finden

Beispiel 2: Sortieralgorithmen im Vergleich
Weshalb Testen | Syntax | Programmteile | Integrationstests | Programmänderung Beispiel 2: Sortieralgorithmen im Vergleich Bubblesort Quicksort Shellsort Beginn kurze Zeit später Am Ende

Bewertung der Animation
Weshalb Testen | Syntax | Programmteile | Integrationstests | Programmänderung Bewertung der Animation andere Betrachtungsweise von Sortieralgorithmen Vergleich des Verlaufs besser möglich Rückschlüsse auf Arbeitsweise Rückschlüsse auf Komplexität

Exkurs: Tonunterstützung
Weshalb Testen | Syntax | Programmteile | Integrationstests | Programmänderung Exkurs: Tonunterstützung Erweitern oder Ersetzen von visuellen Mitteln gleichzeitiges Arbeiten mit visuellen Mitteln stört nicht die GUI eines Programmes kann leichtere Darstellung sein als visuell

Umrißdiagramme ursprünglich für ALGOL-Programme entwickelt
Weshalb Testen | Syntax | Programmteile | Integrationstests | Programmänderung Umrißdiagramme ursprünglich für ALGOL-Programme entwickelt angepaßt an Objektorientierung und Logische Sprachen visualisieren Änderungen während Programmablauf Basis für Testprogramme

Aufbau bestehen aus ineinandergeschachtelten Boxen
Weshalb Testen | Syntax | Programmteile | Integrationstests | Programmänderung Aufbau bestehen aus ineinandergeschachtelten Boxen jede Box repräsentiert Zustand einer Prozedur Veränderungen während Programmablauf Box beinhaltet Attribute, Rücksprungadresse (rpdl) und Quelltext instruction pointer Box wird gelöscht, wenn zurückgesprungen wird

Beispiel f id attr value x y p1 int proc 2 10 p1.cf rpdl system begin ... end f;

Aufruf einer Prozedur f id attr value rpdl system var x, y : int; procedure p1(value y: int); y := 1; end p1; begin x := 1; p1(0); y := 3; end f;

Aufruf einer Prozedur f id attr value x y int - - rpdl system var x, y : int; procedure p1(value y: int); y := 1; end p1; begin x := 1; p1(0); y := 3; end f;

Aufruf einer Prozedur f id attr value x y p1 int proc - - - rpdl system var x, y : int; procedure p1(value y: int); y := 1; end p1; begin x := 1; p1(0); y := 3; end f;

Aufruf einer Prozedur f id attr value x y p1 int proc 1 - - rpdl system var x, y : int; procedure p1(value y: int); y := 1; end p1; begin x := 1; p1(0); y := 3; end f;

Aufruf einer Prozedur f id attr value x y p1 int proc 1 - cf rpdl system var x, y : int; procedure p1(value y: int); y := 1; end p1; begin x := 1; p1(0); y := 3; end f; id attr value y int rpdl y:=3; y := 1;

Aufruf einer Prozedur f id attr value x y p1 int proc 1 - cf rpdl system var x, y : int; procedure p1(value y: int); y := 1; end p1; begin x := 1; p1(0); y := 3; end f; id attr value y int 1 rpdl y:=3; y := 1;

Aufruf einer Prozedur f id attr value x y p1 int proc 1 3 - rpdl system var x, y : int; procedure p1(value y: int); y := 1; end p1; begin x := 1; p1(0); y := 3; end f;

Dynamische Datenstrukturen
Weshalb Testen | Syntax | Programmteile | Integrationstests | Programmänderung Dynamische Datenstrukturen Beispiel: Array f in Heaps dargestellt id attr value A x arr int true false rpdl ... ...

Testen komplexer Systeme mit GUI
Historisch: Mainframe  Client/Server mit GUI Geänderte Anforderungen vielversprechender Ansatz: „Capture/Replay“ Tools Mainframe: Textbasiert Eingabe / Berechnung / Ausgabe Client/Server: Leistungsfähigkeit Vernetzung Vielfältige Möglichkeiten der Interaktion mit GUI-Elementen (Menüs, Buttons, Bildlaufleisten, Symbolleisten) Nicht vorhersehbares Verhalten  neue Testverfahren

Wie wird GUI gestestet? Einhaltung spezifizierter Vorgaben? Use-Cases
Probleme: komplexe Abläufe Unmengen an „Verzweigungen“  Manuell kaum möglich! Vorgaben? Vor Projektbeginn festgehalten Tester probiert anhand festgehaltener Testfälle durch ob Reaktion des Servers wie erwartet Z.B. Klick File Open  Auswahldialog für Datei  Bestätigung  Laden der Datei Probleme: Beschaffenheit Client/Server Applikationen oft sehr komplex Z.B. Speichert Datum in DB – nicht nachvollziehbar (relational, verteiltes System…) Multi-User-Tests unmöglich Vielzahl an Möglichkeiten  Verzweigungen wachsen mit vielen Graph. Bedienungselementen  Anzahl Pfade gleicher Länge = Aktionssequenzen mit gl. Anzahl an Schritten wächst exponentiell

Automatisches Testen – „Capture/Replay“ Tools
Idee: - Aufzeichnen der Benutzeraktivitäten (Capture) - Editieren, Kombinieren Wiedergabemöglichkeiten (Replay) Nur kurz

„Capture/Replay“ Tools
Tester Interaktion GUI C/R Tool capture replay Test Skript editieren, kombinieren Testsystem Erläutern

Capture - GUI-Elemente als Objekte
- User-Aktivitäten den Objekten zuordnen - Sequenz festhalten im Testskript Objekte mit ID und Attributen (z.B. Name, Farbe, Beschriftung) Benutzereingaben (Mausklicks, Tastatureingaben)

Testskript (1) Erste Sequenz aufgezeichnet Programmierung möglich
FileOpen.Files.SelectFileName Erste Sequenz aufgezeichnet Programmierung möglich FileOpen.OK.Click Möglichkeiten strukturierter Programmiersprachen wie Fallunterscheidung, Schleifen und Subroutinen

Testskript (2) Editiermöglichkeiten Bibliotheken FileOpen.OK.Click
Auswahl Sequenz File.Edit.TextInput File.Edit.TextFormat Auch komplett manuell möglich (z.B. wenn noch kein Testsystem komplett implementiert) Oft: Vorgefertigte Skripte als Module in Bibliothek können übernommen werden Schleife File.Scrollbar.Down …

Replay Gemerkte Aktionen automatisch ausführen Objektorientierung !
Kontrollpunkte für gewünschte Reaktion des GUI Abweichungen in Datenbank speichern Analyse / Korrektur der Fehler erneute Ausführung Testsystem übernimmt Rolle des Bedieners (Tester kann virtuellen Benutzer am Bildschirm beobachten) Objektorientierte Indexierung der GUI-Elemente. Gleiches Skript auch wenn Buttons andere Farbe oder Position Kontrollpunkte z.B. Anzahl Elemente Menü, Inhalt Textfeld bei Tastatureingabe, Bildpunkte Bitmap - Wie soll GUI nach bestimmter Sequenz von Aktionen aussehen – tatsächliches Aussehen mit Kontrollpunkt vergleichen

Bewertung Multi-User-Einsatz Zeitplanung
Schnelligkeit, Konsistenz, Reproduzierbarkeit Einbeziehung der Anwender in Testphase Kosten „Intelligenz“ des C/R Tools Vorteile: Startzeiten für Skripte  Multi User  Belastungstest Automatisch mehrere Plattformen testen Resourcenintensiv ohne Beaufsichtigung am Wochenende, später auswerten/korrigieren Intuitive Oberfläche bei C/R -> weniger Kommunikationsprobleme Nachteile: Kosten Lizenz, Installation, Wartung (wenn überhaupt C/R für spezif. Anforderungen existiert) Aufzeichnen von Aktivitäten oft erst sehr spät im Entwicklungsprozeß möglich, wenn schon fast komplett implementiert -> jetzt Fehler gefunden, Korrektur schwierig, teuer Intelligenz: Automatisiert nur bei Wiederholung sinnvoll Programmierer als Tester bedient nur wie für ihn logisch wie geplant Benutzer intuitiv evtl. anders System automatisch alle sinnvollen Variationen testen? Notwendige Vorgaben des Programmierers Unvollständig oder fehlerhaft -> C/R bedingt sinnvoll

Bibliographie - B. Jayaraman, C.M. Blatus: Visualizing program execution; Proc. IEEE Symp. Visual Languages, 1996, 30-37 - T. Hill et al.: Visualising the structure of object-oriented systems; Proc. IEEE Intl. Symp. Visual languages, 2000, R. Baecker et al.: Software visualization for debugging; Comm. ACM, 40 (1997) 4, 44-54 E.F.Miller: Software test tools considered harmful?; Application Note, undatiert; T.Souder et al.: Form – A framework for creating views of program execution; IEEE Intl. Conf. Software Maintenance, 2001, 612 ff T. Ostrand et al.: A visual test development environment for GUI systems; ACM Software Engineering Notes, 23 (1998) 2, 82-92 NN (GI): Questionnaire on OO-test tools; Mai 1999, NN (Intl. Software Automation, Inc.): Java Analyzer & Panorama for Java;

Visuell-unterstütztes Programmieren Visuelles Testen von Programmen

Ähnliche Präsentationen

Präsentation zum Thema: "Visuell-unterstütztes Programmieren Visuelles Testen von Programmen"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Visuell-unterstütztes Programmieren Visuelles Testen von Programmen

Ähnliche Präsentationen

Präsentation zum Thema: "Visuell-unterstütztes Programmieren Visuelles Testen von Programmen"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback