Automatisiertes webauftritt testen

4.084 Aufrufe

Veröffentlicht am

German Thesis on automated browser testing

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
4.084
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
2
Aktionen
Geteilt
0
Downloads
33
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Automatisiertes webauftritt testen

  1. 1. Automatisiertes Webauftritt-Testen auf struktureller und visueller Ebene Bachelorprojekt im Informatikstudium an der Universität Basel September 2010Autor:Reto KaiserErlenstrasse 414058 BaselSchweizreto.kaiser@stud.unibas.chBetreuung:High Performance and Web ComputingDepartement InformatikKlingelbergstrasse 504056 BaselSchweizProf. Dr. Helmar Burkharthelmar.burkhart@unibas.chDr. Sven Rizzottisven.rizzotti@unibas.ch
  2. 2. InhaltsverzeichnisAbstractEinleitung1. 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! 92. 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! 303. 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! 42ZusammenfassungQuellen Abbildungen Literatur
  3. 3. AbstractIn der Softwareentwicklung ist das Testen ein zentraler Bestandteil der Qualitätskontrolle.Anhand der Unterteilung Komponenten-, Integrations-, System- und Abnahmetest wird dertheoretische Hintergrund und die praktische Anwendung aufgerollt.Moderne Webauftritte und -anwendungen müssen ebenfalls getestet werden, wobei einigeBesonderheiten zu beachten sind. Neben der Erläuterung etablierter Ansätze werdeneinige 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.EinleitungWebauftritte basieren auf einer Reihe von Technologien wie HTTP, HTML, CSS,JavaScript und einigen weiteren. Im letzten Jahrzehnt sind interaktive Webanwendungenentstanden, wobei sich deren Komplexität symbiotisch mit den entsprechendenTechnologien entwickelt. Die rasanten Fortschritte in diesem Bereich führen dazu, dassWebanwendungen heute in vielerlei Hinsicht klassischen Anwendungen gleichzustellensind.Entsprechend angestiegen ist die wirtschaftliche Bedeutung von Webauftritten. Vielesogenannte Dotcom-Firmen bieten ihre Dienstleistungen ausschliesslich über das Internetan. Es gibt also gute Gründe, in die Qualitätskontrolle und damit auch in das Testen vonWebauftritten zu investieren.Die Etablierung iterativer und testgetriebener Entwicklungmodelle in den letzten 20 Jahrenführte zu einer Erstarkung des automatisierten Testens; ein Konzept, das auch im jungenBereich 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 derenMöglichkeiten und Grenzen ausgelotet werden.Schlussendlich wird die Frage gestellt, wieso und in welchem Umfang es nötig ist, dievisuelle Erscheinung einer Webseite automatisiert zu testen. Dazu wird eineHerangehensweise anhand einer Java-Implementierung präsentiert. -1-
  4. 4. 1. Software-Testen1.1 GrundlagenUnter Software-Testen werden verschiedene Verfahren verstanden, welche zurSicherstellung der Softwarequalität dienen1 . Mit ihnen wird versucht, Fehler zu finden undneue zu verhindern.Damit ist das Testen ein wichtiger Faktor in der Beurteilung der Produktqualität vonSoftware; speziell die Testabdeckung kann eine aussagekräftige Metrik sein2.Die starke Heterogenität in Softwareentwicklungsprozessen und Laufzeitumgebungenführt zu einem diversifizierten Metier, welches schwer formalisierbar ist. Entwickler, aberauch dedizierte Tester müssen Tests planen, erstellen, durchführen und dokumentieren.IEEE 829-1998 “Software Test Documentation” beschreibt acht Dokumente zurDokumentation von Tests, welche von der Konzeption, über die Spezifikation von Ein- undAusgabewerten bis zu einer Zusammenfassung der Ergebnisse reichen. In der Praxiswird, abhängig von den Qualitätsanforderungen, deutlich weniger dokumentiert3.Automatisierte Tests erlauben es häufig, ganz auf eine manuelle Dokumentation zuverzichten, wobei Werkzeuge es ermöglichen aus den Tests selbst berichtartigeDokumente zu erzeugen.Software-Testen beinhaltet sowohl statische wie auch dynamische Techniken. Code-Reviews oder -Analysen sind beispielsweise statische Methoden. Diese Arbeit befasst sichhingegen mit den dynamischen Methoden, welche die tatsächliche Ausführung einesProgramms oder Programmteilsüberprüfen.Für die Klassifizierung vonTestmethoden, -kriterien oder -stufen existieren verschiedensteModelle. Im Folgenden wird aufeinige verbreitete Technikenanhand verschiedener Stufen derSoftwareentwicklung im V-Modell4 Abb. 1: Stufen des V-Modellseingegangen.1 IEEE 1012-2004, 2004, Abschnitt 5.4.52 IEEE 1012-2004, 2004, Abschnitt 7.8, Tabelle 13 Bspw. Interviews, Abschnitt 1.1.7 und 2.4.14 Vorgehensmodell der Softwareentwicklung, siehe Abb. 1 -2-
  5. 5. 1.1.1 KomponententestMit einem Komponententest (Modultest, Unittest) wird ein einzelner Programmteil aufFehler geprüft. Eine zu testende Komponente kann beispielsweise ein funktionales Modulim Sinne der Softwarearchitektur oder eine Klasse in der objektorientiertenProgrammierung sein. Diese Komponente wird isoliert vom Rest der Software getestet. Istdie Funktionalität einer Komponente beschränkt und genau definiert, lassen sich damit aufeinfache Weise erwartete Ergebnisse überprüfen.Im einfachsten Fall können die Schnittstellen einer Komponente anhand von Ein- underwarteten Ausgaben geprüft werden. Dabei werden auch Fehlerszenarien, wie dasVerhalten bei ungültigen Eingaben, getestet. Wenn eine Komponente auf weitereProgrammteile angewiesen ist, so müssen diese für den Test simuliert werden. In diesemFall wird von Mock-Objekten gesprochen, welche häufig mit entsprechenden Frameworksfür Datenbank- oder Datei-Mocks erstellt werden.Komponententests werden fast immer automatisiert durchgeführt5, wobei entsprechendeWerkzeuge, wie die vielzähligen xUnit-Frameworks6, Anwendung finden. Dies ermöglichtes, ein ganzes Set von Komponententests regelmässig auszuführen. Bei genügendgrosser Testabdeckung können Entwickler so in Erfahrung bringen, ob eineSoftwareänderung neue Fehler auslöst oder alte tilgt.In grösseren Entwicklungsteams kann es sinnvoll sein, die Ausführung und das Bestehender Komponententests als Bedingung für die Aufnahme neuen Codes zu definieren. DieTestausführung kann beispielsweise von einem Pre-commit hook7 desVersionierungssystems, 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, 20066 http://www.martinfowler.com/bliki/Xunit.html [23.9.2010]7 Automatisierte Programmausführung vor dem Einchecken in ein Versionierungssystem8 http://martinfowler.com/articles/continuousIntegration.html#MakeYourBuildSelf-testing [7.9.2010] -3-
  6. 6. 1.1.2 IntegrationstestDas Ziel eines Integrationstests ist es, die vorher durch Komponententests geprüftenProgrammteile 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 überderen interne Funktionsweise und Struktur ist für den Integrationstest also nicht nötig.Auch hier sollten sowohl gültige wie auch fehlerhafte Zwischenkomponenten-Interaktionengetestet 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 dessenkönnen gemeinsam geprüfte Programmteile in einem nächsten Schritt als einzelneKomponente verstanden werden, welche in Zusammenarbeit mit einer anderenzusammengesetzten Komponente getestet wird. Dieses stufenweise, n-äreZusammensetzen der Software wird als Bottom Up10-Ansatz bezeichnet.Häufig werden aber auch Mischformen mit Ansätzen wie Top Down 11 (umgekehrteZusammenbaureihenfolge) oder Big Bang12 (Zusammenarbeit der Komponenten imGesamtprodukt testen) verwendet.Bei Projekten mit mehreren Entwicklern wird mit Integrationstests die Zusammenarbeit vonKomponenten unterschiedlicher Autoren getestet. Schnittstellenspezifikationen und -änderungen werden demnach auf die Probe gestellt. In solchen Entwicklungsszenarienmacht es besonders Sinn diese Teststufe zu automatisieren.Integrationstests finden entgegen ihrer akademischen Definition im V-Modell aber auch inEin-Mann-Projekten ohne jegliche Komponententests Anwendung. Abhängig von derverwendeten Technologiepalette und der eingebauten Testbarkeit wird derAutomatisierungsaufwand unvertretbar hoch, sodass das Zusammenwirken derKomponenten in deren Entwicklungsphase vom Autor manuell getestet wird.1.1.3 SystemtestBeim Systemtest wird der Black Box-Ansatz weitergetrieben, wobei das ganzezusammengesetzte Software-System ohne Wissen über dessen inneren Aufbau getestetwird. Die Testumgebung simuliert dabei die spätere Produktivumgebung.9 Ohne Kenntnisse über die innere Funktionsweise, es werden nur öffentliche Schnittstellen betrachtet.10 BS 7925-111 BS 7925-112 BS 7925-1 -4-
  7. 7. In diesem Schritt testet die entwickelnde Organisation erneut die Funktionalität derSoftware, aber auch die Erfüllung nicht-funktionaler Anforderungen. Solche Anforderungenan Performanzverhalten, Sicherheitsvorkehrungen oder Gebrauchstauglichkeit müssengenau spezifiziert sein; ein späterer Abschnitt befasst sich mit derem Spezifizieren undTesten.Das Automatisieren von Systemtests kann sich als schwierig, beziehungsweiseunwirtschaftlich 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 demKunden zu präsentieren.1.1.4 AbnahmetestEin Abnahmetest (Acceptance test und User acceptance test) findet bei praktisch jedemfür einen Kunden entwickelten System statt, Umfang und Formalitätsgrad varieren jedochstark. IEEE 1012-2004 “Software Verification and Validation” definiert den Vorgang als“Formal testing conducted to determine whether or not a system satisfies its acceptancecriteria and to enable the customer to determine whether or not to accept the system.” 14 Indiesem Sinne wird im englischen Sprachgebrauch vielfach zwischen Acceptance testingund User acceptance testing unterschieden, wobei ersteres durch den Entwickler, undzweiteres durch den Kunden oder Anwender durchgeführt wird.Ein User acceptance Test dient meist als Abnahmekriterium für eine Software. Dabei solldie Funktionalität des Produkt mit realen Anwendungsszenarien überprüft werden, wobeivielfach 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 inagilen, testgetriebenen Entwicklungsmodellen Anwendung finden, können Anforderungenfür Abnahmetests sein. Weniger detailliert als Anwendungsfälle (Use Case), dafür einausführlicheres Benutzerszenario beschreibend, dienen sie der abstrakten Beschreibungder 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, 199914 IEEE 1012-2004, 2004, Abschnitt 3.1.1 -5-
  8. 8. 1.1.5 Nicht-funktionale TestsAus Anwendungsfällen, oder daraus abgeleitet, können die funktionalen Anforderungeneiner Software definiert werden. Sie beschreiben, was diese tun soll, wie sie alsoEingaben verarbeitet, und welche Ausgaben erwartet werden.Im Gegensatz dazu definieren die nicht-funktionalen Anforderungen, wie sich das Systemin allen anderen Belangen verhält. Diese Qualitätsauflagen können verschiedensteBereiche tangieren: Performanz, Sicherheit, Gebrauchstauglichkeit (Usability), Wartung,Robustheit, Erweiterbarkeit, Installation, Skalierbarkeit, Lokalisierbarkeit, Dokumentation etcetera15. Abhängig von Umfang, gesetzlichen Rahmenbedingungen, Einsatzgebiet und soweiter einer Software, fallen diese Nebenbedingungen unterschiedlich grosszügig aus.Einige dieser Anforderungen können im Sinne der Informatik und Informationstechnikgetestet werden, benötigen aber meist spezialisierte Kenntnisse ausserhalb derSoftwareentwicklung. Der vielfältige Bereich des Performanzverhaltens, welcher sich zumBeispiel mit der Skalierbarkeit, dem Zeitverhalten und der Verfügbarkeit eines Systemsbefasst, kann Kenntnisse zu Netzwerktopologie, Last-Erzeugung und Hardware-Verhaltenvoraussetzen. Um hingegen die Gebrauchstauglichkeit einer Software einzuschätzen, sindPsychologie-Kenntnisse, Design-Leitfäden oder spezielle Gerätschaften nötig.Diese diversifizierten Qualifikationsanforderungen führen zu einem hohen Aufwand desTestens und Erfüllens von nicht-funktionalen Anforderungen. Es wird deshalbvorgeschlagen, die Wichtigkeit dieser Anforderungen für den Kunden in Erfahrung zubringen.16Nicht-funktionale Tests werden üblicherweise in der Integrations- oder Abnahmephase desProjekts durchgeführt, wobei eine vielfältige Palette an freien, sowie kommerziellenWerkzeugen und Diensten verwendet werden kann.1.1.6 StandardisierungDas Ausmass und die Professionalität des Software-Testens hat sich in den letzten 30Jahren massiv gesteigert.17 Viele Softwareschmieden besitzen unterdessen Personal fürdas 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 zustandardisieren. Im folgenden einige aktuell gültige Standardisierungsdokumente zum15 Bspw. Chung; Leite, 200916 Melnik; Meszaros, 2009, Abschnitt 5.2.217 Gelperin; Hetzel, 1988, Abschnitt “Growth of professionalism” -6-
  9. 9. Thema, sowie ein mir vielversprechend erscheinender Entwurf für einen umfassendenISO/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 ElmerDr. Franz-Josef Elmer unterrichtet “Software Engineering” an der Universität Basel undarbeitet seit 1998 in der Softwareentwicklung. Er entwickelte in zwei- bis sechsköpfigenTeams 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 Unittestabdeckungweit unter 100% liegt, wahrscheinlich auch unterhalb von 50%.Meist gehen wir nach dem Prinzip “Code a little, test a little” vor. Geschriebener Codemuss also testbar sein, wobei die entsprechenden Tests nach der Fertigstellung einerEtappe umgesetzt werden.Reine testgetriebene Entwicklung ist bei uns kein Thema. Ich kann mir speziell in derexplorativen Anfangsphase der Entwicklung einer Software auch schlecht vorstellen, wiedas sinnvoll funktionieren soll.«Welche Entwicklungen konnten und können Sie beobachten?»In meiner Anfangsphase haben wir das gemacht, was man heute manuelle System- undAbnahmetests nennt, die Anwendung also einfach ausprobiert. In dieser Zeit wurden meistwasserfallartige Entwicklungsmodelle verwendet.Vor 10 Jahren bin ich zum ersten Malauf das Konzept des automatischen »Vor 10 Jahren bin ich zum erstenTestens gestossen. Nachdem ich Mal auf das Konzept desselber ein Framework entwickelt automatischen Testens gestossen.«habe, hat mich ein Kollege auf einenArtikel in der iX über JUnit, einem Testingframework, aufmerksam gemacht. -7-
  10. 10. Automatisiertes Testen hat sich in der Zwischenzeit entwickelt und ist in derSoftwareentwicklung zum Standard geworden. Der Trend zu iterativenEntwicklungsmethoden 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 sehrmit den GUI-Elementen verbunden.GUI-Tests sind generell heikel und brechen bereits bei kleinen Änderungen. KomplexeBenutzerschnittstellen und dadurch viele Eingabemöglichkeiten bringen einen hohenTestaufwand mit sich, wobei der Nutzen vielfach unklar bleibt.«1.2 EntwicklungenDie Koryphäen des Software-Testens Dave Gelperin und William C. Hetzel beschreiben181988 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 derZwischenzeit hat sich jedoch wiederum einiges getan.In den 90er-Jahren wird das Software-Testen professionalisiert, wobei das Thema imgrossen Stil diskutiert wird, beispielsweise an Konferenzen wie der “Software TestingAnalysis & Review” (STAR, seit 1992 19) oder der “Software & Systems Quality” (SQC, seit199620). Ausserdem wird 199121 erstmals der Standard ISO/IEC 9126 “Softwareengineering - 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. 11. Gleichzeitig entstehen testgetrieben sowie agile Entwicklungsmethoden wie Scrum 22 oderExtreme Programming23, bei welchen das Testen ein wichtiger Bestandteil desEntwicklungsprozesses ist. Speziell das Komponententesten, welches es demSoftwareautor ermöglicht, leicht automatierbare Tests für funktionale Anforderungen zuerstellen, gewinnt dadurch an Bedeutung. 1998 begründet und beschreibt der ZürcherErich Gamma zusammen mit dem Amerikaner Kent Beck das beliebte JUnit24.Das Software-Testen hat also einige Paradigmenwechsel durchgemacht, und wird sichauch zukünftig an neue Ansprüche und Technologien anpassen müssen.1.3 GUI-TestenAls Computerprogramme noch mehrheitlich mit einer Kommandozeile (CLI) gesteuertwurden, beschränkte sich die Benutzerschnittstelle auf eingegebenen Text und dietextuelle 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 besitzttypischerweise eine Vielzahl von Steuerelementen wie Schaltflächen, Bildlaufleisten,Menüs et cetera, welche gleichzeitig Eingaben entgegennehmen können. Durch diegrosse Anzahl solcher Elemente und die vielen möglichen Eingabe-Reihenfolgen ergibtsich schnell eine unüberschaubar grosse Anzahl von GUI-Zuständen.Aufgrund dieser problematischen Umstände ist es schwierig eine GUI durchgängig zutesten, und es wird nötig das Testen zu automatisieren.In der Praxis werden häufig manuelle Benutzerinteraktionsabläufe aufgezeichnet, um siedann mit einer entsprechenden Softwareautomatisiert abspielen zu können.Dadurch wird der manuelle Aufwand aufdas Aufzeichnen reduziert, und der Testkann beliebig oft wiederholt werden.Um eine GUI überhaupt automatisierttestbar zu machen, müssenBenutzerinteraktionen automatisierbarsein. Einige Ansätze führen Abb. 2: GUI-Testpläne für MS WordPad22 Takeuchi; Nonaka, 198623 Beck, 199924 Gamma; Beck, 1999 -9-
  12. 12. Benutzereingaben auf Betriebssystemebene aus25, sodass keine speziellen Vorkehrungenim zu testenden Programm vorgenommen werden müssen. Andernfalls kann ein GUI-Treiber in das Programm verbaut werden, über welchen ein anderes Programm die zutestende GUI mit Eingaben versorgen, und Ausgaben auslesen kann.Auch das Überprüfen der Ausgaben einer GUI mit einem automatisierten Test istproblematisch. Grafische Ausgaben können abhängig von der Laufzeitumgebung inDimensionen, Farben und Schriftarten variieren. Eine automatische Validierung erkenntsolche Unterschiede als Fehler, obwohl sie unter Umständen gewollt sind.2. Webauftritt-Testen2.1 GrundlagenGrössere Webauftritte (Website) sind heute üblicherweise sogenannte Webanwendungen,also Computerprogramme, die auf einem Webserver laufen. Grundsätzlich dient dabei derWebclient desAnwenders als ThinClient, wobei dieeigentlicheProgrammlogik alsCGI26-Programm, oderals integrierteAnwendung desWebservers auf einementfernten Rechnerausgeführt wird. Abb. 3: Datenfluss einer WebanwendungServer und Clientkommunizieren dabei mit dem Hypertext-Übertragungsprotokoll (HTTP) über eineNetzwerkverbindung, sodass im Idealfall eine fast verzögerungsfreie Benutzerschnittstellebereitgestellt werden kann.Diese Architektur bedingt im Vergleich mit einer klassischen, lokal laufenden Softwareeinige technische Unterschiede. Einerseits wird durch den Thin Client die Installation,Konfiguration und Wartung für den Anwender grössenteils hinfällig, und der Herstellerkann Softwareänderungen unverzögert zur Verfügung stellen, andererseits entsteht25 Z.B. “AutoHotkey”26 Common Gateway Interface, RFC 3875 - 10 -
  13. 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 Webanwendungenberücksichtigt werden.Im Webbereich kommen einige spezialisierte Techniken zum Einsatz, die unter Anderemein 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 erstensdie Programmlogik lose gekoppelt auf zwei physisch getrennten und technischverschiedenen Systemen (Client und Server) abläuft, und sich zweitens speziell dieAusprägungen nicht-funktionaler Anforderungen erheblich von denen klassischer Softwareunterscheiden können.2.2 EntwicklungenDie Disziplin des Webauftritt-Testens ist relativ jung. Grund dafür ist, dassWebanwendungen erst in den letzten zwei Jahrzehnten entstanden sind, wobei ihrKomplexitätsgrad in den letzten Jahren erheblich zugenommen hat.Eine der erstenWebanwendungen ist“SPIRES HEP” derStanford-Universität, welchees 1991 erlaubt, einenKatalog von Teilchenphysik-Publikationen zu Abb. 4: SPIRES HEP Benutzerschnittstelle, 1991durchsuchen27 .27 http://www.slac.stanford.edu/history/earlyweb/firstpages.shtml [7.9.2010] - 11 -
  14. 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 Kommunikationzwischen Client und Server (Ajax), eingesetzt wird. Damit kann die Benutzerschnittstelleim Webbrowser zügig und nahtlos auf Benutzereingaben reagieren, indem die auf demServer laufende Anwendung im Hintergrund mit JavaScript kontaktiert wird.Software fürs Webauftritt-Testen entsteht in dieser Ära. So publiziert Russell Gold im Jahr200035 die Version 1.0 von HttpUnit, welche es erlaubt Komponententests fürWebseitenaufrufe zu schreiben, ohne einen Webbrowser einsetzen zu müssen.Um die Jahrtausendwende gibt es also Bestrebungen, die Funktionalität von Webauftrittenzu überprüfen36 , namentlich den Kontrollfluss von Forms und Hyperlinks. Aber auch dasÜberprüfen nicht-funktionaler Anforderungen wie der Gebrauchstauglichkeit37 wirdthematisiert.Die wachsende wirtschaftliche Bedeutung während den letzten zehn Jahren vonWebanwendungen wie Google, Yahoo, Facebook und Co. hat dazu geführt, dass mehrRessourcen in die Qualitätskontrolle von Webanwendungen investiert werden. DieDisziplin des Webauftritt-Testens ist jung, und die Anwendungsfälle gehen starkauseinander.2.3 AnsätzeEs scheint sich bis heute kein Konsens gebildet zu haben, wie ein Webauftritt getestetwerden soll. Standardisierungsdokumente geben, durch ihre Langlebigkeit bedingt, wenigAuskunft. Verschiedenste Anforderungskataloge und technische Umsetzungen führen zueiner 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 Digitalisierung34 Bspw. Google 1998, Hotmail 1996, Yahoo 199535 http://sourceforge.net/mailarchive/message.php?msg_name=v03110704b5d5d324518e%40%5B207.106.60.98%5D [7.9.2010]36 Yang; Huang; Wang, 199837 Corry; Frick; Hansen, 1997 - 12 -
  15. 15. 2.3.1 KomponententestDie eigentliche Anwendungslogik einer Webapplikation, die auf einem Server läuft, kanngrösstenteils im Sinne der klassischen Softwareentwicklung betrachtet werden. Um sietestbar zu machen, sollte sie streng von der Benutzerschnittstelle getrennt sein. Dazu hatsich mehrheitlich das Model View Controller (MVC)-Paradigma etabliert. Dabei werden Anwendungslogik(Model), Präsentation (View) und Programmsteuerung(Controller) als möglichst unabhängige Einheitenbetrachtet, welche über Schnittstellen kommunizieren.Gängige Webanwendungs-Frameworks wie das ZendFramework, Catalyst oder JavaServer Faces erlaubenoder fordern die Entwicklung im MVC-Stil.In einem MVC-Projekt können die üblichenKomponententest-Frameworks für die entsprechendeProgrammiersprache verwendet werden, währendMock-Objekte die Datenquellen simulieren. Abb. 5: MVC-ParadigmaDie serverseitige Anwendungslogik ist aber nicht dieeinzige Stelle, an der Komponententests angewendet werden. Durch die zunehmendenInteraktionsmöglichkeiten von Web-Benutzerschnittstellen, wird vermehrt Programmlogikauf der Clientseite gebräuchlich. So lädt beispielsweise eine Facebook-Webseite um die600KB komprimierten JavaScript-Quellcode nach38 . Beliebte JavaScript-Bibliothekenhaben in ihren aktuellen Versionen erheblichen Umfang: jQuery 6240 Zeilen39 , MooTools4329 Zeilen40 und Dojo 11251 Zeilen41 Code.Dieser Teil einer Webanwendung wird nur selten automatisiert getestet. Der häufigprozedurale Programmierstil von JavaScript-Code und die enge Verknüpfung von Logikund Benutzerschnittstelle verringern die Testbarkeit. Gleichzeitig sind Webbrowser alswichtigste JavaScript-Interpreter nicht dafür ausgelegt, automatisierte Tests laufen zulassen.Trotzdem gibt es Bestrebungen, JavaScript-Komponententests auf verschiedenen Ebenenmöglich zu machen. Eine Variante ist es, die Anwendungslogik in einem Webbrowser zu38 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. 16. testen. Da sich die JavaScript-Interpreter der verschiedenen Webbrowser teilweiseerheblich unterscheiden, können dabei auch Interpreter-implementierungsspezifischeFehler aufgedeckt werden. Die Test-Frameworks sind dabei selbst in JavaScriptgeschrieben und bieten an die xUnit-Familie angelehnte Funktionalität.Andere Ansätze führen die zu testende Logik in einem besser kontrollierbaren, dezidiertenJavaScript-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, musshäufig festgestellt werden, dass ein Grossteil der serverseitigen Anwendungslogikclientseitig in JavaScript dupliziert wird. Das führt zu doppeltem Wartungs- undTestaufwand.Einige Webanwendungs-Frameworks versuchen diesen Missstand zu beheben, indemQuellcode in einer einzigen Programmiersprache beim Deployment in die entsprechendenTechnologien der Clientseite wie HTML, CSS und JavaScript übersetzt wird. WichtigeVertreter 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 derWirtssprache geschrieben werden, welche entweder im Wirtssprachen- oder JavaScript-Interpreter laufen können46 .2.3.2 IntegrationstestIntegrationstests an Webanwendungen werden grösstenteils mit zwei verschiedenenAnsätzen auf unterschiedlichen Ebenen der Software umgesetzt. Dabei soll festgestelltwerden, ob die möglicherweise vorher komponentengetesteten Programmteile auch alsGanzes ihre Funktionalität erfüllen.Um die reine Programmlogik auf dem Server zu testen, können HTTP-Anfragen simuliertund Antworten ausgewertet werden. Ein entsprechendes Testing-Framework mimt denBrowser eines Anwenders und erlaubt dadurch, die Client-Server-Kommunikation zuüberprüfen. Dazu müssen entsprechende Anfragen formuliert und, etwas aufwändiger, diemeist 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. 17. Um die Clientseite einer Webanwendung testen zu können, muss zudem das Verhaltendes Browsers testbar sein. Dazu müssen externe Ressourcen eines HTML-Dokumentswie CSS-Dateien, Bilder und JavaScript-Programme nachgeladen, die CSS-Regeln aufdie HTML-Elemente angewendet, und JavaScript ausgeführt werden.Diese Funktionalität steckt in bestehenden Endanwender-Browsern, welche tatsächlich fürIntegrationstests verwendet werden. Dabei muss der verwendete Browser von einerprogrammierbaren Umgebung ferngesteuert werden.Es existieren weitere Ansätze, in denen das Verhalten eines Browsers simuliert wird, dieWebseiten also nicht tatsächlich gerendert werden, ihr gesamtes Verhalten aber imHintergrund abläuft und über entsprechende Schnittstellen testbar ist.2.3.3 SystemtestAuf der Systemtest-Ebene werden Webauftritte meist auf nicht-funktionale Anforderungengeprüft. So kann es nötig sein eine neue Version einer Webanwendung vor ihrerAufschaltung 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ächlichproduktiven 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, 200849 Bspw. Wack; Tracy; Souppaya, 2003 - 15 -
  18. 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, 200651 BS 7925-1 - 16 -
  19. 19. Weitere nicht-funktionale Anforderungen an Webauftritte wie Barrierefreiheit,Lokalisierbarkeit oder Interoperabilität52 werden teilweise getestet, setzen aber meist auchKenntnisse ausserhalb des IT-Bereichs voraus, und erfordern viel manuellen Testaufwand.2.4 PraxisDie Webentwicklung ist ein vielfältig bepflügtes Feld. Webauftritte werden vonEinzelpersonen 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 derPraxis.2.4.1 Interview mit Urs Gürtler, NextronUrs Gürtler arbeitet seit zweieinhalb Jahren als Applikationsentwickler bei der “NextronInternet Team GmbH”54. Diese beschäftigt acht Mitarbeitende und erstellt seit 1996Webauftritte 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 Modulenergä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 etwa30% der Entwicklungszeit aufgewendet. Automatisierte Tests haben wir keine.An den fertigen Webauftritten werden je nach Kundenansprüchen manuelle Systemtestsdurchgeführt, um Anforderungen wie Sicherheit, Skalierbarkeit und Funktionalität zuprüfen.«Wird das Webseiten-Layout getestet?»Der Designer, welcher die Templates für das CMS erstellt, testet die korrekte Darstellungder Webseiten manuell in verschiedenen Browsern auf unterschiedlichenBetriebssystemen.«52 Bspw. Chung; Leite, 200953 http://www.day.com/day/en/company.html [7.9.2010]54 http://www.nextron.ch [7.9.2010] - 17 -
  20. 20. Welche Entwicklungen können Sie beobachten?»Die Ansprüche unserer Kunden steigen, die Webauftritte werden als wie komplexer. Diemeisten wollen irgendetwas Aussergewöhnliches auf ihrer Website.«2.4.2 Umfrage bei Webauftritt-BetreuernFolgende vier Fragestellungen habe ich an Webauftritt-Betreuer geschickt, umeinschä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 allebeteiligten 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 Entwicklerteams79% der Befragten geben an, ein Entwicklerteam mit ein bis zehn Mitarbeitenden zubeschäftigen. - 18 -
  21. 21. Anzahl Webentwickler 1-5 6-10 11-20 21-50 51-100Praktisch alle Befragten testen ihren Webauftritt auf die eine oder andere Art, undüberprüfen auch die korrekte Darstellung der Benutzerschnittstelle auf verschiedenenEndnutzersystemen.TestautomatisierungEine Mehrheit setzt an irgendeiner Stelle auf Testautomatisierung. AutomatischeBenutzerschnittstellen-Tests verwenden hingegen nur 12% der Entwicklerteams, welcheallesamt 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 SystemtestsBei den automatisiert getesteten Anforderungen überwiegen die funktionalen knapp dennicht-funktionalen. Eine leichte Mehrheit wird serverseitig getestet. - 19 -
  22. 22. Getestete Anforderungen Testausführung 11 10 8 7 Funktional Nicht-funktional Serverseitig ClientseitigVerwendete SoftwareZur Testautomatisierung werden folgende Software-Lösungen genannt: Selenium55 (4x),Grinder56, Google Website Optimizer57 , JUnit58, NUnit59, HP SiteScope60, HPLoadRunner61, 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. 23. 2.5 WerkzeugeIm Folgenden werden zehn beliebte Werkzeuge für verschiedene Aspekte des Webauftritt-Testens vorgestellt. Damit soll ein Überblick geschaffen werden, wobei mehrereQuellcode-Beispiele einen Einblick in die praktische Verwendung bieten.2.5.1 Serverseitige KomponententestsKomponententests für die serverseitige Anwendungslogik können mit Frameworks derxUnit-Familie implementiert werden. Der Extreme Programming-Mitbegründer Ron Jeffriesunterhä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 imWebbereich grosser Verbreitung erfreut.Das Werkzeug dient mit einer an xUnit angelehnten Schnittstelle als Komponententest-Framework, und berichtet über die Resultate von durchgelaufenen Tests, beispielsweisemit Testabdeckungs-Berichten.Im Folgenden ein beispielhafter Testfall “LoginLogout” mit den zwei Testmethoden“testLogin()” und “testLogout()”. Die Methoden “setUp()” und “tearDown()” werden vomTest-Framework vor beziehungsweise nach dem Abarbeiten der Testmethoden einesTestfalls ausgeführt. Im Beispiel erstellt “setUp()” mittels einer externen Hilfsklasse einBenutzerobjekt, und “tearDown()” stellt die verwendete Datenbank zum Schluss desTestfalls wieder auf den Ursprungszustand zurück. - 21 -
  24. 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ückgabewerteiner Methode) die geforderten Bedingungen erfüllt. So schlägt “assertTrue()” Alarm, wennder erste Parameter nicht true ist.PHPUnit kann in phpUnderControl66,eine Erweiterung für denkontinuierlichen IntegrationsserverCruiseControl 67, integriert werden.Damit kann die kontinuierlicheAusführung einesErstellungsprozesses mit demDurchlaufen von Komponententests Abb. 6: Testabdeckung mit phpUnderControlverknüpft werden. Entwickler erhaltenauf diese Weise zügig Rückmeldungen über allfällig fehlschlagende Tests imGesamtprodukt.66 http://phpundercontrol.org [7.9.2010]67 http://cruisecontrol.sourceforge.net [7.9.2010] - 22 -
  25. 25. 2.5.2 JavaScript KomponententestsMit dem Siegeszug von JavaScript als clientseitige Web-Programmiersprache 68 steigt dasBedürfnis nach JavaScript-Komponententests. In einem Browser laufend stellt dabeiinsbesondere die automatisierte Ausführung und Analyse der Tests eine Herausforderungdar.FireUnit (fireunit.org)FireUnit bietet Komponententest-Schnittstellen in JavaScript an und stellt Ergebnisse inder Mozilla Firefox-Webentwicklungs-Erweiterung Firebug an. Ursprünglich für dieEntwicklung von Firefox-Erweiterungen erdacht69 , kann FireUnit auch für das Testen vonWebauftritten verwendet werden.Die Software bietet einige Methoden zur Simulation von Benutzereingaben an, und enthältgrundlegende xUnit-Schnittstellen: fireunit.ok(true, "This should pass"); fireunit.ok(false, "This should fail"); fireunit.compare("This is expected", "This isnt expected", ! "Texts differ");Die Testsergebnisse werden in Firebug tabellarisch aufgeführt: Abb. 7: FireUnit-Ergebnisse in Firebug68 Crockford, 200869 http://www.softwareishard.com/blog/firebug/fireunit-testing-in-the-firebug-world/ [7.9.2010] - 23 -
  26. 26. QUnit (docs.jquery.com/Qunit)Die Funktionalität des JavaScript-Frameworks jQuery wird durch QUnit-Komponententestsgeprüft71 . QUnit kann aber ebenfalls für das Testen beliebiger JavaScript Anwendungenverwendet 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 isnt 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 Ergebnisanzeige2.5.3 HTTP IntegrationstestsBeim Einsatz spezieller HTTP-Dienste wie Reverse Proxys oder gar selbst entwickeltenHTTP-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 Skriptsprachegesteuert HTTP-Clients und -Server simulieren, wobei die stattfindende Kommunikationmit Bedingungen überprüft wird. Zusätzlich können Eingaben mit externenProgrammaufrufen 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. 27. Während der Ausführung der Befehle zeigt HTTest die gesamte HTTP-Kommunikation aufder Standardausgabe an.2.5.4 Browser IntegrationstestsNeben 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 undJavaScript ausführen. Die resultierenden Webseiten werden jedoch nicht auf denBildschirm gerendert, sondern stehen über Java-Schnittstellen zur Verfügung. Dieangebotene API erinnert stark an die übliche Verwendungsweise eines Browsers. Sokönnen Forms ausgefüllt und Links verfolgt werden. Gleichzeitig können via DocumentObject Model (DOM)72 an die Dokumentenstruktur gestellte Bedingungen überprüftwerden.Im folgenden Beispiel soll in einem JUnit-Testfall in Kombination mit HtmlUnit die Referenzeines 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 mittles71 Open Systems Interconnection model, ISO-Schichtenmodell von Kommunikationsprotokollen72 Schnittstellenspezifikation für den HTML- und XML-Zugriff - 25 -
  28. 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 automatisiertsteuern. Die Funktionalität der Software hinkt dafür den realen Browserversionenhinterher, speziell der JavaScript-Funktionsumfang, welcher auf Mozillas Rhino basiert.Selenium (seleniumhq.org)Selenium ist ein vielseitiges Integrationstest-Framework fürs Web. Es umfasst einerseitseine Firefox-Erweiterung, die dasAufzeichnen und Abspielen vonTestszenarien erlaubt (SeleniumIDE) und andererseits ein Systemfür die automatisierte Kontrolle vonWebbrowsern mittels Schnittstellen(Selenium Remote Control [RC]).Selenium RC besteht aus einemServer, der Browser öffnet, schliesstund ihnen als Proxy dient. Mit Hilfedieses Proxys kann in EchtzeitJavaScript in eine geladeneWebseite eingeschleust werden.Über Schnittstellen, die für Abb. 8: Selenium RCverschiedene Programmiersprachenzur Verfügung stehen, wird dieser “Remote Control Server” kontrolliert.Durch eigenständige Programme, oder mittels einem xUnit-Framework können damit inJava, Python, Ruby, C#, Perl oder PHP die Browser Firefox, Internet Explorer, Safarisowie Chrome ferngesteuert werden.Beispielhaft wird mit Java erneut das “href”-Attribut eines Links auf “sbb.ch” geprüft: - 26 -
  29. 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, sondernvon einer davon abgeleitete Klasse SeleneseTestCase. Damit werden im Testfallverschiedene 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 aufdas “href”-Attribut zuzugreifen.Um Selenium-Tests schneller und auf mehreren Betriebssystemen gleichzeitig laufen zulassen, wird Selenium Grid angeboten. Damit können in einem Testset Selenium RC-Instanzen auf verschiedenen Rechnern angesprochen werden. Um vomGeschwindigkeitsvorteil zu profitieren, müssen Tests parallel ablaufen - für JUnitverwendet man beispielsweise Parallel JUnit73 , welches Testfälle in Threads ausführt.Um die Verwirrung komplett zu machen, wird im Moment an Selenium 2 gearbeitet, eineVerschmelzung von Selenium und WebDriver (deshalb auch Selenium WebDrivergenannt).WebDriver ist ein ursprünglich von Google veröffentlichtes74 Projekt, mit dem ebenfallsverschiedenste Webbrowser automatisch gesteuert werden können. Anstatt dies mittelsJavaScript zu lösen, werden aber höherschichtige Ansätze verwendet, die spezifisch aufden 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 Browsernzü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. 30. Rund um SeleniumIm 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 SystemtestsAuch für nicht-funktionale Anforderungen kann es nötig sein Tests zu automatisieren. MitLasttests 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 zuerkennen und zu analysieren, muss auf dem entsprechenden System hohe Last simuliertwerden.p-unit (p-unit.sourceforge.net)Das seit zwei Jahren nicht mehr weiterentwickelte Benchmarking-Framework p-unit bietetsimple Java-Schnittstellen an, um die Laufzeit und den Speicherbedarf von ausgeführtemJava-Code zu messen.75 Component Object Model, Interprozesskommunikation unter Windows76 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. 31. Mit einem solchen Werkzeug kann beispielsweise die Ausführungszeit derAnwendungslogik einer Webanwendung gemessen werden. Dabei kann das Lastverhaltenvon Datenbankanfragen, der Dateizugriff oder die Ausführung von externen SkriptenObjekt von Interesse sein.Folgendes Beispiel misst den Zeitbedarf für das Berechnen aller Quadratwurzeln zwischen1 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 Antwortzeiteneines Webservers zu messen.Das Kommandozeilen-Werkzeug kann über Parameter dazu aufgefordert werden, einebestimmte Anzahl an HTTP-Anfragen gleichzeitig und wiederholt an einen Server zuschicken, und schlussendlich über die Antwortzeiten zu berichten. Ein solcher Berichtenthä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 244Sofern das Performanzverhalten der Anwendungslogik auf dem Server getestet wird, solltedarauf 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. 32. 2.5.6 Sicherheit SystemtestsEs gibt eine Menge an kommerziellen und quelloffenen Sicherheits-Werkzeugen fürWebanwendungen. Die meisten nennen sich Scanner und versuchen semi-automatisiertnach Schwachstellen wie SQL-Injection-Lücken zu suchen. Ein ausführliche Liste anProgrammen 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 selbstnennt es auch ein Erkundungs-Werkzeug. Herausragend ist vor allem die Performanz derSoftware. Eine schnelle HTTP-Implementierung in C soll bis zu 7000 Anfragen proSekunde an einen lokalen Server ermöglichen80 .Die Software sucht nach SQL-Injection-, XSS- und Pufferüberlauf-Lücken, aber auch nachweniger dramatischen Fehlern wie falschen MIME-Typen oder HTTP-Statuscodes.Die Erkundungs-Ergebnisse werden in einer interaktiv navigierbaren HTML-Seitepräsentiert.w3af (w3af.org)Das Web Application Attack and Audit Framework (w3af) ist ein Sicherheits-Scanner fürWebanwendungen, der inzwischen von Rapid781 gesponsert wird - eine Sicherheitsfirmadie 200982 das Penetrationstest-Framework Metasploit83 gekauft hat.Über eine Plugin-Infrastruktur verwaltet w3af die verfügbaren Scantaktiken. GrösserePlugin-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- oderDateiupload-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. 33. 3. Webseiten Layout-Testen: Screencompare3.1 ProblemEtliche Faktoren machen es unter gewissen Umständen wünschenswert, die clientseitigePräsentation einer Webanwendung auf visueller Ebene zu überprüfen, und diesenProzess zu automatisieren.3.1.1 Diversifizierte Client-LandschaftDie Darstellung und Ausführung von Webanwendungs-Benutzerschnittstellen wird durcheine Vielzahl von Webbrowsern übernommen. Deren Interpretierung von HTML-, CSS-und JavaScript-Anweisungen entscheidet darüber, wie ein Anwender die Webseiten zuGesicht bekommt.Es gibt seit jeher Bestrebungen, Webtechnologien über Browsergrenzen hinweg zustandardisieren. Die wohl einflussreichste Organisation diesbezüglich ist das World WideWeb Consortium (W3C)85, welches Standardisierungsdokumente zu HTML, XHTML, CSS,DOM, CGI und vielen weiteren Technologien veröffentlicht. Der ECMAScript-DialektJavaScript wird hingegen von der Ecma International86 standardisiert.Verschiedene Faktoren führen aber auch heute noch zu schlechter Interoperabilitätzwischen Browsern verschiedener Hersteller. Einerseits werden die Standardsunvollständig oder fehlerhaft umgesetzt, andererseits werden browserspezifischeFunktionalitäten eingeführt, da die Standards beispielsweise als unvollständig erachtetwerden87.Dies führt dazu, dass bei der Entwicklung von Webauftritten darauf geachtet werdenmuss, dass die Benutzerschnittstelle des Produkts bei den Endanwendern auch wirklichso aussieht und funktioniert wie erdacht. Es hat sich eingebürgert vor dem Produktstarteiner Webanwendung die Benutzerschnittstelle in mindestens zwei bis drei verschiedenenWebbrowsern einem Abnahmetest zu unterziehen.Der Grossteil eingesetzter Browser wird von fünf verschiedenen Unternehmen entwickeltoder getragen, namentlich Microsoft (Internet Explorer), Mozilla (Firefox), Google(Chrome), Apple (Safari) und Opera. Das kalifornische Webanalyse-Unternehmen NetApplications88 sammelt Benutzerinformationen von nach eigenen Angaben 160 Millionen85 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-Eigenschaften88 http://www.netapplications.com [7.9.2010] - 31 -
  34. 34. Webauftritt-Besuchern im Monat89. Anhand dieser öffentlich zugänglichen Daten setzt sichder 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 Explorerauch -Versionen. Das Zweite zeigt verschiedene sogenannte Layout-Engines, also dieeinem Browser zugrundeliegende Software, welche für das HTML-Rendering zuständigist.Die Zahlen belegen, dass eine Menge verschiedener Web-Clients verwendet wird. Auchder durch seine eigenwillige Interpretation von Webstandards bei Entwicklern verachtete90Internet Explorer 6 hat neun Jahre nach seiner Einführung noch einen beachtlichenMarktanteil.Auch die neusten Versionen von Browsern machen Entwicklern in mancher Hinsicht dasLeben schwer. Dies ist mehrheitlich darauf zurückzuführen, dass sich die verwendetenTechnologien rasant weiterentwickeln. So befinden sich zur Zeit die viel gelobtenStandards HTML5 und CSS 3 in Entwicklung. Im Rennen um gewiefteBenutzerschnittstellen für Webanwendungen werden Vorabversionen und eigeneInterpretationen dieser Technologien implementiert, wodurch Webauftritte wieder in denverschiedenen Browsern getestet werden müssen.3.1.2 Pixelgenaues DesignEs ist umstritten, wie sehr sich das Layout von Webseiten in verschiedenen Browsernunterscheiden darf91 . Vielfach macht es Sinn, nur einige Design-Bausteine genau zudefinieren, und diese in ein loses, mehrheitlich durch seine Struktur beschriebenes HTML-Dokument einzubetten. Dadurch gewinnt der Anwender gewisse Freiheiten, indem er die89 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. 35. Präsentation einer Webseite an eigene Bedürfnisse anpassen kann. Gleichzeitig wird dasDesign dadurch eher Inhaltsagnostisch, verträgt sich also mit aller Art von textuellen undmultimedialen Inhalten.Trotzdem kann es eine Anforderung sein,gewisse Design-Elemente oder ganzeWebseiten pixelgenau zu implementieren. Meistwerden solche Designs in einemBildbearbeitungs- oder Layoutprogrammentworfen, und müssen dann mittels HTML undCSS mit möglichst allen gängigen Browsernkompatibel umgesetzt werden.Solche pixelgenauen Designs sind vielfachbildlastig, werden aber vemehrt auch HTML-Markup und CSS gestützt implementiert. Abb. 9: CSS-Aufklappmenüs können Pixelgenauigkeit benötigenDadurch wird es meist schwieriger eine korrekteWiedergabe über Browsergrenzen hinweg zu erreichen.3.1.3 Bedarf nach visuellem Layout-TestenObig genannte Umstände führen dazu, dass die Präsentation gewisser Webseiten inverschiedenen Browsern mit einer Referenz verglichen wird. Dabei sind üblicherweisekleine Unterschiede wie beispielsweise in der Schrift-Darstellungen hinnehmbar, ananderen 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-FrameworkjQuery. Mit ihm kann ein Entwickler mit einigen Zeilen Quellcodeeine Bilddatei über eine Webseite im Browser legen. Diese liegtdann halbdurchsichtig und mit der Maus verschiebbar alsReferenz ü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- Überlagerungeinsetzbar und bietet mit einer einfachen GUI etwas mehr Komfort.Allerdings ist es nur in Firefox verwendbar. - 33 -
  36. 36. Das Überlagern einer Bilddatei vereinfacht das Überprüfen der visuellen Präsentation vonWebseiten, ist aber ein manueller Prozess.Bei komplexen Webanwendungen wird üblicherweise versucht server- wie auchclientseitigen Quellcode für mehrere Webseiten wiederzuverwenden. Dadurch wirdeinerseits Code-Duplizierung verhindert, was die Wart-, Test- und Erweiterbarkeitverbessert. Andererseits können dadurch clientseitige Hilfsdokumente wie CSS-Dateienwiederverwendet 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 derSoftware auswirken. In Verbindung mit einer grossen Anzahl unterschiedlicher Webseiteneines Webauftritts wird das zu einem Problem: Änderung eines Enwicklers an einereinzelnen Webseite können ungewollt Auswirkungen auf andere Webseiten haben, welchenur mit grossem Aufwand manuell zu entdecken sind.Eine solche Nebenwirkung einer Softwareänderung wird Regression, das Überprüfen aufsolche Unannehmlichkeiten Regressionstest92 genannt. Weil diese Tests bei möglichstjeder 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 einesganzen Webauftritts verändern, und damit unter Umständen in nur einer von hundertenWebseiten einen Layout-Fehler hervorrufen.In solchen Fälle sind automatisierte Regressionstests des Layouts wünschenswert.3.2 LösungsansatzAls Ansatz für visuelle Layouttests stelle ich eine automatisierte Variante von Referenz-Überlagerung auf Webseiten vor. Eine konkrete Implementierung in Java nenne ichScreencompare. 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. 37. • Automatisiert: Der visuelle Vergleich soll automatisiert stattfinden.Grundlegend funktioniert das Ganze analog einer manuellen Referenz-Überlagerung. Eswird also eine Bilddatei (Referenz) mit dem Render-Ergebnis eines Browsers verglichen.Um eine Webseite automatisiert zu laden und eventuelles JavaScript auszuführen mussdas Test-Framework den Browser steuern können. Dabei soll die existierendeFunktionalität von Selenium verwendet werden (es kämen aber auch andere Produkte inFrage, siehe Kapitel 2.5.4). Der Einfachheit halber wird nur der Viewport, also dersichtbare Teil einer Webseite im Browser, mit der Referenz verglichen.Der eigentliche Vergleich von Referenz und Rendering findet automatisiert mittels einesPixelvergleichs statt.3.3 Funktionsweise3.3.1 TestablaufScreencompare vergleicht Bilder des Viewports eines Webbrowsers. Dazu wird der zuverwendende Browser per Selenium ferngesteuert, um danach aus einem Screenshot desganzen Bildschirms den eigentlichen Viewport zu extrahieren. Die Erkennung desViewports auf dem Screenshot geschieht mittels farbbasierter Bildfreistellung, indem vorjedem Test eine rein grüne Webseite im Browser angezeigt wird.Obige Bildreihe stellt diesen Vorgang dar. Nachdem der Webbrowser gestartet ist, wird derHintergrund der Webseite mittels JavaScript grün eingefärbt. Dabei wird zusätzlichsichergestellt, dass das Browserfenster in maximaler Grösse dargestellt wird und - 35 -
  38. 38. vollständig sichtbar ist. Screencompare macht einen Screenshot und erkennt anhand dergrünen Fläche die Position und Grösse des Viewports.Danach werden die eigentlichen Webseiten aufgerufen, welche getestet werden sollen. Dadie Viewport-Position nun bekannt ist, kann aus einem Screenshot direkt der Viewport mitder angezeigten Webseite extrahiert werden.Zum Vergleich der aufgenommenen Webseiten-Bilder stehen einige Methoden zurVerfügung, welche auf unterschiedliche Weise deren Differenz berechnen und ausgeben.Das Framework ist darauf ausgelegt, in einem JUnit-ähnlichen Komponententestverwendet zu werden. Dazu wird JUnits TestCase als ScreencompareTestCase erweitert.Neben den gängigen JUnit-Methodensteht darin Funktionalität für dieBrowser-Steuerung, die Viewport-Aufnahme und für den Viewport-Vergleich zur Verfügung.ScreencompareTestCase verwendeteinen “Treiber”, welcher dieFernsteuerung des Browsersübernimmt. Im Normalfall wirdSelenium RC verwendet, allerdingssteht auch eine Implementierung fürSelenium WebDriver zur Verfügung.Ausserdem können eigene Treiber alsImplementierung der abstrakten Abb. 11: Funktionsprinzip ScreencompareKlasse Driver geschrieben werden.Die beiden Selenium-Treiber unterstützen zum jetztigen Zeitpunkt folgende Browser: - 36 -
  39. 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ängigerCode wird benötigt, um sicherzustellen, dass der Browser im Fenstersystem für denScreenshot sichtbar ist. Dies wird entweder mit AppleScript oder einer kleinen C++-MFC-Anwendung erledigt.3.3.2 VerwendungZur sinnvollen Auswertung aufgenommener Viewport-Bilder stehen inScreencompareTestCase einige öffentliche Methoden zur Verfügung. Im Folgenden wirdauf diese Funktionalität anhand von Beispielen eingegangen.Grundlegend empfiehlt es sich, einen von ScreencompareTestCase erbenden Testfall zuerstellen: 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 derentsprechende Browser mit der im Argument übergebenen URL geöffnet,beziehungsweise wieder geschlossen. Die Methode captureScreen() fängt dieangezeigte Webseite ein und gibt eine Instanz der Klasse Screen zurück. Diese hältneben dem eigentlich Bild auch Metainformationen wie die URL, den verwendetenBrowser und den Namen des entsprechenden Komponententests.Während ein Browser geöffnet ist stehen unter Anderem folgende Methoden zurVerfü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. 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() zurVerfü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ürBildunterschiede und eine Ausrichtungs-Anweisung übergeben. Die beiden Aufnahmenwerden 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 werdenkann, wieso der Testfall fehlschlug. - 38 -
  41. 41. Abb. 12: PDF-Report mit Firefox- und IE6-Screen sowie deren DifferenzAnhand eines weiteren Beispiels soll erläutert werden, wie Elemente auf einer Seite vorder Viewport-Aufnahme versteckt werden können. Dies kann nützlich sein, wenn eineSeite 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. DaSchriftzeichen in verschiedenen Browsern vielfach verschieden angezeigt werden, kannes wünschenswert sein, diese vor einem Referenzvergleich auszublenden.Nach jedem Zwischenschritt wird der Screen abgespeichert:In kurzen Entwicklungszyklen aktualisierte Webauftritte erfordern besondere Wachsamkeitbezüglich der korrekten Darstellung im Webbrowser. Eine überschaubare Änderung amQuellcode einer Webanwendung kann Render-Probleme in einzelnen Client-Konfigurationen auslösen, welche nur mit grossem Aufwand manuell auffindbar sind. - 39 -
  42. 42. Screencompare bietet verschiedene Möglichkeiten, automatisierte Regressionstests dervisuellen Darstellung einer Webanwendung durchzuführen, indem Screens verschiedenerProgrammversionen verglichen werden.Im Folgenden Beispiel wird das Layout einer Webseite abgespeichert, um es später mitdem Referenzlayout einer neuen Webauftrittsversion zu vergleichen.Dieser erste Teil des Regressionstests öffnet zwei Webseiten und speichert derenDarstellung 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 imDatenverzeichnis 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 diesemabgespeicherten Zustand: - 40 -
  43. 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 Datenverzeichnisgeladenen Referenzen verglichen. Unter der Annahme, dass sich das visuelleErscheinungsbild 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 diekonkreten 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. 44. Bei der Entwicklung grosser Webauftritte, welche hunderte bis tausende unterschiedlicheWebseiten beinhalten, kann mit Hilfe einer solchen Regressionstest-Strategie mit wenigAufwand dem entstehen neuer Darstellungsfehler in verschiedenen Client-Konfigurationenentgegengetreten werden.3.3.3 VerfügbarkeitScreencompare 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 dieTestausführung und -entwicklung mit möglichst geringem Aufwand ermöglichen soll. Darinsind alle benötigten Bibliotheken, einige Beispiel-Tests sowie zwei Skripten zum Ausführenvon 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.ZusammenfassungTesten ist als integraler Bestandteil der Softwareentwicklung akzeptiert. In modernenEntwicklungsmodellen ist diese Disziplin zentral verankert. Gleichzeitig kommen speziellim Web-Bereich eine Vielzahl kleiner bis mittelgrosser Projekte ohne jeglicheTestautomatisierung aus.Dies scheint einerseits mit dem strukturell komplexen Technologiemix, und andererseitsmit teilweise unausgereiften und damit aufwändig zu implementierenden Testkonzeptenzusammenzuhängen.In dem momentan sehr dynamischen Feld der Webtechnologien und der daraufaufbauenden Frameworks gibt es allerdings viele Bestrebungen nach einfacherTestbarkeit und technologieübergreifenden Lösungen94 .Aus meiner eigenen Erfahrung in der Webentwicklung komme ich zum Schluss, dass dieTestbarkeit möglichst aller Aspekte einer Webanwendung erstrebenswert ist, wobei dieAnforderungen verschiedener Projekte jeweils unterschiedliche Ansätze verlangen. Diekurzen Entwicklungszyklen in diesem Bereich sprechen fast immer für die Automatisierungdes Testarsenals, wobei anforderungsübergreifende Werkzeuge wünschenswert sind, umden 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. 45. Mit Screencompare ist ein Prototyp für automatisiertes Layout-Testen auf visueller Ebeneentstanden. Dieser kann hoffentlich als Inspiration dienen und Entwicklern helfen, dieentsprechende Anforderungen prüfen möchten. Durch seinen modularen Aufbau istScreencompare einfach erweiterbar und kann für die Verwendung in verschiedenstenProjekten angepasst werden. - 43 -
  46. 46. QuellenAbbildungen1. 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 erstellt6. Manuel (2010): Screenshots. http://phpundercontrol.org/screenshots.html [7.9.2010]7. Selbst erstellt8. 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 erstellt13. Selbst erstelltLiteratur• 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. 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 Worlds Most Misunderstood Programming Language Has Become the Worlds 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 cooks 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. 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 -

×