SlideShare ist ein Scribd-Unternehmen logo
Automatisiertes Webauftritt-Testen
  auf struktureller und visueller Ebene
             Bachelorprojekt im Informatikstudium an der Universität Basel
                                   September 2010




Autor:
Reto Kaiser
Erlenstrasse 41
4058 Basel
Schweiz
reto.kaiser@stud.unibas.ch

Betreuung:
High Performance and Web Computing
Departement Informatik
Klingelbergstrasse 50
4056 Basel
Schweiz
Prof. Dr. Helmar Burkhart
helmar.burkhart@unibas.ch
Dr. Sven Rizzotti
sven.rizzotti@unibas.ch
Inhaltsverzeichnis
Abstract
Einleitung
1. Software-Testen!                                2
   1.1 Grundlagen!                                 2
      1.1.1 Komponententest!                       3
      1.1.2 Integrationstest!                      4
      1.1.3 Systemtest!                            4
      1.1.4 Abnahmetest!                           5
      1.1.5 Nicht-funktionale Tests!               6
      1.1.6 Standardisierung!                      6
      1.1.7 Interview mit Dr. Franz-Josef Elmer!   7
   1.2 Entwicklungen!                              8
   1.3 GUI-Testen!                                 9
2. Webauftritt-Testen!                             10
   2.1 Grundlagen!                                 10
   2.2 Entwicklungen!                              11
   2.3 Ansätze!                                    12
      2.3.1 Komponententest!                       13
      2.3.2 Integrationstest!                      14
      2.3.3 Systemtest!                            15
   2.4 Praxis!                                     17
      2.4.1 Interview mit Urs Gürtler, Nextron!    17
      2.4.2 Umfrage bei Webauftritt-Betreuern!     18
   2.5 Werkzeuge!                                  21
      2.5.1 Serverseitige Komponententests!        21
      2.5.2 JavaScript Komponententests!           23
      2.5.3 HTTP Integrationstests!                24
      2.5.4 Browser Integrationstests!             25
      2.5.5 Last Systemtests!                      28
      2.5.6 Sicherheit Systemtests!                30
3. Webseiten Layout-Testen: Screencompare!         31
   3.1 Problem!                                    31
      3.1.1 Diversifizierte Client-Landschaft!      31
      3.1.2 Pixelgenaues Design!                   32
      3.1.3 Bedarf nach visuellem Layout-Testen!   33
   3.2 Lösungsansatz!                              34
   3.3 Funktionsweise!                             35
      3.3.1 Testablauf!                            35
      3.3.2 Verwendung!                            37
      3.3.3 Verfügbarkeit!                         42
Zusammenfassung
Quellen
  Abbildungen
  Literatur
Abstract
In der Softwareentwicklung ist das Testen ein zentraler Bestandteil der Qualitätskontrolle.
Anhand der Unterteilung Komponenten-, Integrations-, System- und Abnahmetest wird der
theoretische Hintergrund und die praktische Anwendung aufgerollt.
Moderne Webauftritte und -anwendungen müssen ebenfalls getestet werden, wobei einige
Besonderheiten zu beachten sind. Neben der Erläuterung etablierter Ansätze werden
einige existierende Werkzeuge anhand von Beispielen vorgestellt.
Eine selbstentwickelte Software für visuelle Layout-Tests an Webseiten wird vorgestellt,
die gebrauchsfertig und online verfügbar ist.


Einleitung
Webauftritte basieren auf einer Reihe von Technologien wie HTTP, HTML, CSS,
JavaScript und einigen weiteren. Im letzten Jahrzehnt sind interaktive Webanwendungen
entstanden, wobei sich deren Komplexität symbiotisch mit den entsprechenden
Technologien entwickelt. Die rasanten Fortschritte in diesem Bereich führen dazu, dass
Webanwendungen heute in vielerlei Hinsicht klassischen Anwendungen gleichzustellen
sind.
Entsprechend angestiegen ist die wirtschaftliche Bedeutung von Webauftritten. Viele
sogenannte Dotcom-Firmen bieten ihre Dienstleistungen ausschliesslich über das Internet
an. Es gibt also gute Gründe, in die Qualitätskontrolle und damit auch in das Testen von
Webauftritten zu investieren.
Die Etablierung iterativer und testgetriebener Entwicklungmodelle in den letzten 20 Jahren
führte zu einer Erstarkung des automatisierten Testens; ein Konzept, das auch im jungen
Bereich des Webauftritt-Testens Anklang findet.
Die Client-Server-Struktur von Webauftritten birgt dazu einige strukturelle Stolpersteine.
Die verbreiteten Webbrowser sind in der Regel abgeschlossene Endnutzer-Anwendungen,
die nur umständlich als Testumgebung genutzt werden können.
In dieser Arbeit sollen einige verbreitete Ansätze des Web-Testens vorgestellt, und deren
Möglichkeiten und Grenzen ausgelotet werden.
Schlussendlich wird die Frage gestellt, wieso und in welchem Umfang es nötig ist, die
visuelle Erscheinung einer Webseite automatisiert zu testen. Dazu wird eine
Herangehensweise anhand einer Java-Implementierung präsentiert.




                                            -1-
1. Software-Testen
1.1 Grundlagen
Unter Software-Testen werden verschiedene Verfahren verstanden, welche zur
Sicherstellung der Softwarequalität dienen1 . Mit ihnen wird versucht, Fehler zu finden und
neue zu verhindern.
Damit ist das Testen ein wichtiger Faktor in der Beurteilung der Produktqualität von
Software; speziell die Testabdeckung kann eine aussagekräftige Metrik sein2.
Die starke Heterogenität in Softwareentwicklungsprozessen und Laufzeitumgebungen
führt zu einem diversifizierten Metier, welches schwer formalisierbar ist. Entwickler, aber
auch dedizierte Tester müssen Tests planen, erstellen, durchführen und dokumentieren.
IEEE 829-1998 “Software Test Documentation” beschreibt acht Dokumente zur
Dokumentation von Tests, welche von der Konzeption, über die Spezifikation von Ein- und
Ausgabewerten bis zu einer Zusammenfassung der Ergebnisse reichen. In der Praxis
wird, abhängig von den Qualitätsanforderungen, deutlich weniger dokumentiert3.
Automatisierte Tests erlauben es häufig, ganz auf eine manuelle Dokumentation zu
verzichten, wobei Werkzeuge es ermöglichen aus den Tests selbst berichtartige
Dokumente zu erzeugen.


Software-Testen beinhaltet sowohl statische wie auch dynamische Techniken. Code-
Reviews oder -Analysen sind beispielsweise statische Methoden. Diese Arbeit befasst sich
hingegen mit den dynamischen Methoden, welche die tatsächliche Ausführung eines
Programms oder Programmteils
überprüfen.
Für die Klassifizierung von
Testmethoden, -kriterien oder -
stufen existieren verschiedenste
Modelle. Im Folgenden wird auf
einige verbreitete Techniken
anhand verschiedener Stufen der
Softwareentwicklung im V-Modell4              Abb. 1: Stufen des V-Modells

eingegangen.

1 IEEE 1012-2004, 2004, Abschnitt 5.4.5
2 IEEE 1012-2004, 2004, Abschnitt 7.8, Tabelle 1
3 Bspw. Interviews, Abschnitt 1.1.7 und 2.4.1
4 Vorgehensmodell der Softwareentwicklung, siehe Abb. 1

                                                  -2-
1.1.1 Komponententest
Mit einem Komponententest (Modultest, Unittest) wird ein einzelner Programmteil auf
Fehler geprüft. Eine zu testende Komponente kann beispielsweise ein funktionales Modul
im Sinne der Softwarearchitektur oder eine Klasse in der objektorientierten
Programmierung sein. Diese Komponente wird isoliert vom Rest der Software getestet. Ist
die Funktionalität einer Komponente beschränkt und genau definiert, lassen sich damit auf
einfache Weise erwartete Ergebnisse überprüfen.
Im einfachsten Fall können die Schnittstellen einer Komponente anhand von Ein- und
erwarteten Ausgaben geprüft werden. Dabei werden auch Fehlerszenarien, wie das
Verhalten bei ungültigen Eingaben, getestet. Wenn eine Komponente auf weitere
Programmteile angewiesen ist, so müssen diese für den Test simuliert werden. In diesem
Fall wird von Mock-Objekten gesprochen, welche häufig mit entsprechenden Frameworks
für Datenbank- oder Datei-Mocks erstellt werden.
Komponententests werden fast immer automatisiert durchgeführt5, wobei entsprechende
Werkzeuge, wie die vielzähligen xUnit-Frameworks6, Anwendung finden. Dies ermöglicht
es, ein ganzes Set von Komponententests regelmässig auszuführen. Bei genügend
grosser Testabdeckung können Entwickler so in Erfahrung bringen, ob eine
Softwareänderung neue Fehler auslöst oder alte tilgt.
In grösseren Entwicklungsteams kann es sinnvoll sein, die Ausführung und das Bestehen
der Komponententests als Bedingung für die Aufnahme neuen Codes zu definieren. Die
Testausführung kann beispielsweise von einem Pre-commit hook7 des
Versionierungssystems, oder auch vom Erstellungsprozess (Build) ausgelöst werden8 .


Ein JUnit 3 Komponententest:

    public class CalcTest extends TestCase {

    !   public void testAdd() {
    !   !      int result = MyCalc.add(3, 4);
    !   !      assertEquals(7, result);
    !   }

    }




5 Runeson, 2006
6 http://www.martinfowler.com/bliki/Xunit.html [23.9.2010]
7 Automatisierte Programmausführung vor dem Einchecken in ein Versionierungssystem
8 http://martinfowler.com/articles/continuousIntegration.html#MakeYourBuildSelf-testing [7.9.2010]

                                                       -3-
1.1.2 Integrationstest
Das Ziel eines Integrationstests ist es, die vorher durch Komponententests geprüften
Programmteile kombiniert zu testen. Dabei können funktionale (Schnittstellen-)
Anforderungen, aber auch das Performanzverhalten Testobjekte sein.
Die einzelnen Komponenten werden dabei als Black Boxes9 gehandhabt. Wissen über
deren interne Funktionsweise und Struktur ist für den Integrationstest also nicht nötig.
Auch hier sollten sowohl gültige wie auch fehlerhafte Zwischenkomponenten-Interaktionen
getestet werden, indem eine Komponente eine oder mehrere andere verwendet.
Um den Testaufwand überschaubar zu halten, macht es bei grösseren Projekten Sinn,
nicht alle Komponenten in jeglichen Kombinationen gegeneinander zu testen. Statt dessen
können gemeinsam geprüfte Programmteile in einem nächsten Schritt als einzelne
Komponente verstanden werden, welche in Zusammenarbeit mit einer anderen
zusammengesetzten Komponente getestet wird. Dieses stufenweise, n-äre
Zusammensetzen der Software wird als Bottom Up10-Ansatz bezeichnet.
Häufig werden aber auch Mischformen mit Ansätzen wie Top Down 11 (umgekehrte
Zusammenbaureihenfolge) oder Big Bang12 (Zusammenarbeit der Komponenten im
Gesamtprodukt testen) verwendet.
Bei Projekten mit mehreren Entwicklern wird mit Integrationstests die Zusammenarbeit von
Komponenten unterschiedlicher Autoren getestet. Schnittstellenspezifikationen und -
änderungen werden demnach auf die Probe gestellt. In solchen Entwicklungsszenarien
macht es besonders Sinn diese Teststufe zu automatisieren.
Integrationstests finden entgegen ihrer akademischen Definition im V-Modell aber auch in
Ein-Mann-Projekten ohne jegliche Komponententests Anwendung. Abhängig von der
verwendeten Technologiepalette und der eingebauten Testbarkeit wird der
Automatisierungsaufwand unvertretbar hoch, sodass das Zusammenwirken der
Komponenten in deren Entwicklungsphase vom Autor manuell getestet wird.

1.1.3 Systemtest
Beim Systemtest wird der Black Box-Ansatz weitergetrieben, wobei das ganze
zusammengesetzte Software-System ohne Wissen über dessen inneren Aufbau getestet
wird. Die Testumgebung simuliert dabei die spätere Produktivumgebung.



9 Ohne Kenntnisse über die innere Funktionsweise, es werden nur öffentliche Schnittstellen betrachtet.
10 BS 7925-1
11 BS 7925-1
12 BS 7925-1

                                                  -4-
In diesem Schritt testet die entwickelnde Organisation erneut die Funktionalität der
Software, aber auch die Erfüllung nicht-funktionaler Anforderungen. Solche Anforderungen
an Performanzverhalten, Sicherheitsvorkehrungen oder Gebrauchstauglichkeit müssen
genau spezifiziert sein; ein späterer Abschnitt befasst sich mit derem Spezifizieren und
Testen.
Das Automatisieren von Systemtests kann sich als schwierig, beziehungsweise
unwirtschaftlich erweisen13 , speziell wenn diese mehrheitlich aus Benutzerschnittstellen-
Tests bestehen.
Eine spätere formelle Abnahme der Software durch den Kunden kann vereinfacht werden,
indem die Systemtest-Abläufe und -Ergebnisse genau dokumentiert werden, um sie dem
Kunden zu präsentieren.

1.1.4 Abnahmetest
Ein Abnahmetest (Acceptance test und User acceptance test) findet bei praktisch jedem
für einen Kunden entwickelten System statt, Umfang und Formalitätsgrad varieren jedoch
stark. IEEE 1012-2004 “Software Verification and Validation” definiert den Vorgang als
“Formal testing conducted to determine whether or not a system satisfies its acceptance
criteria and to enable the customer to determine whether or not to accept the system.” 14 In
diesem Sinne wird im englischen Sprachgebrauch vielfach zwischen Acceptance testing
und User acceptance testing unterschieden, wobei ersteres durch den Entwickler, und
zweiteres durch den Kunden oder Anwender durchgeführt wird.
Ein User acceptance Test dient meist als Abnahmekriterium für eine Software. Dabei soll
die Funktionalität des Produkt mit realen Anwendungsszenarien überprüft werden, wobei
vielfach angestrebt wird, von der Entwicklung unabhängige Tester einzusetzen.
Systemtest-Dokumentationen können zur Abnahme-Beurteilung hinzugezogen werden.
Sogenannte Benutzergeschichten (User Story), welche in grösserem Aussmass auch in
agilen, testgetriebenen Entwicklungsmodellen Anwendung finden, können Anforderungen
für Abnahmetests sein. Weniger detailliert als Anwendungsfälle (Use Case), dafür ein
ausführlicheres Benutzerszenario beschreibend, dienen sie der abstrakten Beschreibung
der Software-Anforderungen durch den Kunden.
Eine Benutzergeschichte:

 Beim öffnen eines Videos wird dieses an der zuletzt gestoppten
 Position oder, wenn noch nie geöffnet, an dessen Anfang abgespielt.


13   Hoffman, 1999
14   IEEE 1012-2004, 2004, Abschnitt 3.1.1
                                             -5-
1.1.5 Nicht-funktionale Tests
Aus Anwendungsfällen, oder daraus abgeleitet, können die funktionalen Anforderungen
einer Software definiert werden. Sie beschreiben, was diese tun soll, wie sie also
Eingaben verarbeitet, und welche Ausgaben erwartet werden.
Im Gegensatz dazu definieren die nicht-funktionalen Anforderungen, wie sich das System
in allen anderen Belangen verhält. Diese Qualitätsauflagen können verschiedenste
Bereiche tangieren: Performanz, Sicherheit, Gebrauchstauglichkeit (Usability), Wartung,
Robustheit, Erweiterbarkeit, Installation, Skalierbarkeit, Lokalisierbarkeit, Dokumentation et
cetera15. Abhängig von Umfang, gesetzlichen Rahmenbedingungen, Einsatzgebiet und so
weiter einer Software, fallen diese Nebenbedingungen unterschiedlich grosszügig aus.
Einige dieser Anforderungen können im Sinne der Informatik und Informationstechnik
getestet werden, benötigen aber meist spezialisierte Kenntnisse ausserhalb der
Softwareentwicklung. Der vielfältige Bereich des Performanzverhaltens, welcher sich zum
Beispiel mit der Skalierbarkeit, dem Zeitverhalten und der Verfügbarkeit eines Systems
befasst, kann Kenntnisse zu Netzwerktopologie, Last-Erzeugung und Hardware-Verhalten
voraussetzen. Um hingegen die Gebrauchstauglichkeit einer Software einzuschätzen, sind
Psychologie-Kenntnisse, Design-Leitfäden oder spezielle Gerätschaften nötig.
Diese diversifizierten Qualifikationsanforderungen führen zu einem hohen Aufwand des
Testens und Erfüllens von nicht-funktionalen Anforderungen. Es wird deshalb
vorgeschlagen, die Wichtigkeit dieser Anforderungen für den Kunden in Erfahrung zu
bringen.16
Nicht-funktionale Tests werden üblicherweise in der Integrations- oder Abnahmephase des
Projekts durchgeführt, wobei eine vielfältige Palette an freien, sowie kommerziellen
Werkzeugen und Diensten verwendet werden kann.

1.1.6 Standardisierung
Das Ausmass und die Professionalität des Software-Testens hat sich in den letzten 30
Jahren massiv gesteigert.17 Viele Softwareschmieden besitzen unterdessen Personal für
das Testen und dessen Leitung.
Während eine Vielfältigkeit an Meinungen und Praktiken zum Software-Testen existiert,
versuchen einige Organisationen Begriffsdefinitionen, Anforderungen und Abläufe zu
standardisieren. Im folgenden einige aktuell gültige Standardisierungsdokumente zum


15 Bspw. Chung; Leite, 2009
16 Melnik; Meszaros, 2009, Abschnitt 5.2.2
17 Gelperin; Hetzel, 1988, Abschnitt “Growth of professionalism”

                                                     -6-
