Testen von Benutzeroberflächen - Department of Information Systems

Westfälische Wilhelms-Universität Münster
Ausarbeitung
Testen von Benutzeroberflächen
im Rahmen des Skiseminars Software Engineering
Fabian Scholz
Themensteller: Prof. Dr. Herbert Kuchen
Betreuer: Prof. Dr. Herbert Kuchen
Institut für Wirtschaftsinformatik
Praktische Informatik in der Wirtschaft
Inhaltsverzeichnis
1 Einleitung ................................................................................................................... 1 2 Grundlagen des Testens ............................................................................................. 2 3 2.1 Testen von Software ........................................................................................... 2 2.2 Grafische Benutzerschnittstellen ........................................................................ 3 2.3 Testen von Benutzeroberflächen ........................................................................ 5 Tools zum Testen von Benutzeroberflächen ............................................................. 8 3.1 Automatisierung von Tests ................................................................................ 8 3.2 Merkmale der GUI-Testtools ............................................................................. 9 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 3.2.8 3.2.9 4 5 Plattformunterstützung................................................................................ 9 Toolkit-Unterstützung ............................................................................... 10 Ausführungsmodus ................................................................................... 10 Identifikation der Oberflächenelemente ................................................... 11 Testskriptgenerierung ............................................................................... 12 Ergebnisvergleich ..................................................................................... 14 Skripttechniken ......................................................................................... 15 Synchronisation ........................................................................................ 17 Testfallverwaltung .................................................................................... 17 IBM Rational Functional Tester 8.0 ........................................................................ 18 4.1 Vorstellung ....................................................................................................... 18 4.2 Aufzeichnungsablauf........................................................................................ 19 4.3 Verhalten bei Oberflächenänderungen ............................................................. 22 Resümee und Fazit ................................................................................................... 25 Literaturverzeichnis ........................................................................................................ 27 II
Kapitel 1: Einleitung
1 Einleitung
Die meisten heutigen Softwaresysteme werden über grafische Benutzeroberflächen
bedient. Die Gründe dafür liegen vor allem in der leichteren und intuitiveren
Handhabung gegenüber Systemen, die über Befehlseingaben angesteuert werden. Zur
Qualitätssicherung
der
Software
gehört
neben
dem
Testen
der
einzelnen
Softwarekomponenten auch das Testen der Benutzeroberfläche. Die Vielzahl der
grafischen Oberflächenelemente wie Buttons, Texteingabefelder oder Menüs und die
vielen möglichen Benutzerinteraktionen mit diesen Elementen machen das manuelle
Testen der Oberfläche zu einem langwierigen, monotonen und kostspieligen Prozess.
Abhilfe soll hier die Automatisierung des Oberflächentests schaffen. Die Hersteller von
Testtools, die das automatisierte Testen ermöglichen, werben mit großen Zeit- und
Kostenersparnissen, so dass Software schneller, günstiger und fehlerfreier auf den
Markt gebracht werden kann. Die Tools unterscheiden sich sowohl hinsichtlich ihrer
Unterstützung von Plattformen und Schnittstellentechnologien als auch der eingesetzten
Methoden, die die Testautomatisierung ermöglichen sollen.
Ziel dieser Arbeit ist es, ein führendes auf dem Markt befindliches Testtool anhand
dieser Techniken und weiterer Merkmale vorzustellen. Dazu wird im zweiten Kapitel
der Oberflächentest zunächst in den gesamten Testprozess eingeordnet, wozu die
Grundlagen des Testens und grafischer Benutzerschnittstellen (Graphical User
Interface, GUI) erläutert werden. Daneben wird auf die besonderen Probleme
eingegangen, die der Oberflächentest mit sich bringt. Im dritten Kapitel werden dann
die Vor- und Nachteile der Testautomatisierung zur Lösung dieser Probleme und die
allgemeinen Merkmale und Techniken zur Umsetzung der Automatisierung dargestellt,
bevor diese anschließend anhand des Tools konkretisiert werden. Daneben wird das
Verhalten des Tools bei Änderungen einer Oberfläche analysiert und der
Anpassungsaufwand abgeschätzt, um zu sehen, ob sich effizient Oberflächentests
durchführen lassen. Die Arbeit endet mit einem Resümee, der Bewertung des Tools und
einem kurzen Fazit.
1
Kapitel 2: Grundlagen des Testens
2 Grundlagen des Testens
Um auf den Test von Benutzeroberflächen im Besonderen einzugehen, wird im
Folgenden zunächst kurz allgemein auf das Testen im gesamten Entwicklungsprozess
von
Software
eingegangen
sowie
auf
die
Eigenschaften
von
grafischen
Benutzeroberflächen.
2.1 Testen von Software
Das Testen von Software dient der Sicherstellung bzw. Steigerung der Qualität der
Software. Dabei wird geprüft, ob sie den spezifizierten Anforderungen, die zu Beginn
des Entwicklungsprozesses dokumentiert werden, gerecht wird. Auf Basis dieser
Vorgaben wird ein Testplan erstellt, der die Auflistung aller möglichen Testfälle enthält.
Durch den Vergleich von vorgegebenem Verhalten mit dem Verhalten während der
Testdurchführung kann somit bestimmt werden, ob die Software den Anforderungen
entspricht oder nicht. Bei Abweichungen zwischen Soll- und Ist-Verhalten liegt ein
Fehler vor, der einen Qualitätsmangel darstellt. Das Ziel des Testens ist es diese Fehler
aufzudecken [SL05, S.12; PP04, S. 55; FR07 S. 24].
Der Testprozess kann mithilfe von Vorgehensmodellen zeitlich in den gesamten
Softwareentwicklungsprozess eingeordnet werden. Im klassischen V-Modell ist ein
finden die Testaktivitäten parallel zur Softwareentwicklung statt. Diese Testaktivitäten
werden in Teststufen unterteilt, wobei jede Teststufe einer Entwicklungsphase
zugeordnet
ist.
So
kann
auf
jeder
Stufe
überprüft
werden,
ob
die
Entwicklungsergebnisse den spezifizierten Anforderungen entsprechen. Die Teststufe
mit dem höchsten Detaillierungsgrad im V-Modell bildet der Komponententest, auch
Modul- oder Unit-Test genannt. In ihm werden einzelne Softwarebausteine, z.B.
Klassen, isoliert voneinander betrachtet und ihr Ein- und Ausgabeverhalten getestet,
sodass die Ursache für die Aufdeckung eines Fehlers direkt dem Testobjekt zugeordnet
werden kann. Nach dem Test der Komponenten hat dann der Integrationstest die
Aufgabe, das Zusammenspiel der zusammengefügten Komponenten zu überprüfen,
indem eventuelle Fehler in den Schnittstellen zwischen ihnen aufgedeckt werden. Nach
Abschluss des Integrationstests wird beim Systemtest als dritte Stufe geprüft, ob das
Softwaresystem als Ganzes die vorgegebenen Anforderungen vollständig und korrekt
2
Kapitel 2: Grundlagen des Testens
erfüllt. Der abschließende Test ist der Abnahmetest, bei dem das Urteil des Kunden
darüber entscheidet, ob die vertraglich festgehaltenen Leistungen erbracht wurden
[SL05, S.39ff.].
Auf diesen vier Teststufen des Entwicklungsprozesses kommen jeweils mehrere
unterschiedliche Testmethoden zum Einsatz. [LIG02, S. 33ff.] klassifiziert diese in
statische und dynamische Tests. Im Gegensatz zu dynamischen Tests wird bei
statischen Tests die zu testende Software nicht ausgeführt, sondern der Quelltext oder
das formale Softwaremodell analysiert. Dynamische Tests überprüfen hingegen das in
Ausführung befindliche Programm, das sich auch in realer Betriebsumgebung befinden
kann, mittels stichprobenartiger Eingabedaten. Zu den dynamischen Testtechniken
gehören vor allem funktionale, nicht funktionale und änderungsbezogene Tests.
Funktionale Tests umfassen alle Methoden, die das von außen sichtbare Ein- und
Ausgabeverhalten der Software mit den funktionalen Anforderungen vergleichen. Nicht
funktionale Tests überprüfen, wie gut das Softwaresystem qualitativen Anforderungen
an die Zuverlässigkeit, Effizienz und Benutzbarkeit gerecht wird. Dazu zählt z.B. die
Robustheit gegenüber Fehlbedienungen oder die Benutzerfreundlichkeit der grafischen
Oberfläche. Änderungsbezogene Tests werden auch Regressionstests genannt. Sie
werden bei Modifikationen des Softwaresystems durchgeführt und geben Aufschluss
darüber, ob das bereits getestete System nach dessen Änderung neue oder bisher
versteckte Fehler aufweist [SL05, S.69ff.].
2.2 Grafische Benutzerschnittstellen
Grafische Benutzerschnittstellen finden heute Einsatz in fast jedem modernen
Softwaresystem. Durch ihre pixelorientierte grafische Darstellung auf dem Bildschirm
und die Bedienung mit Maus, Tastatur und anderen Eingabegeräten lässt sich oft
leichter und intuitiver mit Software arbeiten als über text- und befehlsorientierte
Schnittstellen. Im Folgenden werden dazu die Grundbegriffe erläutert, auf deren
Verständnis der weitere Teil der Arbeit aufbaut.
Benutzerschnittstelle
Unter einer Benutzerschnittstelle versteht man eine Kommunikationsschnittstelle
zwischen Mensch und Computer, über die der Mensch mit dem Computer interagieren
3
Kapitel 2: Grundlagen des Testens
kann. Dazu zählen Hardwarekomponenten wie Tastatur, Maus oder der Bildschirm
sowie Softwaresysteme.
Grafische Benutzerschnittstelle
Eine grafische Benutzerschnittstelle (Graphical User Interface, GUI) ist der sichtbare
Teil der Benutzerschnittelle, der grafisch auf dem Bildschirm dargestellt wird. Sie
beinhaltet grafische Elemente (Widgets), mit deren Hilfe der Benutzer durch Interaktion
Daten mit der dahinter liegenden Software austauschen kann. Synonym für den Begriff
wird in dieser Arbeit auch von grafischen Benutzeroberflächen gesprochen [GBO08].
Fenstersystem
Die grafischen Elemente für den Datenaustausch zwischen Computer und Benutzer
werden in einem rechteckigen Ausschnitt, dem sogenannten Fenster, dargestellt, das auf
dem Bildschirm verschoben, vergrößert und verkleinert werden kann. Solche Elemente
können beispielsweise Menüs, Eingabefelder, Tabellen, Grafiken oder Textfelder sein,
die Informationen bereitstellen oder aufnehmen. Das Fenstersystem übernimmt die
Verwaltung der Fenster auf dem Bildschirm [FS08]. Zu ihren Aufgaben zählen unter
anderem, die Fenster und Elemente grafisch darzustellen und die Benutzereingaben an
die gerade fokussierte Anwendung weiterzuleiten. Daneben stellt das Fenstersystem ein
API (Application Programming Interface) zur Verfügung, das es erlaubt, in Fenstern zu
zeichnen oder Standard-Elemente wie Knöpfe oder Menüs zu erstellen und auf dem
Fenster zu positionieren. Für Webseiten dient im weitesten Sinne der Browser als
Fenstersystem.
Toolkit
Toolkits (Widget Toolkits) bauen auf der Funktionalität des Fenstersystems auf. Sie
stellen eine Anzahl eigener Oberflächenelemente (GUI-Elemente) bereit und besitzen
eine eigene Ereignisbehandlung. Beispiele für Toolkits sind Microsofts Windows Forms
für .Net-Anwendungen oder Suns Swing für Java-Anwendungen.
Ereignissteuerung
Durch die Interaktion des Benutzers mit den Oberflächenelementen werden Ereignisse
ausgelöst, die bestimmte Programmfunktionen ausführen. Bspw. wird durch einen
Mausklick auf einen Button das Ereignis buttonClick ausgelöst, das dazu führt ein
4
Kapitel 2: Grundlagen des Testens
Fenster zu schließen oder eine Berechnung durchzuführen. Besitzt ein Fenster neben
diesem Button noch zwei Textfelder, so kann der Benutzer selbst bestimmen, in welcher
Reihenfolge er mit den Elementen agieren möchte, in welchem Textfeld er zuerst
Eingaben tätigen möchte oder ob er sofort auf den Button klickt. Bei textbasierten
Anwendungen, die über Befehle gesteuert werden, ist die Eingabereihenfolge dagegen
eindeutig
vorgegeben.
Die
Steuerung
über
Ereignisse
erhöht
die
Interaktionsmöglichkeiten des Benutzers, da er nun die Kontrolle über den
Programmablauf hat [SW02, S. 18f.].
2.3 Testen von Benutzeroberflächen
Beim Testen von Benutzeroberflächen wird die Interaktion zwischen dem
Softwaresystem und dem Bediener geprüft. Der Test lässt sich in zwei Bereiche
einteilen. Zum einen muss geprüft werden, wie sich die Anwendung dem Benutzer
gegenüber visuell darstellt, also ob bestimmte Design-Vorgaben der GUI-Schicht
eingehalten werden. Zum anderen wird über die Benutzeroberfläche die Funktionalität
der dahinterliegenden Software bedient, so dass neben dem Prüfen der DesignVorgaben das Testen der Funktionen hinter der Präsentationsschicht ein wesentlicher
Bestandteil des Oberflächentests ist [LD08].
Design-Vorgaben
Die Design-Vorgaben betreffen vor allem die Übersichtlichkeit und Einheitlichkeit der
gesamten Anwendungsoberfläche. Organisationen haben eigene Design-Standards, die
für jede ihrer Anwendungen gelten sollten und mit Hilfe von Checklisten geprüft
werden können [PG97]. Zu den Vorgaben zählen die grafischen Eigenschaften der
Oberflächenelemente und Fenster bzw. Webseiten, wie Positionierung, Größe, Farbe,
Textausrichtung und Textgröße, die die Übersichtlichkeit und Lesbarkeit der Oberfläche
erhöhen. Daneben kann getestet werden, ob Elementbeschriftungen einheitlich
verwendet werden, also Bezeichnungskonventionen eingehalten werden. Bietet bspw.
eine Webseite die Möglichkeit, dem Benutzer seine gesammelten Waren in einem
Warenkorb anzuzeigen, so sollte geprüft werden, dass alle Buttons der Seite, die zum
Warenkorb führen, die gleiche Beschriftung „Warenkorb“ besitzen und nicht an Stelle
inkonsistent mit „Einkaufswagen“ bezeichnet wurden.
5
Kapitel 2: Grundlagen des Testens
Funktionalität
Da der Benutzer über die Oberfläche die Anwendungsfunktionalitäten bedient, muss
geprüft werden, ob die gewünschten Funktionen vollständig und fehlerfrei mit Hilfe der
Oberflächenelemente ausgeführt werden. Zu den zu testenden Funktionen zählen neben
den eigentlichen fachlichen Funktionen, die für die Anwendung spezifiziert wurden,
auch Standardfunktionalitäten, die die Benutzbarkeit des Systems erhöhen und heute
fast selbstverständlich sind. Z.B. sollten Sortierungen korrekt dargestellt werden und
jede Funktion nicht nur über die Maus, sondern auch über die Tabulator-Tasten
erreichbar sein. Bei Falscheingaben sollte der Cursor auf das entsprechende Eingabefeld
gesetzt werden. Speziell bei Webseiten sollte geprüft werden, ob über die BrowserNavigation vor- und zurückgeblättert werden kann, ohne dass Datenverluste entstehen,
oder Inhalte beim Ausdruck der Seite verloren gehen [FK07, S.132-136].
Der Oberflächentest als funktionaler und nicht-funktionaler Test kann somit als Teil des
Systemtests angesehen werden, da er die Anwendung als Ganzes von außen über die
Benutzeroberfläche betrachtet [SC05, S. 361].
Probleme beim Testen von Oberflächen
Wie oben dargestellt, basieren Benutzeroberflächen meist auf einer ereignisgesteuerten
Implementierung. Dadurch haben die Benutzer einen sehr hohen Freiheitsgrad beim
Anwählen eines Oberflächenelementes per Mausklick oder Tastatur. Um die
Benutzeroberfläche vollständig zu testen, müssen alle möglichen Benutzerinteraktionen,
die auf der Oberfläche ausgeführt werden können, in jeder beliebigen Reihenfolge
getestet werden. Dazu gehören neben den zugelassenen Bedienungsmöglichkeiten auch
die nicht-zugelassenen, die von der Software entsprechend abgefangen werden müssen.
Bei sieben Textfeldern ergeben sich allein 5040 verschiedene Kombinationen der
Dateneingabe und somit genauso viele Testfälle. Die Abdeckung aller Testfälle ist
allein aus Zeit- und Kostengründen fast unmöglich. Um eine Anwendung in einen
bestimmten Zustand zu bringen, kann der Benutzer meist mehrere Wege über die
Oberfläche nehmen, bspw. durch Tastaturkürzel, Mausklicks oder Auswahl bestimmter
Menüeinträge. Auch hier stellt sich die Frage, wie viele Wege es zu diesem Zustand
gibt, bzw. welche Wege durch Testfälle abgedeckt werden sollten [PG97]. Der
Testaufwand wird zusätzlich noch dadurch erhöht, dass nach jeder Benutzeraktion der
Programmzustand mit seinem vorgegebenen Soll-Zustand verglichen werden muss. Es
6
Kapitel 2: Grundlagen des Testens
reicht nicht aus, die Endzustände nach dem gesamten Testlauf eines Testfalls zu
vergleichen, da jede Zwischenaktion zu einem undefinierten Zustand führen kann. Ohne
Zwischenvergleiche lässt sich ein möglicher Fehler nicht lokalisieren, wenn der
Sollzustand vom tatsächlichen Endzustand abweicht. Ist der Endzustand trotzdem
korrekt, werden falsche Zwischenzustände nicht aufgedeckt. Ebenso erhöht sich der
Testaufwand, wenn das Softwaresystem auf unterschiedlichen Plattformen lauffähig
sein soll, da Benutzeroberflächen oftmals grafisch unterschiedlich dargestellt werden
und ihre grafischen Elemente ggf. anders zu bedienen sind [PG97]. Da GUIs während
der Programmentwicklung laufend geändert werden, werden auch Regressionstests
aufwändiger, auch wenn sich die darunterliegende Programmlogik nicht ändert. Viele
alte Testfälle werden somit ungültig, weil der darin beschriebene Interaktionspfad in
dieser Form nicht mehr ausführbar ist. Wird bspw. die Bezeichnung eines Textfeldes in
einem Dialogfenster umbenannt, so kann der Tester anhand des Testfalls den
einzugebenden Text keinem Textfeld mehr eindeutig zuordnen [GST08].
7
Kapitel 3: Tools zum Testen von Benutzeroberflächen
3 Tools zum Testen von Benutzeroberflächen
Auf dem Markt gibt es eine Reihe von Tools zur Unterstützung oder Automatisierung
von Tests, die als CAST-Tools (Computer Aided Software Testing-Tools) bezeichnet
werden. Je nach Testaktivität oder Testphase gibt es verschiedene Typen von CASTTools mit unterschiedlichen Aufgaben und Funktionen [SL05, S.203]. Tools, die die
Durchführung von Oberflächentests automatisieren, werden allgemein als GUITesttools bezeichnet. In diesem Kapitel werden die allgemeinen Merkmale und
Methoden dieser Tools vorgestellt. Zuvor wird jedoch auf die Vor- und Nachteile der
Testautomatisierung eingegangen, um den Einsatz der Tools bei Oberflächentests zu
begründen.
3.1 Automatisierung von Tests
Das manuelle Testen von Benutzeroberflächen kann, wie im vorherigen Kapitel
erläutert wurde, aufgrund der zahlreichen Bedienungsmöglichkeiten sehr zeitaufwändig
und damit kostenintensiv sein. Beschränkt man sich dagegen lediglich auf das
Überprüfen einzelner Testfälle, so kann darunter die Softwarequalität leiden. Zudem
können menschliche Fehler den Test der Software verfälschen. Durch die
Automatisierung
von
Tests
mit
Hilfe
von
CAST-Tools
versprechen
sich
Softwarehersteller mit geringen finanziellen Mitteln und geringerem Zeitaufwand
Software mit hoher Qualität produzieren zu können [MM06, S. 37]. Dafür geben sie
nach [TG02, S.228f.] unter Anderem folgende Vorteile an:
•
Regressionstests können bei leicht modifizierten Anwendungen durch
geringfügige Änderungen der Testfälle durchgeführt werden.
•
Es können Tests vorgenommen werden, die aus Zeitmangel manuell nicht
vorgenommen würden, weil mehr Tests öfter ausgeführt werden können.
•
Durch Automatisierung langwieriger, monotoner Tests können sich die Tester
mit wichtigeren Aufgaben befassen.
•
Automatisierte
Tests
können
auch
mit
unterschiedlichen
Rechner-
konfigurationen leicht wiederholt werden.
•
Die Tests können wiederverwendet werden.
8
Kapitel 3: Tools zum Testen von Benutzeroberflächen
•
Durch die Automatisierung kann die Testphase verkürzt werden und die
Software früher fertiggestellt werden.
Die Testdurchführung eignet sich am besten für eine Automatisierung, da der Ablauf
zumeist aus vielen sich wiederholenden langwierigen Eingaben besteht, die viel Zeit in
Anspruch nehmen. Der Testentwurf sowie der Soll-Ist-Vergleich der Ergebnisse lassen
sich nur eingeschränkt automatisieren, weil diese Prozesse teilweise intellektuelle
Fähigkeiten und Kreativität voraussetzen.
Der Einsatz automatisierter Tests ist aber nicht in jedem Fall sinnvoll, da die höhere
Wirtschaftlichkeit im Vergleich zu manuellen Tests nicht immer gegeben sein muss.
Regressionstests lassen sich zwar effizient automatisieren[MM06, S.36], aber gerade
wenn Benutzeroberflächen in der Entwicklungsphase in kurzen Abständen geändert
werden, müssen die vorgesehenen automatisierten Regressionstests immer wieder
angepasst werden, so dass der Aufwand den Nutzen der Automatisierung übersteigen
kann. Dasselbe gilt für Tests, die nur sehr selten durchgeführt werden oder manuelle
Handlungen erfordern und für Testaspekte, die nur von einem Menschen beurteilt
werden können, wie bspw. die Benutzerfreundlichkeit der grafischen Oberfläche
[TG02, S. 236f.].
3.2 Merkmale der GUI-Testtools
3.2.1 Plattformunterstützung
Viele GUI-Testtools sind für bestimmte Plattformen ausgerichtet. Sollen z.B.
Oberflächen von Windows-Anwendungen getestet werden, so muss das Tool unter
Windows lauffähig sein. Wenn Software für mehrere Plattformen verfügbar sein soll,
dann ist es vorteilhaft ein Testtool auszuwählen, dass auf all diesen Plattformen
ausgeführt werden kann, da dadurch doppelter Aufwand für die Einarbeitung in das
Tool und für die Testerstellung vermieden wird. Ist das Testtool selbst eine JavaAnwendung, ist die Plattform von untergeordnetem Interesse, da Java-Anwendungen
plattformunabhängig sind.
9
Kapitel 3: Tools zum Testen von Benutzeroberflächen
3.2.2 Toolkit-Unterstützung
Neben der geeigneten Plattform ist der Einsatz des Testtools auch abhängig von der
Schnittstellen-Technologie, mit der die Oberfläche der zu testenden Anwendung
dargestellt wird. Dabei kann es sich um native GUIs aber auch um Webseiten handeln.
Zu den nativen Toolkits zählen bspw. Microsofts Windows Forms, Java/Swing, und
Java/SWT. Die grafischen Oberflächen von Webseiten werden über HTML-Quelltext
beschrieben und mit Hilfe eines Browsers dargestellt. Jede dieser Schnittstellen hat
eigene grafische Bedienelemente und Mechanismen zur Behandlung von Ereignissen,
die vom jeweiligen Testtool unterstützt werden müssen. Dazu gehören neben einfachen
Ereignissen (Low-Level-Events), wie Mausklicks oder Tastatureingaben, die von jeder
GUI-Technologie unterstützt werden, auch spezielle Ereignisse, wie bspw. onload
beim Laden einer Webseite oder TextEvent bei Änderung des Inhalts von Java/SWTTextfeldern.
3.2.3 Ausführungsmodus
Bei der Testdurchführung wird die Oberfläche durch Auslösen von Aktionen der
grafischen Elemente gesteuert. Diese Bedienung kann positions- oder objektorientiert
erfolgen.
Positionsorientierung
Bei der positionsorientierten Testausführung simuliert das Testtool Tastatureingaben,
Mausbewegungen und Mausklicks so, als würde ein Benutzer die Oberfläche bedienen.
Zur Positionierung der Maus werden im Test (x, y)-Koordinaten verwendet, die wie die
Klicks und Tastatureingaben an das Betriebssystem oder im Falle von JavaAnwendungen an virtuelle Maschinen geschickt werden. Dort werden die Ereignisse
dann an die zu testende Anwendung oder den Browser weitergeleitet und das grafische
Element ermittelt, das auf der Mauskoordinate liegt. Ausgehend von diesem Element
werden dann die dahinterliegenden Funktionen ausgeführt. Ein großer Nachteil dieses
Modus ist, dass er nicht sehr robust gegenüber Veränderungen auf der
Benutzeroberfläche ist. In der Entwicklungsphase aber auch beim Vergrößern oder
Verschieben des Oberflächenfensters kann sich die Größe und Position der Elemente
ändern, so dass Testdurchführungen stehen bleiben oder abbrechen, weil sich plötzlich
10
Kapitel 3: Tools zum Testen von Benutzeroberflächen
unter der vorgegebenen Mausposition ein anderes oder kein Element befindet [SL05, S.
210] (vgl. Abbildung 1).
Abbildung 1: Nachteil der Positionsorientierung bei Layoutänderung
Objektorientierung
Bei der objektorientierten Ausführung wird von der Position des Mauszeigers auf
unterster Ebene abstrahiert. Stattdessen wird versucht die Oberflächenelemente zu
identifizieren und Referenzen auf sie anzulegen. Dadurch werden die automatisierten
Testabläufe gegenüber Änderungen am Layout robuster, da die Größe und die Position
der Elemente innerhalb eines Fensters nun keine Rolle mehr spielt [HD08, S.475]. Ein
Nachteil ist, dass mit diesem Modus auf verdeckte Objekte zugegriffen werden kann,
die positionsorientiert mit dem Mauszeiger nicht erreichbar wären. Bspw. kann es
Oberflächenelemente geben, die außerhalb des sichtbaren Fensterbereichs liegen oder
sich überdecken. Deshalb muss die Oberfläche zusätzlich visuell überprüft werden.
Daneben müssen Benutzeroberflächen, die individuell von der dahinterliegenden
Software als Grafik gerendert werden und nicht auf die Standardelemente eines
entsprechenden Toolkits zurückgreifen, positionsorientiert getestet werden, weil ihre
grafischen Objekte nicht auf der Oberfläche identifiziert werden können.
3.2.4 Identifikation der Oberflächenelemente
Aktuelle GUI-Testtools führen Testabläufe objektorientiert durch, bieten daneben aber
auch die Möglichkeit die Tests positionsorientiert auszuführen. Die Objektorientierung
setzt voraus, dass die Oberflächenelemente der zu testenden Software vom Testtool
erkannt werden können. Wie in Kapitel 3.2.2 beschrieben, muss dafür die von der
Software verwendete GUI-Technologie in Form von Toolkits oder Webseiten vom
Testtool unterstützt werden.
11
Kapitel 3: Tools zum Testen von Benutzeroberflächen
Ein bestimmtes Oberflächenelement kann über eine Kombination seiner spezifischen
Attribute eindeutig identifiziert werden. Zu diesen Eigenschaften zählen u.a. der
Elementtyp (Button, Textfeld, Liste, etc.), die Elementbeschriftung, die Position im
Fenster oder der softwareinterne Bezeichner des Elements. Soll im Testlauf z.B. ein
Button in einem bestimmten Fenster mit der Aufschrift „Ok“ automatisiert angeklickt
werden,
so
könnte
dies
im
Testskript
bspw.
über
getButton(label=“Ok“).click() geschehen. Bei Änderungen an den
Attributen oder Austausch durch ein anderes Oberflächenelement während der
Entwicklungsphase müssen bei dieser Art des Zugriffs allerdings alle entsprechenden
Testfälle angepasst werden. Deshalb bieten viele GUI-Testtools die Möglichkeit GUIMapping-Dateien zu erstellen, um hohen Anpassungsaufwand zu vermeiden. Dabei
werden die Objekteigenschaften zur Identifikation in eine Mapping-Datei ausgelagert
und ihnen ein logischer Name zugewiesen, über den man dann in den Testskripten
Zugriff auf das entsprechende Element erhält. Ein Eintrag in dieser Datei könnte wie
folgt aussehen:
butOK = { .class = Button;
.label = “Ok“; }
In den Skripten erzielt dann butOK.click() den gleichen Effekt wie der obige
Befehl, mit dem Vorteil, dass bei Layoutänderungen die Testskripte meist unberührt
bleiben und lediglich der Mapping-Eintrag einmalig angepasst werden muss [FG99, S.
533ff.].
3.2.5 Testskriptgenerierung
Für die Erstellung von Testskripten bieten die Testtools folgende Ansätze.
Programmierung
Mit der Programmierung ist die manuelle Erstellung von Testskripts von Hand in einer
bestimmten Skriptsprache gemeint. Hierbei erfolgt letztlich nur die Ausführung der
geschriebenen Skripte automatisiert durch Computerunterstützung. Ein Vorteil
der
Programmierung ist, dass der Skriptersteller die Kontrolle über die Struktur und den
Inhalt der Skripte hat. Allerdings stellt sich die Frage, wie die zu testenden
Oberflächenelemente mit der Skriptsprache angesprochen werden können, so dass
12
Kapitel 3: Tools zum Testen von Benutzeroberflächen
neben der Programmierung auch Verweise auf die Elemente erstellt werden müssen. Da
die Skriptsprachen komplex sein können, sind allerdings Experten als Testersteller
erforderlich, die sich mit der Funktionalitäten und den Bibliotheken der Skriptsprache
auskennen.
Capture-Replay
Der Capture-Replay-Ansatz ist das verbreitetste Verfahren zur Erstellung von
Testskripts in GUI-Testtools. Dabei werden die Benutzerinteraktionen bei einer
Testdurchführung
mit
dem
laufenden
System
in
Form
von
Mausklicks,
Mausbewegungen und Tastatureingaben objekt- oder positionsorientiert im Hintergrund
aufgenommen und das Testskript um diese Aktionen ergänzt (Capture). Während der
Aufzeichnung können Soll-Ist-Vergleiche in Form von Prüfpunkten (Checkpoints) in
das Skript eingefügt werden, um das Programmverhalten sowie layoutrelevante
Eigenschaften der Oberflächenelemente zu überprüfen. Das fertige Skript kann dann in
Form von automatisierten Testdurchführungen beliebig oft abgespielt werden (Replay).
Werden Vor- oder Nachbedingungen der Checkpoints nicht eingehalten, wird die
Ausführung mit einer entsprechenden Fehlermeldung abgebrochen [FG99, S. 42ff.].
Deshalb bietet sich das Verfahren besonders zur Automatisierung von Regressionstests
an [SL05, S. 210].
Ein weiterer Vorteil dieses Ansatzes ist, dass auch Tester, die sich nicht mit der
Skriptsprache auskennen, sehr schnell lauffähige Skripte erstellen können. Daneben gibt
es aber auch einige Nachteile.
•
Viele offensichtliche Fehler werden vom Testersteller schon während der
Aufnahme erkannt, wenn sich das System nicht so verhält, wie gedacht. Die
Aufnahme muss abgebrochen werden und das Programm berichtigt. Erst dann
kann die Aufzeichnung wiederholt werden, sodass bei der Ausführung des
fertigen Skripts die meisten Fehler schon beseitigt wurden. Deshalb ist die
Aussicht Fehler mit Hilfe des Capture-Replay-Ansatzes zu finden eher begrenzt
[LW05, S. 21]. Testskripts können demnach erst erstellt werden, wenn das
Softwaresystem bereits existiert und die Testaufzeichnung erfolgreich
durchgeführt wurde. Deshalb eignet sich das Verfahren lediglich für
Regressionstests.
13
Kapitel 3: Tools zum Testen von Benutzeroberflächen
•
Die Werte, die bspw. in Textfeldern auf der Oberfläche während der
Aufzeichnung eingegeben wurden, sind fest im Testskript verankert. Zur
Wiederverwendung des Skripts mit anderen Eingabedaten muss es nachträglich
manuell angepasst werden.
•
Das aufgezeichnete Testskript entspricht einem linearen Aktionspfad auf der
Softwareoberfläche, was zu Problemen führen kann, wenn sich z.B. das
Programmverhalten bei Aufzeichnung und Testausführung durch aufpoppende
Hinweisfenster
oder
Systemmeldungen
unterscheidet.
Deshalb
müssen
Fallunterscheidung berücksichtigt werden, so dass das Skript nachträglich
überarbeitet werden muss [FG99, S. 58f.].
Automatisierte Ansätze
Neben den Ansätzen Programmierung und Capture-Replay, bei denen eine Person
maßgeblich an der Erstellung der Testskripte beteiligt ist, gibt es weitere Methoden, bei
denen neben der automatisierten Testdurchführung auch Testskripte automatisch
generiert werden, so dass zufällige lauffähige Skripte in kurzer Zeit und ohne viel
Aufwand erzeugt werden können.
3.2.6 Ergebnisvergleich
Neben der Simulation der Benutzerinteraktionen werden bei der Testdurchführung die
Ausgaben bzw. Ergebnisse dieser Aktionen mit den vorgegebenen Soll-Werten
verglichen. Dieser Vergleich kann auf bildlicher und inhaltlicher Ebene geschehen.
Inhaltlicher Vergleich
Werden die Testläufe objektorientiert ausgeführt, kann das Testtool die grafischen
Standard-Oberflächenelemente erkennen und ihre Eigenschaften auslesen. Zu einem
Textfeld gehört neben seiner Position und Farbe bspw. die Eigenschaft text, in der der
Inhalt des dargestellten Textes im Textfeld als Zeichenkette verwaltet wird. So können
auf inhaltlicher Ebene Texte, Zahlen oder boolesche Werte miteinander verglichen
werden.
Bildvergleich
Beim Bildvergleich werden Bildschirmausschnitte anhand von Bitmaps binär
miteinander
verglichen.
Dieses
Verfahren
kommt
zum
Einsatz,
wenn
14
Kapitel 3: Tools zum Testen von Benutzeroberflächen
Oberflächenelemente nicht erkannt werden können oder Grafiken verglichen werden
sollen. Am einfachsten ist dabei die Erfassung des gesamten Bildschirms.
Problematisch daran sind allerdings grafische Elemente, die sich zwischen
Testausführungen unterscheiden können, wie z.B. die Darstellung der Uhrzeit oder
eines Benutzernamens. Deshalb sollten Testtools die Möglichkeit bieten auch kleinere
Bildschirmbereiche miteinander zu vergleichen [FG99, S. 50]. Aufgrund des binären
Vergleichs müssen die Bilder daneben absolut identisch sein. Hat ein Pixel eines Bildes
bspw. einen sehr leicht abweichenden Farbton, den ein menschlicher Tester nicht
wahrnehmen würde, so sind die Bilder für das Testtool verschieden, so dass der Testlauf
ungewollt fehlschlägt. Testtools, die es erlauben, Toleranzwerte für Pixelabweichungen
anzugeben, können Abhilfe schaffen.
Vergleich mithilfe von Texterkennung
Die Texterkennung (OCR) ist sinnvoll, wenn es nicht möglich ist, Textausgaben
objektorientiert über den Inhalt oder über Bitmaps zu vergleichen. Das ist bspw. der
Fall, wenn die Oberflächenelemente, deren textueller Inhalt verglichen werden soll,
nicht von Testtool erkannt werden können und die Software auf mehreren Plattformen
getestet wird, so dass sich die Texte in Schriftart und Farbe ggf. unterscheiden. Die
Texterkennung abstrahiert von diesen Texteigenschaften und liest lediglich die
Textinhalte auf Basis von Bitmaps aus.
3.2.7 Skripttechniken
Viele Testtools bieten unterschiedliche Methoden zur Strukturierung von Testskripten
an, die einzeln aber auch in Kombination dazu beitragen, dass der Aufwand bei der
Erstellung, Wartung und Wiederverwendung automatisierter GUI-Tests reduziert
werden kann.
Unterstützung von Kontrollstrukturen
Sehr einfach gehaltene Testtools bieten meist die Möglichkeit lineare Skripts mit der
Capture-Replay-Methode zu erstellen und abzuspielen. Soll der lineare Ablauf eines
solchen Testskriptes beeinflusst werden können, so ist es notwendig, dass die zugrunde
liegende Skriptsprache Funktionsaufrufe und Kontrollstrukturen in Form von Schleifen
und Bedingungen unterstützt. Soll in einem Testfall bspw. über die Benutzeroberfläche
15
Kapitel 3: Tools zum Testen von Benutzeroberflächen
eine Datei gespeichert werden, so kann es sein, dass ein zusätzliches Dialogfenster
danach fragt, ob die Datei überschrieben werden soll. Da bei der Erstellung nicht
feststeht, ob die Datei bereits existiert, kann z.B. mit einer if-Abfrage, die prüft, ob der
Überschreiben-Dialog angezeigt wird, die Befehlsausführung verzweigt werden.
Kontrollstrukturen tragen somit dazu bei, dass Testskripte robuster werden. Mit Hilfe
von Funktionsaufrufen können die Skripte zusätzlich modularisiert werden, sodass sie
übersichtlicher und in Teilen wiederverwendbar sind [FG99, S. 78ff.].
Datengetriebene Tests (data-driven tests)
Testskripte beinhalten oft fest eingecodete Daten, die das Testtool z.B. automatisiert in
Textfelder eingibt oder mit einem Ergebnis vergleicht. Soll ein Testlauf allerdings mit
verschiedenen Testdaten wiederholt werden, bietet es sich an, die Testdaten vom
eigentlichen Testskript zu trennen. Die Eingabe- und Ergebnisdaten werden dazu bspw.
in Tabellenform in einem externen Datenpool abgespeichert und können beliebig
erweitert werden. Das Testtool wiederholt das Skript dann mit allen oder zufälligen
Einträgen aus der Tabelle [FG99, S. 83ff.; SL05, S. 212]. Neue Testfälle können so sehr
schnell durch Erweiterung des Datenpools erstellt werden ohne Änderungen am
Testskript vornehmen zu müssen.
Kommandogetriebene Tests (keyword-driven tests)
Bei
vielen
Testabläufen
werden
bestimmte
Interaktionspfade
mit
der
Benutzeroberfläche oft identisch verwendet, so dass es sinnvoll ist, sie in Prozeduren zu
kapseln. Kommandogetriebene Tests beinhalten neben Skripten, die diese Prozeduren
definieren, Tabellen, die die Prozeduren über Prozedurnamen (Kommandos) mit
bestimmten Eingabedaten aufrufen. Ähnlich wie bei datengetriebenen Tests kommen
die Eingabe- und Prüfwerte aus einer externen Tabelle, mit dem Unterschied, dass
diesen Werten zusätzlich ein Kommando voransteht, dem diese Werte im Testlauf
übergeben werden. Mit Hilfe der Skripte, die die Prozeduren implementieren, kann von
dem verwendeten GUI-Testtool und der Plattform abstrahiert werden. Die Tabellen, die
die Testläufe beinhalten, bedürfen keinerlei Modifikation, lediglich die Prozedurskripte
müssen an das jeweilige Tool angepasst werden [FG99, S. 90 ff.].
16
Kapitel 3: Tools zum Testen von Benutzeroberflächen
3.2.8 Synchronisation
Im Gegensatz zum manuellen Test kann der automatisierte Testlauf um ein vielfaches
schneller durchgeführt werden. Die Geschwindigkeit, in der eine grafische Oberfläche
Benutzereingaben erwartet, richtet sich in vielen Fällen eher an einem menschlichen
Akteur aus. Soll bspw. eine Datei geöffnet werden, so wird der Benutzer erst einen
Dateinamen eingeben, wenn der entsprechende Öffnen-Dialog sichtbar ist. Ein GUITesttool dagegen erkennt nicht, dass es die simulierte Eingabe solange verzögern sollte,
bis das Fenster sichtbar ist. Problematisch sind auch Ergebnisvergleiche, z.B. bei
Webseiten. Soll ein Bildschirmausschnitt einer Seite mit der Soll-Ausgabe durch einen
Prüfpunkt verglichen werden, so kann es sein, dass die Webseite direkt nach ihrem
Aufruf noch nicht vollständig geladen wurde und der Ausschnitt deshalb einen komplett
anderen Inhalt enthält als einige Sekunden später, so dass der Testlauf fehlschlägt. Aus
diesem Grund muss es bei der automatisierten Ausführung die Möglichkeit geben, auf
die Benutzeroberfläche zu warten [FG99, S. 243, KL94]. Dazu können z.B. sleepBefehle eingesetzt werden, die die Testausführung für eine bestimmte Zeit stoppen oder
es kann mithilfe der Ereignis-Warteschlange der Benutzeroberfläche geprüft werden, ob
sie bereit ist neue Ereignisse entgegenzunehmen [PZ08].
3.2.9 Testfallverwaltung
Außer der automatisierten Testdurchführung bieten einige GUI-Testtools weitere
Unterstützung des Testprozesses an. Dazu gehört neben der Auswertung der
Testergebnisse in Form von Testberichten und Aufstellung schon ausgeführter Testfälle
die Möglichkeit der Fehlerverfolgung (bug-tracking). Dabei werden auftretende Fehler
nummeriert und in einer Fehlerdatenbank dokumentiert, die für alle Testmitarbeiter
zugänglich ist. Diese Datenbank gibt Auskunft über die Testfälle, in denen der Fehler
auftritt und in welcher Programmversion er aufgetreten ist, die Fehlerpriorität, den
aktuellen Fehlerstatus, den für den Fehler zuständigen Entwickler, das Datum der
Entdeckung, Zuweisung an einen Entwickler etc. Somit haben die Testpersonen eine
genaue Übersicht über die gefundenen Fehler und können jederzeit Auskunft über den
aktuellen Fehlerstatus der zu testenden Software geben [MM06, S.136ff.].
17
Kapitel 4: IBM Rational Functional Tester 8.0
4 IBM Rational Functional Tester 8.0
Nachdem im vorherigen Kapitel die grundlegenden Features von GUI-Testtools
erläutert wurden, soll jetzt der IBM Rational Functional Tester 8.0 (RFT), einer der
Marktführer im Bereich kommerzieller GUI-Testtools, vorgestellt werden, an dem diese
Merkmale
konkretisiert
werden.
Da
während
der
Entwicklungsphase
von
Softwaresystemen Design und Navigation der Oberfläche oftmals einer ständigen
Anpassung unterliegen, soll auch auf die Frage eingegangen werden, in welcher Form
sich das Tool gegenüber sich ändernden Oberflächenlayouts verhält.
4.1 Vorstellung
Mit dem Rational Functional Tester lassen sich GUI-Tests unter Windows und Linux
ausführen, wobei unter Linux die Einschränkung besteht, dass keine Tests
aufgezeichnet
werden
können.
Grundsätzlich
lassen
sich
alle
ausführbaren
Anwendungen testen. Die Erkennung grafische Standardoberflächenelemente und ihrer
Eigenschaften wird in der Grundversion des Tools für .NET 3.0-, Java- und
Webanwendungen sowie einiger anderer spezieller Anwendungen unterstützt. Das
mitgelieferte SDK ermöglicht zudem durch Eigenprogrammierung das Tool um die
Unterstützung individueller Oberflächenelemente
zu erweitern. Die Erstellung der
Testskripts verläuft anfangs zumeist über die Aufzeichnung von Benutzerinteraktionen.
Für die Nachbearbeitung bietet das Tool keine eigene Entwicklungsumgebung an, es
bettet sich während der Installation auf Wunsch in die vertraute Eclipse- oder VisualStudio-Umgebung ein, in denen Java bzw. Visual Basic .NET als Testskriptsprachen
dienen. Eine Einarbeitung in das Tool ist somit schnell möglich, nicht zuletzt auch
aufgrund der einsteigerfreundlichen Hilfetexte und Beispiele.
Abbildung 2 zeigt die Standardansicht des Tools in der Eclipse-Umgebung. Im linken
Fensterbereich können Testprojekte erstellt und eingesehen werden. Diese Projekte
können Testfälle und Testordner mit weiteren Testfällen enthalten, so dass durch diese
Gruppierung die Vielzahl von Testfällen bei großen Testprojekten trotzdem
überschaubar bleibt. Zudem kann man von hier aus auf die Ergebnisse des letzten
Testlaufs eines Testfalls zugreifen, so dass insgesamt eine sehr schlichte
Testfallverwaltung möglich ist. Auf der rechten Fensterseite befindet sich der Skript18
Kapitel 4: IBM Rational Functional Tester 8.0
Explorer, der alle Objekte enthält, auf die im Testskript zugegriffen werden kann. Dazu
zählen Referenzen auf die grafische Oberflächenelemente (Testobjekte), Prüfpunkte für
den Ergebnisvergleich und Datenpools für datengetriebene Tests. Im mittleren
Fensterbereich kann das Testskript mit den üblichen Eclipse-Hilfestellungen, wie
Autovervollständigung und Refactoringfunktionen editiert und debuggt werden.
Abbildung 2: RFT-Hauptfenster in der Eclipse IDE
4.2 Aufzeichnungsablauf
Vor der eigentlichen Testaufzeichnung muss das zu testende Softwaresystem im RFT
global und projektunabhängig registriert werden und bei Javaanwendungen die
Laufzeitumgebung, bei Webanwendungen der Browser gewählt werden, mit dem die
Aufnahme bzw. die Testläufe durchgeführt werden solle. Nachdem ein neues Projekt
erstellt wurde, können Testskripte mit Hilfe der Capture-Replay-Funktion aufgezeichnet
werden. Dazu minimiert sich das Hauptfenster automatisch und ein kleines
Aufnahmefenster wird angezeigt, das während der gesamten Aufzeichnung im
Vordergrund zur Testanwendung bleibt. Es beinhaltet Funktionen zum Starten,
Pausieren und Stoppen der Aufzeichnung und Setzen von Prüfpunkten und
Verknüpfungen zwischen GUI-Elementen und Datenpools. Bei Aufzeichnungsbeginn
wird die Anwendung bzw. der gewünschte Webbrowser mit entsprechender URL
19
Kapitel 4: IBM Rational Functional Tester 8.0
aufgerufen. Die getätigten Benutzerinteraktionen werden während der manuellen
Testdurchführung im Aufnahmefenster mitgeloggt. Beim Einfügen von Prüfpunkten
kann das zu testende GUI-Element mit der Maus selektiert werden, worauf es durch ein
rotes Rechteck umrahmt wird, wenn es erkannt wurde. Überprüft werden können
einzelne Dateneinträge z.B. in Textfeldern oder ganze Datengruppen in Tabellen und
viele weitere Eigenschaften über einen Wizard, in dem sich die Sollwerte in
tabellarischer Form eintragen lassen. Zusätzlich lassen sich seit Version 8.0 auch
Bildausschnitte überprüfen. Allerdings können keine Toleranzgrenzen für den Vergleich
angeben werden; die Ausschnitte müssen absolut identisch sein, damit der Prüfpunkt
passiert werden kann. Für Prüfpunkte kann zudem angegeben werden, ob sie
zeitverzögert nochmals durchlaufen werden sollen, falls sie aktuell nicht passiert
werden können. So kann bei Bildvergleichen auf Webseiten bspw. nach zwei Sekunden
erneut geprüft werden, ob die Ausschnitte identisch sind. Eine OCR-Texterkennung in
Bildausschnitten ist allerdings nicht möglich.
Der Wizard erlaubt ebenfalls die
Erstellung datengesteuerter Tests. Dazu wird einem Attribut eines GUI-Elements ein
Wert in Form einer Variablen zugewiesen, wobei sich die Variable wiederum auf eine
Tabellenspalte des Datenpools bezieht. Auch bei den Prüfpunkten können konstante
Sollwerte durch Variablen ersetzt werden, die sich auf andere Spalten dieser Tabelle
beziehen. Jede Tabellenzeile aus dem Datenpool entspricht dabei dann einem möglichen
Testlauf, der nun datengesteuert Zeile für Zeile wiederholt werden kann. Kann ein
Prüfpunkt nicht passiert werden, weil Soll- und Istwerte nicht übereinstimmen, oder die
Durchführung nicht fortgesetzt werden, weil ein zu testendes GUI-Element nicht
identifiziert werden kann, liegt ein Fehler vor und der Testlauf wird vorzeitig
abgebrochen. Nach jeder Testausführung erstellt das Tool dann ein Testprotokoll im
Text-, HTML- oder nativen Format, in dem die passierten Prüfpunkte, Warnungen und
Fehler gelistet sind.
Abbildung 3 zeigt die Anmeldeoberfläche einer Web-Anwendung. Mit einem einfachen
Testfall soll nun geprüft werden, ob sie sich bei Eingabe bestimmter Anmeldedaten den
Erwartungen entsprechend verhält. Bei der Testaufzeichnung erhält zunächst das
Benutzertextfeld durch Mausklick den Eingabecursor und die Zeichenfolge „admin“
wird eingetippt. Dasselbe wird mit dem Passworttextfeld mit der Folge „123“
wiederholt. Daraufhin wird auf den Anmelden-Button geklickt und geprüft, ob die
angezeigte Meldung dem String „Sie sind angemeldet!“ entspricht. Der Browser wird
20
Kapitel 4: IBM Rational Functional Tester 8.0
geschlossen und die Aufzeichnung beendet. Listing 1 zeigt den vom Tool generierten
Quelltext.
Abbildung 3: Webseite mit HTML-Elementen
1 public class TestLoginSite extends TestLoginSiteHelper {
2 public void testMain(Object[] args) {
3
startApp("http://localhost:1203/WebApp/login.aspx");
4
5
// Document: Anmeldung: http://localhost:1203/WebApp/login.aspx
6
text_user().click(atPoint(36,13));
7
browser_htmlBrowser(document_anmeldung(),DEFAULT_FLAGS).
8
inputKeys("admin");
9
10
text_pass().click(atPoint(32,10));
11
browser_htmlBrowser(document_anmeldung(),DEFAULT_FLAGS).
12
inputChars("123");
13
14
button_anmeldensubmit().click();
15
16
// Document: Haupseite: http://localhost:1203/WebApp/main.aspx
17
html_loginMessage().performTest(LoginMessage_textVP());
18
browser_htmlBrowser(document_haupseite(),MAY_EXIT).close();
19 }
20 }
Listing 1: Generiertes RFT-Testskript
Es lässt sich erkennen, dass die HTML-Textfelder und der HTML-Button im Skript
entsprechende Testobjekte besitzen. Bspw. wird über den Aufruf der Methode
text_user() das Testobjekt zurückgeliefert, das dem Benutzertextfeld entspricht;
sie ist in der Hilfsklasse TestLoginSiteHelper implementiert, die zusätzlich zum
Testskript generiert wird. Um das Testobjekt mit seinem entsprechenden GUI-Element
zu verknüpfen, greift sie intern auf die GUI-Map zurück. Alle Testobjekte im Skript
sind Instanzen der Basisklasse TestObject, die grundlegende Methoden für den
21
Kapitel 4: IBM Rational Functional Tester 8.0
Zugriff auf Objekte der laufenden Anwendung bereitstellen, wie getProperty zur
Abfrage bestimmter Eigenschaften oder performTest zum Testen von Prüfpunkten.
Testobjekte, die sich auf Standardoberflächenelemente beziehen, sind Instanzen der
Unterklasse GuiTestObject, die es ermöglicht, low-level-Events durch Aufruf von
click(), mouseMove(Point pt), etc. zu feuern. Zum Aufruf höherwertiger,
abstrakterer Ereignisse müssen die Objekte von einem spezielleren Typ sein.
TextGuiTestObject stellt bspw. für Textfelder die Methode setText bereit, die
direkt den Text im Feld verändert, ganz ohne Simulation von Tastatureingaben. Auch
Prüfpunkte sind im Skript über Objekte definiert und können mit Wizards editiert
werden. Der Prüfpunkt LoginMessage_textVP in Zeile 17 beinhaltet z.B. die
Information, dass das Datum „Sie sind angemeldet!“ vom Typ „Text“ mit der
entsprechenden Eigenschaft eines Testobjekts verglichen werden soll. Das Testobjekt
ist in diesem Fall der HTML-Text html_loginMessage. Prüfpunkte können in
dieser Form mehrfach verwendet werden und verkürzen das Testskript erheblich.
Allerdings geht so im Gegensatz zu im Skript formulierten Vergleichen mit Hilfe von
if-Anweisungen bei schlecht gewählten Prüfpunktbezeichnungen gegebenenfalls
Aussagekraft verloren.
4.3 Verhalten bei Oberflächenänderungen
Unter dem Namen ScriptAssure bewirbt IBM ein Feature des RFT, das den
Anpassungsaufwand des Testskripts bei Änderung der Benutzeroberfläche verringern
bzw. gänzlich vermeiden soll. Eine geringe Änderung an einem GUI-Element kann
dazu führen, dass es nicht mehr anhand der vorgegebenen Attribute erkannt wird, so
dass Testläufe abgebrochen werden und die Testskripte nachbearbeitet werden müssen.
Um diesem Problem entgegenzuwirken, wird im RFT deshalb für jede Eigenschaft
zusätzlich eine Gewichtung definiert, die angibt, was für eine Rolle sie bei der Suche
nach dem Element spielt [IBM08].
Anhand des in Kapitel 4.2 vorgestellten Testfalls soll nun skizziert werden, wie hoch
der tatsächliche Anpassungsaufwand des Testskripts in Listing 1 unter Einsatz dieses
Features
ist,
wenn
die
Benutzeroberfläche
modifiziert
wird.
Neben
dieser
Webanwendung wird der Aufwand auch für eine baugleiche Java-Swing-Anwendung
22
Kapitel 4: IBM Rational Functional Tester 8.0
analysiert, um mögliche Verhaltensunterschiede bei verschiedenen Oberflächenarten
aufzudecken.
Umbenennung der Elemente
Bei Änderung des Namens des Benutzertextfeldes stoppt das Tool direkt und meldet,
dass das zu text_user() gehörende Oberflächenelement nicht gefunden wurde. In
das Testskript können jedoch komfortabel neue Testobjekte eingefügt werden, ohne den
Testfall erneut aufzuzeichnen; ersetzt man alle Vorkommnisse von text_user()
durch den Namen des neuen Testobjektes, ist das Skript wieder lauffähig. Eine
Alternative dazu ist die Erweiterung der Erkennungseigenschaften von HTML-, bzw.
Swing-Textfeldern. Da bei Umbenennungen keine Layouteigenschaften eines Elements
verändert werden, bietet es sich an, die Elementposition als weiteres Merkmal schon vor
der Skriptaufzeichnung in der GUI-Map zu definieren. Misst man mittels ScriptAssure
dem Elementnamen ein geringes und der Position ein hohes Gewicht bei, so ist die
Elementposition das auschlaggebende Erkennungsmerkmal für ein Element. Das
Benutzertextfeld kann so erfolgreich identifiziert werden und das Skript ohne
Änderungen
ausgeführt
werden.
Allerdings
erscheint
im
Testprotokoll
die
Warnmeldung, dass die Objekterkennung für das Textfeld schwach ist.
Verschiebung der Elemente
Bei Layoutänderungen, in denen Elemente an eine anderen Position verschoben oder
anders skaliert wurden, ist der Anpassungsaufwand aufgrund der objektorientierten
Ausführung relativ gering. Hier verfolgt man die gegenteilige Strategie bei der
Gewichtung der Erkennungsmerkmale; Layouteigenschaften bekommen ein sehr
geringes
Gewicht,
andere
Eigenschaften
wie
der
Elementname
oder
die
Elementbeschriftung ein hohes. Java-Swing-Elemente können innerhalb eines Fensters
oder Frames problemlos verschoben und skaliert werden. Auch ein Verschieben eines
Elements aus einem Swing-Container, wie bspw. einem Panel, in einen anderen
erfordert keinerlei Skriptanpassungen. Auf HTML-Oberflächen werden die Elemente
allerdings nur wiedererkannt, wenn sie durch ihre Verschiebung noch im selben
übergeordneten Element, wie einem <div>-Block oder einer Tabelle liegen. Im obigen
Beispiel liegen alle Elemente in einer Tabelle. Wird bspw. das Passworttextfeld unter
den Anmelden-Button verschoben, befindet es sich außerhalb dieser Tabelle. Die
23
Kapitel 4: IBM Rational Functional Tester 8.0
Testausführung wird abgebrochen. Die GUI-Map muss nachträglich manuell bearbeitet
werden.
Änderung der Ereignissequenz
Bei Änderung der Ereignisabfolge muss in jedem Fall das Testskript angepasst werden.
Durch Hinzufügen eines dritten Textfeldes unter das Passwortfeld ändert sich die
Ereignisabfolge, da nun vor dem Login z.B. zusätzlich ein Sicherheitscode angegeben
werden muss. Deshalb muss vor Zeile 14 in Listing 1 weiterer Quelltext eingefügt
werden. Dazu gibt es zwei Möglichkeiten. Zum einen gibt es die Option ein Testobjekt
für ein GUI-Element im Skript über einen Wizard zu erstellen, mit dem man manuell
die Aktionen programmiert. Daneben gibt es die Möglichkeit mit Hilfe der DebuggingFunktion die Testdurchführung in Zeile 14 durch einen Haltepunkt zu stoppen und ab
diesem Punkt eine Aufzeichnung zu starten, bei der eine Eingabe in das dritte Textfeld
stattfindet. Der zugehörige Quelltext wird dann automatisch vor der Zeile platziert. Der
Anpassungsaufwand ist im Vergleich zur Objektverschiebung oder Umbenennung
höher. Allerdings muss bei Änderung der Ereignisfolge nicht das gesamte Testskript
erneut aufgenommen werden, da die Testausführung bis zu der Stelle in der Anwendung
läuft, in der die neue Ereignisfolge beginnt und ein alter Testskriptbereich durch
Aufnahme eines neuen ersetzt werden kann.
24
Kapitel 5: Resümee und Fazit
5 Resümee und Fazit
Das Testen von Benutzeroberflächen ist mit einigen Problemen behaftet. Die Vielzahl
der zu testenden möglichen Interaktionsfolgen und Eingabewerte, die stetige
Modifikation der Oberfläche zur Entwicklungszeit und der Test auf unterschiedlichen
Plattformen macht das manuelle Testen sehr zeit- und kostenaufwendig. Aus diesem
Grund gibt es mittlerweile eine große Zahl von kommerziellen und freien GUI-Testtools
auf dem Markt, die den Aufwand durch Automatisierung der Testdurchführung
verringern sollen, so dass vor allem Regressionstest schnell ausgeführt werden können.
Zur Beschreibung der Tools wurden die allgemeinen Merkmale und Verfahren
vorgestellt und dann anhand des Rational Functional Testers 8.0, eines der führenden
Tools im Bereich von Oberflächentests, konkretisiert. Daneben wurde gezeigt, wie in
dem Tool Testfälle mit der Capture-Replay-Methode erstellt werden und es sich
gegenüber Änderungen der Oberfläche verhält. Eine der Stärken des Tools ist dabei
sicherlich die Möglichkeit Erkennungsmerkmale von GUI-Elementen gewichten zu
können. So ist es möglich, Elemente zu verschieben oder umzubenennen, ohne dass
Testskripte nachträglich angepasst werden müssen. Allerdings zeigt das Tool bei
Layoutänderungen von HTML-Oberflächen Schwächen, die bspw. mit dem frei
erhältlichen Web-Testtool Selenium IDE nicht auftreten, so dass man hier nicht ganz
ohne Nachbearbeitungen auskommt. Ändert sich durch die Oberflächenmodifikation die
Ereignisfolge, bietet der RFT den Vorteil leicht weitere Teilaufnahmen der neuen
Ereignisfolge in das Skript zu integrieren, so dass sich der Anpassungsaufwand in
Grenzen hält. Neben der automatisierten Ausführung trägt auch die Möglichkeit
datengetriebene Tests durchzuführen dazu bei, dass der Testprozess schneller und
fallabdeckender durchgeführt werden kann. Die große Auswahl an prüfbaren
Elementeigenschaften ermöglicht zudem auch robuste nicht-funktionale Layouttests
durchzuführen. Insgesamt gesehen trägt das Tool somit sicherlich zu einem
effizienteren Test von Benutzeroberflächen bei und bietet sinnvolle Features zur
Aufwandsreduzierung, die nach Recherche in alternativen Tools nicht ausfindig zu
machen waren.
Allerdings müssen alle denkbaren Interaktionsmöglichkeiten der Oberfläche getestet
werden, um die Software vor unerwarteter Bedienung zu schützen. In vielen GUI25
Kapitel 5: Resümee und Fazit
Testtools wie dem RFT muss deshalb die Aufzeichnung eines Testfalls für alle
Bedienungskombinationen wiederholt werden, was den Aufwand stark erhöht; Deshalb
wird an Verfahren geforscht, die nicht nur die Testdurchführung eines Skripts, sondern
die Skripterstellung selbst automatisieren.
26
Kapitel 0: Literaturverzeichnis
Literaturverzeichnis
[FG99]
Fewster, M., Graham, D.: Software Test Automation. ACM Press, AddisonWesley, 1999.
[FK07]
Franz, K.: Handbuch zum Testen von Web-Applikationen. Testverfahren,
Werkzeuge, Praxistipps. Springer Verlag, 2007.
[FS08]
Wikipedia: Fenstersystem, URL:
http://de.wikipedia.org/wiki/Fenstersystem, Abrufdatum: 27.10.2008
[GBO08] Wikipedia: Grafische Benutzeroberfläche, URL:
http://de.wikipedia.org/wiki/Grafische_Benutzeroberflaeche, Abrufdatum:
27.10.2008.
[GST08]
Wikipedia: GUI software testing, URL:
http://en.wikipedia.org/wiki/GUI_software_testing, Abrufdatum: 2.11.2008.
[HD08]
Hoffman, D.W.: Software-Qualität. Springer Verlag, 2008
[IBM08]
IBM: Rational Functional Tester – Components, URL:
http://www-01.ibm.com/software/awdtools/tester/functional/sa.html,
Abrufdatum: 1.12.2008.
[KL94]
Kepple, L.R.: The black art of GUI testing. Dr. Dobb's Journal of Software
Tools, 19(2): 40, Feb. 1994.
[LD08]
Linz, T., Daigl, M.: How to Automate Testing of Grahical User Inferfaces.
Results of the ESSI PIE 24306, URL:
http://www.imbus.de/forschung/pie24306/gui/aquis-full_paper-1.3.shtml,
Abrufdatum 28.10.2008.
[LW05]
Li, K., Wu, M.: Effective GUI Test Automation. Developing an Automated
GUI Testing Tool. Sybex Verlag, 2005.
[PG97]
Gerrad, P.: Testing GUI Applications, URL:
http://www.gerrardconsulting.com/GUI/TestGui.html, Abrufdatum:
27.10.2008.
[PP04]
Pomberger, G., Pree, W.: Software Engineering. Architektur-Design und
Prozessorientierung. Hanser Verlag, 2004.
[PZ08]
Zembrod, P.: GUI Testing: Don’t Sleep Without Synchronisation, URL:
http://googletesting.blogspot.com/2008/10/gui-testing-dont-sleepwithout.html, Abrufdatum: 29.10.2008
[SC05]
Steinweg, C.: Management der Software-Entwicklung. Vieweg Verlag,
2005.
27
Kapitel 0: Literaturverzeichnis
[SL05]
Spillner, A., Linz,T.: Basiswissen Software Test. Dpunkt Verlag, 2005.
[SW02]
Sneed, H.M., Winter, M.: Testen objektorientierter Software. Das
Praxisbuch für den Test objektorientierter Client/Server-Systeme. Hanser
Verlag, 2002.
[TG02]
Thaller, G. E.: Software-Test. Verifikation und Validation. 2. Auflage. Heise
Verlag, 2002.
28