Web-basierte Tests Julian Aumiller, Christian Dins Index: 1. Geschichte des Internets 2. World Wide Web Consortium Standard 3. Webseitenaufbau 4. Web-basierte.

Präsentation zum Thema: "Web-basierte Tests Julian Aumiller, Christian Dins Index: 1. Geschichte des Internets 2. World Wide Web Consortium Standard 3. Webseitenaufbau 4. Web-basierte."—  Präsentation transkript:

1 Web-basierte Tests Julian Aumiller, Christian Dins Index: 1. Geschichte des Internets 2. World Wide Web Consortium Standard 3. Webseitenaufbau 4. Web-basierte Tests 5. Capture and Replay

2 Geschichte des Internets 1971: Die Protokolle Telnet und FTP (File Transfer Protocol) werden entwickelt. 1973: Das Protokoll TCP (Transmission Control Protocol) wird entwickelt. 1977: Das Protokoll IP (Internet Protocol) wird entwickelt. 1979: Das Usenet entsteht durch Vernetzung zweier Unix-Maschinen der Duke University und der University of North Carolina. 1983: TCP/IP löst das NCP (Network Control Protocol) als Standprotokoll ab. 1984: Das DNS (Domain Name Solving) System wird entwickelt und in Betrieb genommen. 1986:.de wird offizieller Domainname Deutschlands. 1990: Tim Berners-Lee entwickelt den ersten Webserver httpd (HyperText Transfer Protocol Daemon). 1991: Das World Wide Web wird weltweit zur allgemeinen Benutzung freigegeben. 1994: Das W3C (World Wide Web Consortium) wird von Tim Berners-Lee in Zusammenarbeit mit CERN, RARPA und der Europäischen Kommission in's Leben gerufen. Das W3C soll Internetstandards erarbeiten und verwalten. 1995: Der Apache Webserver wird veröffentlicht. Er nennt sich ebenfalls httpd. So genannte LAMP-Server hosten heute mehr als 59.36 % aller Webauftritte und mehr als 66.56 % der meistbesuchten 1 Mio.

3 W3C Standards Auszeichnungssprachen ➔ HTML ➔ XML ➔ XHTML Stylesheetsprachen ➔ CSS Grafikformate ➔ PNG (Rastergrafik) ➔ SVG (Vektorgrafik) Dokumententypdefinitionen (DTDs)

4 Webseitenaufbau 3.1. HTML und XHTML HTML und XHTML werden für die textuelle Darstellung eines Webdokuments und für die Verknüpfung zu weiteren Dokumenten verwendet. Die einzelnen Komponenten können per definierter ID beispielsweise per Stylsheet angesprochen werden. HTML und XHTML unterscheiden sich hauptsächlich in ihrer Syntax, da diese von verschiedenen Basissprachen abgeleitet wurden. HTML (HyperText Markup Language) → SGML (Standard Generalized Markup Language) XHTML (Extensible HyperText Markup Language) → XML (Extensible Markup Language)

5 Webseitenaufbau 3.2. Cascading Style Sheets Die Stylesheetsprache CSS ist unter anderem für das Design einzelner Elemente gut. Auch das festlegen verschiedener Layouts kann per CSS erfolgen. Früher wurde hierfür ebenfalls HTML verwendet, was allerdings heutzutage als sehr unschön tituliert wird.

6 Webseitenaufbau 3.3. Statische und dynamische Webseiten Eine statische Webseite besteht aus einem (X)HTML-Dokument, welches über eine fest definierte URL (Uniform Ressource Locator) von einem Server geladen und angezeigt wird. Statische Webseiten eignen sich vor allem für kleinere Webauftritte, da jede Unterseite einzeln beschrieben werden muss. Eine dynamische Webseite besteht in der Regel aus einem (X)HTML Template, welches mittels einer serverseitige Programmiersprache mit Platzhaltern versehen ist. Ein solches (X)HTML Template kann für beliebig viele Unterseiten verwendet werden.

7 Webseitenaufbau Die Platzhalter werden bei Bedarf durch ein Skript, welches in einer serverseitigen Scriptsprache verfasst ist, mit Informationen belegt. Diese Informationen können beispielsweise von einer Berechnung oder aus dem Ergebnis einer Datenbankabfrage stammen. Welche Informationen benötigt werden, wird über einen dynamisch erzeugte URI (Uniform Ressource Identifier) festgelegt.

8 Webseitenaufbau 3.4. Fehlerquellen Mögliche Fehler bei einer Webseite oder Webanwendung sind: ● Syntaktische Fehler (Programmcode enthält unzulässige Anweisungen) ● Semantische Fehler (Anwendung verhält sich nicht so, wie vorgesehen) ● Browserinkompatibilität ● Falsche Adressen bei Hyperlinks ● Falsche Platzierung von Elementen