Thema, sowie ein mir vielversprechend erscheinender Entwurf für einen umfassenden
ISO/IEC-Standard:
• IEEE 829-1998. Software Test Documentation
• IEEE 1008-1987. Software Unit Testing
• IEEE 1012-2004. Software Verification and Validation
• IEEE 1028-2008. Software Reviews and Audits
• ISO/IEC 25000:2005. Software product Quality Requirements and Evaluation (SQuaRE)
• ISO/IEC 29119. Software Testing (Entwurf, siehe http://softwaretestingstandard.org)

1.1.7 Interview mit Dr. Franz-Josef Elmer
Dr. Franz-Josef Elmer unterrichtet “Software Engineering” an der Universität Basel und
arbeitet seit 1998 in der Softwareentwicklung. Er entwickelte in zwei- bis sechsköpfigen
Teams GUI- und Webanwendungen mit Client-Server-Struktur, wobei vor allem Java,
Bash, Python, SQL, XML und HTML Anwendung finden.

Wie testen Sie heute Anwendungen?
Elmer: »Wir betreiben Unit-, Integrations- und Systemtests, wobei die Unittestabdeckung
weit unter 100% liegt, wahrscheinlich auch unterhalb von 50%.
Meist gehen wir nach dem Prinzip “Code a little, test a little” vor. Geschriebener Code
muss also testbar sein, wobei die entsprechenden Tests nach der Fertigstellung einer
Etappe umgesetzt werden.
Reine testgetriebene Entwicklung ist bei uns kein Thema. Ich kann mir speziell in der
explorativen Anfangsphase der Entwicklung einer Software auch schlecht vorstellen, wie
das sinnvoll funktionieren soll.«

Welche Entwicklungen konnten und können Sie beobachten?
»In meiner Anfangsphase haben wir das gemacht, was man heute manuelle System- und
Abnahmetests nennt, die Anwendung also einfach ausprobiert. In dieser Zeit wurden meist
wasserfallartige Entwicklungsmodelle verwendet.
Vor 10 Jahren bin ich zum ersten Mal
auf das Konzept des automatischen         »Vor 10 Jahren bin ich zum ersten
Testens gestossen. Nachdem ich            Mal auf das Konzept des
selber ein Framework entwickelt           automatischen Testens gestossen.«
habe, hat mich ein Kollege auf einen
Artikel in der iX über JUnit, einem Testingframework, aufmerksam gemacht.



                                            -7-
Automatisiertes Testen hat sich in der Zwischenzeit entwickelt und ist in der
Softwareentwicklung zum Standard geworden. Der Trend zu iterativen
Entwicklungsmethoden hat dazu beigetragen.«

Welche Herausforderungen sehen Sie beim Webauftritt-Testen?
»Serverseitig ist das sicher unproblematisch, Unittests für die Logik sind da stabil.
Um die Clientlogik gut testen zu können sind aber die Controller [im MVC-Pattern] zu sehr
mit den GUI-Elementen verbunden.
GUI-Tests sind generell heikel und brechen bereits bei kleinen Änderungen. Komplexe
Benutzerschnittstellen und dadurch viele Eingabemöglichkeiten bringen einen hohen
Testaufwand mit sich, wobei der Nutzen vielfach unklar bleibt.«

1.2 Entwicklungen
Die Koryphäen des Software-Testens Dave Gelperin und William C. Hetzel beschreiben18
1988 folgende fünf Phasen des frühen Testens von Software:
• Bis 1956 “Debugging oriented”: Fehler werden explorativ gefunden und behoben.
• 1957-1978 “Demonstration oriented”: Wachsende wirtschaftliche Wichtigkeit von
     Software führt zu stärkerem Engagement für das Fehlerfinden.
• 1979-1982 “Destruction oriented”: Testen soll aktiv Fehler finden, es müssen also auch
     unübliche Eingaben berücksichtigt werden.
• 1983-1987 “Evaluation oriented”: Softwarequalität wird anhand von Richtlinien evaluiert.
• 1988 “Prevention oriented”: Anforderungen werden im Voraus definiert, Tests zu deren
     Überprüfung werden geplant.
Das Aufkommen der “Prevention oriented”-Periode hat sich wohl bewahrheitet, in der
Zwischenzeit hat sich jedoch wiederum einiges getan.
In den 90er-Jahren wird das Software-Testen professionalisiert, wobei das Thema im
grossen Stil diskutiert wird, beispielsweise an Konferenzen wie der “Software Testing
Analysis & Review” (STAR, seit 1992 19) oder der “Software & Systems Quality” (SQC, seit
199620). Ausserdem wird 199121 erstmals der Standard ISO/IEC 9126 “Software
engineering - Product quality” veröffentlicht.




18 Gelperin; Hetzel, 1988, Abschnitt “Evolution of the models”
19 http://www.sqe.com/Events/Archive/sw2002/ [7.9.2010]
20 http://www.iqnite-conferences.com [7.9.2010]
21 http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=16722 [7.9.2010]

                                                      -8-
Gleichzeitig entstehen testgetrieben sowie agile Entwicklungsmethoden wie Scrum 22 oder
Extreme Programming23, bei welchen das Testen ein wichtiger Bestandteil des
Entwicklungsprozesses ist. Speziell das Komponententesten, welches es dem
Softwareautor ermöglicht, leicht automatierbare Tests für funktionale Anforderungen zu
erstellen, gewinnt dadurch an Bedeutung. 1998 begründet und beschreibt der Zürcher
Erich Gamma zusammen mit dem Amerikaner Kent Beck das beliebte JUnit24.
Das Software-Testen hat also einige Paradigmenwechsel durchgemacht, und wird sich
auch zukünftig an neue Ansprüche und Technologien anpassen müssen.

1.3 GUI-Testen
Als Computerprogramme noch mehrheitlich mit einer Kommandozeile (CLI) gesteuert
wurden, beschränkte sich die Benutzerschnittstelle auf eingegebenen Text und die
textuelle Ausgabe. Das Testen einer solchen Benutzerschnittstelle ist relativ überschaubar,
da die Anzahl an Eingabemöglichkeiten beschränkt werden kann.
Im Zeitalter von grafischen Benutzeroberflächen (Graphical user interface, GUI) hingegen,
ist das Testen der Benutzerschnittstelle einiges problematischer. Eine GUI besitzt
typischerweise eine Vielzahl von Steuerelementen wie Schaltflächen, Bildlaufleisten,
Menüs et cetera, welche gleichzeitig Eingaben entgegennehmen können. Durch die
grosse Anzahl solcher Elemente und die vielen möglichen Eingabe-Reihenfolgen ergibt
sich schnell eine unüberschaubar grosse Anzahl von GUI-Zuständen.
Aufgrund dieser problematischen Umstände ist es schwierig eine GUI durchgängig zu
testen, und es wird nötig das Testen zu automatisieren.
In der Praxis werden häufig manuelle Benutzerinteraktionsabläufe aufgezeichnet, um sie
dann mit einer entsprechenden Software
automatisiert abspielen zu können.
Dadurch wird der manuelle Aufwand auf
das Aufzeichnen reduziert, und der Test
kann beliebig oft wiederholt werden.
Um eine GUI überhaupt automatisiert
testbar zu machen, müssen
Benutzerinteraktionen automatisierbar
sein. Einige Ansätze führen
                                             Abb. 2: GUI-Testpläne für MS WordPad

22 Takeuchi; Nonaka, 1986
23 Beck, 1999
24 Gamma; Beck, 1999

                                            -9-
Benutzereingaben auf Betriebssystemebene aus25, sodass keine speziellen Vorkehrungen
im zu testenden Programm vorgenommen werden müssen. Andernfalls kann ein GUI-
Treiber in das Programm verbaut werden, über welchen ein anderes Programm die zu
testende GUI mit Eingaben versorgen, und Ausgaben auslesen kann.
Auch das Überprüfen der Ausgaben einer GUI mit einem automatisierten Test ist
problematisch. Grafische Ausgaben können abhängig von der Laufzeitumgebung in
Dimensionen, Farben und Schriftarten variieren. Eine automatische Validierung erkennt
solche Unterschiede als Fehler, obwohl sie unter Umständen gewollt sind.


2. Webauftritt-Testen
2.1 Grundlagen
Grössere Webauftritte (Website) sind heute üblicherweise sogenannte Webanwendungen,
also Computerprogramme, die auf einem Webserver laufen. Grundsätzlich dient dabei der
Webclient des
Anwenders als Thin
Client, wobei die
eigentliche
Programmlogik als
CGI26-Programm, oder
als integrierte
Anwendung des
Webservers auf einem
entfernten Rechner
ausgeführt wird.             Abb. 3: Datenfluss einer Webanwendung
Server und Client
kommunizieren dabei mit dem Hypertext-Übertragungsprotokoll (HTTP) über eine
Netzwerkverbindung, sodass im Idealfall eine fast verzögerungsfreie Benutzerschnittstelle
bereitgestellt werden kann.
Diese Architektur bedingt im Vergleich mit einer klassischen, lokal laufenden Software
einige technische Unterschiede. Einerseits wird durch den Thin Client die Installation,
Konfiguration und Wartung für den Anwender grössenteils hinfällig, und der Hersteller
kann Softwareänderungen unverzögert zur Verfügung stellen, andererseits entsteht


25   Z.B. “AutoHotkey”
26   Common Gateway Interface, RFC 3875
                                            - 10 -
serverseitig ein Single Point of Failure (SPOF), und es muss damit gerechnet werden,
dass die Client-Server-Verbindung jederzeit unterbrochen werden kann.
Diese Eigenheiten müssen bei der Qualitätsbeurteilung von Webanwendungen
berücksichtigt werden.
Im Webbereich kommen einige spezialisierte Techniken zum Einsatz, die unter Anderem
ein angenehmes Benutzererlebnis ermöglichen:
• Cookies ermöglichen es, auf dem zustandslosen Protokoll (HTTP) Benutzer über
     mehrere Anfragen hinweg zu identifizieren.
• Hypertext-Auszeichnungssprache (HTML) strukturiert als Grundlage jeder Webseite
     Inhalte wie Text, Bilder und Hyperlinks, welche im Webbrowser angezeigt werden.
• Cascading Style Sheets (CSS) dient der Definition der Darstellung von
     Benutzerschnittstellen-Elementen der HTML, womit der Inhalt einer Webseite von
     dessen Aussehen getrennt wird.
• JavaScript ist eine Skriptsprache, welche clientseitig als Teil einer Webseite im
     Webbrowser ausgeführt wird und HTML-Elemente, sowie CSS-Regeln ändern kann.
     Damit werden dynamische Benutzerschnittstellen innerhalb einer Webseite möglich.
Zur Auseinandersetzung des Testens solcher Anwendungen ist festzuhalten, dass erstens
die Programmlogik lose gekoppelt auf zwei physisch getrennten und technisch
verschiedenen Systemen (Client und Server) abläuft, und sich zweitens speziell die
Ausprägungen nicht-funktionaler Anforderungen erheblich von denen klassischer Software
unterscheiden können.

2.2 Entwicklungen
Die Disziplin des Webauftritt-Testens ist relativ jung. Grund dafür ist, dass
Webanwendungen erst in den letzten zwei Jahrzehnten entstanden sind, wobei ihr
Komplexitätsgrad in den letzten Jahren erheblich zugenommen hat.
Eine der ersten
Webanwendungen ist
“SPIRES HEP” der
Stanford-Universität, welche
es 1991 erlaubt, einen
Katalog von Teilchenphysik-
Publikationen zu                       Abb. 4: SPIRES HEP Benutzerschnittstelle, 1991

durchsuchen27 .

27   http://www.slac.stanford.edu/history/earlyweb/firstpages.shtml [7.9.2010]
                                                       - 11 -
Technologische Meilensteine sind CGI (1995 28), PHP (1995 29), JavaScipt (199530),
XMLHttpRequest (1999 31) und Ajax (200532).
Während der New Economy 33 der 1990er Jahre entstehen grosse Webanwendungen34,
welche schnell an Interaktionsmöglichkeiten gewinnen, indem asynchrone Kommunikation
zwischen Client und Server (Ajax), eingesetzt wird. Damit kann die Benutzerschnittstelle
im Webbrowser zügig und nahtlos auf Benutzereingaben reagieren, indem die auf dem
Server laufende Anwendung im Hintergrund mit JavaScript kontaktiert wird.
Software fürs Webauftritt-Testen entsteht in dieser Ära. So publiziert Russell Gold im Jahr
200035 die Version 1.0 von HttpUnit, welche es erlaubt Komponententests für
Webseitenaufrufe zu schreiben, ohne einen Webbrowser einsetzen zu müssen.
Um die Jahrtausendwende gibt es also Bestrebungen, die Funktionalität von Webauftritten
zu überprüfen36 , namentlich den Kontrollfluss von Forms und Hyperlinks. Aber auch das
Überprüfen nicht-funktionaler Anforderungen wie der Gebrauchstauglichkeit37 wird
thematisiert.
Die wachsende wirtschaftliche Bedeutung während den letzten zehn Jahren von
Webanwendungen wie Google, Yahoo, Facebook und Co. hat dazu geführt, dass mehr
Ressourcen in die Qualitätskontrolle von Webanwendungen investiert werden. Die
Disziplin des Webauftritt-Testens ist jung, und die Anwendungsfälle gehen stark
auseinander.

2.3 Ansätze
Es scheint sich bis heute kein Konsens gebildet zu haben, wie ein Webauftritt getestet
werden soll. Standardisierungsdokumente geben, durch ihre Langlebigkeit bedingt, wenig
Auskunft. Verschiedenste Anforderungskataloge und technische Umsetzungen führen zu
einer Vielzahl möglicher Ansätze.




28 http://www.w3.org/Daemon/User/CGI/Overview.html [7.9.2010]
29 http://groups.google.ch/group/comp.infosystems.www.authoring.cgi/msg/cc7d43454d64d133 [7.9.2010]
30 http://web.archive.org/web/20070916144913/http://wp.netscape.com/newsref/pr/newsrelease67.html

[7.9.2010]
31 http://blogs.msdn.com/b/ie/archive/2006/01/23/516393.aspx [7.9.2010]
32 http://www.adaptivepath.com/ideas/essays/archives/000385.php [7.9.2010]
33 Dienstleistungsbetonte Wirtschaftsform, geprägt durch Globalisierung und Digitalisierung
34 Bspw. Google 1998, Hotmail 1996, Yahoo 1995
35 http://sourceforge.net/mailarchive/message.php?msg_name=v03110704b5d5d324518e

%40%5B207.106.60.98%5D [7.9.2010]
36 Yang; Huang; Wang, 1998
37 Corry; Frick; Hansen, 1997

                                                    - 12 -
2.3.1 Komponententest
Die eigentliche Anwendungslogik einer Webapplikation, die auf einem Server läuft, kann
grösstenteils im Sinne der klassischen Softwareentwicklung betrachtet werden. Um sie
testbar zu machen, sollte sie streng von der Benutzerschnittstelle getrennt sein. Dazu hat
sich mehrheitlich das Model View Controller (MVC)-

Paradigma etabliert. Dabei werden Anwendungslogik

(Model), Präsentation (View) und Programmsteuerung
(Controller) als möglichst unabhängige Einheiten
betrachtet, welche über Schnittstellen kommunizieren.
Gängige Webanwendungs-Frameworks wie das Zend
Framework, Catalyst oder JavaServer Faces erlauben
oder fordern die Entwicklung im MVC-Stil.
In einem MVC-Projekt können die üblichen
Komponententest-Frameworks für die entsprechende
Programmiersprache verwendet werden, während
Mock-Objekte die Datenquellen simulieren.
                                                                     Abb. 5: MVC-Paradigma

Die serverseitige Anwendungslogik ist aber nicht die
einzige Stelle, an der Komponententests angewendet werden. Durch die zunehmenden
Interaktionsmöglichkeiten von Web-Benutzerschnittstellen, wird vermehrt Programmlogik
auf der Clientseite gebräuchlich. So lädt beispielsweise eine Facebook-Webseite um die
600KB komprimierten JavaScript-Quellcode nach38 . Beliebte JavaScript-Bibliotheken
haben in ihren aktuellen Versionen erheblichen Umfang: jQuery 6240 Zeilen39 , MooTools
4329 Zeilen40 und Dojo 11251 Zeilen41 Code.
Dieser Teil einer Webanwendung wird nur selten automatisiert getestet. Der häufig
prozedurale Programmierstil von JavaScript-Code und die enge Verknüpfung von Logik
und Benutzerschnittstelle verringern die Testbarkeit. Gleichzeitig sind Webbrowser als
wichtigste JavaScript-Interpreter nicht dafür ausgelegt, automatisierte Tests laufen zu
lassen.
Trotzdem gibt es Bestrebungen, JavaScript-Komponententests auf verschiedenen Ebenen
möglich zu machen. Eine Variante ist es, die Anwendungslogik in einem Webbrowser zu


38 http://www.facebook.com [7.9.2010]
39 http://code.jquery.com/jquery-1.4.2.js [7.9.2010]
40 http://mootools.net/download/get/mootools-1.2.4-core-nc.js [7.9.2010]
41 http://download.dojotoolkit.org/release-1.5.0/dojo.js.uncompressed.js [7.9.2010]

                                                      - 13 -
testen. Da sich die JavaScript-Interpreter der verschiedenen Webbrowser teilweise
erheblich unterscheiden, können dabei auch Interpreter-implementierungsspezifische
Fehler aufgedeckt werden. Die Test-Frameworks sind dabei selbst in JavaScript
geschrieben und bieten an die xUnit-Familie angelehnte Funktionalität.
Andere Ansätze führen die zu testende Logik in einem besser kontrollierbaren, dezidierten
JavaScript-Interpreter ausserhalb eines Webbrowsers aus. So verwenden einige Test-
Frameworks Mozillas in Java geschriebene JavaScript-Implementierung Rhino42.


Während die Benutzerschnittstelle einer Webanwendung als wie komplexer wird, muss
häufig festgestellt werden, dass ein Grossteil der serverseitigen Anwendungslogik
clientseitig in JavaScript dupliziert wird. Das führt zu doppeltem Wartungs- und
Testaufwand.
Einige Webanwendungs-Frameworks versuchen diesen Missstand zu beheben, indem
Quellcode in einer einzigen Programmiersprache beim Deployment in die entsprechenden
Technologien der Clientseite wie HTML, CSS und JavaScript übersetzt wird. Wichtige
Vertreter sind Google Web Toolkit (GWT)43 in Java, RubyJS 44 in Ruby und Wt45 in C++.
Bei Verwendung eines solchen Frameworks können auch Client-Komponententests in der
Wirtssprache geschrieben werden, welche entweder im Wirtssprachen- oder JavaScript-
Interpreter laufen können46 .

2.3.2 Integrationstest
Integrationstests an Webanwendungen werden grösstenteils mit zwei verschiedenen
Ansätzen auf unterschiedlichen Ebenen der Software umgesetzt. Dabei soll festgestellt
werden, ob die möglicherweise vorher komponentengetesteten Programmteile auch als
Ganzes ihre Funktionalität erfüllen.
Um die reine Programmlogik auf dem Server zu testen, können HTTP-Anfragen simuliert
und Antworten ausgewertet werden. Ein entsprechendes Testing-Framework mimt den
Browser eines Anwenders und erlaubt dadurch, die Client-Server-Kommunikation zu
überprüfen. Dazu müssen entsprechende Anfragen formuliert und, etwas aufwändiger, die
meist als HTML-Dokumente vorliegenden Antworten auf ihre strukturelle Korrektheit
überprüft werden.

42 http://www.mozilla.org/rhino/ [7.9.2010]
43 http://code.google.com/webtoolkit/ [7.9.2010]
44 http://rubyforge.org/projects/rubyjs/ [7.9.2010]
45 http://www.webtoolkit.eu [7.9.2010]
46 http://google-web-toolkit.googlecode.com/svn/javadoc/1.5/com/google/gwt/junit/client/GWTTestCase.html

[7.9.2010]
                                                    - 14 -
Um die Clientseite einer Webanwendung testen zu können, muss zudem das Verhalten
des Browsers testbar sein. Dazu müssen externe Ressourcen eines HTML-Dokuments
wie CSS-Dateien, Bilder und JavaScript-Programme nachgeladen, die CSS-Regeln auf
die HTML-Elemente angewendet, und JavaScript ausgeführt werden.
Diese Funktionalität steckt in bestehenden Endanwender-Browsern, welche tatsächlich für
Integrationstests verwendet werden. Dabei muss der verwendete Browser von einer
programmierbaren Umgebung ferngesteuert werden.
Es existieren weitere Ansätze, in denen das Verhalten eines Browsers simuliert wird, die
Webseiten also nicht tatsächlich gerendert werden, ihr gesamtes Verhalten aber im
Hintergrund abläuft und über entsprechende Schnittstellen testbar ist.

2.3.3 Systemtest
Auf der Systemtest-Ebene werden Webauftritte meist auf nicht-funktionale Anforderungen
geprüft. So kann es nötig sein eine neue Version einer Webanwendung vor ihrer
Aufschaltung in einer fast-produktiven Umgebung einem letzten Lasttest zu unterziehen,
um sicherzugehen, dass der Produktstart reibungslos über die Bühne geht.
Eine Vielzahl weiterer Anforderungen wird in einem live-ähnlichen oder tatsächlich
produktiven Setup getestet:
• Sicherheit: Webanwendungen werden häufig ganz gezielt angegriffen, um diese
     unbenutzbar zu machen oder Informationen zu stehlen. Verbreitete Angriffsvektoren sind
     SQL-Injection und Cross-Site Scripting (XSS)47.
     Neben den Vorkehrungen die während der Sotwareentwicklung getroffen werden sollten,
     um solche Lücken zu verhindern, gibt es Analye- und Scanning-Werkzeuge, mit welchen
     Sicherheitslücken in existierenden Anwendungen gefunden werden können. So können
     mittels Fuzzing48 Fehler gefunden werden, die bei unvorhergesehenen Eingaben
     auftreten, indem zufällige Eingaben an HTTP- und HTML-Schnittstellen gesendet
     werden.
     Mit Penetrationstests49 werden mögliche Sicherheitslücken systematisch ausprobiert, um
     beispielsweise SQL-Injection-Lücken zu finden. Dies kann manuell, aber auch
     unterstützt durch grösstenteils automatisierte Werkzeuge geschehen, welche zum
     Beispiel für einen bestimmten HTTP-POST-Parameter übliche SQL-Injection-Werte
     übergeben.


47 http://www.owasp.org/index.php/OWASP_Top_Ten_Project [7.9.2010]
48 Bspw. Neystadt, 2008
49 Bspw. Wack; Tracy; Souppaya, 2003

                                              - 15 -
• Gebrauchstauglichkeit: Webanwendungen stehen heute vielfach unter hohem
     Konkurrenzdruck. Damit Benutzer einem Webauftritt loyal bleiben, muss dessen
     Bedienung effizient und zufriedenstellend sein.
     Um dies zu erreichen, ist es nötig, das Benutzerverhalten zu kennen, und die eigenen
     Webseiten entsprechend anzupassen. Ein ganzes Berufsfeld widmet sich der Thematik,
     wie Menschen vor einem Computerbildschirm eine Webseite aufnehmen und mit ihr
     interagieren. Dabei müssen Softwareentwickler, Designer und Usability-Experten
     zusammenarbeiten.
     Die Analyse der Gebrauchstauglichkeit ist vornehmlich ein manueller Vorgang. Doch es
     gibt auch Möglichkeiten, die Wirkung eines Weblayouts auf einen Probanden mit
     Gerätschaften maschinell zu erfassen.
     Alternativ können die Interaktionsflüsse auf einem Webauftritt gemessen werden,
     woraus die Wichtigkeit von Hyperlinks, Forms und Knöpfen bestimmt werden kann.
     Wenn gleichzeitig unterschiedlichen Benutzergruppen verschiedene
     Benutzeroberflächen-Versionen präsentiert werden (A-B-Test50), können die
     Auswirkungen von Layout-Änderungen statistisch gemessen werden.
• Performanzverhalten: Ein verbreitetes Problem von Webanwendungen ist die
     Überlastung der Serverressourcen bei einem Anstieg der Anfragemenge.
     Architekturbedingt ist ein Webauftritt im Normalfall der beliebigen Anzahl von
     Clientanfragen ausgeliefert. Plötzlicher oder allmählicher Popularitätsanstieg kann eine
     Webanwendung lahmlegen.
     Es ist nicht einfach, Anforderungen an die verarbeitbare Anfragemenge und an die
     Verfügbarkeit einer Serverinfrastruktur zu formulieren. So gehen auch grosse
     Webauftritte hin und wieder aufgrund einer Vielzahl von Zugriffen in die Knie.
     Gleichzeitig ist es schwierig die Anforderungen gründlich zu testen, und auch eine
     Skalierungs-Strategie bereit zu halten.
     Bei sogenannten Lasttests (Stress test)51 wird eine grosse Zahl von HTTP-Anfragen an
     den Webserver geschickt, wobei dessen Performanzverhalten und allfällige
     Flaschenhälse studiert werden können. Dabei muss allerdings beachtet werden, dass
     das tatsächliche Verhalten erwarteter Benutzer simuliert wird. Es sollten also reale
     Navigationsflüsse durchgeführt werden, mitsamt Logins, Form-Absendungen et cetera.




50   Bswp. Dixon; Enos; Brodmerkle, 2006
51   BS 7925-1
                                               - 16 -
Weitere nicht-funktionale Anforderungen an Webauftritte wie Barrierefreiheit,
Lokalisierbarkeit oder Interoperabilität52 werden teilweise getestet, setzen aber meist auch
Kenntnisse ausserhalb des IT-Bereichs voraus, und erfordern viel manuellen Testaufwand.

2.4 Praxis
Die Webentwicklung ist ein vielfältig bepflügtes Feld. Webauftritte werden von
Einzelpersonen im Wohnzimmer realisiert, während grosse Firmen gleichzeitig Content-
Management-Systeme (CMS) entwickeln und damit Millionenumsätze generieren53 .
Entsprechend heterogen sind Ansätze und Umfänglichkeiten von Webauftritt-Tests in der
Praxis.

2.4.1 Interview mit Urs Gürtler, Nextron
Urs Gürtler arbeitet seit zweieinhalb Jahren als Applikationsentwickler bei der “Nextron
Internet Team GmbH”54. Diese beschäftigt acht Mitarbeitende und erstellt seit 1996
Webauftritte wie www.mybasel.ch oder www.biovalley.ch.

Wie realisiert ihr eure Projekte normalerweise?
Gürtler: »Wir verwenden unser eigenes CMS, welches mit ColdFusion umgesetzt ist.
Dieses wird für jeden Webauftritt entsprechend angepasst und nach Bedarf mit Modulen
ergänzt.
Üblicherweise beschäftigen sich zwei Personen einige Arbeitstage mit einem Projekt.«

Wie testet ihr eure Software?
»Unser CMS wird während der iterativen Entwicklung manuell getestet. Dafür wird etwa
30% der Entwicklungszeit aufgewendet. Automatisierte Tests haben wir keine.
An den fertigen Webauftritten werden je nach Kundenansprüchen manuelle Systemtests
durchgeführt, um Anforderungen wie Sicherheit, Skalierbarkeit und Funktionalität zu
prüfen.«

Wird das Webseiten-Layout getestet?
»Der Designer, welcher die Templates für das CMS erstellt, testet die korrekte Darstellung
der Webseiten manuell in verschiedenen Browsern auf unterschiedlichen
Betriebssystemen.«




52 Bspw. Chung; Leite, 2009
53 http://www.day.com/day/en/company.html [7.9.2010]
54 http://www.nextron.ch [7.9.2010]

                                                 - 17 -
Welche Entwicklungen können Sie beobachten?
»Die Ansprüche unserer Kunden steigen, die Webauftritte werden als wie komplexer. Die
meisten wollen irgendetwas Aussergewöhnliches auf ihrer Website.«

2.4.2 Umfrage bei Webauftritt-Betreuern
Folgende vier Fragestellungen habe ich an Webauftritt-Betreuer geschickt, um
einschätzen zu können, in welchem Umfang deren Webseiten getestet werden:

 • UI Tests: Wird die korrekte visuelle Darstellung Ihrer Webseite auf
   unterschiedlichen Endnutzersystemen (Browsern, Geräten,
   Einstellungen) getestet?
   • Automatisierung: Wenn ja, geschieht dies automatisiert durch
     Software (welche)?
 • Andere Tests: Werden andere Aspekte Ihrer Webseite getestet?
   • Automatisierung: Wenn ja, geschieht dies automatisiert
     (Serverseitige Unit Tests, Clientseitige Unit Tests, Integrations
     Tests, …)?
 • Anzahl Webentwickler: Wie viele Personen sind für die Entwicklung und
   Wartung Ihrer Webseite verantwortlich?

Von 242 Anfragen sind 35 Antworten zurückgekommen. Herzlichen Dank an alle
beteiligten Personen der folgenden Webauftritte und Firmen!: www.cmsbox.com,
www.maxomedia.ch, www.iwannagothere.com, www.homegate.ch, www.amazee.com,
www.birdlife-zuerich.ch, www.dropbox.com, www.20minuten.ch, www.zdf.de,
www.skyscanner.net, www.ford.com, www.ubs.com, www.hilti.com, www.comparis.ch,
www.netcetera.ch, www.search.ch, www.autoscout24.ch, www.post.ch, www.zhaw.ch,
www.idg.ch, www.zeeyoo.com, www.hsr.ch, www.bambuser.com, www.jinni.com,
www.swisscom.com, www.bakespace.com, www.comvation.com, www.mubi.com,
www.liip.ch, www.weltwoche.ch, www.xwave.ch, www.cookstr.com, www.bs.ch,
www.rtpartner.ch, www.pornhub.com und www.tokenrock.com.

Grösse der Entwicklerteams
79% der Befragten geben an, ein Entwicklerteam mit ein bis zehn Mitarbeitenden zu
beschäftigen.




                                         - 18 -
Anzahl Webentwickler




                             1-5    6-10   11-20 21-50 51-100

Praktisch alle Befragten testen ihren Webauftritt auf die eine oder andere Art, und
überprüfen auch die korrekte Darstellung der Benutzerschnittstelle auf verschiedenen
Endnutzersystemen.

Testautomatisierung
Eine Mehrheit setzt an irgendeiner Stelle auf Testautomatisierung. Automatische
Benutzerschnittstellen-Tests verwenden hingegen nur 12% der Entwicklerteams, welche
allesamt aus 10 oder mehr Entwicklern bestehen.

                              UI Tests               Andere Tests

                         Automatisiert
                            12 %                              Manuell
                                                               37 %
                                              Automatisiert
                                Manuell          63 %
                                 88 %

Einige Entwicklerteams führen Komponententests am serverseitigen Quellcode durch.
Eine ähnlich grosse Menge führt automatisierte Systemtests durch, meist um nicht-
funktionale Anforderungen wie die Ladezeit oder Barrierefreiheit zu prüfen.

                               Getestete Entwicklungsstufen



                        9
                                                                    7
                                              4

               Komponententests       Integrationstests       Systemtests

Bei den automatisiert getesteten Anforderungen überwiegen die funktionalen knapp den
nicht-funktionalen. Eine leichte Mehrheit wird serverseitig getestet.


                                            - 19 -
Getestete Anforderungen                                           Testausführung




             11                                                          10
                                                                                           8
                               7


        Funktional Nicht-funktional                                 Serverseitig     Clientseitig

Verwendete Software
Zur Testautomatisierung werden folgende Software-Lösungen genannt: Selenium55 (4x),
Grinder56, Google Website Optimizer57 , JUnit58, NUnit59, HP SiteScope60, HP
LoadRunner61, Webtrends62 , WebAii63, IBM Rational64 und Webrat65.




55 http://seleniumhq.org [23.9.2010]
56 http://grinder.sourceforge.net [23.9.2010]
57 http://www.google.com/websiteoptimizer [23.9.2010]
58 http://www.junit.org [23.9.2010]
59 http://www.nunit.org [23.9.2010]
60 https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?

zn=bto&cp=1-11-15-25^849_4000_100__ [23.9.2010]
61 https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?

zn=bto&cp=1-11-126-17^8_4000_100__ [23.9.2010]
62 http://www.webtrends.com [23.9.2010]
63 http://www.telerik.com/products/web-testing-tools/webaii-framework-features.aspx [23.9.2010]
64 http://www.ibm.com/software/rational [23.9.2010]
65 http://github.com/brynary/webrat [23.9.2010]

                                                     - 20 -
2.5 Werkzeuge
Im Folgenden werden zehn beliebte Werkzeuge für verschiedene Aspekte des Webauftritt-
Testens vorgestellt. Damit soll ein Überblick geschaffen werden, wobei mehrere
Quellcode-Beispiele einen Einblick in die praktische Verwendung bieten.

2.5.1 Serverseitige Komponententests
Komponententests für die serverseitige Anwendungslogik können mit Frameworks der
xUnit-Familie implementiert werden. Der Extreme Programming-Mitbegründer Ron Jeffries
unterhält eine ausführliche Liste solcher Werkzeuge auf http://www.xprogramming.com/
software.htm unter dem Abschnitt “Unit Testing”.

PHPUnit (phpunit.de)
PHPUnit ist ein Komponententestframework für die Skriptsprache PHP, die sich im
Webbereich grosser Verbreitung erfreut.
Das Werkzeug dient mit einer an xUnit angelehnten Schnittstelle als Komponententest-
Framework, und berichtet über die Resultate von durchgelaufenen Tests, beispielsweise
mit Testabdeckungs-Berichten.
Im Folgenden ein beispielhafter Testfall “LoginLogout” mit den zwei Testmethoden
“testLogin()” und “testLogout()”. Die Methoden “setUp()” und “tearDown()” werden vom
Test-Framework vor beziehungsweise nach dem Abarbeiten der Testmethoden eines
Testfalls ausgeführt. Im Beispiel erstellt “setUp()” mittels einer externen Hilfsklasse ein
Benutzerobjekt, und “tearDown()” stellt die verwendete Datenbank zum Schluss des
Testfalls wieder auf den Ursprungszustand zurück.




                                             - 21 -
class LoginLogoutTest extends PHPUnit_Framework_TestCase {
 !
 !   public function setUp() {
 !   !      TestHelperFunctions::createTestUser();
 !   }

 !        public function tearDown() {
 !        !      TestHelperFunctions::clearDb();
 !        }

          public    function testLogin() {
 !        !         $this->assertTrue(
 !        !         !    LoginLogout::login('username', 'password'),
 !        !         !    'Login failed');
 !        }
 !
 !        public    function testLogout() {
 !        !         LoginLogout::logout();
 !        !         $this->assertNull(
 !        !         !    My_Session::getUserId(),
 !        !         !    'Logout did not clear session');
          }
 !
 }

Die mit “assert” beginnenden Methoden sind die eigentlichen Schnittstellen zum Test-
Framework. Mit ihnen wird überprüft, ob eine Variable (in diesem Fall der Rückgabewert
einer Methode) die geforderten Bedingungen erfüllt. So schlägt “assertTrue()” Alarm, wenn
der erste Parameter nicht true ist.
PHPUnit kann in phpUnderControl66,
eine Erweiterung für den
kontinuierlichen Integrationsserver
CruiseControl 67, integriert werden.
Damit kann die kontinuierliche
Ausführung eines
Erstellungsprozesses mit dem
Durchlaufen von Komponententests
                                                       Abb. 6: Testabdeckung mit phpUnderControl
verknüpft werden. Entwickler erhalten
auf diese Weise zügig Rückmeldungen über allfällig fehlschlagende Tests im
Gesamtprodukt.




66   http://phpundercontrol.org [7.9.2010]
67   http://cruisecontrol.sourceforge.net [7.9.2010]
                                                        - 22 -
2.5.2 JavaScript Komponententests
Mit dem Siegeszug von JavaScript als clientseitige Web-Programmiersprache 68 steigt das
Bedürfnis nach JavaScript-Komponententests. In einem Browser laufend stellt dabei
insbesondere die automatisierte Ausführung und Analyse der Tests eine Herausforderung
dar.

FireUnit (fireunit.org)
FireUnit bietet Komponententest-Schnittstellen in JavaScript an und stellt Ergebnisse in
der Mozilla Firefox-Webentwicklungs-Erweiterung Firebug an. Ursprünglich für die
Entwicklung von Firefox-Erweiterungen erdacht69 , kann FireUnit auch für das Testen von
Webauftritten verwendet werden.
Die Software bietet einige Methoden zur Simulation von Benutzereingaben an, und enthält
grundlegende xUnit-Schnittstellen:

 fireunit.ok(true, "This should pass");
 fireunit.ok(false, "This should fail");

 fireunit.compare("This is expected", "This isn't expected",
 !   "Texts differ");

Die Testsergebnisse werden in Firebug tabellarisch aufgeführt:




 Abb. 7: FireUnit-Ergebnisse in Firebug




68   Crockford, 2008
69   http://www.softwareishard.com/blog/firebug/fireunit-testing-in-the-firebug-world/ [7.9.2010]

                                                      - 23 -
QUnit (docs.jquery.com/Qunit)
Die Funktionalität des JavaScript-Frameworks jQuery wird durch QUnit-Komponententests
geprüft71 . QUnit kann aber ebenfalls für das Testen beliebiger JavaScript Anwendungen
verwendet werden. Als Assertions stehen ok(), equals() und same() zur Verfügung:

 test("A basic test example", function() {
 !   ok(true, "This should pass");
 !   ok(false, "This should fail");

 !   equals("This is expected", "This isn't expected",
 !   !      "Texts differ");
 });

Die Resultate werden direkt im getesteten HTML-Dokument angezeigt, was bedeutet,
dass das Framework browserübergreifend verwendet werden kann:




      Abb. 8: QUnits Ergebnisanzeige

2.5.3 HTTP Integrationstests
Beim Einsatz spezieller HTTP-Dienste wie Reverse Proxys oder gar selbst entwickelten
HTTP-Servern kann es nötig sein, die HTTP-Kommunikation zu testen.

HTTest (htt.sourceforge.net)
Das in C entwickelte Test-Framework HTTest kann durch eine simple Skriptsprache
gesteuert HTTP-Clients und -Server simulieren, wobei die stattfindende Kommunikation
mit Bedingungen überprüft wird. Zusätzlich können Eingaben mit externen
Programmaufrufen generiert und Ausgaben an solche weitergeleitet werden.
Folgendes Skript ruft eine nicht vorhandene Datei auf dem “sbb.ch”-Server auf und
überprüft, ob eine 404-Antwort zurückkommt:

 CLIENT
 _REQ sbb.ch 80
 __GET /doesnotexist HTTP/1.1
 __Host: sbb.ch
 __
 _EXPECT . "HTTP/1.1 404 Not Found"
 _WAIT
 END

                                          - 24 -
Während der Ausführung der Befehle zeigt HTTest die gesamte HTTP-Kommunikation auf
der Standardausgabe an.

2.5.4 Browser Integrationstests
Neben der Client-Server-Kommunikation auf HTTP-Ebene, also im OSI-
Schichtenmodell71 , sollen vielfach auch die darauf aufbauenden Inhalte getestet werden.
Diese konkreten Anwendungsinhalte liegen beispielsweise strukturiert als HTML-
Dokumente vor.
Eine strukturelle Analyse bietet sich an, um Bedingungen an diese Inhalte zu formulieren.
Dazu muss im Allgemeinen die Syntaxanalyse eines Browsers nachempfunden werden,
um anschliessend die entstandenen Datenstrukturen zu überprüfen.

HtmlUnit (htmlunit.sourceforge.net)
HtmlUnit ist ein in Java implementierter Webbrowser ohne grafische Benutzerschnittstelle.
Die Software kann wie ein klassischer Browser Webseiten laden, CSS anwenden und
JavaScript ausführen. Die resultierenden Webseiten werden jedoch nicht auf den
Bildschirm gerendert, sondern stehen über Java-Schnittstellen zur Verfügung. Die
angebotene API erinnert stark an die übliche Verwendungsweise eines Browsers. So
können Forms ausgefüllt und Links verfolgt werden. Gleichzeitig können via Document
Object Model (DOM)72 an die Dokumentenstruktur gestellte Bedingungen überprüft
werden.
Im folgenden Beispiel soll in einem JUnit-Testfall in Kombination mit HtmlUnit die Referenz
eines Hyperlinks (“href”) auf der Indexdatei des “sbb.ch”-Servers geprüft werden:

 public class SbbTest extends TestCase {

 !       public    void testCargo() throws Exception {
 !       !         WebClient client = new WebClient(BrowserVersion.FIREFOX_3);
 !       !         HtmlPage page =! client.getPage("http://www.sbb.ch");
 !       !         HtmlAnchor anchor = page.getAnchorByText("Cargo");
 !       !         assertEquals(anchor.getHrefAttribute(),
 !       !         !    !     !     "http://www.sbbcargo.com");
 !       }

 }

Dabei wird zuerst eine Browser-Instanz erstellt (“WebClient”), wobei hier ein “Firefox 3”
simuliert werden soll. Nachdem die gewünschte Webseite geladen ist, wird mittles



71   Open Systems Interconnection model, ISO-Schichtenmodell von Kommunikationsprotokollen
72   Schnittstellenspezifikation für den HTML- und XML-Zugriff
                                                    - 25 -
“getAnchorByText()” auf einen spezifischen Hyperlink in der HTML-Struktur zugegriffen,
dessen “href”-Attribut mit einer Bedingung geprüft wird.
Als Browser-Simulation wird HtmlUnit in verschiedensten Test-Frameworks verwendet.
Gerade weil keine GUI verwendet wird, lässt sich HtmlUnit verlässlich automatisiert
steuern. Die Funktionalität der Software hinkt dafür den realen Browserversionen
hinterher, speziell der JavaScript-Funktionsumfang, welcher auf Mozillas Rhino basiert.

Selenium (seleniumhq.org)
Selenium ist ein vielseitiges Integrationstest-Framework fürs Web. Es umfasst einerseits
eine Firefox-Erweiterung, die das
Aufzeichnen und Abspielen von
Testszenarien erlaubt (Selenium
IDE) und andererseits ein System
für die automatisierte Kontrolle von
Webbrowsern mittels Schnittstellen
(Selenium Remote Control [RC]).
Selenium RC besteht aus einem
Server, der Browser öffnet, schliesst
und ihnen als Proxy dient. Mit Hilfe
dieses Proxys kann in Echtzeit
JavaScript in eine geladene
Webseite eingeschleust werden.
Über Schnittstellen, die für            Abb. 8: Selenium RC
verschiedene Programmiersprachen
zur Verfügung stehen, wird dieser “Remote Control Server” kontrolliert.
Durch eigenständige Programme, oder mittels einem xUnit-Framework können damit in
Java, Python, Ruby, C#, Perl oder PHP die Browser Firefox, Internet Explorer, Safari
sowie Chrome ferngesteuert werden.
Beispielhaft wird mit Java erneut das “href”-Attribut eines Links auf “sbb.ch” geprüft:




                                            - 26 -
public class SbbTest extends SeleneseTestCase {
 !
 !   public void setUp() throws Exception {
 !   !      setUp("http://www.sbb.ch/", "*firefox");
 !   }

 !        public   void testCargo() throws Exception {
 !        !        selenium.open("/");
 !        !        String cargoHref =
 !        !        !    selenium.getAttribute("//a[text()='Cargo']@href");
 !        !        assertEquals(cargoHref, "http://www.sbbcargo.com");
 !        }
 !
 }

Der Testfall erbt im Unterschied zu HtmlUnit nicht direkt von JUnits TestCase, sondern
von einer davon abgeleitete Klasse SeleneseTestCase. Damit werden im Testfall
verschiedene Selenium-Methoden verfügbar.
Ausserdem startet Selenium RC anstelle einer Browsersimulation eine richtige Firefox-
Instanz, in welcher die “sbb.ch”-Webseite geladen wird, um anschliessend per XPath auf
das “href”-Attribut zuzugreifen.
Um Selenium-Tests schneller und auf mehreren Betriebssystemen gleichzeitig laufen zu
lassen, wird Selenium Grid angeboten. Damit können in einem Testset Selenium RC-
Instanzen auf verschiedenen Rechnern angesprochen werden. Um vom
Geschwindigkeitsvorteil zu profitieren, müssen Tests parallel ablaufen - für JUnit
verwendet man beispielsweise Parallel JUnit73 , welches Testfälle in Threads ausführt.


Um die Verwirrung komplett zu machen, wird im Moment an Selenium 2 gearbeitet, eine
Verschmelzung von Selenium und WebDriver (deshalb auch Selenium WebDriver
genannt).
WebDriver ist ein ursprünglich von Google veröffentlichtes74 Projekt, mit dem ebenfalls
verschiedenste Webbrowser automatisch gesteuert werden können. Anstatt dies mittels
JavaScript zu lösen, werden aber höherschichtige Ansätze verwendet, die spezifisch auf
den jeweiligen Browser angepasst sind. So wird beispielsweise Firefox über eine Firefox-
Erweiterung gesteuert.
Mit der Verwendung von WebDriver können in Selenium 2 Tests in realen Browsern
zügiger und verlässlicher ausgeführt werden.



73   https://parallel-junit.dev.java.net [7.9.2010]
74   http://google-opensource.blogspot.com/2009/05/introducing-webdriver.html [7.9.2010]
                                                    - 27 -
Rund um Selenium
Im Folgenden eine Auswahl an Test-Software aus dem Selenium-Umfeld.
• Sahi (sahi.co.in) basiert ähnlich wie Selenium 1 auf einem Proxy-Server, der im Browser
     eingetragen wird und diesem JavaScript-Befehle unterschiebt. Durch die
     Implementierung des Servers in Java ist Sahi browser- und betriebssystemunabhängig.
     Die Tests selbst werden mit Methoden wie _click() und _div() in JavaScript
     entwickelt.
• Watir (watir.com) ist ein in Ruby geschriebenes Framework, das ähnlich wie WebDriver
     über verschiedene Betriebssystem- und Applikationsschnittstellen einen Webbrowser
     kontrolliert. So wird beispielsweise der Internet Explorer über COM75-Schnittstellen
     angesprochen.
     Es existieren einige von Watir inspirierte Test-Frameworks in anderen
     Programmiersprachen: WatiN 76 in C#, Watij77 in Java, oder das Perl-Modul
     Win32::Watir78 .
• CubicTest (http://cubictest.seleniumhq.org) ist eine Eclipse79-Erweiterung, die es erlaubt
     Webseiten-Tests mit einer GUI als Flussdiagramm zusammenzuklicken. Ganze
     Benutzergeschichten können mit pfeilartigen Verbindungen zwischen Kästchen für
     Klicks, Text-Eingaben und Bedingungen zusammengestellt werden. Die fertigen Tests
     werden durch Selenium oder Watir ausgeführt.

2.5.5 Last Systemtests
Auch für nicht-funktionale Anforderungen kann es nötig sein Tests zu automatisieren. Mit
Lasttests soll geprüft werden, wie sich eine Webanwendung bei vielen Anfragen verhält.
Je nach verwendeter Technik gibt es dutzende mögliche Flaschenhälse. Um diese zu
erkennen und zu analysieren, muss auf dem entsprechenden System hohe Last simuliert
werden.

p-unit (p-unit.sourceforge.net)
Das seit zwei Jahren nicht mehr weiterentwickelte Benchmarking-Framework p-unit bietet
simple Java-Schnittstellen an, um die Laufzeit und den Speicherbedarf von ausgeführtem
Java-Code zu messen.




75 Component Object Model, Interprozesskommunikation unter Windows
76 http://watin.sourceforge.net [7.9.2010]
77 http://watij.com [7.9.2010]
78 http://search.cpan.org/dist/Win32-Watir/ [7.9.2010]
79 http://www.eclipse.org [7.9.2010]

                                                     - 28 -
Mit einem solchen Werkzeug kann beispielsweise die Ausführungszeit der
Anwendungslogik einer Webanwendung gemessen werden. Dabei kann das Lastverhalten
von Datenbankanfragen, der Dateizugriff oder die Ausführung von externen Skripten
Objekt von Interesse sein.
Folgendes Beispiel misst den Zeitbedarf für das Berechnen aller Quadratwurzeln zwischen
1 und 500ʼ000ʼ000 mit Math.sqrt():

 public class SqrtTest {

 !    public static void main(String[] args) {
 !    !      new SoloRunner().run(SqrtTest.class);
 !    }

 !    public   void test500mio() {
 !    !        for (long i=1; i<=500000000.0; i++) {
 !    !        !    Math.sqrt(i);
 !    !        }
 !    }
 !
 }

Das Ergebnis wird auf die Konsole ausgegeben:

 test10mio() - [1211.751ms]

Es können auch Grafiken und PDF-Reporte generiert werden.

ApacheBench (httpd.apache.org/docs/2.2/programs/ab.html)
ApacheBench (ab) ist Teil des Apache HTTP Servers und dient dazu die Antwortzeiten
eines Webservers zu messen.
Das Kommandozeilen-Werkzeug kann über Parameter dazu aufgefordert werden, eine
bestimmte Anzahl an HTTP-Anfragen gleichzeitig und wiederholt an einen Server zu
schicken, und schlussendlich über die Antwortzeiten zu berichten. Ein solcher Bericht
enthält unter Anderem den Zeitbedarf verschiedener Phasen der HTTP-Kommunikation:

 Connection Times (ms)
               min mean[+/-sd] median               max
 Connect:       23   35 11.7     30                  55
 Processing:   166 181 10.0     180                 194
 Waiting:       40   50  6.2     51                  59
 Total:        201 215 13.2     216                 244

Sofern das Performanzverhalten der Anwendungslogik auf dem Server getestet wird, sollte
darauf geachtet werden, dass ab auf dem gleichen Rechner wie der HTTP Server läuft,
um ohne den Flaschenhals Netzwerk viel Last erzeugen zu können.

                                           - 29 -
2.5.6 Sicherheit Systemtests
Es gibt eine Menge an kommerziellen und quelloffenen Sicherheits-Werkzeugen für
Webanwendungen. Die meisten nennen sich Scanner und versuchen semi-automatisiert
nach Schwachstellen wie SQL-Injection-Lücken zu suchen. Ein ausführliche Liste an
Programmen wird vom Web Application Security Consortium (WASC) unterhalten: http://
projects.webappsec.org/Web-Application-Security-Scanner-List.
Im Folgenden werden zwei solche Werkzeuge kurz vorgestellt.

Skipfish (code.google.com/p/skipfish)
Das von Google initiierte Skipfish ist ein klassischer Sicherheits-Scanner. Google selbst
nennt es auch ein Erkundungs-Werkzeug. Herausragend ist vor allem die Performanz der
Software. Eine schnelle HTTP-Implementierung in C soll bis zu 7000 Anfragen pro
Sekunde an einen lokalen Server ermöglichen80 .
Die Software sucht nach SQL-Injection-, XSS- und Pufferüberlauf-Lücken, aber auch nach
weniger dramatischen Fehlern wie falschen MIME-Typen oder HTTP-Statuscodes.
Die Erkundungs-Ergebnisse werden in einer interaktiv navigierbaren HTML-Seite
präsentiert.

w3af (w3af.org)
Das Web Application Attack and Audit Framework (w3af) ist ein Sicherheits-Scanner für
Webanwendungen, der inzwischen von Rapid781 gesponsert wird - eine Sicherheitsfirma
die 200982 das Penetrationstest-Framework Metasploit83 gekauft hat.
Über eine Plugin-Infrastruktur verwaltet w3af die verfügbaren Scantaktiken. Grössere
Plugin-Kategorien sind “evasion” zum Umgehen von Intrusion Detection Systemen 84,
“grep” zum generellen Durchsuchen von HTTP-Antworten beispielsweise auf IP-Adressen,
oder Kreditkartennummern und “audit” zum eigentlichen Prüfen auf Sicherheitslücken.
Dabei werden die üblichen Verdächtigen wie XSS-, SQL-Injection-, XPath-Injection- oder
Dateiupload-Lücken erkannt.




80 http://code.google.com/p/skipfish/wiki/SkipfishDoc [7.9.2010]
81 http://www.rapid7.com [7.9.2010]
82 http://www.rapid7.com/metasploit-announcement.jsp [7.9.2010]
83 http://www.metasploit.com [7.9.2010]
84 System zur Erkennung von Angriffen und Einbrüchen in Computersysteme

                                                   - 30 -
3. Webseiten Layout-Testen: Screencompare
3.1 Problem
Etliche Faktoren machen es unter gewissen Umständen wünschenswert, die clientseitige
Präsentation einer Webanwendung auf visueller Ebene zu überprüfen, und diesen
Prozess zu automatisieren.

3.1.1 Diversifizierte Client-Landschaft
Die Darstellung und Ausführung von Webanwendungs-Benutzerschnittstellen wird durch
eine Vielzahl von Webbrowsern übernommen. Deren Interpretierung von HTML-, CSS-
und JavaScript-Anweisungen entscheidet darüber, wie ein Anwender die Webseiten zu
Gesicht bekommt.
Es gibt seit jeher Bestrebungen, Webtechnologien über Browsergrenzen hinweg zu
standardisieren. Die wohl einflussreichste Organisation diesbezüglich ist das World Wide
Web Consortium (W3C)85, welches Standardisierungsdokumente zu HTML, XHTML, CSS,
DOM, CGI und vielen weiteren Technologien veröffentlicht. Der ECMAScript-Dialekt
JavaScript wird hingegen von der Ecma International86 standardisiert.
Verschiedene Faktoren führen aber auch heute noch zu schlechter Interoperabilität
zwischen Browsern verschiedener Hersteller. Einerseits werden die Standards
unvollständig oder fehlerhaft umgesetzt, andererseits werden browserspezifische
Funktionalitäten eingeführt, da die Standards beispielsweise als unvollständig erachtet
werden87.
Dies führt dazu, dass bei der Entwicklung von Webauftritten darauf geachtet werden
muss, dass die Benutzerschnittstelle des Produkts bei den Endanwendern auch wirklich
so aussieht und funktioniert wie erdacht. Es hat sich eingebürgert vor dem Produktstart
einer Webanwendung die Benutzerschnittstelle in mindestens zwei bis drei verschiedenen
Webbrowsern einem Abnahmetest zu unterziehen.
Der Grossteil eingesetzter Browser wird von fünf verschiedenen Unternehmen entwickelt
oder getragen, namentlich Microsoft (Internet Explorer), Mozilla (Firefox), Google
(Chrome), Apple (Safari) und Opera. Das kalifornische Webanalyse-Unternehmen Net
Applications88 sammelt Benutzerinformationen von nach eigenen Angaben 160 Millionen



85 http://www.w3.org [7.9.2010]
86 http://www.ecma-international.org [7.9.2010]
87 Bspw. Internet Explorer box model Fehler, "-moz-*", "-ms-*" oder "-webkit-*" CSS-Eigenschaften
88 http://www.netapplications.com [7.9.2010]



                                                   - 31 -
Webauftritt-Besuchern im Monat89. Anhand dieser öffentlich zugänglichen Daten setzt sich
der Browser-Markt im Mai 2010 wie folgt zusammen:

                             Webbrowser                        Layout-Engines
                                (Andere)
                             Opera                          Presto(Andere)
                                                                   (Opera)
                          Safari           IE6
                                                 WebKit (Safari+Chrome)
                  Chrome                                                         Trident (IE6+7)



                                                 IE7


                Firefox                          Gecko (Firefox)




                      IE8 comp. mode       IE8                            Trident 4 (IE8)


Das erste Diagramm unterscheidet zwischen Browser-Namen und beim Internet Explorer
auch -Versionen. Das Zweite zeigt verschiedene sogenannte Layout-Engines, also die
einem Browser zugrundeliegende Software, welche für das HTML-Rendering zuständig
ist.
Die Zahlen belegen, dass eine Menge verschiedener Web-Clients verwendet wird. Auch
der durch seine eigenwillige Interpretation von Webstandards bei Entwicklern verachtete90
Internet Explorer 6 hat neun Jahre nach seiner Einführung noch einen beachtlichen
Marktanteil.
Auch die neusten Versionen von Browsern machen Entwicklern in mancher Hinsicht das
Leben schwer. Dies ist mehrheitlich darauf zurückzuführen, dass sich die verwendeten
Technologien rasant weiterentwickeln. So befinden sich zur Zeit die viel gelobten
Standards HTML5 und CSS 3 in Entwicklung. Im Rennen um gewiefte
Benutzerschnittstellen für Webanwendungen werden Vorabversionen und eigene
Interpretationen dieser Technologien implementiert, wodurch Webauftritte wieder in den
verschiedenen Browsern getestet werden müssen.

3.1.2 Pixelgenaues Design
Es ist umstritten, wie sehr sich das Layout von Webseiten in verschiedenen Browsern
unterscheiden darf91 . Vielfach macht es Sinn, nur einige Design-Bausteine genau zu
definieren, und diese in ein loses, mehrheitlich durch seine Struktur beschriebenes HTML-
Dokument einzubetten. Dadurch gewinnt der Anwender gewisse Freiheiten, indem er die


89 http://www.netmarketshare.com [7.9.2010]
90 http://www.bringdownie6.com [7.9.2010]
91 Bspw. http://boagworld.com/technology/effective-browser-support [23.9.2010]

                                                   - 32 -
Präsentation einer Webseite an eigene Bedürfnisse anpassen kann. Gleichzeitig wird das
Design dadurch eher Inhaltsagnostisch, verträgt sich also mit aller Art von textuellen und
multimedialen Inhalten.
Trotzdem kann es eine Anforderung sein,
gewisse Design-Elemente oder ganze
Webseiten pixelgenau zu implementieren. Meist
werden solche Designs in einem
Bildbearbeitungs- oder Layoutprogramm
entworfen, und müssen dann mittels HTML und
CSS mit möglichst allen gängigen Browsern
kompatibel umgesetzt werden.
Solche pixelgenauen Designs sind vielfach
bildlastig, werden aber vemehrt auch HTML-
Markup und CSS gestützt implementiert.                  Abb. 9: CSS-Aufklappmenüs können
                                                        Pixelgenauigkeit benötigen
Dadurch wird es meist schwieriger eine korrekte
Wiedergabe über Browsergrenzen hinweg zu erreichen.

3.1.3 Bedarf nach visuellem Layout-Testen
Obig genannte Umstände führen dazu, dass die Präsentation gewisser Webseiten in
verschiedenen Browsern mit einer Referenz verglichen wird. Dabei sind üblicherweise
kleine Unterschiede wie beispielsweise in der Schrift-Darstellungen hinnehmbar, an
anderen Stellen wird allerdings Pixelgenauigkeit gefodert.
Zur Überprüfung kann zum Beispiel eine Referenz über den Browser überlagert werden.

Smile Designer Smile (9elements.com/io/?page_id=54)
Smile Designer Smile ist ein Plugin für das JavaScript-Framework
jQuery. Mit ihm kann ein Entwickler mit einigen Zeilen Quellcode
eine Bilddatei über eine Webseite im Browser legen. Diese liegt
dann halbdurchsichtig und mit der Maus verschiebbar als
Referenz über der Webseite.

Pixel Perfect (pixelperfectplugin.com)
Die fast identische Funktionalität bietet Pixel Perfect. Als Firefox-
Firebug-Plugin ist es allerdings ohne Programmieraufwand                Abb. 10: Referenz-
                                                                        Überlagerung
einsetzbar und bietet mit einer einfachen GUI etwas mehr Komfort.
Allerdings ist es nur in Firefox verwendbar.


                                               - 33 -
Das Überlagern einer Bilddatei vereinfacht das Überprüfen der visuellen Präsentation von
Webseiten, ist aber ein manueller Prozess.
Bei komplexen Webanwendungen wird üblicherweise versucht server- wie auch
clientseitigen Quellcode für mehrere Webseiten wiederzuverwenden. Dadurch wird
einerseits Code-Duplizierung verhindert, was die Wart-, Test- und Erweiterbarkeit
verbessert. Andererseits können dadurch clientseitige Hilfsdokumente wie CSS-Dateien
wiederverwendet werden, so dass sich die Übertragungszeiten von Webseiten verkürzen.
Die dadurch entstehenden Abhängigkeiten innerhalb der Anwendung haben zur Folge,
dass sich kleine Änderungen in einzelnen Quell-Dateien vielfach auf grosse Teile der
Software auswirken. In Verbindung mit einer grossen Anzahl unterschiedlicher Webseiten
eines Webauftritts wird das zu einem Problem: Änderung eines Enwicklers an einer
einzelnen Webseite können ungewollt Auswirkungen auf andere Webseiten haben, welche
nur mit grossem Aufwand manuell zu entdecken sind.
Eine solche Nebenwirkung einer Softwareänderung wird Regression, das Überprüfen auf
solche Unannehmlichkeiten Regressionstest92 genannt. Weil diese Tests bei möglichst
jeder Code-Änderung durchgeführt werden sollten, ist es sinnvoll sie zu automatisieren.
Für Web-Benutzerschnittstellen gilt das genauso wie für die Anwendungslogik.
Beispielsweise kann die Änderung einer einzelnen CSS-Regel das Aussehen eines
ganzen Webauftritts verändern, und damit unter Umständen in nur einer von hunderten
Webseiten einen Layout-Fehler hervorrufen.
In solchen Fälle sind automatisierte Regressionstests des Layouts wünschenswert.

3.2 Lösungsansatz
Als Ansatz für visuelle Layouttests stelle ich eine automatisierte Variante von Referenz-
Überlagerung auf Webseiten vor. Eine konkrete Implementierung in Java nenne ich
Screencompare. Dabei sind folgende Anforderungen relevant:
• Browserübergreifend: Es sollen die Render-Ergebnisse verschiedener Browser prüfbar
     sein, um deren Eigenheiten testbar zu machen.
• Selektiv: Nicht immer muss das Layout einer ganze Webseite pixelgenau geprüft
     werden, es müssen auch Ausschnitte vergleichbar sein.
• JavaScript-kompatibel: Um JavaScript-lastige Webseiten zu testen, sollen vor der
     Referenz-Überlagerung JavaScript-Anweisungen ausgeführt werden können.
• Regressionstest-kompatibel: Damit verschiedene Versionen eines Webauftritts
     verglichen werden können, müssen Render-Ergebnisse speicherbar sein.

92   BS 7925-1
                                             - 34 -
• Automatisiert: Der visuelle Vergleich soll automatisiert stattfinden.
Grundlegend funktioniert das Ganze analog einer manuellen Referenz-Überlagerung. Es
wird also eine Bilddatei (Referenz) mit dem Render-Ergebnis eines Browsers verglichen.




Um eine Webseite automatisiert zu laden und eventuelles JavaScript auszuführen muss
das Test-Framework den Browser steuern können. Dabei soll die existierende
Funktionalität von Selenium verwendet werden (es kämen aber auch andere Produkte in
Frage, siehe Kapitel 2.5.4). Der Einfachheit halber wird nur der Viewport, also der
sichtbare Teil einer Webseite im Browser, mit der Referenz verglichen.
Der eigentliche Vergleich von Referenz und Rendering findet automatisiert mittels eines
Pixelvergleichs statt.

3.3 Funktionsweise
3.3.1 Testablauf
Screencompare vergleicht Bilder des Viewports eines Webbrowsers. Dazu wird der zu
verwendende Browser per Selenium ferngesteuert, um danach aus einem Screenshot des
ganzen Bildschirms den eigentlichen Viewport zu extrahieren. Die Erkennung des
Viewports auf dem Screenshot geschieht mittels farbbasierter Bildfreistellung, indem vor
jedem Test eine rein grüne Webseite im Browser angezeigt wird.




Obige Bildreihe stellt diesen Vorgang dar. Nachdem der Webbrowser gestartet ist, wird der
Hintergrund der Webseite mittels JavaScript grün eingefärbt. Dabei wird zusätzlich
sichergestellt, dass das Browserfenster in maximaler Grösse dargestellt wird und


                                            - 35 -
vollständig sichtbar ist. Screencompare macht einen Screenshot und erkennt anhand der
grünen Fläche die Position und Grösse des Viewports.




Danach werden die eigentlichen Webseiten aufgerufen, welche getestet werden sollen. Da
die Viewport-Position nun bekannt ist, kann aus einem Screenshot direkt der Viewport mit
der angezeigten Webseite extrahiert werden.
Zum Vergleich der aufgenommenen Webseiten-Bilder stehen einige Methoden zur
Verfügung, welche auf unterschiedliche Weise deren Differenz berechnen und ausgeben.


Das Framework ist darauf ausgelegt, in einem JUnit-ähnlichen Komponententest
verwendet zu werden. Dazu wird JUnits TestCase als ScreencompareTestCase erweitert.
Neben den gängigen JUnit-Methoden
steht darin Funktionalität für die
Browser-Steuerung, die Viewport-
Aufnahme und für den Viewport-
Vergleich zur Verfügung.
ScreencompareTestCase verwendet
einen “Treiber”, welcher die
Fernsteuerung des Browsers
übernimmt. Im Normalfall wird
Selenium RC verwendet, allerdings
steht auch eine Implementierung für
Selenium WebDriver zur Verfügung.
Ausserdem können eigene Treiber als
Implementierung der abstrakten          Abb. 11: Funktionsprinzip Screencompare
Klasse Driver geschrieben werden.




Die beiden Selenium-Treiber unterstützen zum jetztigen Zeitpunkt folgende Browser:
                                          - 36 -
Remote Control   Remote Control   WebDriver       WebDriver
                             (Windows)        (Mac OS X)     (Windows)       (Mac OS X)

 Google Chrome                    ✔                   ✔         ✔                ✔

 Firefox                          ✔                   ✔         ✔                ✔

 Internet Explorer                ✔                   ✗         ✔                ✗

 Safari                           ✔                   ✔          ✗               ✗

Screencompare läuft derzeit auf Windows und Mac OS X. Betriebssystem-abhängiger
Code wird benötigt, um sicherzustellen, dass der Browser im Fenstersystem für den
Screenshot sichtbar ist. Dies wird entweder mit AppleScript oder einer kleinen C++-MFC-
Anwendung erledigt.

3.3.2 Verwendung
Zur sinnvollen Auswertung aufgenommener Viewport-Bilder stehen in
ScreencompareTestCase einige öffentliche Methoden zur Verfügung. Im Folgenden wird
auf diese Funktionalität anhand von Beispielen eingegangen.
Grundlegend empfiehlt es sich, einen von ScreencompareTestCase erbenden Testfall zu
erstellen:

 public class ExampleTest extends ScreencompareTestCase {

 !        public   void test() throws Exception {
 !        !        start("http://www.google.ch", Browser.FIREFOX);
 !        !        captureScreen().save();
 !        !        stop();
 !        }

 }

Viewport-Aufnahmen werden jeweils von start() und stop() umrahmt. Damit wird der
entsprechende Browser mit der im Argument übergebenen URL geöffnet,
beziehungsweise wieder geschlossen. Die Methode captureScreen() fängt die
angezeigte Webseite ein und gibt eine Instanz der Klasse Screen zurück. Diese hält
neben dem eigentlich Bild auch Metainformationen wie die URL, den verwendeten
Browser und den Namen des entsprechenden Komponententests.
Während ein Browser geöffnet ist stehen unter Anderem folgende Methoden zur
Verfügung:
• js(String javascript): Führt übergebenes JavaScript aus.
• setBackground(Color color): Setzt die Seiten-Hintergrundfarbe. Nützlich für eigene
 farbbasierte Bildfreistellung.
                                             - 37 -
• hideElement(String elementId): Versteckt ein Element, um beispielsweise Werbebanner
 vom Bildvergleich auszunehmen.
• hideText(): Versteckt alle Textstellen einer Seite, um das rein graphische Layout einer
 Seite zu prüfen.
• waitElementVisible(String elementId): Unterbricht die Programmausführung, bis das
 entsprechende Element sichtbar ist. Dies kann nützlich sein, wenn vor der Viewport-
 Aufnahme beispielsweise auf eine AJAX-Antwort gewartet werden soll.
Zur tatsächlichen Auswertung von Bedingungen steht beispielsweise verifySame() zur
Verfügung, welches zwei Screens vergleicht. Im folgenden Beispiel wird das Render-
Ergebnis zweier Webseiten im Internet Explorer und Firefox verglichen:

 public class CompareFirefoxIETest extends ScreencompareTestCase {

 !    public void test() throws Exception {
 !    !      String[] urls = {"http://www.google.ch",
 !    !      !    !     !    "http://weatherflash.com/"};

 !    !        for (String url:urls) {
 !    !        !    start(url, Browser.FIREFOX);
 !    !        !    Screen firefox = captureScreen();
 !    !        !    stop();
 !    !        !
 !    !        !    start(url, Browser.IE);
 !    !        !    Screen ie = captureScreen();
 !    !        !    stop();
 !    !        !
 !    !        !    verifySame(firefox, ie, 0.05f, Alignment.TOP_CENTER);
 !    !        }
 !    }

 }

Dabei wird verifySame() neben den beiden Screens ein Schwellenwert für
Bildunterschiede und eine Ausrichtungs-Anweisung übergeben. Die beiden Aufnahmen
werden im Beispiel mittig oben übereinandergelegt, wobei eine Ausnahmesituation
(Exception) ausgelöst wird, sobald mehr als 5% der Pixel Unterschiede aufweisen.
Falls dieser Schwellenwert überschritten wird, und der Testfall entsprechend fehlschlägt,
wird zusätzlich ein PDF-Report generiert, anhand von dem später untersucht werden
kann, wieso der Testfall fehlschlug.




                                            - 38 -
Abb. 12: PDF-Report mit Firefox- und IE6-Screen sowie deren Differenz

Anhand eines weiteren Beispiels soll erläutert werden, wie Elemente auf einer Seite vor
der Viewport-Aufnahme versteckt werden können. Dies kann nützlich sein, wenn eine
Seite beispielsweise Werbebanner enthält, welche aber nicht Teil des Tests sein sollen.

 public class HideTest extends ScreencompareTestCase {

 !   public   void test() throws Exception {
 !   !        start("http://photography.nationalgeographic.com/photo-of-
 the-day/",   Browser.FIREFOX);
 !   !        captureScreen().save("nationalgeographic-1.png");
 !   !        hideElement("headerboard");
 !   !        captureScreen().save("nationalgeographic-2.png");
 !   !        hideText();
 !   !        captureScreen().save("nationalgeographic-3.png");
 !   !        stop();
 !   }

 }

Im Beispiel wird mittels hideElement() das “headerboard” einer National Geographic-
Webseite entfernt, welches einen Werbebanner enthält.
In einem zweiten Schritt versteckt hideText() alle Textstellen auf der Seite. Da
Schriftzeichen in verschiedenen Browsern vielfach verschieden angezeigt werden, kann
es wünschenswert sein, diese vor einem Referenzvergleich auszublenden.
Nach jedem Zwischenschritt wird der Screen abgespeichert:




In kurzen Entwicklungszyklen aktualisierte Webauftritte erfordern besondere Wachsamkeit
bezüglich der korrekten Darstellung im Webbrowser. Eine überschaubare Änderung am
Quellcode einer Webanwendung kann Render-Probleme in einzelnen Client-
Konfigurationen auslösen, welche nur mit grossem Aufwand manuell auffindbar sind.


                                           - 39 -
Screencompare bietet verschiedene Möglichkeiten, automatisierte Regressionstests der
visuellen Darstellung einer Webanwendung durchzuführen, indem Screens verschiedener
Programmversionen verglichen werden.
Im Folgenden Beispiel wird das Layout einer Webseite abgespeichert, um es später mit
dem Referenzlayout einer neuen Webauftrittsversion zu vergleichen.
Dieser erste Teil des Regressionstests öffnet zwei Webseiten und speichert deren
Darstellung als Bilddatei ab:

 public class RegressionStore extends ScreencompareTestCase {

 !    public void test() throws Exception {
 !    !      String[] urls = {"http://www.retokaiser.com/",
 !    "http://www.retokaiser.com/Unterrichtsmaterialien Informatik/"};

 !    !        for (String url:urls) {
 !    !        !    start(url, Browser.SAFARI);
 !    !        !    captureScreen().save();
 !    !        !    stop();
 !    !        }
 !    }

 }

Dabei öffnet Screenreport den Safari-Browser und legt die aufgenommenen Bilddateien im
Datenverzeichnis ab.




Die Entwicklung an diesem Webauftritt kann nun weitergeführt werden, mit dem Wissen,
dass ein Sollzustand des Layouts vorhanden ist.
Folgender Test vergleicht eine neuere Version des Webauftritts mit diesem
abgespeicherten Zustand:




                                          - 40 -
public class RegressionStoredTest extends ScreencompareTestCase {

 !    public void test() throws Exception {
 !    !      String[] urls = {"http://www.retokaiser.com/",
 !    "http://www.retokaiser.com/Unterrichtsmaterialien Informatik/"};

 !    !       for (String url:urls) {
 !    !       !    start(url, Browser.SAFARI);
 !    !       !    Screen reference = loadScreen(url, Browser.SAFARI);
 !    !       !    verifySame(captureScreen(), reference);
 !    !       !    stop();
 !    !       }
 !    }

 }

In der Schleife werden die aufgenommenen Screens mit den vom Datenverzeichnis
geladenen Referenzen verglichen. Unter der Annahme, dass sich das visuelle
Erscheinungsbild des Webauftritts geändert hat, schlägt der Test fehl, und JUnit Alarm.




Der Tester oder Entwickler kann sich dem erstellten PDF-Report bedienen, um die
konkreten Unterschiede zu sehen und einzuschätzen.
Beispielhaft wurde dem Titel auf der zweiten Webseite das Wort “Informatik” angehängt.
Der Report zeigt neben den beiden verglichenen Screens auch deren Differenz an,
wodurch eine schnelle Beurteilung der Unterschiede erleichtert wird:




                                           - 41 -
Bei der Entwicklung grosser Webauftritte, welche hunderte bis tausende unterschiedliche
Webseiten beinhalten, kann mit Hilfe einer solchen Regressionstest-Strategie mit wenig
Aufwand dem entstehen neuer Darstellungsfehler in verschiedenen Client-Konfigurationen
entgegengetreten werden.

3.3.3 Verfügbarkeit
Screencompare ist quelloffen und kann über Google Code bezogen werden:
                             http://code.google.com/p/screencompare/


Neben den Quellen steht ein Paket “screencompare.zip” zur Verfügung, welches die
Testausführung und -entwicklung mit möglichst geringem Aufwand ermöglichen soll. Darin
sind alle benötigten Bibliotheken, einige Beispiel-Tests sowie zwei Skripten zum Ausführen
von Tests auf der Kommandozeile enthalten.
Auf Google Code findet sich ausserdem ein “Getting Started” 93-Dokument (englisch),
welches die ersten Schritte erläutert und auf einzelne Beispiel-Tests eingeht.


Zusammenfassung
Testen ist als integraler Bestandteil der Softwareentwicklung akzeptiert. In modernen
Entwicklungsmodellen ist diese Disziplin zentral verankert. Gleichzeitig kommen speziell
im Web-Bereich eine Vielzahl kleiner bis mittelgrosser Projekte ohne jegliche
Testautomatisierung aus.
Dies scheint einerseits mit dem strukturell komplexen Technologiemix, und andererseits
mit teilweise unausgereiften und damit aufwändig zu implementierenden Testkonzepten
zusammenzuhängen.
In dem momentan sehr dynamischen Feld der Webtechnologien und der darauf
aufbauenden Frameworks gibt es allerdings viele Bestrebungen nach einfacher
Testbarkeit und technologieübergreifenden Lösungen94 .
Aus meiner eigenen Erfahrung in der Webentwicklung komme ich zum Schluss, dass die
Testbarkeit möglichst aller Aspekte einer Webanwendung erstrebenswert ist, wobei die
Anforderungen verschiedener Projekte jeweils unterschiedliche Ansätze verlangen. Die
kurzen Entwicklungszyklen in diesem Bereich sprechen fast immer für die Automatisierung
des Testarsenals, wobei anforderungsübergreifende Werkzeuge wünschenswert sind, um
den Testaufwand gering zu halten.


93   http://code.google.com/p/screencompare/wiki/GettingStarted [7.9.2010]
94   Vgl. Abschnitt 2.5 oder Test-Werkzeuge in Frameworks wie dem Zend Framework, GWT oder Wt
                                                    - 42 -
Mit Screencompare ist ein Prototyp für automatisiertes Layout-Testen auf visueller Ebene
entstanden. Dieser kann hoffentlich als Inspiration dienen und Entwicklern helfen, die
entsprechende Anforderungen prüfen möchten. Durch seinen modularen Aufbau ist
Screencompare einfach erweiterbar und kann für die Verwendung in verschiedensten
Projekten angepasst werden.




                                           - 43 -
Quellen
Abbildungen
1. Pätzold, Michael (2010): V-Modell.svg. http://de.wikipedia.org/w/index.php?title=Datei:V-
    Modell.svg&filetimestamp=20100126152418 [7.9.2010]
2. Memon, Atif M.; Pollack, Martha E.; Soffa, Mary L. (1999): Using a goal-driven approach to
    generate test cases for GUIs. Proceedings of the 1999 International Conference on Software
    Engineering, S. 264. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=841016 [7.9.2010]
3. Franke, Gerd (2006): Webanwendung client server 01.png. http://de.wikipedia.org/w/
    index.php?title=Datei:Webanwendung_client_server_01.png&filetimestamp=20070603211516
    [7.9.2010]
4. Deken, Jean M.: Documentation of the Early Web at SLAC. http://www.slac.stanford.edu/
    history/earlyweb/firstpages.shtml [7.9.2010]
5. Selbst erstellt
6. Manuel (2010): Screenshots. http://phpundercontrol.org/screenshots.html [7.9.2010]
7. Selbst erstellt
8. Selenium Remote Control. http://seleniumhq.org/projects/remote-control/ [7.9.2010]
9. Theme for the LWIS.net CSS Drop-Down Menu. http://www.lwis.net/free-css-drop-down-menu/
    dropdown.mtv.com.html [7.9.2010]
10. Smile Designer Smile. http://9elements.com/io/?page_id=54 [7.9.2010]
11. Fowler, Martin: Xunit. http://www.martinfowler.com/bliki/Xunit.html [23.9.2010]
12. Selbst erstellt
13. Selbst erstellt


Literatur
• 1998: IEEE 829-1998 Software Test Documentation. http://ieeexplore.ieee.org/xpls/abs_all.jsp?
  arnumber=4578383 [7.9.2010]
• 1987: IEEE 1008-1987 Software Unit Testing. http://ieeexplore.ieee.org/xpls/abs_all.jsp?
  arnumber=27763 [7.9.2010]
• 2004: IEEE 1012-2004 Software Verification and Validation. http://ieeexplore.ieee.org/xpls/
  abs_all.jsp?arnumber=1488512 [7.9.2010]
• 2008: IEEE 1028-2008 Software Reviews and Audits. http://ieeexplore.ieee.org/xpls/abs_all.jsp?
  arnumber=4601584 [7.9.2010]
• ISO/IEC 29119 (Entwurf). http://softwaretestingstandard.org [7.9.2010]
• Version 6.3: BS 7925-1. http://www.testingstandards.co.uk/bs_7925-1_online.htm
• Komponententest. http://de.wikipedia.org/wiki/Komponententest [7.9.2010]
• Integrationstest. http://de.wikipedia.org/wiki/Integrationstest [7.9.2010]
• Regressionstest. http://de.wikipedia.org/wiki/Regressionstest [7.9.2010]
                                                 - 44 -
• Beck, Kent (1999): Embracing change with extreme programming. Computer, 32/10. http://
 ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=796139 [7.9.2010]
• Chung, Lawrence; Leite, Julio C. S. P. (2009): On Non-Functional Requirements in Software
 Engineering. Lecture Notes in Computer Science, 5600. http://www.springerlink.com/content/
 l8p285p273461j60/ [23.9.2010]
• Corry, Michael D.; Frick, Theodore W.; Hansen, Lisa (1997): User-Centered Design and Usability
 Testing of a Web Site: An Illustrative Case Study. Educational Technology Research and
 Development, 45/4. http://www.springerlink.com/content/8075186635071u92/ [7.9.2010]
• Crockford, Douglas (2008): The World's Most Misunderstood Programming Language Has
 Become the World's Most Popular Programming Language. http://javascript.crockford.com/
 popular.html [23.9.2010]
• Dixon, Eleri; Enos, Emily; Brodmerkle (2006): A/B Testing. US Patent Application Publication, US
 2006/0162071 A1. http://ip.com/patapp/US20060162071 [23.9.2010]
• Elmendorf, William (1967): Evaluation of the Functional Testing of Control Programs. http://
 benderrbt.com/Evaluation%20of%20the%20Functional%20Testing%20of%20Control
 %20Programs%20-%201967.pdf [7.9.2010]
• Fowler, Martin (2006): Continuous Integration. http://martinfowler.com/articles/
 continuousIntegration.html [7.9.2010]
• Gamma, Erich; Beck, Kent (1999): JUnit: A cook's tour. http://www.redbrick.dcu.ie/~deviant/files/
 Renaat/testing/cookstour.pdf [7.9.2010]
• Gelperin, David; Hetzel, Bill (1988): The growth of software testing. Communications of the ACM,
 31/6. http://portal.acm.org/citation.cfm?id=62959.62965 [7.9.2010]
• Hoffman, Douglas (1999): Cost Benefits Analysis of Test Automation. http://
 www.softwarequalitymethods.com/Papers/Star99%20model%20Paper.pdf [7.9.2010]
• Meerts, Joris; Graham, Dorothy: The Annotated History of Software Testing. http://
 www.testingreferences.com/testinghistory.php [7.9.2010]
• Melnik, Grigori; Meszaros, Gerard (2009, RC1): Acceptance Test Engineering Guide, Vol. I.
 http://testingguidance.codeplex.com/ [7.9.2010]
• Memon, Atif M.; Pollack, Martha E.; Soffa, Mary L. (1999): Using a goal-driven approach to
 generate test cases for GUIs. Proceedings of the 1999 International Conference on Software
 Engineering. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=841016 [7.9.2010]
• Neystadt, John (2008). Automated Penetration Testing with White-Box Fuzzing. http://
 msdn.microsoft.com/en-us/library/cc162782.aspx [23.9.2010]
• Runeson, Per (2006): A Survey of Unit Testing Practices. IEEE Software, 23/4. http://
 doi.ieeecomputersociety.org/10.1109/MS.2006.91 [23.9.2010]




                                                - 45 -
• Takeuchi, Hirotaka; Nonaka, Ikujiro (1986): The new new product development game. Harvard
 Business Review. https://www.iei.liu.se/fek/frist/723g18/articles_and_papers/1.107457/
 TakeuchiNonaka1986HBR.pdf [7.9.2010]
• Wack, John; Tracy, Miles; Souppaya, Murugiah (2003): Guideline on Network Security Testing.
 NIST Special Publication, 800-42. http://csrc.nist.gov/publications/nistpubs/800-42/NIST-
 SP800-42.pdf [23.9.2010]
• Yang, Ji-Tzay; Huang, Jiun-Long; Wang, Feng-Jian (1998): A Tool Set to Support Web
 Application Testing. http://dspace.lib.fcu.edu.tw/jspui/bitstream/2377/2111/1/
 ce07ics001998000155.pdf [7.9.2010]




                                               - 46 -

Weitere ähnliche Inhalte

Andere mochten auch

Pesquisa - fornecedores de software empresarial - 2011
Pesquisa - fornecedores de software empresarial - 2011Pesquisa - fornecedores de software empresarial - 2011
Pesquisa - fornecedores de software empresarial - 2011
Roberto Dias Duarte
 
Reperes Vers Le Metaverse 290807
Reperes Vers Le Metaverse 290807Reperes Vers Le Metaverse 290807
Reperes Vers Le Metaverse 290807François Abiven
 
Palladium Magazine (Spring-Summer 2010)
Palladium Magazine (Spring-Summer 2010)Palladium Magazine (Spring-Summer 2010)
Palladium Magazine (Spring-Summer 2010)
Palladium Hotel Group
 
The ADL Initiative & the USCG
The ADL Initiative & the USCGThe ADL Initiative & the USCG
The ADL Initiative & the USCG
Jay Allen
 
You oughta be in pictures, and blogs, and video and 140 character updates, an...
You oughta be in pictures, and blogs, and video and 140 character updates, an...You oughta be in pictures, and blogs, and video and 140 character updates, an...
You oughta be in pictures, and blogs, and video and 140 character updates, an...
Kula Partners
 
Servicios De ConsultoríA 2011
Servicios De ConsultoríA 2011Servicios De ConsultoríA 2011
Servicios De ConsultoríA 2011
ninipinilla
 
Freizeitcafe-Hintergrund
Freizeitcafe-HintergrundFreizeitcafe-Hintergrund
Freizeitcafe-Hintergrund
Freizeitcafe
 
ENT3976 - Visual Resume - Martin Schaub
ENT3976 - Visual Resume - Martin SchaubENT3976 - Visual Resume - Martin Schaub
ENT3976 - Visual Resume - Martin Schaub
MartinSchaub
 
El Empresario ante la Morosidad Diciembre 2008
El Empresario ante la Morosidad Diciembre 2008El Empresario ante la Morosidad Diciembre 2008
El Empresario ante la Morosidad Diciembre 2008
Andrés Romero
 
Estudo de cheias
Estudo de cheiasEstudo de cheias
Estudo de cheias
emsbarretos
 
Bcr informativo semanal 12102012
Bcr informativo semanal 12102012Bcr informativo semanal 12102012
Bcr informativo semanal 12102012
joseleorcasita
 
Presentación para cetemma lidoilght
Presentación para cetemma lidoilghtPresentación para cetemma lidoilght
Presentación para cetemma lidoilght
www.yeclaofertas.com
 
The web is too slow
The web is too slow The web is too slow
The web is too slow
Andy Davies
 
Album de Fotografias MEDICINA
Album de Fotografias MEDICINAAlbum de Fotografias MEDICINA
Album de Fotografias MEDICINA
MafeMed13
 
Memorias Finalistas Concurso Ventures 2014
Memorias Finalistas Concurso Ventures 2014Memorias Finalistas Concurso Ventures 2014
Memorias Finalistas Concurso Ventures 2014
CorporacionVentures
 
Tuxtla y su crecimiento urbano
Tuxtla y su crecimiento urbanoTuxtla y su crecimiento urbano
Tuxtla y su crecimiento urbano
Sergio Antonio Tapia Perez
 
Informe i seminario internacional de resolución de conflictos socio
Informe i seminario internacional de resolución de conflictos socioInforme i seminario internacional de resolución de conflictos socio
Informe i seminario internacional de resolución de conflictos socio
alejdateran
 
Crushed by technical debt
Crushed by technical debtCrushed by technical debt
Crushed by technical debt
Scott W. Ambler
 

Andere mochten auch (20)

Pesquisa - fornecedores de software empresarial - 2011
Pesquisa - fornecedores de software empresarial - 2011Pesquisa - fornecedores de software empresarial - 2011
Pesquisa - fornecedores de software empresarial - 2011
 
Reperes Vers Le Metaverse 290807
Reperes Vers Le Metaverse 290807Reperes Vers Le Metaverse 290807
Reperes Vers Le Metaverse 290807
 
Palladium Magazine (Spring-Summer 2010)
Palladium Magazine (Spring-Summer 2010)Palladium Magazine (Spring-Summer 2010)
Palladium Magazine (Spring-Summer 2010)
 
The ADL Initiative & the USCG
The ADL Initiative & the USCGThe ADL Initiative & the USCG
The ADL Initiative & the USCG
 
You oughta be in pictures, and blogs, and video and 140 character updates, an...
You oughta be in pictures, and blogs, and video and 140 character updates, an...You oughta be in pictures, and blogs, and video and 140 character updates, an...
You oughta be in pictures, and blogs, and video and 140 character updates, an...
 
546_HotelNews_n15
546_HotelNews_n15546_HotelNews_n15
546_HotelNews_n15
 
Servicios De ConsultoríA 2011
Servicios De ConsultoríA 2011Servicios De ConsultoríA 2011
Servicios De ConsultoríA 2011
 
Freizeitcafe-Hintergrund
Freizeitcafe-HintergrundFreizeitcafe-Hintergrund
Freizeitcafe-Hintergrund
 
ENT3976 - Visual Resume - Martin Schaub
ENT3976 - Visual Resume - Martin SchaubENT3976 - Visual Resume - Martin Schaub
ENT3976 - Visual Resume - Martin Schaub
 
El Empresario ante la Morosidad Diciembre 2008
El Empresario ante la Morosidad Diciembre 2008El Empresario ante la Morosidad Diciembre 2008
El Empresario ante la Morosidad Diciembre 2008
 
Estudo de cheias
Estudo de cheiasEstudo de cheias
Estudo de cheias
 
Bcr informativo semanal 12102012
Bcr informativo semanal 12102012Bcr informativo semanal 12102012
Bcr informativo semanal 12102012
 
Sandra Peeters
Sandra PeetersSandra Peeters
Sandra Peeters
 
Presentación para cetemma lidoilght
Presentación para cetemma lidoilghtPresentación para cetemma lidoilght
Presentación para cetemma lidoilght
 
The web is too slow
The web is too slow The web is too slow
The web is too slow
 
Album de Fotografias MEDICINA
Album de Fotografias MEDICINAAlbum de Fotografias MEDICINA
Album de Fotografias MEDICINA
 
Memorias Finalistas Concurso Ventures 2014
Memorias Finalistas Concurso Ventures 2014Memorias Finalistas Concurso Ventures 2014
Memorias Finalistas Concurso Ventures 2014
 
Tuxtla y su crecimiento urbano
Tuxtla y su crecimiento urbanoTuxtla y su crecimiento urbano
Tuxtla y su crecimiento urbano
 
Informe i seminario internacional de resolución de conflictos socio
Informe i seminario internacional de resolución de conflictos socioInforme i seminario internacional de resolución de conflictos socio
Informe i seminario internacional de resolución de conflictos socio
 
Crushed by technical debt
Crushed by technical debtCrushed by technical debt
Crushed by technical debt
 

Ähnlich wie Automatisiertes webauftritt testen

DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes
QAware GmbH
 
UI Testautomation in der Praxis: Von Lokalisierung bis Nachhaltigkeit
UI Testautomation in der Praxis: Von Lokalisierung bis NachhaltigkeitUI Testautomation in der Praxis: Von Lokalisierung bis Nachhaltigkeit
UI Testautomation in der Praxis: Von Lokalisierung bis Nachhaltigkeit
Nico Orschel
 
Testing XAML-based Windows Store Apps mit VS 2013
Testing XAML-based Windows Store Apps mit VS 2013Testing XAML-based Windows Store Apps mit VS 2013
Testing XAML-based Windows Store Apps mit VS 2013
Nico Orschel
 
JavaScript und trotzdem Softwerker
JavaScript und trotzdem SoftwerkerJavaScript und trotzdem Softwerker
JavaScript und trotzdem Softwerker
Dennis Wilson
 
Agiles Testen - Überblick
Agiles Testen - ÜberblickAgiles Testen - Überblick
Agiles Testen - Überblick
Claudia Haußmann 🦋
 
Automatisiertes Testen von Software in C++ (mit dem Test Framework Google Test)
Automatisiertes Testen von Software in C++ (mit dem Test Framework Google Test)Automatisiertes Testen von Software in C++ (mit dem Test Framework Google Test)
Automatisiertes Testen von Software in C++ (mit dem Test Framework Google Test)
Florian Wolters
 
Testmanagement mit Visual Studio 2013
Testmanagement mit Visual Studio 2013Testmanagement mit Visual Studio 2013
Testmanagement mit Visual Studio 2013
Nico Orschel
 
Test-Automation mit Selenium WebDriver - ein Artikel der iks im dotnetpro
Test-Automation mit Selenium WebDriver - ein Artikel der iks im dotnetproTest-Automation mit Selenium WebDriver - ein Artikel der iks im dotnetpro
Test-Automation mit Selenium WebDriver - ein Artikel der iks im dotnetpro
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Testautomatisierung mit CodedUI für Fortgeschrittende
Testautomatisierung mit CodedUI für FortgeschrittendeTestautomatisierung mit CodedUI für Fortgeschrittende
Testautomatisierung mit CodedUI für Fortgeschrittende
Nico Orschel
 
Objektbasierte Versionierung und Lifecycle Management für den OWB
Objektbasierte Versionierung und Lifecycle Management für den OWBObjektbasierte Versionierung und Lifecycle Management für den OWB
Objektbasierte Versionierung und Lifecycle Management für den OWB
Minerva SoftCare GmbH
 
DWX 2017 - Alternativen zu Visual-Studio-Testtools: Wann lohnt es sich auch m...
DWX 2017 - Alternativen zu Visual-Studio-Testtools: Wann lohnt es sich auch m...DWX 2017 - Alternativen zu Visual-Studio-Testtools: Wann lohnt es sich auch m...
DWX 2017 - Alternativen zu Visual-Studio-Testtools: Wann lohnt es sich auch m...
Marc Müller
 
DevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
DevDay 2016 Keynote - Die Evolution agiler Software EntwicklungDevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
DevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
Marc Müller
 
SE2013 ANECON Testen in agilen Projekten
SE2013 ANECON Testen in agilen ProjektenSE2013 ANECON Testen in agilen Projekten
SE2013 ANECON Testen in agilen Projekten
Peter Haberl
 
Einführung in die Software-Qualitätssicherung
Einführung in die Software-QualitätssicherungEinführung in die Software-Qualitätssicherung
Einführung in die Software-QualitätssicherungChristian Baranowski
 
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Marc Bless
 
Hey, wie geht es dir?
Hey, wie geht es dir?Hey, wie geht es dir?
Hey, wie geht es dir?
Hendrik Lösch
 
PROFACTOR Gruppe | Complete Inspect
PROFACTOR Gruppe | Complete InspectPROFACTOR Gruppe | Complete Inspect
PROFACTOR Gruppe | Complete InspectPROFACTOR Group
 
Softwarequalitätssicherung mit Continuous Integration Tools
Softwarequalitätssicherung mit Continuous Integration ToolsSoftwarequalitätssicherung mit Continuous Integration Tools
Softwarequalitätssicherung mit Continuous Integration Tools
GFU Cyrus AG
 
DWX 2014 - Coded UI in der Praxis: Von Lokalisierung bis Nachhaltigkeit
DWX 2014 -  Coded UI in der Praxis: Von Lokalisierung bis NachhaltigkeitDWX 2014 -  Coded UI in der Praxis: Von Lokalisierung bis Nachhaltigkeit
DWX 2014 - Coded UI in der Praxis: Von Lokalisierung bis Nachhaltigkeit
Nico Orschel
 

Ähnlich wie Automatisiertes webauftritt testen (20)

DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes
 
UI Testautomation in der Praxis: Von Lokalisierung bis Nachhaltigkeit
UI Testautomation in der Praxis: Von Lokalisierung bis NachhaltigkeitUI Testautomation in der Praxis: Von Lokalisierung bis Nachhaltigkeit
UI Testautomation in der Praxis: Von Lokalisierung bis Nachhaltigkeit
 
Systementwurf mit UML
Systementwurf mit UMLSystementwurf mit UML
Systementwurf mit UML
 
Testing XAML-based Windows Store Apps mit VS 2013
Testing XAML-based Windows Store Apps mit VS 2013Testing XAML-based Windows Store Apps mit VS 2013
Testing XAML-based Windows Store Apps mit VS 2013
 
JavaScript und trotzdem Softwerker
JavaScript und trotzdem SoftwerkerJavaScript und trotzdem Softwerker
JavaScript und trotzdem Softwerker
 
Agiles Testen - Überblick
Agiles Testen - ÜberblickAgiles Testen - Überblick
Agiles Testen - Überblick
 
Automatisiertes Testen von Software in C++ (mit dem Test Framework Google Test)
Automatisiertes Testen von Software in C++ (mit dem Test Framework Google Test)Automatisiertes Testen von Software in C++ (mit dem Test Framework Google Test)
Automatisiertes Testen von Software in C++ (mit dem Test Framework Google Test)
 
Testmanagement mit Visual Studio 2013
Testmanagement mit Visual Studio 2013Testmanagement mit Visual Studio 2013
Testmanagement mit Visual Studio 2013
 
Test-Automation mit Selenium WebDriver - ein Artikel der iks im dotnetpro
Test-Automation mit Selenium WebDriver - ein Artikel der iks im dotnetproTest-Automation mit Selenium WebDriver - ein Artikel der iks im dotnetpro
Test-Automation mit Selenium WebDriver - ein Artikel der iks im dotnetpro
 
Testautomatisierung mit CodedUI für Fortgeschrittende
Testautomatisierung mit CodedUI für FortgeschrittendeTestautomatisierung mit CodedUI für Fortgeschrittende
Testautomatisierung mit CodedUI für Fortgeschrittende
 
Objektbasierte Versionierung und Lifecycle Management für den OWB
Objektbasierte Versionierung und Lifecycle Management für den OWBObjektbasierte Versionierung und Lifecycle Management für den OWB
Objektbasierte Versionierung und Lifecycle Management für den OWB
 
DWX 2017 - Alternativen zu Visual-Studio-Testtools: Wann lohnt es sich auch m...
DWX 2017 - Alternativen zu Visual-Studio-Testtools: Wann lohnt es sich auch m...DWX 2017 - Alternativen zu Visual-Studio-Testtools: Wann lohnt es sich auch m...
DWX 2017 - Alternativen zu Visual-Studio-Testtools: Wann lohnt es sich auch m...
 
DevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
DevDay 2016 Keynote - Die Evolution agiler Software EntwicklungDevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
DevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
 
SE2013 ANECON Testen in agilen Projekten
SE2013 ANECON Testen in agilen ProjektenSE2013 ANECON Testen in agilen Projekten
SE2013 ANECON Testen in agilen Projekten
 
Einführung in die Software-Qualitätssicherung
Einführung in die Software-QualitätssicherungEinführung in die Software-Qualitätssicherung
Einführung in die Software-Qualitätssicherung
 
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
 
Hey, wie geht es dir?
Hey, wie geht es dir?Hey, wie geht es dir?
Hey, wie geht es dir?
 
PROFACTOR Gruppe | Complete Inspect
PROFACTOR Gruppe | Complete InspectPROFACTOR Gruppe | Complete Inspect
PROFACTOR Gruppe | Complete Inspect
 
Softwarequalitätssicherung mit Continuous Integration Tools
Softwarequalitätssicherung mit Continuous Integration ToolsSoftwarequalitätssicherung mit Continuous Integration Tools
Softwarequalitätssicherung mit Continuous Integration Tools
 
DWX 2014 - Coded UI in der Praxis: Von Lokalisierung bis Nachhaltigkeit
DWX 2014 -  Coded UI in der Praxis: Von Lokalisierung bis NachhaltigkeitDWX 2014 -  Coded UI in der Praxis: Von Lokalisierung bis Nachhaltigkeit
DWX 2014 - Coded UI in der Praxis: Von Lokalisierung bis Nachhaltigkeit
 

Automatisiertes webauftritt testen

  • 1. Automatisiertes Webauftritt-Testen auf struktureller und visueller Ebene Bachelorprojekt im Informatikstudium an der Universität Basel September 2010 Autor: Reto Kaiser Erlenstrasse 41 4058 Basel Schweiz reto.kaiser@stud.unibas.ch Betreuung: High Performance and Web Computing Departement Informatik Klingelbergstrasse 50 4056 Basel Schweiz Prof. Dr. Helmar Burkhart helmar.burkhart@unibas.ch Dr. Sven Rizzotti sven.rizzotti@unibas.ch
  • 2. Inhaltsverzeichnis Abstract Einleitung 1. Software-Testen! 2 1.1 Grundlagen! 2 1.1.1 Komponententest! 3 1.1.2 Integrationstest! 4 1.1.3 Systemtest! 4 1.1.4 Abnahmetest! 5 1.1.5 Nicht-funktionale Tests! 6 1.1.6 Standardisierung! 6 1.1.7 Interview mit Dr. Franz-Josef Elmer! 7 1.2 Entwicklungen! 8 1.3 GUI-Testen! 9 2. Webauftritt-Testen! 10 2.1 Grundlagen! 10 2.2 Entwicklungen! 11 2.3 Ansätze! 12 2.3.1 Komponententest! 13 2.3.2 Integrationstest! 14 2.3.3 Systemtest! 15 2.4 Praxis! 17 2.4.1 Interview mit Urs Gürtler, Nextron! 17 2.4.2 Umfrage bei Webauftritt-Betreuern! 18 2.5 Werkzeuge! 21 2.5.1 Serverseitige Komponententests! 21 2.5.2 JavaScript Komponententests! 23 2.5.3 HTTP Integrationstests! 24 2.5.4 Browser Integrationstests! 25 2.5.5 Last Systemtests! 28 2.5.6 Sicherheit Systemtests! 30 3. Webseiten Layout-Testen: Screencompare! 31 3.1 Problem! 31 3.1.1 Diversifizierte Client-Landschaft! 31 3.1.2 Pixelgenaues Design! 32 3.1.3 Bedarf nach visuellem Layout-Testen! 33 3.2 Lösungsansatz! 34 3.3 Funktionsweise! 35 3.3.1 Testablauf! 35 3.3.2 Verwendung! 37 3.3.3 Verfügbarkeit! 42 Zusammenfassung Quellen Abbildungen Literatur
  • 3. Abstract In der Softwareentwicklung ist das Testen ein zentraler Bestandteil der Qualitätskontrolle. Anhand der Unterteilung Komponenten-, Integrations-, System- und Abnahmetest wird der theoretische Hintergrund und die praktische Anwendung aufgerollt. Moderne Webauftritte und -anwendungen müssen ebenfalls getestet werden, wobei einige Besonderheiten zu beachten sind. Neben der Erläuterung etablierter Ansätze werden einige existierende Werkzeuge anhand von Beispielen vorgestellt. Eine selbstentwickelte Software für visuelle Layout-Tests an Webseiten wird vorgestellt, die gebrauchsfertig und online verfügbar ist. Einleitung Webauftritte basieren auf einer Reihe von Technologien wie HTTP, HTML, CSS, JavaScript und einigen weiteren. Im letzten Jahrzehnt sind interaktive Webanwendungen entstanden, wobei sich deren Komplexität symbiotisch mit den entsprechenden Technologien entwickelt. Die rasanten Fortschritte in diesem Bereich führen dazu, dass Webanwendungen heute in vielerlei Hinsicht klassischen Anwendungen gleichzustellen sind. Entsprechend angestiegen ist die wirtschaftliche Bedeutung von Webauftritten. Viele sogenannte Dotcom-Firmen bieten ihre Dienstleistungen ausschliesslich über das Internet an. Es gibt also gute Gründe, in die Qualitätskontrolle und damit auch in das Testen von Webauftritten zu investieren. Die Etablierung iterativer und testgetriebener Entwicklungmodelle in den letzten 20 Jahren führte zu einer Erstarkung des automatisierten Testens; ein Konzept, das auch im jungen Bereich des Webauftritt-Testens Anklang findet. Die Client-Server-Struktur von Webauftritten birgt dazu einige strukturelle Stolpersteine. Die verbreiteten Webbrowser sind in der Regel abgeschlossene Endnutzer-Anwendungen, die nur umständlich als Testumgebung genutzt werden können. In dieser Arbeit sollen einige verbreitete Ansätze des Web-Testens vorgestellt, und deren Möglichkeiten und Grenzen ausgelotet werden. Schlussendlich wird die Frage gestellt, wieso und in welchem Umfang es nötig ist, die visuelle Erscheinung einer Webseite automatisiert zu testen. Dazu wird eine Herangehensweise anhand einer Java-Implementierung präsentiert. -1-
  • 4. 1. Software-Testen 1.1 Grundlagen Unter Software-Testen werden verschiedene Verfahren verstanden, welche zur Sicherstellung der Softwarequalität dienen1 . Mit ihnen wird versucht, Fehler zu finden und neue zu verhindern. Damit ist das Testen ein wichtiger Faktor in der Beurteilung der Produktqualität von Software; speziell die Testabdeckung kann eine aussagekräftige Metrik sein2. Die starke Heterogenität in Softwareentwicklungsprozessen und Laufzeitumgebungen führt zu einem diversifizierten Metier, welches schwer formalisierbar ist. Entwickler, aber auch dedizierte Tester müssen Tests planen, erstellen, durchführen und dokumentieren. IEEE 829-1998 “Software Test Documentation” beschreibt acht Dokumente zur Dokumentation von Tests, welche von der Konzeption, über die Spezifikation von Ein- und Ausgabewerten bis zu einer Zusammenfassung der Ergebnisse reichen. In der Praxis wird, abhängig von den Qualitätsanforderungen, deutlich weniger dokumentiert3. Automatisierte Tests erlauben es häufig, ganz auf eine manuelle Dokumentation zu verzichten, wobei Werkzeuge es ermöglichen aus den Tests selbst berichtartige Dokumente zu erzeugen. Software-Testen beinhaltet sowohl statische wie auch dynamische Techniken. Code- Reviews oder -Analysen sind beispielsweise statische Methoden. Diese Arbeit befasst sich hingegen mit den dynamischen Methoden, welche die tatsächliche Ausführung eines Programms oder Programmteils überprüfen. Für die Klassifizierung von Testmethoden, -kriterien oder - stufen existieren verschiedenste Modelle. Im Folgenden wird auf einige verbreitete Techniken anhand verschiedener Stufen der Softwareentwicklung im V-Modell4 Abb. 1: Stufen des V-Modells eingegangen. 1 IEEE 1012-2004, 2004, Abschnitt 5.4.5 2 IEEE 1012-2004, 2004, Abschnitt 7.8, Tabelle 1 3 Bspw. Interviews, Abschnitt 1.1.7 und 2.4.1 4 Vorgehensmodell der Softwareentwicklung, siehe Abb. 1 -2-
  • 5. 1.1.1 Komponententest Mit einem Komponententest (Modultest, Unittest) wird ein einzelner Programmteil auf Fehler geprüft. Eine zu testende Komponente kann beispielsweise ein funktionales Modul im Sinne der Softwarearchitektur oder eine Klasse in der objektorientierten Programmierung sein. Diese Komponente wird isoliert vom Rest der Software getestet. Ist die Funktionalität einer Komponente beschränkt und genau definiert, lassen sich damit auf einfache Weise erwartete Ergebnisse überprüfen. Im einfachsten Fall können die Schnittstellen einer Komponente anhand von Ein- und erwarteten Ausgaben geprüft werden. Dabei werden auch Fehlerszenarien, wie das Verhalten bei ungültigen Eingaben, getestet. Wenn eine Komponente auf weitere Programmteile angewiesen ist, so müssen diese für den Test simuliert werden. In diesem Fall wird von Mock-Objekten gesprochen, welche häufig mit entsprechenden Frameworks für Datenbank- oder Datei-Mocks erstellt werden. Komponententests werden fast immer automatisiert durchgeführt5, wobei entsprechende Werkzeuge, wie die vielzähligen xUnit-Frameworks6, Anwendung finden. Dies ermöglicht es, ein ganzes Set von Komponententests regelmässig auszuführen. Bei genügend grosser Testabdeckung können Entwickler so in Erfahrung bringen, ob eine Softwareänderung neue Fehler auslöst oder alte tilgt. In grösseren Entwicklungsteams kann es sinnvoll sein, die Ausführung und das Bestehen der Komponententests als Bedingung für die Aufnahme neuen Codes zu definieren. Die Testausführung kann beispielsweise von einem Pre-commit hook7 des Versionierungssystems, oder auch vom Erstellungsprozess (Build) ausgelöst werden8 . Ein JUnit 3 Komponententest: public class CalcTest extends TestCase { ! public void testAdd() { ! ! int result = MyCalc.add(3, 4); ! ! assertEquals(7, result); ! } } 5 Runeson, 2006 6 http://www.martinfowler.com/bliki/Xunit.html [23.9.2010] 7 Automatisierte Programmausführung vor dem Einchecken in ein Versionierungssystem 8 http://martinfowler.com/articles/continuousIntegration.html#MakeYourBuildSelf-testing [7.9.2010] -3-
  • 6. 1.1.2 Integrationstest Das Ziel eines Integrationstests ist es, die vorher durch Komponententests geprüften Programmteile kombiniert zu testen. Dabei können funktionale (Schnittstellen-) Anforderungen, aber auch das Performanzverhalten Testobjekte sein. Die einzelnen Komponenten werden dabei als Black Boxes9 gehandhabt. Wissen über deren interne Funktionsweise und Struktur ist für den Integrationstest also nicht nötig. Auch hier sollten sowohl gültige wie auch fehlerhafte Zwischenkomponenten-Interaktionen getestet werden, indem eine Komponente eine oder mehrere andere verwendet. Um den Testaufwand überschaubar zu halten, macht es bei grösseren Projekten Sinn, nicht alle Komponenten in jeglichen Kombinationen gegeneinander zu testen. Statt dessen können gemeinsam geprüfte Programmteile in einem nächsten Schritt als einzelne Komponente verstanden werden, welche in Zusammenarbeit mit einer anderen zusammengesetzten Komponente getestet wird. Dieses stufenweise, n-äre Zusammensetzen der Software wird als Bottom Up10-Ansatz bezeichnet. Häufig werden aber auch Mischformen mit Ansätzen wie Top Down 11 (umgekehrte Zusammenbaureihenfolge) oder Big Bang12 (Zusammenarbeit der Komponenten im Gesamtprodukt testen) verwendet. Bei Projekten mit mehreren Entwicklern wird mit Integrationstests die Zusammenarbeit von Komponenten unterschiedlicher Autoren getestet. Schnittstellenspezifikationen und - änderungen werden demnach auf die Probe gestellt. In solchen Entwicklungsszenarien macht es besonders Sinn diese Teststufe zu automatisieren. Integrationstests finden entgegen ihrer akademischen Definition im V-Modell aber auch in Ein-Mann-Projekten ohne jegliche Komponententests Anwendung. Abhängig von der verwendeten Technologiepalette und der eingebauten Testbarkeit wird der Automatisierungsaufwand unvertretbar hoch, sodass das Zusammenwirken der Komponenten in deren Entwicklungsphase vom Autor manuell getestet wird. 1.1.3 Systemtest Beim Systemtest wird der Black Box-Ansatz weitergetrieben, wobei das ganze zusammengesetzte Software-System ohne Wissen über dessen inneren Aufbau getestet wird. Die Testumgebung simuliert dabei die spätere Produktivumgebung. 9 Ohne Kenntnisse über die innere Funktionsweise, es werden nur öffentliche Schnittstellen betrachtet. 10 BS 7925-1 11 BS 7925-1 12 BS 7925-1 -4-
  • 7. In diesem Schritt testet die entwickelnde Organisation erneut die Funktionalität der Software, aber auch die Erfüllung nicht-funktionaler Anforderungen. Solche Anforderungen an Performanzverhalten, Sicherheitsvorkehrungen oder Gebrauchstauglichkeit müssen genau spezifiziert sein; ein späterer Abschnitt befasst sich mit derem Spezifizieren und Testen. Das Automatisieren von Systemtests kann sich als schwierig, beziehungsweise unwirtschaftlich erweisen13 , speziell wenn diese mehrheitlich aus Benutzerschnittstellen- Tests bestehen. Eine spätere formelle Abnahme der Software durch den Kunden kann vereinfacht werden, indem die Systemtest-Abläufe und -Ergebnisse genau dokumentiert werden, um sie dem Kunden zu präsentieren. 1.1.4 Abnahmetest Ein Abnahmetest (Acceptance test und User acceptance test) findet bei praktisch jedem für einen Kunden entwickelten System statt, Umfang und Formalitätsgrad varieren jedoch stark. IEEE 1012-2004 “Software Verification and Validation” definiert den Vorgang als “Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system.” 14 In diesem Sinne wird im englischen Sprachgebrauch vielfach zwischen Acceptance testing und User acceptance testing unterschieden, wobei ersteres durch den Entwickler, und zweiteres durch den Kunden oder Anwender durchgeführt wird. Ein User acceptance Test dient meist als Abnahmekriterium für eine Software. Dabei soll die Funktionalität des Produkt mit realen Anwendungsszenarien überprüft werden, wobei vielfach angestrebt wird, von der Entwicklung unabhängige Tester einzusetzen. Systemtest-Dokumentationen können zur Abnahme-Beurteilung hinzugezogen werden. Sogenannte Benutzergeschichten (User Story), welche in grösserem Aussmass auch in agilen, testgetriebenen Entwicklungsmodellen Anwendung finden, können Anforderungen für Abnahmetests sein. Weniger detailliert als Anwendungsfälle (Use Case), dafür ein ausführlicheres Benutzerszenario beschreibend, dienen sie der abstrakten Beschreibung der Software-Anforderungen durch den Kunden. Eine Benutzergeschichte: Beim öffnen eines Videos wird dieses an der zuletzt gestoppten Position oder, wenn noch nie geöffnet, an dessen Anfang abgespielt. 13 Hoffman, 1999 14 IEEE 1012-2004, 2004, Abschnitt 3.1.1 -5-
  • 8. 1.1.5 Nicht-funktionale Tests Aus Anwendungsfällen, oder daraus abgeleitet, können die funktionalen Anforderungen einer Software definiert werden. Sie beschreiben, was diese tun soll, wie sie also Eingaben verarbeitet, und welche Ausgaben erwartet werden. Im Gegensatz dazu definieren die nicht-funktionalen Anforderungen, wie sich das System in allen anderen Belangen verhält. Diese Qualitätsauflagen können verschiedenste Bereiche tangieren: Performanz, Sicherheit, Gebrauchstauglichkeit (Usability), Wartung, Robustheit, Erweiterbarkeit, Installation, Skalierbarkeit, Lokalisierbarkeit, Dokumentation et cetera15. Abhängig von Umfang, gesetzlichen Rahmenbedingungen, Einsatzgebiet und so weiter einer Software, fallen diese Nebenbedingungen unterschiedlich grosszügig aus. Einige dieser Anforderungen können im Sinne der Informatik und Informationstechnik getestet werden, benötigen aber meist spezialisierte Kenntnisse ausserhalb der Softwareentwicklung. Der vielfältige Bereich des Performanzverhaltens, welcher sich zum Beispiel mit der Skalierbarkeit, dem Zeitverhalten und der Verfügbarkeit eines Systems befasst, kann Kenntnisse zu Netzwerktopologie, Last-Erzeugung und Hardware-Verhalten voraussetzen. Um hingegen die Gebrauchstauglichkeit einer Software einzuschätzen, sind Psychologie-Kenntnisse, Design-Leitfäden oder spezielle Gerätschaften nötig. Diese diversifizierten Qualifikationsanforderungen führen zu einem hohen Aufwand des Testens und Erfüllens von nicht-funktionalen Anforderungen. Es wird deshalb vorgeschlagen, die Wichtigkeit dieser Anforderungen für den Kunden in Erfahrung zu bringen.16 Nicht-funktionale Tests werden üblicherweise in der Integrations- oder Abnahmephase des Projekts durchgeführt, wobei eine vielfältige Palette an freien, sowie kommerziellen Werkzeugen und Diensten verwendet werden kann. 1.1.6 Standardisierung Das Ausmass und die Professionalität des Software-Testens hat sich in den letzten 30 Jahren massiv gesteigert.17 Viele Softwareschmieden besitzen unterdessen Personal für das Testen und dessen Leitung. Während eine Vielfältigkeit an Meinungen und Praktiken zum Software-Testen existiert, versuchen einige Organisationen Begriffsdefinitionen, Anforderungen und Abläufe zu standardisieren. Im folgenden einige aktuell gültige Standardisierungsdokumente zum 15 Bspw. Chung; Leite, 2009 16 Melnik; Meszaros, 2009, Abschnitt 5.2.2 17 Gelperin; Hetzel, 1988, Abschnitt “Growth of professionalism” -6-
  • 9. Thema, sowie ein mir vielversprechend erscheinender Entwurf für einen umfassenden ISO/IEC-Standard: • IEEE 829-1998. Software Test Documentation • IEEE 1008-1987. Software Unit Testing • IEEE 1012-2004. Software Verification and Validation • IEEE 1028-2008. Software Reviews and Audits • ISO/IEC 25000:2005. Software product Quality Requirements and Evaluation (SQuaRE) • ISO/IEC 29119. Software Testing (Entwurf, siehe http://softwaretestingstandard.org) 1.1.7 Interview mit Dr. Franz-Josef Elmer Dr. Franz-Josef Elmer unterrichtet “Software Engineering” an der Universität Basel und arbeitet seit 1998 in der Softwareentwicklung. Er entwickelte in zwei- bis sechsköpfigen Teams GUI- und Webanwendungen mit Client-Server-Struktur, wobei vor allem Java, Bash, Python, SQL, XML und HTML Anwendung finden. Wie testen Sie heute Anwendungen? Elmer: »Wir betreiben Unit-, Integrations- und Systemtests, wobei die Unittestabdeckung weit unter 100% liegt, wahrscheinlich auch unterhalb von 50%. Meist gehen wir nach dem Prinzip “Code a little, test a little” vor. Geschriebener Code muss also testbar sein, wobei die entsprechenden Tests nach der Fertigstellung einer Etappe umgesetzt werden. Reine testgetriebene Entwicklung ist bei uns kein Thema. Ich kann mir speziell in der explorativen Anfangsphase der Entwicklung einer Software auch schlecht vorstellen, wie das sinnvoll funktionieren soll.« Welche Entwicklungen konnten und können Sie beobachten? »In meiner Anfangsphase haben wir das gemacht, was man heute manuelle System- und Abnahmetests nennt, die Anwendung also einfach ausprobiert. In dieser Zeit wurden meist wasserfallartige Entwicklungsmodelle verwendet. Vor 10 Jahren bin ich zum ersten Mal auf das Konzept des automatischen »Vor 10 Jahren bin ich zum ersten Testens gestossen. Nachdem ich Mal auf das Konzept des selber ein Framework entwickelt automatischen Testens gestossen.« habe, hat mich ein Kollege auf einen Artikel in der iX über JUnit, einem Testingframework, aufmerksam gemacht. -7-
  • 10. Automatisiertes Testen hat sich in der Zwischenzeit entwickelt und ist in der Softwareentwicklung zum Standard geworden. Der Trend zu iterativen Entwicklungsmethoden hat dazu beigetragen.« Welche Herausforderungen sehen Sie beim Webauftritt-Testen? »Serverseitig ist das sicher unproblematisch, Unittests für die Logik sind da stabil. Um die Clientlogik gut testen zu können sind aber die Controller [im MVC-Pattern] zu sehr mit den GUI-Elementen verbunden. GUI-Tests sind generell heikel und brechen bereits bei kleinen Änderungen. Komplexe Benutzerschnittstellen und dadurch viele Eingabemöglichkeiten bringen einen hohen Testaufwand mit sich, wobei der Nutzen vielfach unklar bleibt.« 1.2 Entwicklungen Die Koryphäen des Software-Testens Dave Gelperin und William C. Hetzel beschreiben18 1988 folgende fünf Phasen des frühen Testens von Software: • Bis 1956 “Debugging oriented”: Fehler werden explorativ gefunden und behoben. • 1957-1978 “Demonstration oriented”: Wachsende wirtschaftliche Wichtigkeit von Software führt zu stärkerem Engagement für das Fehlerfinden. • 1979-1982 “Destruction oriented”: Testen soll aktiv Fehler finden, es müssen also auch unübliche Eingaben berücksichtigt werden. • 1983-1987 “Evaluation oriented”: Softwarequalität wird anhand von Richtlinien evaluiert. • 1988 “Prevention oriented”: Anforderungen werden im Voraus definiert, Tests zu deren Überprüfung werden geplant. Das Aufkommen der “Prevention oriented”-Periode hat sich wohl bewahrheitet, in der Zwischenzeit hat sich jedoch wiederum einiges getan. In den 90er-Jahren wird das Software-Testen professionalisiert, wobei das Thema im grossen Stil diskutiert wird, beispielsweise an Konferenzen wie der “Software Testing Analysis & Review” (STAR, seit 1992 19) oder der “Software & Systems Quality” (SQC, seit 199620). Ausserdem wird 199121 erstmals der Standard ISO/IEC 9126 “Software engineering - Product quality” veröffentlicht. 18 Gelperin; Hetzel, 1988, Abschnitt “Evolution of the models” 19 http://www.sqe.com/Events/Archive/sw2002/ [7.9.2010] 20 http://www.iqnite-conferences.com [7.9.2010] 21 http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=16722 [7.9.2010] -8-
  • 11. Gleichzeitig entstehen testgetrieben sowie agile Entwicklungsmethoden wie Scrum 22 oder Extreme Programming23, bei welchen das Testen ein wichtiger Bestandteil des Entwicklungsprozesses ist. Speziell das Komponententesten, welches es dem Softwareautor ermöglicht, leicht automatierbare Tests für funktionale Anforderungen zu erstellen, gewinnt dadurch an Bedeutung. 1998 begründet und beschreibt der Zürcher Erich Gamma zusammen mit dem Amerikaner Kent Beck das beliebte JUnit24. Das Software-Testen hat also einige Paradigmenwechsel durchgemacht, und wird sich auch zukünftig an neue Ansprüche und Technologien anpassen müssen. 1.3 GUI-Testen Als Computerprogramme noch mehrheitlich mit einer Kommandozeile (CLI) gesteuert wurden, beschränkte sich die Benutzerschnittstelle auf eingegebenen Text und die textuelle Ausgabe. Das Testen einer solchen Benutzerschnittstelle ist relativ überschaubar, da die Anzahl an Eingabemöglichkeiten beschränkt werden kann. Im Zeitalter von grafischen Benutzeroberflächen (Graphical user interface, GUI) hingegen, ist das Testen der Benutzerschnittstelle einiges problematischer. Eine GUI besitzt typischerweise eine Vielzahl von Steuerelementen wie Schaltflächen, Bildlaufleisten, Menüs et cetera, welche gleichzeitig Eingaben entgegennehmen können. Durch die grosse Anzahl solcher Elemente und die vielen möglichen Eingabe-Reihenfolgen ergibt sich schnell eine unüberschaubar grosse Anzahl von GUI-Zuständen. Aufgrund dieser problematischen Umstände ist es schwierig eine GUI durchgängig zu testen, und es wird nötig das Testen zu automatisieren. In der Praxis werden häufig manuelle Benutzerinteraktionsabläufe aufgezeichnet, um sie dann mit einer entsprechenden Software automatisiert abspielen zu können. Dadurch wird der manuelle Aufwand auf das Aufzeichnen reduziert, und der Test kann beliebig oft wiederholt werden. Um eine GUI überhaupt automatisiert testbar zu machen, müssen Benutzerinteraktionen automatisierbar sein. Einige Ansätze führen Abb. 2: GUI-Testpläne für MS WordPad 22 Takeuchi; Nonaka, 1986 23 Beck, 1999 24 Gamma; Beck, 1999 -9-
  • 12. Benutzereingaben auf Betriebssystemebene aus25, sodass keine speziellen Vorkehrungen im zu testenden Programm vorgenommen werden müssen. Andernfalls kann ein GUI- Treiber in das Programm verbaut werden, über welchen ein anderes Programm die zu testende GUI mit Eingaben versorgen, und Ausgaben auslesen kann. Auch das Überprüfen der Ausgaben einer GUI mit einem automatisierten Test ist problematisch. Grafische Ausgaben können abhängig von der Laufzeitumgebung in Dimensionen, Farben und Schriftarten variieren. Eine automatische Validierung erkennt solche Unterschiede als Fehler, obwohl sie unter Umständen gewollt sind. 2. Webauftritt-Testen 2.1 Grundlagen Grössere Webauftritte (Website) sind heute üblicherweise sogenannte Webanwendungen, also Computerprogramme, die auf einem Webserver laufen. Grundsätzlich dient dabei der Webclient des Anwenders als Thin Client, wobei die eigentliche Programmlogik als CGI26-Programm, oder als integrierte Anwendung des Webservers auf einem entfernten Rechner ausgeführt wird. Abb. 3: Datenfluss einer Webanwendung Server und Client kommunizieren dabei mit dem Hypertext-Übertragungsprotokoll (HTTP) über eine Netzwerkverbindung, sodass im Idealfall eine fast verzögerungsfreie Benutzerschnittstelle bereitgestellt werden kann. Diese Architektur bedingt im Vergleich mit einer klassischen, lokal laufenden Software einige technische Unterschiede. Einerseits wird durch den Thin Client die Installation, Konfiguration und Wartung für den Anwender grössenteils hinfällig, und der Hersteller kann Softwareänderungen unverzögert zur Verfügung stellen, andererseits entsteht 25 Z.B. “AutoHotkey” 26 Common Gateway Interface, RFC 3875 - 10 -
  • 13. serverseitig ein Single Point of Failure (SPOF), und es muss damit gerechnet werden, dass die Client-Server-Verbindung jederzeit unterbrochen werden kann. Diese Eigenheiten müssen bei der Qualitätsbeurteilung von Webanwendungen berücksichtigt werden. Im Webbereich kommen einige spezialisierte Techniken zum Einsatz, die unter Anderem ein angenehmes Benutzererlebnis ermöglichen: • Cookies ermöglichen es, auf dem zustandslosen Protokoll (HTTP) Benutzer über mehrere Anfragen hinweg zu identifizieren. • Hypertext-Auszeichnungssprache (HTML) strukturiert als Grundlage jeder Webseite Inhalte wie Text, Bilder und Hyperlinks, welche im Webbrowser angezeigt werden. • Cascading Style Sheets (CSS) dient der Definition der Darstellung von Benutzerschnittstellen-Elementen der HTML, womit der Inhalt einer Webseite von dessen Aussehen getrennt wird. • JavaScript ist eine Skriptsprache, welche clientseitig als Teil einer Webseite im Webbrowser ausgeführt wird und HTML-Elemente, sowie CSS-Regeln ändern kann. Damit werden dynamische Benutzerschnittstellen innerhalb einer Webseite möglich. Zur Auseinandersetzung des Testens solcher Anwendungen ist festzuhalten, dass erstens die Programmlogik lose gekoppelt auf zwei physisch getrennten und technisch verschiedenen Systemen (Client und Server) abläuft, und sich zweitens speziell die Ausprägungen nicht-funktionaler Anforderungen erheblich von denen klassischer Software unterscheiden können. 2.2 Entwicklungen Die Disziplin des Webauftritt-Testens ist relativ jung. Grund dafür ist, dass Webanwendungen erst in den letzten zwei Jahrzehnten entstanden sind, wobei ihr Komplexitätsgrad in den letzten Jahren erheblich zugenommen hat. Eine der ersten Webanwendungen ist “SPIRES HEP” der Stanford-Universität, welche es 1991 erlaubt, einen Katalog von Teilchenphysik- Publikationen zu Abb. 4: SPIRES HEP Benutzerschnittstelle, 1991 durchsuchen27 . 27 http://www.slac.stanford.edu/history/earlyweb/firstpages.shtml [7.9.2010] - 11 -
  • 14. Technologische Meilensteine sind CGI (1995 28), PHP (1995 29), JavaScipt (199530), XMLHttpRequest (1999 31) und Ajax (200532). Während der New Economy 33 der 1990er Jahre entstehen grosse Webanwendungen34, welche schnell an Interaktionsmöglichkeiten gewinnen, indem asynchrone Kommunikation zwischen Client und Server (Ajax), eingesetzt wird. Damit kann die Benutzerschnittstelle im Webbrowser zügig und nahtlos auf Benutzereingaben reagieren, indem die auf dem Server laufende Anwendung im Hintergrund mit JavaScript kontaktiert wird. Software fürs Webauftritt-Testen entsteht in dieser Ära. So publiziert Russell Gold im Jahr 200035 die Version 1.0 von HttpUnit, welche es erlaubt Komponententests für Webseitenaufrufe zu schreiben, ohne einen Webbrowser einsetzen zu müssen. Um die Jahrtausendwende gibt es also Bestrebungen, die Funktionalität von Webauftritten zu überprüfen36 , namentlich den Kontrollfluss von Forms und Hyperlinks. Aber auch das Überprüfen nicht-funktionaler Anforderungen wie der Gebrauchstauglichkeit37 wird thematisiert. Die wachsende wirtschaftliche Bedeutung während den letzten zehn Jahren von Webanwendungen wie Google, Yahoo, Facebook und Co. hat dazu geführt, dass mehr Ressourcen in die Qualitätskontrolle von Webanwendungen investiert werden. Die Disziplin des Webauftritt-Testens ist jung, und die Anwendungsfälle gehen stark auseinander. 2.3 Ansätze Es scheint sich bis heute kein Konsens gebildet zu haben, wie ein Webauftritt getestet werden soll. Standardisierungsdokumente geben, durch ihre Langlebigkeit bedingt, wenig Auskunft. Verschiedenste Anforderungskataloge und technische Umsetzungen führen zu einer Vielzahl möglicher Ansätze. 28 http://www.w3.org/Daemon/User/CGI/Overview.html [7.9.2010] 29 http://groups.google.ch/group/comp.infosystems.www.authoring.cgi/msg/cc7d43454d64d133 [7.9.2010] 30 http://web.archive.org/web/20070916144913/http://wp.netscape.com/newsref/pr/newsrelease67.html [7.9.2010] 31 http://blogs.msdn.com/b/ie/archive/2006/01/23/516393.aspx [7.9.2010] 32 http://www.adaptivepath.com/ideas/essays/archives/000385.php [7.9.2010] 33 Dienstleistungsbetonte Wirtschaftsform, geprägt durch Globalisierung und Digitalisierung 34 Bspw. Google 1998, Hotmail 1996, Yahoo 1995 35 http://sourceforge.net/mailarchive/message.php?msg_name=v03110704b5d5d324518e %40%5B207.106.60.98%5D [7.9.2010] 36 Yang; Huang; Wang, 1998 37 Corry; Frick; Hansen, 1997 - 12 -
  • 15. 2.3.1 Komponententest Die eigentliche Anwendungslogik einer Webapplikation, die auf einem Server läuft, kann grösstenteils im Sinne der klassischen Softwareentwicklung betrachtet werden. Um sie testbar zu machen, sollte sie streng von der Benutzerschnittstelle getrennt sein. Dazu hat sich mehrheitlich das Model View Controller (MVC)- Paradigma etabliert. Dabei werden Anwendungslogik (Model), Präsentation (View) und Programmsteuerung (Controller) als möglichst unabhängige Einheiten betrachtet, welche über Schnittstellen kommunizieren. Gängige Webanwendungs-Frameworks wie das Zend Framework, Catalyst oder JavaServer Faces erlauben oder fordern die Entwicklung im MVC-Stil. In einem MVC-Projekt können die üblichen Komponententest-Frameworks für die entsprechende Programmiersprache verwendet werden, während Mock-Objekte die Datenquellen simulieren. Abb. 5: MVC-Paradigma Die serverseitige Anwendungslogik ist aber nicht die einzige Stelle, an der Komponententests angewendet werden. Durch die zunehmenden Interaktionsmöglichkeiten von Web-Benutzerschnittstellen, wird vermehrt Programmlogik auf der Clientseite gebräuchlich. So lädt beispielsweise eine Facebook-Webseite um die 600KB komprimierten JavaScript-Quellcode nach38 . Beliebte JavaScript-Bibliotheken haben in ihren aktuellen Versionen erheblichen Umfang: jQuery 6240 Zeilen39 , MooTools 4329 Zeilen40 und Dojo 11251 Zeilen41 Code. Dieser Teil einer Webanwendung wird nur selten automatisiert getestet. Der häufig prozedurale Programmierstil von JavaScript-Code und die enge Verknüpfung von Logik und Benutzerschnittstelle verringern die Testbarkeit. Gleichzeitig sind Webbrowser als wichtigste JavaScript-Interpreter nicht dafür ausgelegt, automatisierte Tests laufen zu lassen. Trotzdem gibt es Bestrebungen, JavaScript-Komponententests auf verschiedenen Ebenen möglich zu machen. Eine Variante ist es, die Anwendungslogik in einem Webbrowser zu 38 http://www.facebook.com [7.9.2010] 39 http://code.jquery.com/jquery-1.4.2.js [7.9.2010] 40 http://mootools.net/download/get/mootools-1.2.4-core-nc.js [7.9.2010] 41 http://download.dojotoolkit.org/release-1.5.0/dojo.js.uncompressed.js [7.9.2010] - 13 -
  • 16. testen. Da sich die JavaScript-Interpreter der verschiedenen Webbrowser teilweise erheblich unterscheiden, können dabei auch Interpreter-implementierungsspezifische Fehler aufgedeckt werden. Die Test-Frameworks sind dabei selbst in JavaScript geschrieben und bieten an die xUnit-Familie angelehnte Funktionalität. Andere Ansätze führen die zu testende Logik in einem besser kontrollierbaren, dezidierten JavaScript-Interpreter ausserhalb eines Webbrowsers aus. So verwenden einige Test- Frameworks Mozillas in Java geschriebene JavaScript-Implementierung Rhino42. Während die Benutzerschnittstelle einer Webanwendung als wie komplexer wird, muss häufig festgestellt werden, dass ein Grossteil der serverseitigen Anwendungslogik clientseitig in JavaScript dupliziert wird. Das führt zu doppeltem Wartungs- und Testaufwand. Einige Webanwendungs-Frameworks versuchen diesen Missstand zu beheben, indem Quellcode in einer einzigen Programmiersprache beim Deployment in die entsprechenden Technologien der Clientseite wie HTML, CSS und JavaScript übersetzt wird. Wichtige Vertreter sind Google Web Toolkit (GWT)43 in Java, RubyJS 44 in Ruby und Wt45 in C++. Bei Verwendung eines solchen Frameworks können auch Client-Komponententests in der Wirtssprache geschrieben werden, welche entweder im Wirtssprachen- oder JavaScript- Interpreter laufen können46 . 2.3.2 Integrationstest Integrationstests an Webanwendungen werden grösstenteils mit zwei verschiedenen Ansätzen auf unterschiedlichen Ebenen der Software umgesetzt. Dabei soll festgestellt werden, ob die möglicherweise vorher komponentengetesteten Programmteile auch als Ganzes ihre Funktionalität erfüllen. Um die reine Programmlogik auf dem Server zu testen, können HTTP-Anfragen simuliert und Antworten ausgewertet werden. Ein entsprechendes Testing-Framework mimt den Browser eines Anwenders und erlaubt dadurch, die Client-Server-Kommunikation zu überprüfen. Dazu müssen entsprechende Anfragen formuliert und, etwas aufwändiger, die meist als HTML-Dokumente vorliegenden Antworten auf ihre strukturelle Korrektheit überprüft werden. 42 http://www.mozilla.org/rhino/ [7.9.2010] 43 http://code.google.com/webtoolkit/ [7.9.2010] 44 http://rubyforge.org/projects/rubyjs/ [7.9.2010] 45 http://www.webtoolkit.eu [7.9.2010] 46 http://google-web-toolkit.googlecode.com/svn/javadoc/1.5/com/google/gwt/junit/client/GWTTestCase.html [7.9.2010] - 14 -
  • 17. Um die Clientseite einer Webanwendung testen zu können, muss zudem das Verhalten des Browsers testbar sein. Dazu müssen externe Ressourcen eines HTML-Dokuments wie CSS-Dateien, Bilder und JavaScript-Programme nachgeladen, die CSS-Regeln auf die HTML-Elemente angewendet, und JavaScript ausgeführt werden. Diese Funktionalität steckt in bestehenden Endanwender-Browsern, welche tatsächlich für Integrationstests verwendet werden. Dabei muss der verwendete Browser von einer programmierbaren Umgebung ferngesteuert werden. Es existieren weitere Ansätze, in denen das Verhalten eines Browsers simuliert wird, die Webseiten also nicht tatsächlich gerendert werden, ihr gesamtes Verhalten aber im Hintergrund abläuft und über entsprechende Schnittstellen testbar ist. 2.3.3 Systemtest Auf der Systemtest-Ebene werden Webauftritte meist auf nicht-funktionale Anforderungen geprüft. So kann es nötig sein eine neue Version einer Webanwendung vor ihrer Aufschaltung in einer fast-produktiven Umgebung einem letzten Lasttest zu unterziehen, um sicherzugehen, dass der Produktstart reibungslos über die Bühne geht. Eine Vielzahl weiterer Anforderungen wird in einem live-ähnlichen oder tatsächlich produktiven Setup getestet: • Sicherheit: Webanwendungen werden häufig ganz gezielt angegriffen, um diese unbenutzbar zu machen oder Informationen zu stehlen. Verbreitete Angriffsvektoren sind SQL-Injection und Cross-Site Scripting (XSS)47. Neben den Vorkehrungen die während der Sotwareentwicklung getroffen werden sollten, um solche Lücken zu verhindern, gibt es Analye- und Scanning-Werkzeuge, mit welchen Sicherheitslücken in existierenden Anwendungen gefunden werden können. So können mittels Fuzzing48 Fehler gefunden werden, die bei unvorhergesehenen Eingaben auftreten, indem zufällige Eingaben an HTTP- und HTML-Schnittstellen gesendet werden. Mit Penetrationstests49 werden mögliche Sicherheitslücken systematisch ausprobiert, um beispielsweise SQL-Injection-Lücken zu finden. Dies kann manuell, aber auch unterstützt durch grösstenteils automatisierte Werkzeuge geschehen, welche zum Beispiel für einen bestimmten HTTP-POST-Parameter übliche SQL-Injection-Werte übergeben. 47 http://www.owasp.org/index.php/OWASP_Top_Ten_Project [7.9.2010] 48 Bspw. Neystadt, 2008 49 Bspw. Wack; Tracy; Souppaya, 2003 - 15 -
  • 18. • Gebrauchstauglichkeit: Webanwendungen stehen heute vielfach unter hohem Konkurrenzdruck. Damit Benutzer einem Webauftritt loyal bleiben, muss dessen Bedienung effizient und zufriedenstellend sein. Um dies zu erreichen, ist es nötig, das Benutzerverhalten zu kennen, und die eigenen Webseiten entsprechend anzupassen. Ein ganzes Berufsfeld widmet sich der Thematik, wie Menschen vor einem Computerbildschirm eine Webseite aufnehmen und mit ihr interagieren. Dabei müssen Softwareentwickler, Designer und Usability-Experten zusammenarbeiten. Die Analyse der Gebrauchstauglichkeit ist vornehmlich ein manueller Vorgang. Doch es gibt auch Möglichkeiten, die Wirkung eines Weblayouts auf einen Probanden mit Gerätschaften maschinell zu erfassen. Alternativ können die Interaktionsflüsse auf einem Webauftritt gemessen werden, woraus die Wichtigkeit von Hyperlinks, Forms und Knöpfen bestimmt werden kann. Wenn gleichzeitig unterschiedlichen Benutzergruppen verschiedene Benutzeroberflächen-Versionen präsentiert werden (A-B-Test50), können die Auswirkungen von Layout-Änderungen statistisch gemessen werden. • Performanzverhalten: Ein verbreitetes Problem von Webanwendungen ist die Überlastung der Serverressourcen bei einem Anstieg der Anfragemenge. Architekturbedingt ist ein Webauftritt im Normalfall der beliebigen Anzahl von Clientanfragen ausgeliefert. Plötzlicher oder allmählicher Popularitätsanstieg kann eine Webanwendung lahmlegen. Es ist nicht einfach, Anforderungen an die verarbeitbare Anfragemenge und an die Verfügbarkeit einer Serverinfrastruktur zu formulieren. So gehen auch grosse Webauftritte hin und wieder aufgrund einer Vielzahl von Zugriffen in die Knie. Gleichzeitig ist es schwierig die Anforderungen gründlich zu testen, und auch eine Skalierungs-Strategie bereit zu halten. Bei sogenannten Lasttests (Stress test)51 wird eine grosse Zahl von HTTP-Anfragen an den Webserver geschickt, wobei dessen Performanzverhalten und allfällige Flaschenhälse studiert werden können. Dabei muss allerdings beachtet werden, dass das tatsächliche Verhalten erwarteter Benutzer simuliert wird. Es sollten also reale Navigationsflüsse durchgeführt werden, mitsamt Logins, Form-Absendungen et cetera. 50 Bswp. Dixon; Enos; Brodmerkle, 2006 51 BS 7925-1 - 16 -
  • 19. Weitere nicht-funktionale Anforderungen an Webauftritte wie Barrierefreiheit, Lokalisierbarkeit oder Interoperabilität52 werden teilweise getestet, setzen aber meist auch Kenntnisse ausserhalb des IT-Bereichs voraus, und erfordern viel manuellen Testaufwand. 2.4 Praxis Die Webentwicklung ist ein vielfältig bepflügtes Feld. Webauftritte werden von Einzelpersonen im Wohnzimmer realisiert, während grosse Firmen gleichzeitig Content- Management-Systeme (CMS) entwickeln und damit Millionenumsätze generieren53 . Entsprechend heterogen sind Ansätze und Umfänglichkeiten von Webauftritt-Tests in der Praxis. 2.4.1 Interview mit Urs Gürtler, Nextron Urs Gürtler arbeitet seit zweieinhalb Jahren als Applikationsentwickler bei der “Nextron Internet Team GmbH”54. Diese beschäftigt acht Mitarbeitende und erstellt seit 1996 Webauftritte wie www.mybasel.ch oder www.biovalley.ch. Wie realisiert ihr eure Projekte normalerweise? Gürtler: »Wir verwenden unser eigenes CMS, welches mit ColdFusion umgesetzt ist. Dieses wird für jeden Webauftritt entsprechend angepasst und nach Bedarf mit Modulen ergänzt. Üblicherweise beschäftigen sich zwei Personen einige Arbeitstage mit einem Projekt.« Wie testet ihr eure Software? »Unser CMS wird während der iterativen Entwicklung manuell getestet. Dafür wird etwa 30% der Entwicklungszeit aufgewendet. Automatisierte Tests haben wir keine. An den fertigen Webauftritten werden je nach Kundenansprüchen manuelle Systemtests durchgeführt, um Anforderungen wie Sicherheit, Skalierbarkeit und Funktionalität zu prüfen.« Wird das Webseiten-Layout getestet? »Der Designer, welcher die Templates für das CMS erstellt, testet die korrekte Darstellung der Webseiten manuell in verschiedenen Browsern auf unterschiedlichen Betriebssystemen.« 52 Bspw. Chung; Leite, 2009 53 http://www.day.com/day/en/company.html [7.9.2010] 54 http://www.nextron.ch [7.9.2010] - 17 -
  • 20. Welche Entwicklungen können Sie beobachten? »Die Ansprüche unserer Kunden steigen, die Webauftritte werden als wie komplexer. Die meisten wollen irgendetwas Aussergewöhnliches auf ihrer Website.« 2.4.2 Umfrage bei Webauftritt-Betreuern Folgende vier Fragestellungen habe ich an Webauftritt-Betreuer geschickt, um einschätzen zu können, in welchem Umfang deren Webseiten getestet werden: • UI Tests: Wird die korrekte visuelle Darstellung Ihrer Webseite auf unterschiedlichen Endnutzersystemen (Browsern, Geräten, Einstellungen) getestet? • Automatisierung: Wenn ja, geschieht dies automatisiert durch Software (welche)? • Andere Tests: Werden andere Aspekte Ihrer Webseite getestet? • Automatisierung: Wenn ja, geschieht dies automatisiert (Serverseitige Unit Tests, Clientseitige Unit Tests, Integrations Tests, …)? • Anzahl Webentwickler: Wie viele Personen sind für die Entwicklung und Wartung Ihrer Webseite verantwortlich? Von 242 Anfragen sind 35 Antworten zurückgekommen. Herzlichen Dank an alle beteiligten Personen der folgenden Webauftritte und Firmen!: www.cmsbox.com, www.maxomedia.ch, www.iwannagothere.com, www.homegate.ch, www.amazee.com, www.birdlife-zuerich.ch, www.dropbox.com, www.20minuten.ch, www.zdf.de, www.skyscanner.net, www.ford.com, www.ubs.com, www.hilti.com, www.comparis.ch, www.netcetera.ch, www.search.ch, www.autoscout24.ch, www.post.ch, www.zhaw.ch, www.idg.ch, www.zeeyoo.com, www.hsr.ch, www.bambuser.com, www.jinni.com, www.swisscom.com, www.bakespace.com, www.comvation.com, www.mubi.com, www.liip.ch, www.weltwoche.ch, www.xwave.ch, www.cookstr.com, www.bs.ch, www.rtpartner.ch, www.pornhub.com und www.tokenrock.com. Grösse der Entwicklerteams 79% der Befragten geben an, ein Entwicklerteam mit ein bis zehn Mitarbeitenden zu beschäftigen. - 18 -
  • 21. Anzahl Webentwickler 1-5 6-10 11-20 21-50 51-100 Praktisch alle Befragten testen ihren Webauftritt auf die eine oder andere Art, und überprüfen auch die korrekte Darstellung der Benutzerschnittstelle auf verschiedenen Endnutzersystemen. Testautomatisierung Eine Mehrheit setzt an irgendeiner Stelle auf Testautomatisierung. Automatische Benutzerschnittstellen-Tests verwenden hingegen nur 12% der Entwicklerteams, welche allesamt aus 10 oder mehr Entwicklern bestehen. UI Tests Andere Tests Automatisiert 12 % Manuell 37 % Automatisiert Manuell 63 % 88 % Einige Entwicklerteams führen Komponententests am serverseitigen Quellcode durch. Eine ähnlich grosse Menge führt automatisierte Systemtests durch, meist um nicht- funktionale Anforderungen wie die Ladezeit oder Barrierefreiheit zu prüfen. Getestete Entwicklungsstufen 9 7 4 Komponententests Integrationstests Systemtests Bei den automatisiert getesteten Anforderungen überwiegen die funktionalen knapp den nicht-funktionalen. Eine leichte Mehrheit wird serverseitig getestet. - 19 -
  • 22. Getestete Anforderungen Testausführung 11 10 8 7 Funktional Nicht-funktional Serverseitig Clientseitig Verwendete Software Zur Testautomatisierung werden folgende Software-Lösungen genannt: Selenium55 (4x), Grinder56, Google Website Optimizer57 , JUnit58, NUnit59, HP SiteScope60, HP LoadRunner61, Webtrends62 , WebAii63, IBM Rational64 und Webrat65. 55 http://seleniumhq.org [23.9.2010] 56 http://grinder.sourceforge.net [23.9.2010] 57 http://www.google.com/websiteoptimizer [23.9.2010] 58 http://www.junit.org [23.9.2010] 59 http://www.nunit.org [23.9.2010] 60 https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp? zn=bto&cp=1-11-15-25^849_4000_100__ [23.9.2010] 61 https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp? zn=bto&cp=1-11-126-17^8_4000_100__ [23.9.2010] 62 http://www.webtrends.com [23.9.2010] 63 http://www.telerik.com/products/web-testing-tools/webaii-framework-features.aspx [23.9.2010] 64 http://www.ibm.com/software/rational [23.9.2010] 65 http://github.com/brynary/webrat [23.9.2010] - 20 -
  • 23. 2.5 Werkzeuge Im Folgenden werden zehn beliebte Werkzeuge für verschiedene Aspekte des Webauftritt- Testens vorgestellt. Damit soll ein Überblick geschaffen werden, wobei mehrere Quellcode-Beispiele einen Einblick in die praktische Verwendung bieten. 2.5.1 Serverseitige Komponententests Komponententests für die serverseitige Anwendungslogik können mit Frameworks der xUnit-Familie implementiert werden. Der Extreme Programming-Mitbegründer Ron Jeffries unterhält eine ausführliche Liste solcher Werkzeuge auf http://www.xprogramming.com/ software.htm unter dem Abschnitt “Unit Testing”. PHPUnit (phpunit.de) PHPUnit ist ein Komponententestframework für die Skriptsprache PHP, die sich im Webbereich grosser Verbreitung erfreut. Das Werkzeug dient mit einer an xUnit angelehnten Schnittstelle als Komponententest- Framework, und berichtet über die Resultate von durchgelaufenen Tests, beispielsweise mit Testabdeckungs-Berichten. Im Folgenden ein beispielhafter Testfall “LoginLogout” mit den zwei Testmethoden “testLogin()” und “testLogout()”. Die Methoden “setUp()” und “tearDown()” werden vom Test-Framework vor beziehungsweise nach dem Abarbeiten der Testmethoden eines Testfalls ausgeführt. Im Beispiel erstellt “setUp()” mittels einer externen Hilfsklasse ein Benutzerobjekt, und “tearDown()” stellt die verwendete Datenbank zum Schluss des Testfalls wieder auf den Ursprungszustand zurück. - 21 -
  • 24. class LoginLogoutTest extends PHPUnit_Framework_TestCase { ! ! public function setUp() { ! ! TestHelperFunctions::createTestUser(); ! } ! public function tearDown() { ! ! TestHelperFunctions::clearDb(); ! } public function testLogin() { ! ! $this->assertTrue( ! ! ! LoginLogout::login('username', 'password'), ! ! ! 'Login failed'); ! } ! ! public function testLogout() { ! ! LoginLogout::logout(); ! ! $this->assertNull( ! ! ! My_Session::getUserId(), ! ! ! 'Logout did not clear session'); } ! } Die mit “assert” beginnenden Methoden sind die eigentlichen Schnittstellen zum Test- Framework. Mit ihnen wird überprüft, ob eine Variable (in diesem Fall der Rückgabewert einer Methode) die geforderten Bedingungen erfüllt. So schlägt “assertTrue()” Alarm, wenn der erste Parameter nicht true ist. PHPUnit kann in phpUnderControl66, eine Erweiterung für den kontinuierlichen Integrationsserver CruiseControl 67, integriert werden. Damit kann die kontinuierliche Ausführung eines Erstellungsprozesses mit dem Durchlaufen von Komponententests Abb. 6: Testabdeckung mit phpUnderControl verknüpft werden. Entwickler erhalten auf diese Weise zügig Rückmeldungen über allfällig fehlschlagende Tests im Gesamtprodukt. 66 http://phpundercontrol.org [7.9.2010] 67 http://cruisecontrol.sourceforge.net [7.9.2010] - 22 -
  • 25. 2.5.2 JavaScript Komponententests Mit dem Siegeszug von JavaScript als clientseitige Web-Programmiersprache 68 steigt das Bedürfnis nach JavaScript-Komponententests. In einem Browser laufend stellt dabei insbesondere die automatisierte Ausführung und Analyse der Tests eine Herausforderung dar. FireUnit (fireunit.org) FireUnit bietet Komponententest-Schnittstellen in JavaScript an und stellt Ergebnisse in der Mozilla Firefox-Webentwicklungs-Erweiterung Firebug an. Ursprünglich für die Entwicklung von Firefox-Erweiterungen erdacht69 , kann FireUnit auch für das Testen von Webauftritten verwendet werden. Die Software bietet einige Methoden zur Simulation von Benutzereingaben an, und enthält grundlegende xUnit-Schnittstellen: fireunit.ok(true, "This should pass"); fireunit.ok(false, "This should fail"); fireunit.compare("This is expected", "This isn't expected", ! "Texts differ"); Die Testsergebnisse werden in Firebug tabellarisch aufgeführt: Abb. 7: FireUnit-Ergebnisse in Firebug 68 Crockford, 2008 69 http://www.softwareishard.com/blog/firebug/fireunit-testing-in-the-firebug-world/ [7.9.2010] - 23 -
  • 26. QUnit (docs.jquery.com/Qunit) Die Funktionalität des JavaScript-Frameworks jQuery wird durch QUnit-Komponententests geprüft71 . QUnit kann aber ebenfalls für das Testen beliebiger JavaScript Anwendungen verwendet werden. Als Assertions stehen ok(), equals() und same() zur Verfügung: test("A basic test example", function() { ! ok(true, "This should pass"); ! ok(false, "This should fail"); ! equals("This is expected", "This isn't expected", ! ! "Texts differ"); }); Die Resultate werden direkt im getesteten HTML-Dokument angezeigt, was bedeutet, dass das Framework browserübergreifend verwendet werden kann: Abb. 8: QUnits Ergebnisanzeige 2.5.3 HTTP Integrationstests Beim Einsatz spezieller HTTP-Dienste wie Reverse Proxys oder gar selbst entwickelten HTTP-Servern kann es nötig sein, die HTTP-Kommunikation zu testen. HTTest (htt.sourceforge.net) Das in C entwickelte Test-Framework HTTest kann durch eine simple Skriptsprache gesteuert HTTP-Clients und -Server simulieren, wobei die stattfindende Kommunikation mit Bedingungen überprüft wird. Zusätzlich können Eingaben mit externen Programmaufrufen generiert und Ausgaben an solche weitergeleitet werden. Folgendes Skript ruft eine nicht vorhandene Datei auf dem “sbb.ch”-Server auf und überprüft, ob eine 404-Antwort zurückkommt: CLIENT _REQ sbb.ch 80 __GET /doesnotexist HTTP/1.1 __Host: sbb.ch __ _EXPECT . "HTTP/1.1 404 Not Found" _WAIT END - 24 -
  • 27. Während der Ausführung der Befehle zeigt HTTest die gesamte HTTP-Kommunikation auf der Standardausgabe an. 2.5.4 Browser Integrationstests Neben der Client-Server-Kommunikation auf HTTP-Ebene, also im OSI- Schichtenmodell71 , sollen vielfach auch die darauf aufbauenden Inhalte getestet werden. Diese konkreten Anwendungsinhalte liegen beispielsweise strukturiert als HTML- Dokumente vor. Eine strukturelle Analyse bietet sich an, um Bedingungen an diese Inhalte zu formulieren. Dazu muss im Allgemeinen die Syntaxanalyse eines Browsers nachempfunden werden, um anschliessend die entstandenen Datenstrukturen zu überprüfen. HtmlUnit (htmlunit.sourceforge.net) HtmlUnit ist ein in Java implementierter Webbrowser ohne grafische Benutzerschnittstelle. Die Software kann wie ein klassischer Browser Webseiten laden, CSS anwenden und JavaScript ausführen. Die resultierenden Webseiten werden jedoch nicht auf den Bildschirm gerendert, sondern stehen über Java-Schnittstellen zur Verfügung. Die angebotene API erinnert stark an die übliche Verwendungsweise eines Browsers. So können Forms ausgefüllt und Links verfolgt werden. Gleichzeitig können via Document Object Model (DOM)72 an die Dokumentenstruktur gestellte Bedingungen überprüft werden. Im folgenden Beispiel soll in einem JUnit-Testfall in Kombination mit HtmlUnit die Referenz eines Hyperlinks (“href”) auf der Indexdatei des “sbb.ch”-Servers geprüft werden: public class SbbTest extends TestCase { ! public void testCargo() throws Exception { ! ! WebClient client = new WebClient(BrowserVersion.FIREFOX_3); ! ! HtmlPage page =! client.getPage("http://www.sbb.ch"); ! ! HtmlAnchor anchor = page.getAnchorByText("Cargo"); ! ! assertEquals(anchor.getHrefAttribute(), ! ! ! ! ! "http://www.sbbcargo.com"); ! } } Dabei wird zuerst eine Browser-Instanz erstellt (“WebClient”), wobei hier ein “Firefox 3” simuliert werden soll. Nachdem die gewünschte Webseite geladen ist, wird mittles 71 Open Systems Interconnection model, ISO-Schichtenmodell von Kommunikationsprotokollen 72 Schnittstellenspezifikation für den HTML- und XML-Zugriff - 25 -
  • 28. “getAnchorByText()” auf einen spezifischen Hyperlink in der HTML-Struktur zugegriffen, dessen “href”-Attribut mit einer Bedingung geprüft wird. Als Browser-Simulation wird HtmlUnit in verschiedensten Test-Frameworks verwendet. Gerade weil keine GUI verwendet wird, lässt sich HtmlUnit verlässlich automatisiert steuern. Die Funktionalität der Software hinkt dafür den realen Browserversionen hinterher, speziell der JavaScript-Funktionsumfang, welcher auf Mozillas Rhino basiert. Selenium (seleniumhq.org) Selenium ist ein vielseitiges Integrationstest-Framework fürs Web. Es umfasst einerseits eine Firefox-Erweiterung, die das Aufzeichnen und Abspielen von Testszenarien erlaubt (Selenium IDE) und andererseits ein System für die automatisierte Kontrolle von Webbrowsern mittels Schnittstellen (Selenium Remote Control [RC]). Selenium RC besteht aus einem Server, der Browser öffnet, schliesst und ihnen als Proxy dient. Mit Hilfe dieses Proxys kann in Echtzeit JavaScript in eine geladene Webseite eingeschleust werden. Über Schnittstellen, die für Abb. 8: Selenium RC verschiedene Programmiersprachen zur Verfügung stehen, wird dieser “Remote Control Server” kontrolliert. Durch eigenständige Programme, oder mittels einem xUnit-Framework können damit in Java, Python, Ruby, C#, Perl oder PHP die Browser Firefox, Internet Explorer, Safari sowie Chrome ferngesteuert werden. Beispielhaft wird mit Java erneut das “href”-Attribut eines Links auf “sbb.ch” geprüft: - 26 -
  • 29. public class SbbTest extends SeleneseTestCase { ! ! public void setUp() throws Exception { ! ! setUp("http://www.sbb.ch/", "*firefox"); ! } ! public void testCargo() throws Exception { ! ! selenium.open("/"); ! ! String cargoHref = ! ! ! selenium.getAttribute("//a[text()='Cargo']@href"); ! ! assertEquals(cargoHref, "http://www.sbbcargo.com"); ! } ! } Der Testfall erbt im Unterschied zu HtmlUnit nicht direkt von JUnits TestCase, sondern von einer davon abgeleitete Klasse SeleneseTestCase. Damit werden im Testfall verschiedene Selenium-Methoden verfügbar. Ausserdem startet Selenium RC anstelle einer Browsersimulation eine richtige Firefox- Instanz, in welcher die “sbb.ch”-Webseite geladen wird, um anschliessend per XPath auf das “href”-Attribut zuzugreifen. Um Selenium-Tests schneller und auf mehreren Betriebssystemen gleichzeitig laufen zu lassen, wird Selenium Grid angeboten. Damit können in einem Testset Selenium RC- Instanzen auf verschiedenen Rechnern angesprochen werden. Um vom Geschwindigkeitsvorteil zu profitieren, müssen Tests parallel ablaufen - für JUnit verwendet man beispielsweise Parallel JUnit73 , welches Testfälle in Threads ausführt. Um die Verwirrung komplett zu machen, wird im Moment an Selenium 2 gearbeitet, eine Verschmelzung von Selenium und WebDriver (deshalb auch Selenium WebDriver genannt). WebDriver ist ein ursprünglich von Google veröffentlichtes74 Projekt, mit dem ebenfalls verschiedenste Webbrowser automatisch gesteuert werden können. Anstatt dies mittels JavaScript zu lösen, werden aber höherschichtige Ansätze verwendet, die spezifisch auf den jeweiligen Browser angepasst sind. So wird beispielsweise Firefox über eine Firefox- Erweiterung gesteuert. Mit der Verwendung von WebDriver können in Selenium 2 Tests in realen Browsern zügiger und verlässlicher ausgeführt werden. 73 https://parallel-junit.dev.java.net [7.9.2010] 74 http://google-opensource.blogspot.com/2009/05/introducing-webdriver.html [7.9.2010] - 27 -
  • 30. Rund um Selenium Im Folgenden eine Auswahl an Test-Software aus dem Selenium-Umfeld. • Sahi (sahi.co.in) basiert ähnlich wie Selenium 1 auf einem Proxy-Server, der im Browser eingetragen wird und diesem JavaScript-Befehle unterschiebt. Durch die Implementierung des Servers in Java ist Sahi browser- und betriebssystemunabhängig. Die Tests selbst werden mit Methoden wie _click() und _div() in JavaScript entwickelt. • Watir (watir.com) ist ein in Ruby geschriebenes Framework, das ähnlich wie WebDriver über verschiedene Betriebssystem- und Applikationsschnittstellen einen Webbrowser kontrolliert. So wird beispielsweise der Internet Explorer über COM75-Schnittstellen angesprochen. Es existieren einige von Watir inspirierte Test-Frameworks in anderen Programmiersprachen: WatiN 76 in C#, Watij77 in Java, oder das Perl-Modul Win32::Watir78 . • CubicTest (http://cubictest.seleniumhq.org) ist eine Eclipse79-Erweiterung, die es erlaubt Webseiten-Tests mit einer GUI als Flussdiagramm zusammenzuklicken. Ganze Benutzergeschichten können mit pfeilartigen Verbindungen zwischen Kästchen für Klicks, Text-Eingaben und Bedingungen zusammengestellt werden. Die fertigen Tests werden durch Selenium oder Watir ausgeführt. 2.5.5 Last Systemtests Auch für nicht-funktionale Anforderungen kann es nötig sein Tests zu automatisieren. Mit Lasttests soll geprüft werden, wie sich eine Webanwendung bei vielen Anfragen verhält. Je nach verwendeter Technik gibt es dutzende mögliche Flaschenhälse. Um diese zu erkennen und zu analysieren, muss auf dem entsprechenden System hohe Last simuliert werden. p-unit (p-unit.sourceforge.net) Das seit zwei Jahren nicht mehr weiterentwickelte Benchmarking-Framework p-unit bietet simple Java-Schnittstellen an, um die Laufzeit und den Speicherbedarf von ausgeführtem Java-Code zu messen. 75 Component Object Model, Interprozesskommunikation unter Windows 76 http://watin.sourceforge.net [7.9.2010] 77 http://watij.com [7.9.2010] 78 http://search.cpan.org/dist/Win32-Watir/ [7.9.2010] 79 http://www.eclipse.org [7.9.2010] - 28 -
  • 31. Mit einem solchen Werkzeug kann beispielsweise die Ausführungszeit der Anwendungslogik einer Webanwendung gemessen werden. Dabei kann das Lastverhalten von Datenbankanfragen, der Dateizugriff oder die Ausführung von externen Skripten Objekt von Interesse sein. Folgendes Beispiel misst den Zeitbedarf für das Berechnen aller Quadratwurzeln zwischen 1 und 500ʼ000ʼ000 mit Math.sqrt(): public class SqrtTest { ! public static void main(String[] args) { ! ! new SoloRunner().run(SqrtTest.class); ! } ! public void test500mio() { ! ! for (long i=1; i<=500000000.0; i++) { ! ! ! Math.sqrt(i); ! ! } ! } ! } Das Ergebnis wird auf die Konsole ausgegeben: test10mio() - [1211.751ms] Es können auch Grafiken und PDF-Reporte generiert werden. ApacheBench (httpd.apache.org/docs/2.2/programs/ab.html) ApacheBench (ab) ist Teil des Apache HTTP Servers und dient dazu die Antwortzeiten eines Webservers zu messen. Das Kommandozeilen-Werkzeug kann über Parameter dazu aufgefordert werden, eine bestimmte Anzahl an HTTP-Anfragen gleichzeitig und wiederholt an einen Server zu schicken, und schlussendlich über die Antwortzeiten zu berichten. Ein solcher Bericht enthält unter Anderem den Zeitbedarf verschiedener Phasen der HTTP-Kommunikation: Connection Times (ms) min mean[+/-sd] median max Connect: 23 35 11.7 30 55 Processing: 166 181 10.0 180 194 Waiting: 40 50 6.2 51 59 Total: 201 215 13.2 216 244 Sofern das Performanzverhalten der Anwendungslogik auf dem Server getestet wird, sollte darauf geachtet werden, dass ab auf dem gleichen Rechner wie der HTTP Server läuft, um ohne den Flaschenhals Netzwerk viel Last erzeugen zu können. - 29 -
  • 32. 2.5.6 Sicherheit Systemtests Es gibt eine Menge an kommerziellen und quelloffenen Sicherheits-Werkzeugen für Webanwendungen. Die meisten nennen sich Scanner und versuchen semi-automatisiert nach Schwachstellen wie SQL-Injection-Lücken zu suchen. Ein ausführliche Liste an Programmen wird vom Web Application Security Consortium (WASC) unterhalten: http:// projects.webappsec.org/Web-Application-Security-Scanner-List. Im Folgenden werden zwei solche Werkzeuge kurz vorgestellt. Skipfish (code.google.com/p/skipfish) Das von Google initiierte Skipfish ist ein klassischer Sicherheits-Scanner. Google selbst nennt es auch ein Erkundungs-Werkzeug. Herausragend ist vor allem die Performanz der Software. Eine schnelle HTTP-Implementierung in C soll bis zu 7000 Anfragen pro Sekunde an einen lokalen Server ermöglichen80 . Die Software sucht nach SQL-Injection-, XSS- und Pufferüberlauf-Lücken, aber auch nach weniger dramatischen Fehlern wie falschen MIME-Typen oder HTTP-Statuscodes. Die Erkundungs-Ergebnisse werden in einer interaktiv navigierbaren HTML-Seite präsentiert. w3af (w3af.org) Das Web Application Attack and Audit Framework (w3af) ist ein Sicherheits-Scanner für Webanwendungen, der inzwischen von Rapid781 gesponsert wird - eine Sicherheitsfirma die 200982 das Penetrationstest-Framework Metasploit83 gekauft hat. Über eine Plugin-Infrastruktur verwaltet w3af die verfügbaren Scantaktiken. Grössere Plugin-Kategorien sind “evasion” zum Umgehen von Intrusion Detection Systemen 84, “grep” zum generellen Durchsuchen von HTTP-Antworten beispielsweise auf IP-Adressen, oder Kreditkartennummern und “audit” zum eigentlichen Prüfen auf Sicherheitslücken. Dabei werden die üblichen Verdächtigen wie XSS-, SQL-Injection-, XPath-Injection- oder Dateiupload-Lücken erkannt. 80 http://code.google.com/p/skipfish/wiki/SkipfishDoc [7.9.2010] 81 http://www.rapid7.com [7.9.2010] 82 http://www.rapid7.com/metasploit-announcement.jsp [7.9.2010] 83 http://www.metasploit.com [7.9.2010] 84 System zur Erkennung von Angriffen und Einbrüchen in Computersysteme - 30 -
  • 33. 3. Webseiten Layout-Testen: Screencompare 3.1 Problem Etliche Faktoren machen es unter gewissen Umständen wünschenswert, die clientseitige Präsentation einer Webanwendung auf visueller Ebene zu überprüfen, und diesen Prozess zu automatisieren. 3.1.1 Diversifizierte Client-Landschaft Die Darstellung und Ausführung von Webanwendungs-Benutzerschnittstellen wird durch eine Vielzahl von Webbrowsern übernommen. Deren Interpretierung von HTML-, CSS- und JavaScript-Anweisungen entscheidet darüber, wie ein Anwender die Webseiten zu Gesicht bekommt. Es gibt seit jeher Bestrebungen, Webtechnologien über Browsergrenzen hinweg zu standardisieren. Die wohl einflussreichste Organisation diesbezüglich ist das World Wide Web Consortium (W3C)85, welches Standardisierungsdokumente zu HTML, XHTML, CSS, DOM, CGI und vielen weiteren Technologien veröffentlicht. Der ECMAScript-Dialekt JavaScript wird hingegen von der Ecma International86 standardisiert. Verschiedene Faktoren führen aber auch heute noch zu schlechter Interoperabilität zwischen Browsern verschiedener Hersteller. Einerseits werden die Standards unvollständig oder fehlerhaft umgesetzt, andererseits werden browserspezifische Funktionalitäten eingeführt, da die Standards beispielsweise als unvollständig erachtet werden87. Dies führt dazu, dass bei der Entwicklung von Webauftritten darauf geachtet werden muss, dass die Benutzerschnittstelle des Produkts bei den Endanwendern auch wirklich so aussieht und funktioniert wie erdacht. Es hat sich eingebürgert vor dem Produktstart einer Webanwendung die Benutzerschnittstelle in mindestens zwei bis drei verschiedenen Webbrowsern einem Abnahmetest zu unterziehen. Der Grossteil eingesetzter Browser wird von fünf verschiedenen Unternehmen entwickelt oder getragen, namentlich Microsoft (Internet Explorer), Mozilla (Firefox), Google (Chrome), Apple (Safari) und Opera. Das kalifornische Webanalyse-Unternehmen Net Applications88 sammelt Benutzerinformationen von nach eigenen Angaben 160 Millionen 85 http://www.w3.org [7.9.2010] 86 http://www.ecma-international.org [7.9.2010] 87 Bspw. Internet Explorer box model Fehler, "-moz-*", "-ms-*" oder "-webkit-*" CSS-Eigenschaften 88 http://www.netapplications.com [7.9.2010] - 31 -
  • 34. Webauftritt-Besuchern im Monat89. Anhand dieser öffentlich zugänglichen Daten setzt sich der Browser-Markt im Mai 2010 wie folgt zusammen: Webbrowser Layout-Engines (Andere) Opera Presto(Andere) (Opera) Safari IE6 WebKit (Safari+Chrome) Chrome Trident (IE6+7) IE7 Firefox Gecko (Firefox) IE8 comp. mode IE8 Trident 4 (IE8) Das erste Diagramm unterscheidet zwischen Browser-Namen und beim Internet Explorer auch -Versionen. Das Zweite zeigt verschiedene sogenannte Layout-Engines, also die einem Browser zugrundeliegende Software, welche für das HTML-Rendering zuständig ist. Die Zahlen belegen, dass eine Menge verschiedener Web-Clients verwendet wird. Auch der durch seine eigenwillige Interpretation von Webstandards bei Entwicklern verachtete90 Internet Explorer 6 hat neun Jahre nach seiner Einführung noch einen beachtlichen Marktanteil. Auch die neusten Versionen von Browsern machen Entwicklern in mancher Hinsicht das Leben schwer. Dies ist mehrheitlich darauf zurückzuführen, dass sich die verwendeten Technologien rasant weiterentwickeln. So befinden sich zur Zeit die viel gelobten Standards HTML5 und CSS 3 in Entwicklung. Im Rennen um gewiefte Benutzerschnittstellen für Webanwendungen werden Vorabversionen und eigene Interpretationen dieser Technologien implementiert, wodurch Webauftritte wieder in den verschiedenen Browsern getestet werden müssen. 3.1.2 Pixelgenaues Design Es ist umstritten, wie sehr sich das Layout von Webseiten in verschiedenen Browsern unterscheiden darf91 . Vielfach macht es Sinn, nur einige Design-Bausteine genau zu definieren, und diese in ein loses, mehrheitlich durch seine Struktur beschriebenes HTML- Dokument einzubetten. Dadurch gewinnt der Anwender gewisse Freiheiten, indem er die 89 http://www.netmarketshare.com [7.9.2010] 90 http://www.bringdownie6.com [7.9.2010] 91 Bspw. http://boagworld.com/technology/effective-browser-support [23.9.2010] - 32 -
  • 35. Präsentation einer Webseite an eigene Bedürfnisse anpassen kann. Gleichzeitig wird das Design dadurch eher Inhaltsagnostisch, verträgt sich also mit aller Art von textuellen und multimedialen Inhalten. Trotzdem kann es eine Anforderung sein, gewisse Design-Elemente oder ganze Webseiten pixelgenau zu implementieren. Meist werden solche Designs in einem Bildbearbeitungs- oder Layoutprogramm entworfen, und müssen dann mittels HTML und CSS mit möglichst allen gängigen Browsern kompatibel umgesetzt werden. Solche pixelgenauen Designs sind vielfach bildlastig, werden aber vemehrt auch HTML- Markup und CSS gestützt implementiert. Abb. 9: CSS-Aufklappmenüs können Pixelgenauigkeit benötigen Dadurch wird es meist schwieriger eine korrekte Wiedergabe über Browsergrenzen hinweg zu erreichen. 3.1.3 Bedarf nach visuellem Layout-Testen Obig genannte Umstände führen dazu, dass die Präsentation gewisser Webseiten in verschiedenen Browsern mit einer Referenz verglichen wird. Dabei sind üblicherweise kleine Unterschiede wie beispielsweise in der Schrift-Darstellungen hinnehmbar, an anderen Stellen wird allerdings Pixelgenauigkeit gefodert. Zur Überprüfung kann zum Beispiel eine Referenz über den Browser überlagert werden. Smile Designer Smile (9elements.com/io/?page_id=54) Smile Designer Smile ist ein Plugin für das JavaScript-Framework jQuery. Mit ihm kann ein Entwickler mit einigen Zeilen Quellcode eine Bilddatei über eine Webseite im Browser legen. Diese liegt dann halbdurchsichtig und mit der Maus verschiebbar als Referenz über der Webseite. Pixel Perfect (pixelperfectplugin.com) Die fast identische Funktionalität bietet Pixel Perfect. Als Firefox- Firebug-Plugin ist es allerdings ohne Programmieraufwand Abb. 10: Referenz- Überlagerung einsetzbar und bietet mit einer einfachen GUI etwas mehr Komfort. Allerdings ist es nur in Firefox verwendbar. - 33 -
  • 36. Das Überlagern einer Bilddatei vereinfacht das Überprüfen der visuellen Präsentation von Webseiten, ist aber ein manueller Prozess. Bei komplexen Webanwendungen wird üblicherweise versucht server- wie auch clientseitigen Quellcode für mehrere Webseiten wiederzuverwenden. Dadurch wird einerseits Code-Duplizierung verhindert, was die Wart-, Test- und Erweiterbarkeit verbessert. Andererseits können dadurch clientseitige Hilfsdokumente wie CSS-Dateien wiederverwendet werden, so dass sich die Übertragungszeiten von Webseiten verkürzen. Die dadurch entstehenden Abhängigkeiten innerhalb der Anwendung haben zur Folge, dass sich kleine Änderungen in einzelnen Quell-Dateien vielfach auf grosse Teile der Software auswirken. In Verbindung mit einer grossen Anzahl unterschiedlicher Webseiten eines Webauftritts wird das zu einem Problem: Änderung eines Enwicklers an einer einzelnen Webseite können ungewollt Auswirkungen auf andere Webseiten haben, welche nur mit grossem Aufwand manuell zu entdecken sind. Eine solche Nebenwirkung einer Softwareänderung wird Regression, das Überprüfen auf solche Unannehmlichkeiten Regressionstest92 genannt. Weil diese Tests bei möglichst jeder Code-Änderung durchgeführt werden sollten, ist es sinnvoll sie zu automatisieren. Für Web-Benutzerschnittstellen gilt das genauso wie für die Anwendungslogik. Beispielsweise kann die Änderung einer einzelnen CSS-Regel das Aussehen eines ganzen Webauftritts verändern, und damit unter Umständen in nur einer von hunderten Webseiten einen Layout-Fehler hervorrufen. In solchen Fälle sind automatisierte Regressionstests des Layouts wünschenswert. 3.2 Lösungsansatz Als Ansatz für visuelle Layouttests stelle ich eine automatisierte Variante von Referenz- Überlagerung auf Webseiten vor. Eine konkrete Implementierung in Java nenne ich Screencompare. Dabei sind folgende Anforderungen relevant: • Browserübergreifend: Es sollen die Render-Ergebnisse verschiedener Browser prüfbar sein, um deren Eigenheiten testbar zu machen. • Selektiv: Nicht immer muss das Layout einer ganze Webseite pixelgenau geprüft werden, es müssen auch Ausschnitte vergleichbar sein. • JavaScript-kompatibel: Um JavaScript-lastige Webseiten zu testen, sollen vor der Referenz-Überlagerung JavaScript-Anweisungen ausgeführt werden können. • Regressionstest-kompatibel: Damit verschiedene Versionen eines Webauftritts verglichen werden können, müssen Render-Ergebnisse speicherbar sein. 92 BS 7925-1 - 34 -
  • 37. • Automatisiert: Der visuelle Vergleich soll automatisiert stattfinden. Grundlegend funktioniert das Ganze analog einer manuellen Referenz-Überlagerung. Es wird also eine Bilddatei (Referenz) mit dem Render-Ergebnis eines Browsers verglichen. Um eine Webseite automatisiert zu laden und eventuelles JavaScript auszuführen muss das Test-Framework den Browser steuern können. Dabei soll die existierende Funktionalität von Selenium verwendet werden (es kämen aber auch andere Produkte in Frage, siehe Kapitel 2.5.4). Der Einfachheit halber wird nur der Viewport, also der sichtbare Teil einer Webseite im Browser, mit der Referenz verglichen. Der eigentliche Vergleich von Referenz und Rendering findet automatisiert mittels eines Pixelvergleichs statt. 3.3 Funktionsweise 3.3.1 Testablauf Screencompare vergleicht Bilder des Viewports eines Webbrowsers. Dazu wird der zu verwendende Browser per Selenium ferngesteuert, um danach aus einem Screenshot des ganzen Bildschirms den eigentlichen Viewport zu extrahieren. Die Erkennung des Viewports auf dem Screenshot geschieht mittels farbbasierter Bildfreistellung, indem vor jedem Test eine rein grüne Webseite im Browser angezeigt wird. Obige Bildreihe stellt diesen Vorgang dar. Nachdem der Webbrowser gestartet ist, wird der Hintergrund der Webseite mittels JavaScript grün eingefärbt. Dabei wird zusätzlich sichergestellt, dass das Browserfenster in maximaler Grösse dargestellt wird und - 35 -
  • 38. vollständig sichtbar ist. Screencompare macht einen Screenshot und erkennt anhand der grünen Fläche die Position und Grösse des Viewports. Danach werden die eigentlichen Webseiten aufgerufen, welche getestet werden sollen. Da die Viewport-Position nun bekannt ist, kann aus einem Screenshot direkt der Viewport mit der angezeigten Webseite extrahiert werden. Zum Vergleich der aufgenommenen Webseiten-Bilder stehen einige Methoden zur Verfügung, welche auf unterschiedliche Weise deren Differenz berechnen und ausgeben. Das Framework ist darauf ausgelegt, in einem JUnit-ähnlichen Komponententest verwendet zu werden. Dazu wird JUnits TestCase als ScreencompareTestCase erweitert. Neben den gängigen JUnit-Methoden steht darin Funktionalität für die Browser-Steuerung, die Viewport- Aufnahme und für den Viewport- Vergleich zur Verfügung. ScreencompareTestCase verwendet einen “Treiber”, welcher die Fernsteuerung des Browsers übernimmt. Im Normalfall wird Selenium RC verwendet, allerdings steht auch eine Implementierung für Selenium WebDriver zur Verfügung. Ausserdem können eigene Treiber als Implementierung der abstrakten Abb. 11: Funktionsprinzip Screencompare Klasse Driver geschrieben werden. Die beiden Selenium-Treiber unterstützen zum jetztigen Zeitpunkt folgende Browser: - 36 -
  • 39. Remote Control Remote Control WebDriver WebDriver (Windows) (Mac OS X) (Windows) (Mac OS X) Google Chrome ✔ ✔ ✔ ✔ Firefox ✔ ✔ ✔ ✔ Internet Explorer ✔ ✗ ✔ ✗ Safari ✔ ✔ ✗ ✗ Screencompare läuft derzeit auf Windows und Mac OS X. Betriebssystem-abhängiger Code wird benötigt, um sicherzustellen, dass der Browser im Fenstersystem für den Screenshot sichtbar ist. Dies wird entweder mit AppleScript oder einer kleinen C++-MFC- Anwendung erledigt. 3.3.2 Verwendung Zur sinnvollen Auswertung aufgenommener Viewport-Bilder stehen in ScreencompareTestCase einige öffentliche Methoden zur Verfügung. Im Folgenden wird auf diese Funktionalität anhand von Beispielen eingegangen. Grundlegend empfiehlt es sich, einen von ScreencompareTestCase erbenden Testfall zu erstellen: public class ExampleTest extends ScreencompareTestCase { ! public void test() throws Exception { ! ! start("http://www.google.ch", Browser.FIREFOX); ! ! captureScreen().save(); ! ! stop(); ! } } Viewport-Aufnahmen werden jeweils von start() und stop() umrahmt. Damit wird der entsprechende Browser mit der im Argument übergebenen URL geöffnet, beziehungsweise wieder geschlossen. Die Methode captureScreen() fängt die angezeigte Webseite ein und gibt eine Instanz der Klasse Screen zurück. Diese hält neben dem eigentlich Bild auch Metainformationen wie die URL, den verwendeten Browser und den Namen des entsprechenden Komponententests. Während ein Browser geöffnet ist stehen unter Anderem folgende Methoden zur Verfügung: • js(String javascript): Führt übergebenes JavaScript aus. • setBackground(Color color): Setzt die Seiten-Hintergrundfarbe. Nützlich für eigene farbbasierte Bildfreistellung. - 37 -
  • 40. • hideElement(String elementId): Versteckt ein Element, um beispielsweise Werbebanner vom Bildvergleich auszunehmen. • hideText(): Versteckt alle Textstellen einer Seite, um das rein graphische Layout einer Seite zu prüfen. • waitElementVisible(String elementId): Unterbricht die Programmausführung, bis das entsprechende Element sichtbar ist. Dies kann nützlich sein, wenn vor der Viewport- Aufnahme beispielsweise auf eine AJAX-Antwort gewartet werden soll. Zur tatsächlichen Auswertung von Bedingungen steht beispielsweise verifySame() zur Verfügung, welches zwei Screens vergleicht. Im folgenden Beispiel wird das Render- Ergebnis zweier Webseiten im Internet Explorer und Firefox verglichen: public class CompareFirefoxIETest extends ScreencompareTestCase { ! public void test() throws Exception { ! ! String[] urls = {"http://www.google.ch", ! ! ! ! ! "http://weatherflash.com/"}; ! ! for (String url:urls) { ! ! ! start(url, Browser.FIREFOX); ! ! ! Screen firefox = captureScreen(); ! ! ! stop(); ! ! ! ! ! ! start(url, Browser.IE); ! ! ! Screen ie = captureScreen(); ! ! ! stop(); ! ! ! ! ! ! verifySame(firefox, ie, 0.05f, Alignment.TOP_CENTER); ! ! } ! } } Dabei wird verifySame() neben den beiden Screens ein Schwellenwert für Bildunterschiede und eine Ausrichtungs-Anweisung übergeben. Die beiden Aufnahmen werden im Beispiel mittig oben übereinandergelegt, wobei eine Ausnahmesituation (Exception) ausgelöst wird, sobald mehr als 5% der Pixel Unterschiede aufweisen. Falls dieser Schwellenwert überschritten wird, und der Testfall entsprechend fehlschlägt, wird zusätzlich ein PDF-Report generiert, anhand von dem später untersucht werden kann, wieso der Testfall fehlschlug. - 38 -
  • 41. Abb. 12: PDF-Report mit Firefox- und IE6-Screen sowie deren Differenz Anhand eines weiteren Beispiels soll erläutert werden, wie Elemente auf einer Seite vor der Viewport-Aufnahme versteckt werden können. Dies kann nützlich sein, wenn eine Seite beispielsweise Werbebanner enthält, welche aber nicht Teil des Tests sein sollen. public class HideTest extends ScreencompareTestCase { ! public void test() throws Exception { ! ! start("http://photography.nationalgeographic.com/photo-of- the-day/", Browser.FIREFOX); ! ! captureScreen().save("nationalgeographic-1.png"); ! ! hideElement("headerboard"); ! ! captureScreen().save("nationalgeographic-2.png"); ! ! hideText(); ! ! captureScreen().save("nationalgeographic-3.png"); ! ! stop(); ! } } Im Beispiel wird mittels hideElement() das “headerboard” einer National Geographic- Webseite entfernt, welches einen Werbebanner enthält. In einem zweiten Schritt versteckt hideText() alle Textstellen auf der Seite. Da Schriftzeichen in verschiedenen Browsern vielfach verschieden angezeigt werden, kann es wünschenswert sein, diese vor einem Referenzvergleich auszublenden. Nach jedem Zwischenschritt wird der Screen abgespeichert: In kurzen Entwicklungszyklen aktualisierte Webauftritte erfordern besondere Wachsamkeit bezüglich der korrekten Darstellung im Webbrowser. Eine überschaubare Änderung am Quellcode einer Webanwendung kann Render-Probleme in einzelnen Client- Konfigurationen auslösen, welche nur mit grossem Aufwand manuell auffindbar sind. - 39 -
  • 42. Screencompare bietet verschiedene Möglichkeiten, automatisierte Regressionstests der visuellen Darstellung einer Webanwendung durchzuführen, indem Screens verschiedener Programmversionen verglichen werden. Im Folgenden Beispiel wird das Layout einer Webseite abgespeichert, um es später mit dem Referenzlayout einer neuen Webauftrittsversion zu vergleichen. Dieser erste Teil des Regressionstests öffnet zwei Webseiten und speichert deren Darstellung als Bilddatei ab: public class RegressionStore extends ScreencompareTestCase { ! public void test() throws Exception { ! ! String[] urls = {"http://www.retokaiser.com/", ! "http://www.retokaiser.com/Unterrichtsmaterialien Informatik/"}; ! ! for (String url:urls) { ! ! ! start(url, Browser.SAFARI); ! ! ! captureScreen().save(); ! ! ! stop(); ! ! } ! } } Dabei öffnet Screenreport den Safari-Browser und legt die aufgenommenen Bilddateien im Datenverzeichnis ab. Die Entwicklung an diesem Webauftritt kann nun weitergeführt werden, mit dem Wissen, dass ein Sollzustand des Layouts vorhanden ist. Folgender Test vergleicht eine neuere Version des Webauftritts mit diesem abgespeicherten Zustand: - 40 -
  • 43. public class RegressionStoredTest extends ScreencompareTestCase { ! public void test() throws Exception { ! ! String[] urls = {"http://www.retokaiser.com/", ! "http://www.retokaiser.com/Unterrichtsmaterialien Informatik/"}; ! ! for (String url:urls) { ! ! ! start(url, Browser.SAFARI); ! ! ! Screen reference = loadScreen(url, Browser.SAFARI); ! ! ! verifySame(captureScreen(), reference); ! ! ! stop(); ! ! } ! } } In der Schleife werden die aufgenommenen Screens mit den vom Datenverzeichnis geladenen Referenzen verglichen. Unter der Annahme, dass sich das visuelle Erscheinungsbild des Webauftritts geändert hat, schlägt der Test fehl, und JUnit Alarm. Der Tester oder Entwickler kann sich dem erstellten PDF-Report bedienen, um die konkreten Unterschiede zu sehen und einzuschätzen. Beispielhaft wurde dem Titel auf der zweiten Webseite das Wort “Informatik” angehängt. Der Report zeigt neben den beiden verglichenen Screens auch deren Differenz an, wodurch eine schnelle Beurteilung der Unterschiede erleichtert wird: - 41 -
  • 44. Bei der Entwicklung grosser Webauftritte, welche hunderte bis tausende unterschiedliche Webseiten beinhalten, kann mit Hilfe einer solchen Regressionstest-Strategie mit wenig Aufwand dem entstehen neuer Darstellungsfehler in verschiedenen Client-Konfigurationen entgegengetreten werden. 3.3.3 Verfügbarkeit Screencompare ist quelloffen und kann über Google Code bezogen werden: http://code.google.com/p/screencompare/ Neben den Quellen steht ein Paket “screencompare.zip” zur Verfügung, welches die Testausführung und -entwicklung mit möglichst geringem Aufwand ermöglichen soll. Darin sind alle benötigten Bibliotheken, einige Beispiel-Tests sowie zwei Skripten zum Ausführen von Tests auf der Kommandozeile enthalten. Auf Google Code findet sich ausserdem ein “Getting Started” 93-Dokument (englisch), welches die ersten Schritte erläutert und auf einzelne Beispiel-Tests eingeht. Zusammenfassung Testen ist als integraler Bestandteil der Softwareentwicklung akzeptiert. In modernen Entwicklungsmodellen ist diese Disziplin zentral verankert. Gleichzeitig kommen speziell im Web-Bereich eine Vielzahl kleiner bis mittelgrosser Projekte ohne jegliche Testautomatisierung aus. Dies scheint einerseits mit dem strukturell komplexen Technologiemix, und andererseits mit teilweise unausgereiften und damit aufwändig zu implementierenden Testkonzepten zusammenzuhängen. In dem momentan sehr dynamischen Feld der Webtechnologien und der darauf aufbauenden Frameworks gibt es allerdings viele Bestrebungen nach einfacher Testbarkeit und technologieübergreifenden Lösungen94 . Aus meiner eigenen Erfahrung in der Webentwicklung komme ich zum Schluss, dass die Testbarkeit möglichst aller Aspekte einer Webanwendung erstrebenswert ist, wobei die Anforderungen verschiedener Projekte jeweils unterschiedliche Ansätze verlangen. Die kurzen Entwicklungszyklen in diesem Bereich sprechen fast immer für die Automatisierung des Testarsenals, wobei anforderungsübergreifende Werkzeuge wünschenswert sind, um den Testaufwand gering zu halten. 93 http://code.google.com/p/screencompare/wiki/GettingStarted [7.9.2010] 94 Vgl. Abschnitt 2.5 oder Test-Werkzeuge in Frameworks wie dem Zend Framework, GWT oder Wt - 42 -
  • 45. Mit Screencompare ist ein Prototyp für automatisiertes Layout-Testen auf visueller Ebene entstanden. Dieser kann hoffentlich als Inspiration dienen und Entwicklern helfen, die entsprechende Anforderungen prüfen möchten. Durch seinen modularen Aufbau ist Screencompare einfach erweiterbar und kann für die Verwendung in verschiedensten Projekten angepasst werden. - 43 -
  • 46. Quellen Abbildungen 1. Pätzold, Michael (2010): V-Modell.svg. http://de.wikipedia.org/w/index.php?title=Datei:V- Modell.svg&filetimestamp=20100126152418 [7.9.2010] 2. Memon, Atif M.; Pollack, Martha E.; Soffa, Mary L. (1999): Using a goal-driven approach to generate test cases for GUIs. Proceedings of the 1999 International Conference on Software Engineering, S. 264. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=841016 [7.9.2010] 3. Franke, Gerd (2006): Webanwendung client server 01.png. http://de.wikipedia.org/w/ index.php?title=Datei:Webanwendung_client_server_01.png&filetimestamp=20070603211516 [7.9.2010] 4. Deken, Jean M.: Documentation of the Early Web at SLAC. http://www.slac.stanford.edu/ history/earlyweb/firstpages.shtml [7.9.2010] 5. Selbst erstellt 6. Manuel (2010): Screenshots. http://phpundercontrol.org/screenshots.html [7.9.2010] 7. Selbst erstellt 8. Selenium Remote Control. http://seleniumhq.org/projects/remote-control/ [7.9.2010] 9. Theme for the LWIS.net CSS Drop-Down Menu. http://www.lwis.net/free-css-drop-down-menu/ dropdown.mtv.com.html [7.9.2010] 10. Smile Designer Smile. http://9elements.com/io/?page_id=54 [7.9.2010] 11. Fowler, Martin: Xunit. http://www.martinfowler.com/bliki/Xunit.html [23.9.2010] 12. Selbst erstellt 13. Selbst erstellt Literatur • 1998: IEEE 829-1998 Software Test Documentation. http://ieeexplore.ieee.org/xpls/abs_all.jsp? arnumber=4578383 [7.9.2010] • 1987: IEEE 1008-1987 Software Unit Testing. http://ieeexplore.ieee.org/xpls/abs_all.jsp? arnumber=27763 [7.9.2010] • 2004: IEEE 1012-2004 Software Verification and Validation. http://ieeexplore.ieee.org/xpls/ abs_all.jsp?arnumber=1488512 [7.9.2010] • 2008: IEEE 1028-2008 Software Reviews and Audits. http://ieeexplore.ieee.org/xpls/abs_all.jsp? arnumber=4601584 [7.9.2010] • ISO/IEC 29119 (Entwurf). http://softwaretestingstandard.org [7.9.2010] • Version 6.3: BS 7925-1. http://www.testingstandards.co.uk/bs_7925-1_online.htm • Komponententest. http://de.wikipedia.org/wiki/Komponententest [7.9.2010] • Integrationstest. http://de.wikipedia.org/wiki/Integrationstest [7.9.2010] • Regressionstest. http://de.wikipedia.org/wiki/Regressionstest [7.9.2010] - 44 -
  • 47. • Beck, Kent (1999): Embracing change with extreme programming. Computer, 32/10. http:// ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=796139 [7.9.2010] • Chung, Lawrence; Leite, Julio C. S. P. (2009): On Non-Functional Requirements in Software Engineering. Lecture Notes in Computer Science, 5600. http://www.springerlink.com/content/ l8p285p273461j60/ [23.9.2010] • Corry, Michael D.; Frick, Theodore W.; Hansen, Lisa (1997): User-Centered Design and Usability Testing of a Web Site: An Illustrative Case Study. Educational Technology Research and Development, 45/4. http://www.springerlink.com/content/8075186635071u92/ [7.9.2010] • Crockford, Douglas (2008): The World's Most Misunderstood Programming Language Has Become the World's Most Popular Programming Language. http://javascript.crockford.com/ popular.html [23.9.2010] • Dixon, Eleri; Enos, Emily; Brodmerkle (2006): A/B Testing. US Patent Application Publication, US 2006/0162071 A1. http://ip.com/patapp/US20060162071 [23.9.2010] • Elmendorf, William (1967): Evaluation of the Functional Testing of Control Programs. http:// benderrbt.com/Evaluation%20of%20the%20Functional%20Testing%20of%20Control %20Programs%20-%201967.pdf [7.9.2010] • Fowler, Martin (2006): Continuous Integration. http://martinfowler.com/articles/ continuousIntegration.html [7.9.2010] • Gamma, Erich; Beck, Kent (1999): JUnit: A cook's tour. http://www.redbrick.dcu.ie/~deviant/files/ Renaat/testing/cookstour.pdf [7.9.2010] • Gelperin, David; Hetzel, Bill (1988): The growth of software testing. Communications of the ACM, 31/6. http://portal.acm.org/citation.cfm?id=62959.62965 [7.9.2010] • Hoffman, Douglas (1999): Cost Benefits Analysis of Test Automation. http:// www.softwarequalitymethods.com/Papers/Star99%20model%20Paper.pdf [7.9.2010] • Meerts, Joris; Graham, Dorothy: The Annotated History of Software Testing. http:// www.testingreferences.com/testinghistory.php [7.9.2010] • Melnik, Grigori; Meszaros, Gerard (2009, RC1): Acceptance Test Engineering Guide, Vol. I. http://testingguidance.codeplex.com/ [7.9.2010] • Memon, Atif M.; Pollack, Martha E.; Soffa, Mary L. (1999): Using a goal-driven approach to generate test cases for GUIs. Proceedings of the 1999 International Conference on Software Engineering. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=841016 [7.9.2010] • Neystadt, John (2008). Automated Penetration Testing with White-Box Fuzzing. http:// msdn.microsoft.com/en-us/library/cc162782.aspx [23.9.2010] • Runeson, Per (2006): A Survey of Unit Testing Practices. IEEE Software, 23/4. http:// doi.ieeecomputersociety.org/10.1109/MS.2006.91 [23.9.2010] - 45 -
  • 48. • Takeuchi, Hirotaka; Nonaka, Ikujiro (1986): The new new product development game. Harvard Business Review. https://www.iei.liu.se/fek/frist/723g18/articles_and_papers/1.107457/ TakeuchiNonaka1986HBR.pdf [7.9.2010] • Wack, John; Tracy, Miles; Souppaya, Murugiah (2003): Guideline on Network Security Testing. NIST Special Publication, 800-42. http://csrc.nist.gov/publications/nistpubs/800-42/NIST- SP800-42.pdf [23.9.2010] • Yang, Ji-Tzay; Huang, Jiun-Long; Wang, Feng-Jian (1998): A Tool Set to Support Web Application Testing. http://dspace.lib.fcu.edu.tw/jspui/bitstream/2377/2111/1/ ce07ics001998000155.pdf [7.9.2010] - 46 -