9 Web-basierte Tests 4.1 HTML - Syntaxprüfung Für die HTML Syntaxprüfung gibt es einen Validator, welcher die Übereinstimmung eines Dokumentes mit einem gegebenen Standard überprüft. Da die Validierung automatisch erfolgt, kann jedoch lediglich die syntaktische Korrektheit überprüft werden.

10 Web-basierte Tests 4.2 Dokumententypdefinition Die Dokumententypdefinition beschreibt einen Standard, welcher festlegt wie Dokumente eines bestimmten Typs zu deklarieren sind. Hierfür gibt es für verschiedene Sprachen mehrere Varianten: Strict: Strengste Definitionen wie zum Beispiel es dürfen keine Formatierungselemente im HTLM-Code verwendet werden. Transitional: Alle Elemente aus der Strict-Variante dürfen werdent werden. Außerdem dürfen Formatierungselemente im HTLM-Code verwendet werden. Frameset: Alle Elemente aus der Transitionale Variante dürfen verwednet werden. Es werden Elemente zur Erstellung eines Framesets bereitgestellt.

11 Web-basierte Tests 4.3 CSS-Syntaxprüfung Der CSS-Validator prüft den CSS-Code ebenfalls auf syntaktische Korrektheit und bezieht sich hierbei auf die jeweilige CSS-Version.

12 Web-basierte Tests Browserkompatibilität:

13 Web-basierte Tests 4.5 Broken Link Verfolgung Mit Broken Link kann man die Verlinkungen auf einer Webseite überprüfen. Von W3C wird ein solches Tool zur Verfügung gestellt. Man kann dort eine URL zur Überprüfung eingeben.

14 Web-basierte Tests Diverse Optionen, zum Beispiel auch eine Rekursionstiefe, können eingestellt werden. Bei einer Rekursionstiefe von 0 wird die angegebene Adresse aufgerufen und alle darauf Verfügbaren "Links" (dies betrifft nicht nur direkte Weblinks, sondern z. B. Auch Anker, Bilder, Stylesheets und clientseitige Scriptdateien) werden daraufhin auf ihre Verfügbarkeit überprüft. Bei Rekursionstiefe 1 wird dies auch für jede der gerade geprüften Dateien gemacht und so weiter.

15 Web-basierte Tests Wenn man davon ausgeht, dass jede Seite immer 10 weitere Ressourcen einbindet, ergeben sich folgende Anzahl an Seitenabrufen: ● Rekursionstiefe 0: 10 Ressourcen werden abgerufen ● Rekursionstiefe 1: 100 Ressourcen werden abgerufen ● Rekursionstiefe 2: 1000 Ressourcen werden abgerufen Oftmals werden aber deutlich mehr Ressourcen eingebunden, deshalb kann die Dauer der Überprüfung mit zunehmender Rekursionstiefe extrem stark ansteigen. Es empfiehlt sich daher, mit geringen Rekursionstiefen zu beginnen und sich langsam voranzutasten.

16 Web-basierte Tests 4.6. Firebug Mit Firebug kann man eine Webseite in Echtzeit debuggen und modifizieren. Beispiel: Ein Kunde möchte das Layout seines Internetauftritts ändern lassen. Da aber noch keine Erfahrungswerte verfügbar sind, muss ein wenig experimentiert werden.

17 Web-basierte Tests Der normale Vorgang hierzu wäre, eine Anpassung in der CSS- Datei vorzunehmen, diese auf den Server hochzuladen und das Ergebnis im Browser zu begutachten. Dieser Vorgang wird dann iterativ so lange wiederholt, bis man passende Werte gefunden hat. Dies ist recht aufwändig, war aber vor der Erfindung von Firebug die einzige Möglichkeit, diese Anpassung vorzunehmen. Ohne Firebug stellt der Browser die Seiten so dar, wie er sie vom Server geliefert bekommt. Als Benutzer hat man keinerlei Möglichkeiten, einzusehen, was der Browser genau tut. Man sieht nur das Ergebnis des Rendervorgangs.

18 Web-basierte Tests Firebug hingegen ermöglicht es, clientseitig Änderungen an der Seite vorzunehmen, während sie dargestellt wird. Diese Änderungen erfolgen über das so genannte Document Object Model, die interne Repräsentation des dargestellten Dokuments, die auch über clientseitige Scriptsprachen bearbeitet werden kann. Um eine Änderung vorzunehmen, muss man lediglich auf den entsprechenden Wert in der Baumdarstellung des Document Object Models klicken und neue Werte eingeben. Außerdem können neue Knoten in das Document Object Model eingefügt oder aus diesem entfernt werden. Die Änderungen werden sofort übernommen, sodass die Auswirkungen unmittelbar sichtbar werden.

19 Web-basierte Tests Firebug kann auch die Kommunikation des Browsers mit dem Webserver analysieren (z. B. Header und Inhalte der HTTP-Anfragen und -Antworten) und darstellen, was insbesondere bei der Fehlersuche in Webanwendungen auf Basis von XmlHttpRequest (sog. “Ajax-Anwendungen“) unabkömmlich ist.

20 Web-basierte Tests 4.7. Belastungstests Mit einem Belastungstest kann überprüft werden, wie leistungsfähig ein Server unter hoher Belastung ist und ob unter hoher Last Fehler auftreten. Im Internet sind einige Kommerzielle Belastungstest zu finden, die als Service laufen. Es ist eine Registrierung erforderlich, sowie die Angabe der Webseiten, die Überprüft werden sollen.

21 Web-basierte Tests Im einfachsten Fall sind lediglich URLs anzugeben, die von dem Service abgerufen werden sollen. Aufwändigere Varianten erlauben die Simulation des konkreten Verhaltens bestimmter Benutzer, etwa in welcher Reihenfolge bestimmte Seiten angesteuert werden sollen, welche Daten in Formulare eingetragen werden, etc. So kann der Service z. B. massenweise Accounts erstellen, Artikel in den Warenkorb legen und so weiter.

22 Web-basierte Tests Mithilfe dieser Methode kann man beispielsweise feststellen, ab wie vielen Benutzern die Antwortzeit der Seite einen gewissen Grenzwert überschreitet oder ab wie vielen gleichzeitigen Anfragen es passieren kann, dass der Benutzer der Seite einen Timeout bekommt. Da Benutzerzahlen aber meistens nicht sprunghaft ansteigen, sondern langsam wachsen, sind andere Daten oft interessanter. Etwa können mit solchen Tools auch Engpässe aufgedeckt werden, sodass der Anbieter einer Webanwendung entscheiden kann, ob sich z. B. die Anschaffung eines leistungsfähigeren Datenbankservers lohnt, oder ob der HTTP-Server bzw. die Anbindung an der externe Netzwerk die Leistungsfähigkeit limitiert. Wenn es um die Anschaffung größerer Serverkapazitäten geht, kann das Ergebnis des Lasttests als Anhaltspunkt herangezogen werden.

23 Capture and Replay 5.1. Was ist ein Capture and Replay Test? Bei einem “Capture and Replay“-Test werden manuell Testabläufe erfasst und in einem Script gespeichert, welches jederzeit automatisch wiederholt werden kann. →Automatisierung

24 Capture and Replay 5.2 Die Testautomatisierung ➢ Manuelles Testen kann unzuverlässig sein ➢ Manuelles Testen verleitet zu falscher Sicherheit ➢ Sehr hohe Aufwandskosten durch häufige Wiederholung der Tests ➢ Tests können nicht immer gleichermaßen ablaufen

25 Capture and Replay

26 Capture Mode Der Benutzer zeichnet eine Interaktion mit einem Capture & Replay Tool auf und speichert die Ablaufschritte und Eingabeparameter in einem Skript ab. Programming Mode Die im Capture Mode generierten Testschritte werden in Skripten gespeichert. Mit Hilfe der Skripte können dann komplexe Testszenarien erstellt werden. Mehrere Testszenarien können dann zu einer Testsuite zusammengefasst werden.

27 Capture and Replay Festlegen von Checkpoints Checkpoints sind definierte Zeitpunkte während der Testdurchführung, zu denen der momentane Zustand einer Webanwendung, z.B. Seiteninhalte oder Datenbankinhalte, mit einem Sollwert verglichen werden. Falls beim festlegen der Checkpoints Unstimmigkeiten mit dem Testszenario auftauchen, kann das Szenario noch einmal geändert werden. Replay Mode Im Replay Mode kann man den im Skript gespeicherten Test wiederholen.

28 Capture and Replay Evaluation / Umprogrammieren der Anwendung Nach Beendigung des Tests wird ausgewertet ob der Testlauf erfolgreich war. Falls dies der falls sein sollte wird der Test wiederholt, anderenfalls wird dieser analysiert und ein neuer Test erstellt. Vorteile Testen aus Benutzersicht Kunde kann selbst testen

29 Capture and Replay Mögliche Probleme ➢ relevante Layouts oder Objekt-IDs werden geändert ➢ bereits geänderte Daten befinden sich noch im Cache ➢ Aufgezeichnete Szenarien waren nicht fehlerfrei oder nicht gut durchdacht ➢ der aktuelle Softwarezustand ist fehlerhaft