Automatisiertes Testen von Web-Applikationen

Aus Winfwiki

Wechseln zu: Navigation, Suche
Name der Autoren: Nihat Cikrak, Michael Zura
Titel der Arbeit: Automatisiertes Testen von Web-Applikationen
Hochschule und Studienort: FOM Neuss



Inhaltsverzeichnis


1 Einleitung

Dieser Wiki - Beitrag stellt die Ergebnisse der Fallstudie I mit dem Thema "Automatisiertes Testen von Web-Applikationen" dar. Die Fallstudie I ist Bestandteil im Rahmen des Studienganges für Dipl. Wirtschaftsinformatiker an der Fachhochschule für Ökonomie und Management (FOM). Sie entstand unter der Aufsicht von Herrn Prof. Dr. Uwe Kern.

2 Grundlagen

Die Herstellung einer Software wird üblicherweise kontinuierlich darauf kontrolliert, ob die Anforderungen an die Software eingehalten werden. Ist ein Softwareprodukt fehlerhaft so müssen Korrekturen vorgenommen werden. Da Software ein immaterielles Gut ist, erweist sich die Prüfung der Software als schwierig. Im Vergleich zu einem Industrieprodukt, wo häufig eine einfache optische Sichtprüfung schon ausreicht, benötig eine Software eine besondere Untersuchung. Mit dem Testen der Software sollen zwei der wichtigsten Anforderungen an eine der Software aufgedeckt werden:

  • entspricht die Software überhaupt den Anforderungen
  • Verringerung der Fehler einer Software im Produktiveinsatz

Doch bevor mit einem Softwaretest begonnen werden kann, muss erst einmal festgelegt werden, wann ein nicht anforderungskonformes Verhalten der Software vorliegt. Das geht nur, wenn schon im Vorfeld festgelegt worden ist, wie die erwartete und korrekte Funktionalität aussehen soll. Ein Fehler liegt dann zu Grunde, wenn der Ist-Zustand von dem Soll-Zustand abweicht. Zum Beispiel soll ein Programm zwei Zahlen addieren und die Summe ausgeben. Ein Fehler dann liegt vor, wenn das Programm die Summe der Zahlen nicht ausrechnet und ausgibt.
Zu unterscheiden ist ein Fehler von einem Mangel. Ein Mangel tritt dann ein, wenn die Software zwar die Funktion an sich erfüllt, das Ergebnis aber nicht den Erwartungen entspricht. Wie in dem zuvor erwähnten Beispiel würde uns das Programm zwar die Summe aus zwei Zahlen (2+6=) ausrechnen und anzeigen, das Ergebnis (=9) wäre allerdings falsch.
Ein Softwareprodukt unterliegt nicht der Alterung oder dem Verschleiß, somit ist jeder Fehler und Mangel seit dem Zeitpunkt der Entwicklung vorhaben. Erst bei der Anwendung der Software werden Fehler sichtbar.[1]

2.1 Softwaretest

Der Softwaretest ist eines der häufigsten gebrauchten analytischen Methoden der Qualitätssicherung. Das Funktionsprinzip ist relativ einfach: das zu untersuchende Programm wird mit Hilfe von bestimmten Eingabedaten ausgeführt. Der Ist-Zustand wird mit den Daten des Soll-Zustandes verglichen. Die hieraus ermittelnden Daten dienen dem Entwickler als Anhaltspunkt um mögliche Fehlerquellen zu ermitteln.
Die IEEE Standard Glossary of Software Engineering Terminology definiert den Begriff des Softwaretest als: "An activity in which a system or component is executed under specified conditions, the results are observed or recorded, and an evaluation is made of some aspect of the system or component."
Um dem handwerklichen Charakter eines Softwaretest hervorzuheben, haben Craig und Jaskiel eine erweiterte Definition des Begriffs auf der Prozessebene definiert: "Testing is a concurrent lifecycle process of engineering, using and maintaining testware in order to measure an improve the qualiy of the software being tested."[2]

2.2 Softwarequalität

Das Testen dient der Identifizierung von Fehlern und deren anschließenden Beseitigung zur Steigerung der Softwarequalität. Testfälle werden dabei so gewählt, dass diese dem späteren Einsatz ähneln. Die Norm ISO 9126 definiert mehrere Faktoren:

Funktionalität "[...]umfasst alle Charakteristiken, welche die geforderten Fähigkeiten des Systems beschreiben. Die Fähigkeiten werden meist durch ein spezifiziertes Ein-/Ausgabeverhalten und/oder eine entsprechende Reaktion oder Wirkung des Systems auf entsprechende Eingaben beschrieben. Aufgabe des Tests ist es, nachzuweisen, dass jede einzelne geforderte Fähigkeit im System so realisiert wurde, dass das spezifizierte Ein-/Ausgabeverhalten oder die spezifizierte Reaktion erfüllt wird."[3]

Teilmerkmale der Funktionalität sind:

  • Angemessenheit (jede geforderte Fähigkeit ist im System enthalten)
  • Richtigkeit (die geforderten Fähigkeit machen was sie sollen)
  • Interoperabilität (Zusammenspiel zwischen Testsystem und dem späteren Einsatzsystem)
  • Ordnungsmäßigkeit (Normen, Vereinbarungen, gesetzliche Bestimmungen und ähnliche Vorschriften werden eingehalten)
  • Sicherheit (unberechtigter Zugriff auf Daten und Programme wird verhindert)[4]
Zuverlässigkeit ... meint weitgehende Fehlerfreiheit und Ausfallsicherheit. Die eingegebenen Eingaben liefern stets korrekte Ergebnisse. Ausfallsicherheit meint, dass selbst nach technischen Störungen wie Stromausfall, Rechnerabsturz oder Netzwerkausfall, keine Daten verloren gehen oder die Ergebnisse verfälscht werden.
Benutzbarkeit ... gehört zu den subjektiven Qualitätsmerkmalen. Dazu zählt die Erlernbarkeit des Programms. Diese meint den zeitlichen Aufwand und dem Umfang an Schulungen, Lernprogrammen, Online-Hilfen und Hotline-Service für den Anwender. Die Bedienung eines Programms sollte möglichst einfach sein; dazu zählen ein einheitlicher Programmaufbau, schlüssige Menüstrukturen und eindeutige graphische Symbole.
Effizienz ... meint den sparsamen Umgang mit Ressourcen (Speicher, CPU, Papier, Netzwerk, Speichermedien) und hohe Ausführungsgeschwindigkeit.
Änderbarkeit u. Übertragbarkeit ... meint Portabilität und Kompatibilität auf unterschiedliche Hardware und Betriebssysteme. Eine Software ist kompatibel, wenn das neue System ohne Veränderung der Systemumgebung eingesetzt werden kann. Eine Software ist portabel, wenn sie ohne weiteres auf eine neue Systemumgebung übertragen werden kann. Unter Änderbarkeit versteht man die Fähigkeit der Software, sich an wechselnde Aufgaben innerhalb des Einsatzgebietes anzupassen. Auch die Behebung von Fehlern mit möglichst wenig Aufwand gehört dazu.

Tabelle 01: Norm ISO 9126

Diese sind beim Testen der Software zu berücksichtigen, damit eine Gesamtqualität beurteilt werden kann. Welches Qualitätsniveau erreicht werden muss, muss vorher mit dem Kunden abgesprochen werden und als Qualitätsanforderung gestellt werden. Geeignete Test sind zu machen, um diese Qualitätsanforderungen zu beweisen.[5]

2.3 Test Kontexte

Das folgende Unterkapitel beschäftigt sich mit Methoden, Techniken und Abläufen von Softwaretests.

2.3.1 Dynamische Tests

Dynamische Tests bieten verschiedene Methoden und Techniken an, die bei der Konstruktion eines Testfalls zum Einsatz kommen. Im Folgenden werden die beiden Black-Box-Test und White-Box Verfahren erklärt. Gray-Box Verfahren werden in dieser Fallstudie nicht behandelt und werden nur vervollständigend erwähnt.

2.3.1.1 Black-Box Verfahren

Die Testfälle der Black-Box Verfahren behandeln nur Ein- und Ausgabedaten der Software. Dabei wird nur die externe Struktur behandelt. Der Code und die internen Funktionen werden nicht berücksichtigt. Insgesamt werden bei dem Black-Box Verfahren mehrere Methoden eingesetzt. Die beiden häufigsten werden im Folgenden näher beschrieben werden.
Äquivalenzklassentest
Mit einer möglichst kleinen Anzahl an Testfällen, soll ein möglichst vollständiger Test durchgeführt werden. Die Durchführung eines solchen Tests wird in zwei Schritten unterteilt. Anhand eines kleinen Beispiels wird ein solcher Verlauf dargestellt.
Der Tester muss im ersten Schritt den Wertebereich für die einzugebenden Variablen definieren. Für diesen Wertebereich wählt er einen passenden Repräsentanten, der mit hoher Wahrscheinlichkeit später vom Anwender auch benutzt wird, aus und berücksichtigt diesen Wert beim testen. Zudem müssen noch Wertebereiche definiert werden, die auf keinen Fall vorkommen dürfen.[6]
Als Beispiel wird ein Program berechne_preis getestet, welches den Endpreis eines Autos berechnen soll. Die Eingabevariablen sind: grund_preis (Grundpreis des Wagens), sondermodell_preis (Preisaufschlag für das Sondermodell), zusatzausstattung_preis (Preisaufschlag für Sonderausstattung des Wagens) und rabatt (der gewährte Händlerrabatt). Eine gültige Äquivalenzklassen wird mit gÄk, eine ungültige Äquivalenzklassen wird mit uÄk und eine Not a Number wird mit NaN abgekürzt.

Parameter Äquivalentklasse Repräsentant
grund_preis
gÄk: 0<max
uÄk: 0>max
NaN 		30000
-20000
"abc"
sondermodell_preis
gÄk: 0<max
uÄk: 0>max
NaN 		2550
-3600
"abc"
zusatzausstattung_preis
gÄk: 0<max
uÄk: 0>max
NaN 		6300
-4800
"abc"
rabatt
gÄk: 0=<x<=100
uÄk: x<0,x>100
NaN 		20
-40
"abc"

Tabelle 02: Äquivalenzklassen

Im nächsten Schritt werden die einzelnen Werte kombiniert und getestet, wodurch sich die nächste Matrix bildet. Mit Hilfe dieser lassen sich mögliche Fehler beheben. Allerdings ist festzuhalten, dass die Matrix sehr schnell wachsen kann, wenn weitere Variablen und Äquivalenzklassen miteinander kombiniert werden müssen.[7]

Testfall grund_preis sondermodell_preis zusatzausstattung_preis rabatt result
1 30000 2550 6300 20 31080
2 "-20000" 2550 6300 20 not_valid
3 "abc" 2550 6300 20 not_valid
4 30000 "-3600" 6300 20 not_valid
5 30000 "abc" 6300 20 not_valid
6 30000 2550 "-4800" 20 not_valid
7 30000 2550 "abc" 20 not_valid
8 30000 2550 6300 "-40" not_valid
9 30000 2550 6300 "abc" not_valid

Tabelle 03: Äquivalenzklassentest

Grenzwertbetrachtung
Die Grenzwertbetrachtung erweitert den Äquivalenzklassentest und betrachtet die Grenzbereiche der Äquivalenzklasse. Häufig passieren dort die meisten Fehler. Die Werte werden so gewählt, dass sie sich möglichst nah an der jeweiligen Grenze befinden.[8]

Parameter Äquivalentklasse Repräsentant
grund_preis
gÄk: 0<max
gÄk: 0<0,000001
uÄk: 0>max
uÄk: 0>max
NaN 		30000
0,000001
-20000
-0,000001
"abc"

Tabelle 04: Grenzwertbetrachtung

2.3.1.2 White-Box Verfahren

Bei dem White-Box Verfahren werden im Gegensatz zu dem Black-Box Verfahren ausschließlich der Quellcode und die inneren Programmstrukturen untersucht. Voraussetzung für dieses Verfahren ist jedoch ein funktionsfähiger Quellcode, der ausgeführt werden kann. Das Ziel dieses Testverfahren ist mindesten einmal jede Anweisung im Quellcode durchlaufen zu lassen.
Zu den White-Box Verfahren gehören folgende Testtechniken:

  • Anweisungsüberdeckung
  • Zweigüberdeckung
  • Pfadüberdeckung[9]

Diese Verfahren werden folgend beschrieben.
Anweisungsüberdeckung
Im Vordergrund der Untersuchung stehen die Anweisungen des Programms, die mindestens einmal durchlaufen werden müssen. Im ersten Schritte wird ein Kontrollflussgraph erstellt, der dabei helfen soll, entsprechende Kontrollflüsse auswendig zu machen.[10] Sind diese bekannt, werden Anweisungen als Knoten, Kontrollflüsse zwischen den Anweisungen als Kanten und Sequenzen von Anweisungen als Knoten dargestellt.

Abbildung 01: Kontrollflussdiagraph eines Beispielsprogramms. Quelle:
Abbildung 01: Kontrollflussdiagraph eines Beispielsprogramms. Quelle:[11]

In diesem Beispiel können alle Anweisungen in einem Testfall ermittelt werden. Die Reihenfolge der Ausführung ist: a, b, f, g, h, d, e. Nach der Ausführung des Tests müssen nur noch der Sollzustand und der Istzustand der ausgegebenen Daten miteinander verglichen werden.[12]
Zweigüberdeckung
Bei der Untersuchung der Zweigüberdeckung wird verlangt, dass mindestens ein Testfall jede Kante des Kontrollflussgraphen durchlaufen wird.[13] In unserem Beispiel wären vier Testläufe erforderlich:

  • Durchlauf 1: a, b, f, g, h, d, e (der Testdurchlauf aus dem ersten Beispiel)
  • Durchlauf 2: a, b, c, d, e
  • Durchlauf 3: a, b, f, g, i, g, h, d, e
  • Durchlauf 4: a, k, e

Pfadüberdeckung
Die Untersuchung der Pfadüberdeckung kommt erst in Spiel, wenn Schleifen und Wiederholungen sich im Programmcode befinden. Die beiden ersten Untersuchungen konnten nur einfache Do-While Schleife untersuchen.[14] Das Testkriterium wird erst erfüllt, "[...]wenn für jeden möglichen Pfad, der den Eingangsknoten des Kontrollflussgraphen mit dem Ausgangsknoten verbindet, ein separater Testfall existiert".[15]

2.3.1.3 Gray-Box Verfahren

Das Gray-Box Verfahren kombiniert die Vorteile von White-Box und Black-Box Verfahren zu einem eigenständigen Softwaretest. Dieses Verfahren ist kein Bestandteil dieser Arbeit und wird nur vervollständigend erwähnt.

2.3.2 Statische Tests

Der statische Test, oft mit der statischen Analyse verwechselt, wird im Gegensatz zum dynamischen Test nicht mit Daten gefüttert, sondern unterliegt einer gesonderten Analyse. Die Analyse wird mit Hilfe von einer oder mehreren Personen oder mit Zuhilfenahme bestimmter Werkzeuge durchgeführt. Die Untersuchung durch den Menschen kann alle Dokumente, die zur Erstellung einer Software benötigt werden, beinhalten. Die Untersuchung mit Werkzeugen ist allerdings auf die Dokumente beschränkt, die bestimmte Formalien erfüllen.
Ziel der Untersuchungen ist die Ermittlung von

  • Systemfehlern
  • Verstöße gegen Vorgaben aus dem Soll-Zustand
  • Einhaltung von Standards
  • Nachweis der Verletzungen im Zuge des Projektplans
  • Optimierung des Entwicklungsprozesses

Auf diese Weise versucht man präventiv Fehler und Abweichungen so früh wie möglich zu erkennen, um entsprechend früh darauf reagieren zu können, noch bevor gravierende Eingriffe in zur Nach- oder Verbesserung ergriffen werden müssen.
Die menschliche Analyse- und Denkfähigkeit wird bei der nicht werkzeuggestützten Methode benutzt, um entsprechende Sachverhalte der Software zu überprüfen und nach bestimmten Kriterien zu bewerten. Zu Unterscheiden sind verschiedene Vorgehensweisen, die je nach Bedarf an der Qualitätsanforderungen angewendet werden können.[16] Zu einer dieser Methoden gehört das Review, welches im nächsten Kapitel beschrieben wird.

2.3.2.1 Reviews

Das Review gehört zu den statischen Prüfmethoden, die von Personen durchgeführt werden. Diese Methode ist auch als Inspektion bekannt. Ein Review kann folgende Punkte beinhalten:

  • der Vertrag der Software
  • die Anforderungsbeschreibung
  • die Entwurfsspezifikation
  • die Programmtexte
  • die Testpläne
  • das Benutzerhandbuch
  • die Semantik und Bedeutung der Funktionalitäten

Theoretisch und praktisch kann jedes Dokument einer Software untersucht werden.

Reviews werden als eine effektive Methode angesehen, um frühzeitig die Qualität zu sichern. Meistens werden Reviews im Anschluss einer jeden Phase im V-Modell durchgeführt. Durch die Beseitigung der Fehler wird nicht nur die Qualität der Software gesteigert, vielmehr wirkt es sich positiv auf dem gesamten Entwicklungsprozess aus, da Fehler nicht aus alten Phasen mitgenommen werden. Weitere positive Auswirkungen sind:

  • Fehler werden kostengünstig, da rechtzeitig entdeckt, behoben
  • dadurch verringert sich die Entwicklungszeit des gesamten Softwareprojekts, wodurch die Projektkosten gesenkt und der Gewinn gesteigert werden kann
  • dadurch werden die dynamischen Tests verkürzt, da sich weniger Fehler in einem Testobjekt befinden
  • ungenaue Kundenwünsche können frühzeitig entdeckt, kommuniziert und beseitigt werden
  • die Erwartung an eine fehlerfreie, im späteren Einsatz der Software, wird gesteigert
  • die Überprüfung der Software findet meistens in einem Team statt, somit wird der Wissensaustausch zwischen den Mitarbeitern gefördert. Dies verbessert die Qualität der Software
  • das Team fühlt sich verantwortlich für die Erstellung der Software und sichert damit das Fortbestehen der Qualität

Der Nutzen der Durchführung von Reviews darf nicht unterschätzt werden. Zwar steigen die anfallenden Projektgesamtkosten um 10%-15%, allerdings wird das Einsparungspotential bei ca 14%-25% angesetzt. Durch effizientes testen lassen sich 70% aller Fehler bereits in dieser Testphase finden.[17]

Ein Review wird nach IEEE Standart for Software Reviews in sechs Schritten durchgeführt.
Schritt 1: Planung
Das Projektmanagement entscheidet zu welchem Zeitpunkt, welche Dokumente geprüft werden und ein Team wird mit fachlich geeigneten Personen aufgestellt. Außerdem werden Risiken, Kriterien und dessen Bewertungen für die Tests erstellt. Dabei ist es sinnvoll die Tests aus verschiedenen Blickwinkeln zu betrachten, um einen besseren Überblick erhalten zu können.
Schritt 2: Einführung
Informationsweitergabe an die am Test beteiligten Personen. Prüfdokumente und weitere Unterlagen, die für das Testen von Bedeutung sind, werden an die Personen weitergeleitet. Die Dokumente enthalten Informationen darüber, welches Verhalten unter normal zu verstehen ist und unterumständen auch schon Informationen über Verhalten, die nicht vorkommen dürfen. Diese Informationen können sich auf Pflichtenhefte, Designdokumente, Richtlinien und Standards beziehen, die zuvor mit dem Kunden erarbeitet worden sind. Hilfreich sind auch an der Stelle Checklisten, die bestimmte Formalien abdecken.
Schritt 3: Vorbereitung
Die an den Tests beteiligten Personen bereiten sich auf die kommenden Tests vor. Mit Zuhilfenahme aller Dokumente werden die Prüfdokumente überprüft um eventuelle Mängel und Fehler, Fragen und Anregungen zu notieren.
Schritt 4: Review
Ein erfolgter Review soll dafür sorgen, dass dem Projektteam Aufschluss geben soll, ob die Vorgaben und Richtlinien an das Softwareprodukt eingehalten sind. Fehler, Abweichungen vom Soll-Zustand, Schwächen und Unstimmigkeiten sollen herausgefunden werden.
Wurde ein Review durchgeführt so kann im Team entschieden werden, ob das Dokument akzeptiert, verbessert oder neu erstellt werden muss. Damit ein Review nicht zu lange die Ressourcen bindet, ist es üblich das Review zeitlich zu begrenzen.[18]
Es empfiehlt sich folgende Regeln für das Review einzuhalten.

  • das Review ist auf zwei Stunden begrenzt
  • Abbruch der Sitzung durch den Moderator, wenn Personen mangelhaft vorbereitet sind oder erst gar nicht auflaufen
  • das Prüfdokument und nicht die beteiligten Personen stehen zur Diskussion. Das Prüfdokument darf nicht befürwortet oder verteidigt werden
  • der Moderator ist nicht der Gutachter
  • keine Diskussion über Programmiertechniken und -stiele
  • keine Entwicklungen von Lösungen
  • Befunde müssen präsentiert werden
  • Konsens der Befunde wird protokolliert
  • Befunde werden kategorisiert und bewertet nach: kritischer Fehler, Hauptfehler, Nebenfehler und fehlerfrei
  • Empfehlung vom Team über die Akzeptanz des Dokuments: akzeptieren ohne Änderungen, akzeptieren mit Änderungen und nicht akzeptieren
  • Unterschrift des Protokolls aller beteiligten Testpersonen[19]

Schritt 5: Nachbereitung
Das Management entscheidet anhand der im Review gewonnen Erkenntnisse über weiteres Vorgehen.
Schritt 6: Wiedervorlage
Die gewonnenen Erkenntnisse werden vom Moderator oder Manager und dem Fachpersonal überarbeitet und falls das Review nicht den gewünschten Erfolg gebracht hat wird ein weiterer zweiter Review durchgeführt. Dieses ist dann stark verkürzt, da nur die geänderten Dokumente betrachtet werden. Außerdem können die Manager für wiederholende Fehler Maßnahmen treffen falls bei den Mitarbeiter das Fachwissen fehlt und diese entsprechend schulen.

2.3.2.2 Rollen und Verantwortlichkeiten

In den Kapitel zuvor wurden schon ein paar Rollen der Reviews beschreiben bzw. erklären sich von allein. Im Folgenden werden alle Rollen tabellarisch aufgeführt.

Manager Der Manager stellt ein geeignetes Testteam zur Verfügung. Er entscheidet welche und auf welche Art Dokumente geprüft werden. Da eine freie Diskussion ermöglicht werden soll, sollten die Manager und dessen Vertreter nicht an dem Review teilnehmen.
Moderator Der Moderator moderiert den Ablauf des Reviews. Er ist dafür verantwortlich, dass das Ziel eines Reviews eingehalten wird. In Problemsituationen ist er derjenige, der diplomatisch die teilnehmenden Parteien schlichtet. Auch hier ist es wichtig, dass der Moderator sich neutral zu Problemen und Fehlern verhält.
Autor Der Autor ist ein Vertreter des Teams, der das zu untersuchende Dokument verfasst hat. Er hat dafür Sorge zu tragen, dass das Review vorab entsprechend den Testkriterien vorbereitet worden ist und sich das Dokument auch in einem Status befindet, welches untersucht werden kann. In einem Review gestellte Kritik darf von ihm nicht als Kritik auf seine Person gesehen werden, sondern als eine konstruktive Kritik an dem Dokument.
Gutachter Der Gutachter ist der Experte. Er weiß wie der Soll-Zustand, die Anforderungen, das Design des Dokuments, der Programmtext und die Sicherheit des Tests aussieht. Er bewertet die Dokumente als gut bzw. Mängel werden direkt markiert und nachvollziehbar dokumentiert.
Protokollant Der Protokollant dokumentiert alle im Review gewonnen Fehler, Mängel, Erkenntnisse und Absprachen schriftlich. Dabei muss er darauf achten, dass das Niedergeschriebene fehlerfrei und unverfälscht protokolliert wird.[20]

Tabelle 05: Rollen und Verantwortlichkeiten

2.3.2.3 Statische Analyse

Die statische Analyse wird im Gegensatz zum Review mit Hilfe von Werkzeugen durchgeführt. Als Beispiel könnte man sich eine Rechtschreibprüfung vorstellen, die den Quellcode auf Rechtschreibfehler oder Interpunktion überprüft. Wichtiges Merkmal ist, dass nur der Quellcode überprüft wird und nicht die Funktionalität; der Code wird nicht ausgeführt.
Damit entsprechende Tools solche Fehler aufdecken können, müssen die Dokumente einem vorgegebenen Formalismus entsprechen. Die Klassendiagramme in UML bieten sich als Modellierungsunterstützung an. Ebenso lassen sich generierte HTML und XML Dokumente einer statischen Analyse unterwerfen. So werden schon in frühen Phasen der Softwareentwicklung Fehler und Inkonsistenzen aufdecken. Die Praxis zeigt, dass eigentlich nur der Quellcode sich einer statischen Analyse unterwerfen kann.
Entwickler setzen diese Tools schon während der Entwicklung des Quellcodes ein. Da solche Tools eine Menge Informationen dem Programmierer geben, müssen diese entsprechende Kenntnisse des Tools aufweisen.
Es empfiehlt sich die statische Analyse vor dem Review durchzuführen, da der Aufwand einer statischen Analyse weitaus geringer ist als die eines Reviews. Wird eine statische Analyse durchgeführt, so muss man sich im Klaren sein, dass nicht alle Fehler aufgedeckt werden. Fehler, die erst bei der Laufzeit des Programms auftreten, werden nicht korrigiert. Z.B. erkennt die statische Analyse nicht, dass bei der Addition zweier Zahlen (2+2=) das Ergebnis (=5) falsch ist.
Als Werkzeuge werden in der Praxis Compiler eingesetzt. Diese erkennen meist schon bei der Eingabe des Quellcodes Fehler. Aufgaben eines Compilers in diesem Zusammenhang sind:

  • Aufdeckung einer Verletzung der Syntax
Wird ein Verstoß gegen die Syntax der jeweiligen Programmiersprache eingegeben, so reagiert der Compiler mit einer Warnung, gibt zusätzliche Informationen zum Verstoß oder bietet direkte Hilfe zum Quellcode an. Einige Beispiele wären:
  • Erstellung einer cross referenze list von Variablen und Funktionen (Verwendungsnachweise für einzelne Elemente)
  • Überprüfung, ob die Variablen typgerecht sind
  • Überprüfung der Nichtverwendung von Variablen
  • Ermittlung der nicht deklarierten Variablen
  • Code, der nicht erreicht werden kann
  • Prüfung der Konsistenz von Schnittstellen
  • Prüfung aller Sprungmarken und -Ziele
  • Abweichungen von Standards und Konventionen
Der Compiler kann auch helfen Abweichungen von Standard und bestimmten Konventionen, die eingehalten werden müssen, einzuhalten. Eine manuelle Überprüfung des Quellcodes durch eine Person wäre sehr Aufwendig. Übernimmt diese Funktion ein Compiler so, lässt sich Zeit und Geld durch den Verzicht auf die prüfende Person einsparen.
  • Überprüfung auf Datenflussanomalien
Die Datenflussanalyse untersucht der Quellcode auf die Verwendung von Daten auf Pfaden durch den gesamten Programmcode. Eine Anomalie ist eine Unstimmigkeit, die zu einem Fehler führen kann aber nicht muss. Z.B. Variablen ohne vorherige Initialisierung oder die Nichtverwendung eines Wertes einer Variablen. Insgesamt gibt es drei Verwendungen für Variablen:
  • Variablen sind definiert: der Variablen wurde ein Wert zugewiesen
  • Variablen sind referenziert: der Wert der Variablen wird verwendet
  • Variablen sind undefiniert: haben keinen Wert
Aus diesen drei Verwendungen lassen sich nun drei mögliche Anomalien erstellen:
  • ur-Anomalie: auf dem Programmpfad wird ein undefinierter Wert gelesen
  • du-Anomalie: der Wert der Variable ist ungültig oder wird nicht verwendet
  • dd-Anomalie: auf dem Programmpfad wird ein zweites Mal ein Wert verwendet, ohne dass der erste verwendet wurde
Ein kleines Beispiel soll die drei Anomalien etwas genauer beschreiben:
void tausch (int& Min, int$ Max){
int Hilf;
if (Min > Max){
Max = Hilf;
Max = Min;
Hilf = Min;
}
}
  • ur-Anomalie der Variablen Hilf: der Gültigkeitsbereich ist auf die Funktion beschränkt. Zur ersten Verwendung auf der rechten Seite der Zuweisung hat die Variable noch einen undefinierten Wert, der an der Stelle referenziert wird. Es findet keine Initialisierung bei der Deklaration statt.
  • dd-Anomalie der Variablen Max: die Variable bekommt zwei Mal eine Zuweisung eines Wertes, da diese auf der linken Seite steht, somit kann die erste Zuweisung entfallen oder wurde vom Programmierer vergessen.
  • du-Anomalie der Variablen Hilf: die Variable Hilf bekommt in der letzten Anweisung einen Wert zugewiesen, der nirgends verwendet werden kann, da sich der Gültigkeitsbereich der Variablen nur innerhalb der Funktion erstreckt.
  • Überprüfung auf Kontrollflussanomalien
Anomalien können auftreten, wenn z.B. Sprünge aus Schleifen heraus ungültig sind oder ein Programm mehrere Ausgänge hat. Diese müssen nicht zwangsläufig Fehler verursachen, können allerdings den Grundsätzen der strukturierten Programmierung widersprechen.
  • Aufdeckung von Sicherheitslücken
Sicherheitsprobleme können auftreten, wenn fehlerhafte Programmkonstrukte verwendet werden oder notwendige Überprüfungen nicht durchgeführt werden.
  • Vermeidung von Speicherüberlauf
Speicherüberläufe folgen meistens einem bestimmten Muster. Der Compiler erkennt diese und warnt den Programmierer davor.[21]

2.4 Planung der Tests

Das Testen einer Software erfordert die Planung des gesamten Testprozesses. Ziel jeden Vorgangs ist es Fehler zu finden. Die Maßnahmen, die dafür getroffen werden müssen, erfordern eine gezielte und umfassende Planung und Koordination der zur Verfügung stehenden Ressourcen. Diese Planungs- und Koordinierungsmaßnahmen sind fester Bestandteil der Softwareentwicklung. Von ihnen hängt der Erfolg des Testens ab.
Die Norm DIN EN ISO 9001 beschreibt alle qualitätssichernden Maßnahmen, die bei der Erstellung eines Testplans helfen können:

  • messbare Testziele
  • zu testende Konfigurationen
  • Testmethoden (z.B. Funktionstest, Grenzwerttests, Leistungstests)
  • Testreihenfolge, Testfälle, Testverfahren, Testdaten und Soll-Ergebnisse
  • Umfang der Tests nach Thema und Inhalt
  • Zweckdienlichkeit der Tests für die Testziele und deren späteren Einsatz
  • besondere Gesichtspunkte (Schutz, Sicherheit)
  • Testumgebung und Testwerkzeuge
  • Testen der Benutzerdokumentation
  • erforderliches Personal für Schulungsmaßnahmen
  • Grad der Unabhängigkeit zwischen Entwicklungspersonal und Testpersonal
  • Verantwortlichkeiten für Spezifikationen und Durchführung der Tests
  • messbare zuverlässigkeitsorientierte Kriterien für die Beendigung der Tests
  • Methoden für das Aufzeichnen der Testergebnisse
  • Verfahren für die Analyse und Genehmigung der Ergebnisse
  • Fehlerbehandlung und Kriterien für das Aussetzen und die Wiederaufnahme
  • Notwendigkeit und Umfang von Regressionstest

außerdem müssen folgende Daten ständig auf dem aktuellen Stand gebracht werden:

  • Zeitplan
  • Kalkulation des Aufwands und der benötigten Ressourcen
  • Hardwarekonfiguration der Testumgebung
  • Testprozeduren und Testfallbibliotheken
  • Maße und Kennzahlen für die Qualitätsbewertung der Tests
  • Kriterien für die Freigageempfehlung des Produkts[22]

2.4.1 Aufgaben und Ziele

Um einen Überblick über den Fortschritt des Testens und zur Kontrolle werden messbare Kennzahlen benötigt, die als Kriterium dienen, wann ein Ende des Testens erreicht sind.
Die folgende Abbildung zeigt eine strukturierte Abbildung von Testaufgaben, die in der Norm IEEE Std. 1012 "Software Verification an Validation Plans" vorgeschlagen werden.

Abbildung 02: Testprozess des Softwarepordukts.Quelle:
Abbildung 02: Testprozess des Softwarepordukts.Quelle:[23]

Diese Testaufgaben müssen Verantwortlichen zugeteilt werden, damit alle Testaktivitäten zielgerecht durchgeführt werden können.
Modul- und Integrationstest
Bestandteile des Modultests sind statische Analysen, strukturorientierte und funktionsorientierte Testverfahren. Bei den strukturorientierten Tests werden die Verfahren von den Testüberdeckungszielen abgeleitet. Bei den funktionsorientierten Tests bestimmen die Ein-/Ausgabeverhalten die Testaktivitäten.
Systemtest
Der Systemtest untersucht den Soll- und den Ist-Zustand von Funktionen und Funktionsverkettungen, die Qualitätsmerkmale und Benutzermerkmale. Testverfahren und Testmodelle müssen gefunden werden, die Beispielsweise sich aus den Testvorbereitungen, Testfallermittlung, Testdatendefinitionen, Testdurchführungen uns Testauswertungen ableiten lassen können. Für die Überprüfung von Qualitätsmerkmalen werden oft größere Datenmengen benötigt, um z.B. ein Leistungstest unter realistischen Bedingungen durchzuführen. Geprüft wird, wie sich das System unter Volllast verhält und ob es wieder zum Normalzustand zurückkehrt.
Testziele
Testziele dienen der Kontrolle des Testablaufs. Diese müssen objektiv, angemessen und sinnvoll definiert werden. Kennzahlen können bei der Beurteilung der Testziele helfen.[24]

2.4.2 Testfallermittlung

Eines der wichtigsten Punkte bei der Planung von Testprozessen ist die Testfallermittlung. Diese bestimmt letztendlich den Erfolg oder Misserfolg und folglich die Qualität des Softwareproduktes. Werden fehlerhafte Programme ausgeliefert können hohe Folgekosten entstehen, vor allem wenn der Entwickler dafür haftet.
Testfälle werden systematisch abgeleitet. Man unterscheidet zwischen strukturorientierten und funktionsorientierten Testfallermittlungen. Beide Vorgehensweisen haben entsprechende Testmethoden. Die folgende Abbildung zeigt die Aufteilung der Methoden.

Abbildung 03: Testfallermittlung. Quelle:
Abbildung 03: Testfallermittlung. Quelle:[25]

Ein vollständiger Test ist meistens nicht möglich, da der Dateneingabebereich riesig ist. Kriterien müssen gefunden werden, die repräsentativ als Testeingabedaten fungieren, um Zeit und Kosten zu sparen und ein Maximum an Fehlern zu entdecken. Folgende Testfälle lassen sich als Schwerpunkte auswählen, wenn man als Kriterium den Umfang, Priorität, Schadensausmaß Datenbezug und Zustand mit einbezieht:

  • Repräsentativer Test
Alle Funktionen, Aufgaben oder Daten werden entsprechend ihrer Häufigkeit getestet
  • Schwachstellenorientierter Test
Alle Funktionen, Aufgaben oder Daten werden entsprechend ihrer Fehlerhäufigkeit getestet
  • Schadensausmaßorientierter Test
Alle Funktionen, Aufgaben oder Daten werden entsprechend des Risikos, der während der Betriebsphase auftreten können, getestet
  • Datenorientierter Test
Alle Funktionen, Aufgaben oder Daten werden entsprechend ihrer Ein- und Ausgabedatenbereiche oder anhand Schnittstellenspezifikationen getestet
  • Funktionsorientierter Test
Ein Testfall pro Funktion (im Funktionstest anwenderorientiert, im Modultest anwenderorientiert und systemorientiert)
  • Aufgabenorientierter Test
Alle fachlichen Aufgaben (Anwendungsfall oder Szenario) werden berücksichtigt
  • Zustandsorientierter Test
Alle Zustände von Variablen von Funktionen, Aufgaben oder Daten werden getestet[26]

2.4.3 Kosten des Testens

Testen ist sehr aufwendig und kostspielig. Es muss bestimmt werden wie angemessen eine Software getestet werden muss und wann der Aufwand den möglichen Nutzen übersteigt. Man unterscheidet in dem Zusammenhang mehrere Kostenarten:

  • Direkte Fehlerkosten
Kosten, die dem Kunden durch Fehler beim Betrieb der Software entstehen, z.B. durch Datenverlust, Fehlbuchungen, Schaden an Anlagen oder Hardware, Personenschäden. Kosten wegen Ausfall von Geschäftsprozessen oder Stillstand von Produktionsstraßen.
  • Indirekte Fehlerkosten
Erhöhter Aufwand durch die Software, Unzufriedenheit der Anwender mit der Software
  • Fehlerkorrekturkosten
Kosten, die entstehen, um eine fehlerhafte Software wieder in den Normalbetrieb zu bringen

Die Erfahrung zeigt, dass je früher die Fehler der Software entdeckt werden, desto kostengünstiger ist das gesamte Projekt am Ende.
Für die Schätzung des Testaufwands empfiehlt sich einen Zeitplan einzurichten und entsprechende Ressourcen dafür bereit zu stellen. Bei kleinen Projekten kann das einmalig gemacht werden, bei größeren Projekten empfiehlt sich die die Schätzungen für Test auf mehrere Stufen aufzuteilen. Zwei grundsätzliche Herangehensweisen sind möglich:

  • Der Aufwand wird für jeden Test geschätzt
  • Der Aufwand wird aus bekannten Aufwandsdaten vergangener Projekte abgeleitet[27]

3 Testautomation

Durch immer komplexer werdende Software, vorangetrieben durch den Einsatz von Entwicklungsumgebungen und neuen Entwicklungsplattformen wie Internet, ist auch die Notwendigkeit für den Einsatz von Testautomatisierung gestiegen, um in Bezug auf den Umfang des Testvorgangs dieser Entwicklung stand halten zu können. Nicht zuletzt auch durch das zunehmende Eindringen von Computern in viele Anwendungsbereiche gewinnt die Sicherstellung der korrekten, zuverlässigen Funktion der verwendeten Software an Bedeutung.[28]

Um die Qualität eines Produkts beurteilen zu können, braucht man die notwendigen Maßnahmen im Namen von „Tests“. Es muss festgestellt werden, welche Testverfahren zum Einsatz kommen. Der nächste Schritt ist festzustellen, ob die Tests manuell ausgeführt werden, oder ob sie automatisiert werden. Um diese Entscheidung treffen zu können, muss man wissen welche Vor- und Nachteile die Testautomation bietet, wann sie sich lohnt und wie sie erreicht werden kann.

Um den Kontext des automatisierten Testens zu verstehen, ist es erforderlich, die Testarten zu beschreiben, die typischerweise während der unterschiedlichen Phasen der Anwendungsentwicklung durchgeführt werden. In einer Client/Server oder Web-Umgebung reicht das Zielsystem über eine Softwareanwendung hinaus. Tatsächlich kann es auf mehreren Plattformen laufen, mehrere Schichten unterstützender Anwendungen und Schnittstellen zu verschiedenen kommerziellen Produkten umfassen, eine oder mehrere Datenbanken unterschiedlichen Typs nutzen und sowohl Frontend- als auch Backend-Verarbeitung einschließen. In dieser Umgebung lässt sich u.a. Folgendes testen: Funktionsanforderungen, Serverleitung, Benutzerschnittstelle, einzelne Einheiten, Integration, Abdeckung des Programmcodes, Leistung bei Systembelastung, Abgrenzung, Sicherheit und vieles andere, außerdem kann eine Prüfung aus Speicherprobleme und eine Analyse der Komplexität der Programmmodule vorgenommen werden.[29]

Abbildung 04: Manuelles Testen vs. Testautomatisierung. Quelle:
Abbildung 04: Manuelles Testen vs. Testautomatisierung. Quelle: [30]

Automatisiertes testen kann diese Testarten heute unterstützen, weil die Funktionalität und Fähigkeiten automatisierter Testwerkzeuge in den letzten Jahren erheblich erweitert wurden. Derartige Testoperationen können effizienter ausgeführt werden und lassen sich leichter wiederholen als beim manuellen Testen. Die Fähigkeiten automatisierter Tests nehmen weiter zu, um mit der wachsenden Nachfrage nach schnellerer und preisgünstigerer Produktion besserer Anwendungen Schritt zu halten.[31]

3.1 Eigenschaften

Ein Testfall eines Testprozess muss bestimmte Kriterien erfüllen, damit der Testprozess vom System automatisch ausgeführt werden kann. Ein manuelles Testen bzw. ein menschlicher Tester kann die Testfalldefinition und die erwarteten Testergebnisse interpretieren und die Abweichungen gegebenenfalls tolerieren. Ein automatisierter Test muss genau spezifiziert werden, so dass es dem Testprozess ermöglicht werden kann, anhand von Testergebnis Fehler zu erkennen.

3.1.1 Selbstprüfend

Die „Selbstprüfung“ macht weniger Sinn, wenn größere Testsuiten automatisiert getestet werden, aber die generierten Ergebnisse wiederum manuell kontrolliert werden müssen. Der Test muss daher, das Ergebnis mit dem Sollwert vergleichen, damit er eine definitive Antwort liefern kann. Die Testsuite kann solche Ergebnisse zusammenfassen und entweder global melden, oder im Fehler nur die Testzyklen anzeigen, die tatsächlich fehlgeschlagen sind.

3.1.2 Messbare Erwartungen

Das Messen der Prüfungen ist nur dann möglich, wenn in den Testfällen messbare und vergleichbare Erwartungen spezifiziert sind. Dies kann in einigen Fällen problematisch werden. Besonders Testen von Animationen oder eine Funktion mit Absicht Zufall-basiert programmiert ist. Bei einem menschlichen Tester wäre es sehr leicht das Ergebnis zu beurteilen, für einen automatischen Test ist dagegen sehr aufwändig.

3.1.3 Unabhängig

Viele Testsuiten machen keine Zusicherung, dass die Testfälle immer in derselben festgelegten Reihenfolge ausgeführt werden. Ein Testfall darf sich nicht darauf verlassen, dass ein vorhergehender Test den benötigten Anfangszustand hinterlassen hat, sondern muss sich selber darum kümmern. Um bei einem Testfall eine bestimmte Antwort zurückliefern zu können, muss er unabhängig von den veränderlichen Informationen wie Datum, Datenbankzustand oder Systemressourcen sein. Nur dann kann sichergestellt werden, dass der Testfall bei gleichen Testdaten immer das gleiche Ergebnis liefert.

3.1.4 Robust

Die automatisierten Testfälle sollen unabhängig von anderen Tests sein, aber auch von den weiteren Funktionen des getesteten Systems. Änderungen am Quelltext einer Funktion sollten sich nur auf diejenigen Testfälle auswirken. Die Testfälle sollten daher geringe Überschneidungen aufweisen, je robuster ein Testfall gegen Änderungen ist, desto länger ist seine Lebensdauer. Damit steigt sein Nutzen bzw. sinken seine Kosten.

3.2 Testautomationsverfahren

Es gibt verschiedene Methoden "Automationsverfahren" in unterschiedlichen Anwendungsgebieten, um die Testdefinition zu erstellen und auszuführen.

3.2.1 Capture / Replay

Bei einem Verfahrenstest wird die Anwendung aus der Sicht des Endbenutzers unter der Verwendung der User Interface getestet, deshalb lassen sich die Testbemühungen mittels Capture/Replay-Verfahren automatisieren. Die Aktionen die vom Benutzer ausgehen werden dabei mittels geeigneter Aufnahmewerkzeuge wie z.B. „Makros“ aufgezeichnet und abgespeichert (Capture). Diese gespeicherten Daten werden dann später verglichen, ob den ermittelten Ergebnissen mit denen die bei der Ursprungsaufzeichnung gesammelten Antworten übereinstimmen.

Die Vorteile von Capture/Replay –Verfahren sind zum einen, dass die Testfälle von normalen Benutzern aufgezeichnet werden können, es wird also nicht zwangsläufig geschultes Personal benötigt. Dies bietet sich besonders bei einem Abnahmetest an, wobei es darauf ankommt dass der Kunde versteht was der Test prüft und dass der Test erfolgreich war. Ein anderer Vorteil ist das sich die Testfälle schnell aufnehmen lassen, hierbei ist die Dauer kaum länger als die manuelle Ausführung des Tests.

Primär wird dieses Verfahren für annähernd fertige, funktionierende Software bzw. GUIs herangezogen. Eine Voraussetzung ist das, dass System soweit entwickelt sein muss das es eine Aufnahme überhaupt möglich macht. Capture/Replay empfiehlt sich nicht bei testgetriebenen Entwicklung, da es primär darum geht den Testfall zu erstellen, bevor eine Funktion oder deren GUI vorhanden ist.

Ein weiterer Nachteil ist, dass auch aufgezeichnete Tests nicht Flexibel sind, da das aufzeichnende Instrument nicht wissen kann, welche Eigenschaften des Systems gerade relevant für den Test sind und welche Aktionen für den Test nebensächlich sind, und welche nur der Vorbereitung dienen, somit kann man kaum einen starren Ablauf beim Aufzeichnen verhindern. Eine Möglichkeit die Inflexibilität zu verringern ist das, dass Makro das die Aufzeichnung enthält im Nachhinein zu Bearbeiten, hierbei investiert man dann allerdings wieder Zeit, somit wird die Zeitersparnis die man am Anfang gehabt hat langsam schwinden, und man nähert sich dem Scripting.

3.2.2 Scripting

Das Gegenteil zu Capture/Replay-Verfahren ist das manuelle erstellen von Testskripte:

Alle Testfälle, die automatisiert ohne menschliche Interaktionen ausgeführt werden, kommen in die Berührung mit dem Scripting. Skripte sind Programme, die allgemeinen Mechanismen vorsehen und als Unterstützung für die anderen Verfahren benutzt werden.

Scripting hat in der Regel ein Muster, wie in der Abbildung dargestellt wird.

Abbildung 05: Scripting Verfahren
Abbildung 05: Scripting Verfahren

Vorteile sind z.B. das die Testfälle flexibler gestaltet werden können, und man den Quelltext sehr modular organisieren kann (man kann Arbeitsabläufe die immer wiederkehren zusammenfassen z.B. Login). Die Tests könnten auch im Vorfeld erstellt werden ohne dabei eine Abhängigkeit zwischen fertigem System und Tests zu haben, als einziges müssen die Aufrufschnittstellen im Voraus definiert werden.

Im Gegensatz zu Capture/Replay-Verfahren ist der Aufwand wesentlich höher für die Testfalldefinition und das Personal muss dementsprechend geschult sein damit man dieses Verfahren durchführen kann.

3.2.3 Testsuiten

Einzelne Testfalldefinitionen werden bei sog. Suiten zusammengefasst, die dann als eine Einheit ausführbar sind. Die komplette Testsammlung wäre dann bei einem Start ausführbar.
Eine ausführbare Testsuite ist eine Testsuite, die von einem Programm ausgeführt werden kann. Das bedeutet normalerweise, dass eine Testumgebung mit der Testsuite integriert ist. In der Abbildung wird ein Testsuite-Beispiel angezeigt.

Abbildung 06: Beispiel einer Testsuite. Quelle:
Abbildung 06: Beispiel einer Testsuite. Quelle: [32]

3.2.4 Kontinuierliche Integration

Hat man diese „Start-Automation“ anhand von der Suiten erstellt, könnte man auch den Start selber automatisieren. Hierbei würde dann ein kleines Skript die Ausführung von Testsuiten zeit- oder ereignisgesteuert anstoßen. Dies nennt man "trägere Automation" die vor allem in Werkzeugen zur kontinuierlichen Integration (engl. Continuous Integration) wie CruiseControl zum Einsatz kommt.

CruiseControl ist ein Java-basiertes Open-Source-Computerprogramm, das in der Softwareentwicklung eingesetzt wird, um einen kontinuierlichen Erstellungsprozess umzusetzen.

Solche Werkzeuge sorgen dafür, dass ein separater Rechner durchgehend den aktuellsten Quelltext der in der Versionsverwaltung vorkommt kompiliert und die Haupt-Testsuite darauf ausführt. Falls nicht alle Tests erfolgreich sind, werden die Entwickler per Email etc. vom Werkzeug benachrichtigt. So wird sichergestellt dass zu jeder Zeit eine funktionierende Version des Systems vorhanden ist. Gleichzeitig ist es den Entwicklern möglich, während Entwicklung nur für den für sie relevanten Teil des Test auszuführen, eventuelle Fehler können spätestens beim hinzufügen in die Versionsverwaltung bemerkt werden. Fehler die man bei dem Umgang mit der Versionsverwaltung macht, können somit frühzeitig entdeckt werden, wie das auslassen eines Ordners beim Hinzufügen.

3.3 Bewertung

3.3.1 Vorteile der Testautomation

Die klaren Vorteile eines Automatisierten Testens liegen unumstritten in der Zeitersparnis.

Vom Computer werden Automatisierte Testfälle wesentlich schneller ausgeführt als dies manuell möglich wäre. Eine GUI vollständig zu Testen würde manuell mehrere Tage in Anspruch nehmen, automatisiert Tests brauchen für die gleichen Test meist weniger als eine Stunde. Im Allgemeinen sollten Unit-Tests der Entwickler Ausführungszeiten im Bereich von Sekunden bis wenige Minuten haben.

Bei häufiger Wiederholung der Tests kann somit die Automatisierung sehr viel Zeit und damit auch verbunden Ressourcen sparen; bei einigen Fällen ermöglicht es das automatisierte Testen erst das häufige Wiederholen der Tests. Hierbei ist natürlich zu beachten das der Aufwand den Test zu automatisieren als Aufwand gegenzurechnen ist.

Es gibt darüber hinaus weitere Vorteile, die selbst dann für eine Automatisierung sprechen, wenn keine wesentliche Zeitersparnis zu erwarten ist.

3.3.1.1 Reproduzierbarkeit

Manuelle Tests werden von Menschen durchgeführt, dabei ist nicht zu vergessen das Menschen zu Fehlern neigen, wenn auch eine ausführliche schriftliche Testdefinition vorhanden ist. Beispielsweise können dann Testschritte ausgelassen werden oder falsch durchgeführt werden, oder Unterschiede beim Vergleich der Ergebnisse einer Berechnung übersehen werden. Solche Risiken einer Abweichung vom definierten Ablauf entfällt bei der Automation. Die rechnergestützte Ausführung von Tests schützt nicht allein davor, dass die Testdefinition Fehler oder lückenhaft sind, aber zumindest die ist die Durchführung reproduzierbar. Da der Mensch bei häufigen wiederholen zu Fehlern neigt ist diese Reproduzierbarkeit eine wesentliche Verbesserung.

3.3.1.2 Schutz von Regression

Durch Software-Modifikationen, Funktionalitätserweiterungen oder Fehlerkorrekturen können neue Fehler in zuvor fehlerfreie Teile eingefügt werden. Der Regressionstest zielt auf die Erkennung derartiger Seiteneffekte. Grundsätzlich können solche Fälle manuell getestet werden. Dies ist allerdings eine schlechte Lösung. Ein Regressionstest besteht aus der Wiederholung von bereits durchgeführten Testläufen.

Die Durchführung eines Regressionstests erfordert die wiederholte Abarbeitung stets gleich bleibender Schritte. Es bietet sich daher an, zur Durchführung von Regressionstests ein entsprechendes Werkzeug zu verwenden.

Durch die Automatisierung des Regressionstests wird der Aufwand für die manuelle Wiederholung der Testfälle eingespart. Darüber hinaus wird das Risiko vermieden, Abweichungen zwischen den Regressionstests und den Referenzergebnissen zu übersehen. Automatische Regressionstests sind daher technisch und wirtschaftlich besser als manuelle Regressionstests.[33]

3.3.1.3 Dokumentation

Die Testskripte dienen dem Zweck den Ablauf des Systems zu erfassen, so kann man feststellen ob bei einem bestimmten Ereignis die gewünschte Reaktion darauf eingetreten ist oder nicht. Somit hat man dann eine Dokumentation der Bedienabläufe bei der man auf Knopfdruck überprüfen kann ob das System so funktioniert wie es das Testskript beschreibt. Ein großer Vorteil bei diesem Verfahren ist das sich dieses Dokument immer auf dem neuesten Stand befindet und somit eine Veralterung des Dokumentes entgegenwirkt. Eine Abweichung des Systems zu dem Dokument kann dann spätesten beim Ausführen des Tests festgestellt werden.

Ohne einen Mehraufwand wird der Testvorgang dokumentiert im Gegensatz zum „Erforschenden Test“ der zusätzlich protokolliert werden muss, das führt dazu dass dies in vielen Fällen ausbleibt.

3.3.1.4 Frühzeitiges Feedback

Falls die Tests durch schnell und automatisch ausgeführt werden können, lässt sich die Geschwindigkeit, der Ausführung von Testsuite erhöhen. Dadurch wird auch der Zeitabstand zwischen der Implementierung des Fehlers und des Entdeckung drastisch verkürzt. Somit erhält der Entwickler früher Rückmeldung zu seiner Änderung, und kann somit nachvollziehen das die Änderung die an dem Quelltext vorgenommen wurden, seit dem letzten Testlauf, den Fehler verursacht haben könnten. Hierbei verkürzt sich die Zeit, die für die Fehlersuche benötigt wird.

3.3.2 Nachteile der Testautomation

Natürlich gibt es nicht nur Vorteile sondern es birgt auch gewisse Schwierigkeiten die man beachten sollte.

3.3.2.1 Testmenge

Der Aufwand für die Automatisierung erhöht sich natürlich in der Menge der definierten Testfälle. In der Zeit, die man benötigt, um einen Test zu automatisieren, hätte man mehrere manuelle Tests durchführen können.

Zu beachten wäre das nur die Testfälle automatisiert werden sollten, die mehrfach ausgeführt werden.

3.3.2.2 Aufwand und Kosten

Bei einem Vergleich der Testkosten zwischen manuellen und automatischen Tests sollte die Lebensdauer des Testprojektes beachtet werden. Im Laufe der Lebensdauer kommen weitere Kosten als nur für die Erstellung Testskripte diese wären z.B.

  • Kosten für die wiederholte Ausführung der Tests
  • Kosten für die Wartung der Testskripte bei Änderung des getesteten Systems
  • Allgemeine Automationskosten (Schulungen, Programme etc.)


Beim manuellen Test entstehen zusätzlich zum konstanten Aufwand für die Wiederholung von Tests

  • Kosten für die Dokumentation der gefundenen Fehler / ausgeführten Tests,
  • Kosten für die Wartung der Testfallspezifikationen und
  • Kosten für die ausführlichere Entwickler-Dokumentation des Systems.

Die Höhe der Kosten zwischen manuellen und automatisierten Test ist am Ende von Kriterien abhängig wie z.B. den verwendeten Werkzeugen, als auch von der Sprache die verwendet wurde und das Produkt das zu erstellen ist.

3.3.2.3 Mangelnde Kreativität

Der automatisierte Test läuft stur die Testfalldefinition ab, die explizit vorgegeben wurde. Unter Umständen könnten auch Fehler entdeckt werden, die innerhalb des unterstützten Quelltextes liegen, wie z.B. ein Steuerelement, der entfernt wurde. Dagegen kann ein Mensch während des manuellen Testens auch andere Abweichungen außerhalb des gerade getesteten Bereichs feststellen und somit Testen.

Die automatisierten Tests können sich weniger auf die Veränderungen eines Produktes einstellen. Um die Testskripte anzupassen müsste man Daten neu aufzeichnen oder neu Bearbeiten. Im Gegensatz dazu stellt der manuelle Test eines Menschen eine Neuerstellung eines Testfalles dar, wobei man spontaner auf Veränderungen im Produkt reagiert werden kann.

3.4 Entscheidungskriterien zur Testautomation

Tests auf Systemebene stellen im Allgemeinen eine Kombination automatisierter und manueller Tests dar. Auf Systemebene muss das Testteam alle Testverfahrensanforderungen überprüfen, um festzulegen, welche Testverfahren automatisiert werden können und welche manuell ausgeführt werden sollten. [34]

Einige Kriterien wären z.B. die Häufigkeit der Ausführung oder die Wahrscheinlichkeit, dass der Test wiederholt Fehler entdeckt. Die Entscheidung, ob automatisiert wird, kann anhand der vier Kriterien Aufwand, Ausführungshäufigkeit, Fehlerwahrscheinlichkeit und Fehlerrisiko getroffen werden.

3.4.1 Zusatzaufwand für die Automation

Bei bestimmten Tests verursacht die Automation nur geringe Zusatzkosten. Ein Beispiel für keine Zeitersparnis wäre, wenn der Entwickler der seinen Quelltext auf Ebene der Unit Tests prüfen möchte, auch für einen manuellen Test die dazugehörigen API-Aufrufe eintippt. Man würde keine Zeit sparen, wenn man dies in einem Kommandozeileninterpreter tut anstatt ein Unit Test Framework zu verwenden. Unter bestimmten Umständen ist die Verwendung eines Frameworks leichter, da der Setup- Aufwand geringer ist.

Sind die Zusatzkosten geringer, sollten die anderen Kriterien ausgeklammert werden und dann beurteilt werden, weil diese Tests dann auch als Regressionstests dienen und die übrigen Entscheidungskriterien zudem Wahrscheinlichkeitsschätzungen beinhalten. Wären im Vergleich die Kosten höher müssten sie in Beziehung zu den übrigen (Entscheidungs-) Kriterien gesetzt werden.

3.4.2 Ausführungshäufigkeit

Aus der jeweiligen Test-Form ergibt sich die resultierende erwartete Ausführungshäufigkeit (da Unit Tests häufiger ausgeführt werden als Akzeptanztest) und dem eingesetzten Entwicklungsprozess. Je größer die Anzahl der Iterationen innerhalb des Prozesses ist, desto höher ist das Risiko von Regressionen und desto häufiger muss getestet werden. Bei einem reinen Wasserfallmodell würde es, übertrieben gesagt, ausreichen, jeden Test genau einmal am Ende des Prozesses auszuführen (sofern er keinen Fehler findet).

Die Auswahl des Entwicklungsprozesses beeinflusst darüber hinaus die Anforderungen an Flexibilität, Dokumentation und Feedback. Bei dem Beispiel „Extreme Programming“ wird zudem vollständige Unit Tests verlangt, weil diese als Ersatz zu dem, von dem Entwickler erstellten Quelltext-Dokumentation angesehen wird.

3.4.3 Fehlerwahrscheinlichkeit

Dieses Kriterium kann in erster Linie auf den einzelnen Testfall angewandt werden, teilweise aber auch auf bestimmte Teilmodule des Systems. Die Fehler- bzw. Regressionswahrscheinlichkeit einer Quelltext-Einheit hängt von ihrer logischen Komplexität und ihrer Volatilität ab. Wird sie häufig verändert, steigt das Risiko, dass bei einer dieser Änderungen ein Fehler eingeführt wird. Sie muss also entsprechend häufiger getestet werden und der Automationsaufwand rechnet sich eher.

3.4.4 Fehlerrisiko

Man sollte darauf achten nicht die gerade beschriebene Fehlerwahrscheinlichkeit mit dem Risiko eines Fehlers zu verwechseln. Das Fehlerrisiko beziffert die Schwere der Konsequenzen, die resultieren, wenn der Fehler unkorrigiert in eine Release-Version übernommen wird. So kann etwa die Wahrscheinlichkeit hoch sein, dass die Darstellung eines Formulars in verschiedenen Browsern um wenige Pixel abweicht, die Konsequenzen dieses Fehlers sind aber nicht besonders gravierend. In einem solchen Fall wird sich eine automatisierte Überprüfung nur selten lohnen.

3.5 Allgemeine Empfehlungen

Aus diesen Überlegungen lassen sich folgende allgemeine Empfehlungen beschriebenen Testverfahren aufstellen:

3.5.1 Unit- und Integrationstest

Für den Komponententest sollten immer die automatisiert werden. Da die Komponententests auf Quelltext-Basis ausgeführt werden, kann man diese ohne großen Aufwand in einen Unit-Test-Framework einbinden. Im Hinblick auf die Testkosten für die Erstautomation, kann man dann feststellen dass die Kosten wesentlich geringer ausfallen als bei andere Automationsverfahren. Gleichzeitig werden die Tests, besonders bei testgetriebener Entwicklung, während der Implementierung einer Komponente sehr häufig ausgeführt.

Die Automation der Unit-Test hat weitere Vorteile wie z.B. die Wartbarkeit und die möglichen Erweiterungen des Quelltextes. Die automatische Testsuite sichert zudem den Entwickler beim Refaktorisierung ab und erzwingt ein flexibleres Design, weil jede Funktion von zwei Stellen aufgerufen wird: dem echten Produktivquelltext und dem Testquelltext.

3.5.2 Sicherheitstest

Im Gegensatz zu Unit- und Integrationstests wird Sicherheitstest seltener ausgeführt. Bei diesem Verfahren kommt es auf die Quantität an verschiedenen Testfällen an, weil jeder mögliche Angriffspunkt getestet werden muss. Daher kann man zu dem Entschluss kommen, dass dies ein manueller Test ist.

Falls Fehler entdeckt werden sollten diese mit einem automatischen Test nachgewiesen und behoben werden. Anschließend kann man den automatischen Test in die Reihe der Regressionstests aufnehmen.

Je nach Anwendung kann es zudem sinnvoll seine bestimmten Bereiche des einen Sicherheitsrisikos aufweisen zu automatisieren.

3.5.3 Performancetests

Für die Performanz-Tests gilt vergleichsweise auch, dass sie seltener ausgeführt werden. Hierbei ist allerdings zu beachten dass der Aufwand für die Durchführung eines manuellen Testdurchlaufs höher ist als die Automation, die ohnehin geringer sind, falls einfache oder schon vorhandene Tests vervielfacht oder parallelisiert werden müssen.

3.5.4 Abnahmetests

Die für die Abnahme gestalteten Tests sog. „Abnahmetests“ sollten für den Kunden verständlich sein. Daher ist die Automation durch Scripting in diesem Fall nicht zu beachten. Ohnehin werden solche Tests idealerweise nur einmal pro Release ausgeführt. Bei größeren Projekten mit sehr kurzen Iterationen kann es sinnvoll sein, die durchgeführten Tests der Kunden mit der Methode Capture/ Replay-Werkzeug aufzuzeichnen oder durch den jeweiligen Entwickler als Skripte vorbereiten zu lassen, damit der Release nicht durch zu großen manuellen Testaufwand in die Länge gezogen werden muss.

3.5.5 Regressionstests

Die größte Fehlerwahrscheinlichkeit die bei 100% liegt ist bei den Regressionstests vorzufinden. Auch wenn die Fehler gefunden und behoben wurden, ist die Wahrscheinlichkeit für eine Regression deutlich höher als für das Auftreten eines Fehler in bisher „unauffälligem“ Quelltext. Diese sollten nur in Ausnahmen nicht automatisiert werden, etwa wenn die Fehlersituation sehr schwer automatisiert reproduziert werden kann.

4 Besonderheiten beim Testen von Web-Anwendungen

Theoretisch sind für Webanwendungen die gleichen Tests wie Desktopanwendungen durchzuführen. Auch hier sind dynamische und statische Tests, funktionale Tests, Systemtests und Integrationstests notwendig.

Besonderheiten ergeben sich bei dem User-Interface, als User-Interface wird eine Webseite benutzt, damit kommen neue Komponente wie Webserver und Browser ins Spiel hinzu.

Die Webanwendungen sollen besonders gut getestet werden, weil da viele Anwendungen wie E-Commerce, Web-Shops und Online-Banking sind und bei jeder nicht gefundener Fehler viel Geld für den Betreiber kosten kann. Allein das zeigt, warum eine Webanwendung sehr gut getestet wird und möglichst wenig Fehler haben soll.

Wegen Besonderheiten, wird schnell festgestellt, neben Testverfahren für Desktop-Anwendungen braucht man spezielle Testverfahren in den Bereichen Leistungstest, Skalierbarkeit, Sicherheit und Zuverlässigkeit um eine Webanwendung sicher zu erstellen.

4.1 Verteilte Umgebung

An einer Ausführung einer Webanwendung sind immer mindestens zwei Rechner beteiligt: der Rechner des Benutzers (Client) und der Webserver. Beim Einsatz der Dreischicht-Architektur kommen zu dem auch noch Datenbankrechner und Anwendungsserver dazu, um die eben genannten drei logischen Schichten von einander zu entkoppeln.

Dann verteilt sich die Ausführung einer Funktion über mehrere dieser Rechnerebenen: Zur Beantwortung eines Requests ruft der Webserver eine Funktion auf dem Applikation Server auf, der daraufhin Daten vom Datenbankserver erfragt und das Ergebnis seiner Berechnung an den Webserver zurückliefert. Nachdem dessen Präsentationslogik das Ergebnis in HTML-Markup umgesetzt hat, wird es an den Client-Browser gesendet und muss dort korrekt dargestellt werden.

Daraus ergeben sich folgende Problemstellungen für den Test:

Auf jeder dieser Schichten einer solchen verteilten Architektur können unterschiedliche Fehler auftreten, für die angemessene Testverfahren ausgewählt werden müssen. Zudem ergibt sich aus der notwendigen Kommunikation zwischen den Schichten eine erhöhte Wahrscheinlichkeit von Netzwerk- und Schnittstellenfehlern (z.B. inkorrekter Aufruf oder Unerreichbarkeit entfernter Dienste), und damit auch ein erhöhter Testbedarf in diesem Bereich.

Die Tests sind zwangsläufig Blackbox-Tests: Tritt beim clientseitigen Test ein Fehler in einer weiter unten liegenden Schicht (z.B. Applikation Server) auf, so kann die Ursache dieses Fehlers meist nur schwer festgestellt oder reproduziert werden, weil dem Client-Tester keine Laufzeitinformationen aus dieser Schicht vorliegen.

Webanwendungen können oder werden in der Regel von mehreren Benutzern gleichzeitig genutzt. Hierbei kann es aber zu Problemen kommen, durch die parallelen Zugriffe der Benutzer kann es zu Inkonsistent oder Race Conditions kommen, wie z.B. beim Speichern der Informationen in einer Datenbank. Die Anwendungen sind somit auch auf die Fehlerklassen hin zu testen.
Race Condition: Ein kritischer Wettlauf in der Programmierung eine Konstellation, in denen das Ergebnis einer Operation vom zeitlichen Verhalten bestimmter Einzeloperationen abhängt.

4.2 Unbekannte Client-Konfigurationen

Bei Webanwendungen sind weder die Hardware- noch die Software Konfiguration der Benutzer-Rechner planbar bzw. erkennbar. Je nach Projekt müssen Entwickler und Tester beispielsweise folgenden Variablen berücksichtigen:

  • Bandbreiten der Internetverbindung
  • Verwendeter Browser
  • Im Browser verfügbaren JavaScript-Version
  • Rechnern als auch Grafikleistungen der Benutzer-Rechner
  • Verfügbare Plug-Ins

Beim Test sollte sichergestellt werden, dass das entwickelte System mit der festgelegten Minimalkonfiguration benutzbar ist. Es sollte zusätzlich auch in der Lage sein zu ermitteln in welcher Umgebung die Anwendung nicht ordnungsgemäß funktioniert.

Abbildung 07: Unterschiedliche Client-Konfigurationen
Abbildung 07: Unterschiedliche Client-Konfigurationen

4.3 Interaktionsmodell

Das Interaktionsmodell einer Webanwendung unterscheidet sich aufgrund des verwendeten HTTP-Protokolls deutlich von dem einer herkömmlichen GUI-Applikation. Befehle und Daten werden erst zum Server übertragen, wenn der Benutzer sie explizit absendet. [35]Nguyen, Johnson und Hackett bezeichnen dies als explicit Submission model. So können z.B. Informationen verloren gehen, wenn der Benutzer nach dem Ausfüllen eines Formulars eine neue Seite aufruft, ohne vorher auf den entsprechenden Speichern-Button zu klicken. Ähnliche Probleme treten auch bei der Verwendung der Vor- und Zurück-Schaltflächen des Browsers (besonders in Kombination mit Formulardaten) oder bei der Anmeldung mit Passwort auf: Was geschieht etwa, wenn der Benutzer sich bei einer Webanwendung anmeldet, dann aber den Browser schließt und wieder öffnet – soll er dann noch immer angemeldet sein oder nicht?
Aus diesem Interaktionsmodell resultiert eine spezielle Klasse von Fehlern, die sich zwar niemals vollständig vermeiden lässt, bei der Planung der Testfälle aber in jedem Fall berücksichtigt werden sollte.

4.4 Sicherheit

Webanwendungen können überall aus der Welt aufgerufen werden. Daraus ergeben sich erhöhte Sicherheitsanforderungen – nicht nur der Zugriff auf die Anwendung selber muss geschützt werden, auch besonders der Rechner, über den die Anwendung mit dem Internet verbunden ist, muss abgesichert werden. Durch die Zweiteilung der Anwendung in Client und Server und die damit verbundene Datenkommunikation per HTTP hat der Server keine Möglichkeit, zu unterscheiden, ob ein Request von der echten Client-Anwendung gestellt wird, oder ob der Request von einem »Angreifer« verändert wurde (der damit z.B. die Validierung innerhalb des Clients umgeht). Auch hier ergibt sich wieder eine eigene Klasse von Fehlerquellen, auf deren Auftreten getestet werden muss.


5 Fazit

Tests sind wichtige Maßnahmen zur Qualitätssicherung in der Softwareentwicklung. Das Testen hat das Ziel Fehler aufzudecken, die beseitigt werden müssen. Das Testen kann beendet werden, wenn vorab definierte Testkriterien erfüllt werden. Dem Softwareentwickler und dem Projektmanager werden eine Vielzahl an Methoden und Werkzeugen zur Verfügung gestellt, um eine Software in einem nahezu perfekten Stand zu bringen.
Es muss erst die Frage geklärt werden: Welche Testverfahren für das Unternehmen in Frage kommen? Aufgrund steigender Anforderungen von Webanwendungen, ist manuelles Testen mit einem sehr großen Aufwand an Zeit und Personal verbunden. Moderne Webanwendungen haben eine Vielzahl von Elementen und Interaktionsmöglichkeiten, die alle im Test einbezogen und überprüft werden müssen.
Deswegen kann Testautomation hier Abhilfe schaffen und bringt mehrere Vorteile mit sich. Trotz der Vorteile gibt es auch Nachteile. In vielen Fällen scheitert automatisiertes Web-Testen entweder an dynamischen Inhalten oder Oberflächen.

6 Abbildungs- und Tabellenverzeichnis

Abbildungen

  • Abbildung 01: Kontrollflussdiagraph eines Beispielsprogramms
  • Abbildung 02: Testprozess des Softwareprodukts
  • Abbildung 03: Testfallermittlung
  • Abbildung 04: Manuelles Testen vs. Testautomatisierung
  • Abbildung 05: Scripting Verfahren
  • Abbildung 06: Beispiel einer Testsuite
  • Abbildung 07: Unterschiedliche Client-Konfigurationen

Tabellen

  • Tabelle 01: Norm ISO 9126
  • Tabelle 02: Äquivalenzklassen
  • Tabelle 03: Äquivalenzklassentest
  • Tabelle 04: Grenzwertbetrachtung
  • Tabelle 05: Rollen und Verantwortlichkeiten

7 Fußnoten

  1. ↑ vgl. Quellangabe Nr. 05, Seite 6f
  2. ↑ vgl. Quellangabe Nr. 06, Seite 157
  3. ↑ Quellangabe Nr. 05, Seite 11
  4. ↑ vgl. Quellangabe Nr. 05, Seite 11f.
  5. ↑ vgl. Quellangabe Nr. 07, Seite 84ff.
  6. ↑ vgl. Quellangabe Nr. 06, Seite 177
  7. ↑ vgl. Quellangabe Nr. 05, Seite 115ff.
  8. ↑ vgl. Quellangabe Nr. 06, Seite 181
  9. ↑ vgl. Quellangabe Nr. 06, Seite 200ff.
  10. ↑ vgl. Quellangabe Nr. 06, Seite 206
  11. ↑ vgl. Quellangabe Nr. 05, Seite 145
  12. ↑ vgl. Quellangabe Nr. 05, Seite 144ff.
  13. ↑ vgl. Quellangabe Nr. 06, Seite 209
  14. ↑ vgl. Quellangabe Nr. 06, Seite 210
  15. ↑ Quellangabe Nr. 06, Seite 210
  16. ↑ vgl. Quellangabe Nr. 05, Seite 77
  17. ↑ vgl. Quellangabe Nr. 05, Seite 80
  18. ↑ vgl. Quellangabe Nr. 05, Seite 82
  19. ↑ vgl. Quellangabe Nr. 05, Seite 82f.
  20. ↑ vgl. Quellangabe Nr. 05, Seite 84ff.
  21. ↑ vgl. Quellangabe Nr. 05, Seite 93ff.
  22. ↑ vgl. Quellangabe Nr. 07, Seite 141f.
  23. ↑ vgl. Quellangabe Nr. 07, Seite 143
  24. ↑ vgl. Quellangabe Nr. 07, Seite 142ff.
  25. ↑ vgl. Quellangabe Nr. 07, Seite 151
  26. ↑ vgl. Quellangabe Nr. 07, Seite 153ff.
  27. ↑ vgl. Quellangabe Nr. 05, Seite 177ff.
  28. ↑ vgl. Quellangabe Nr. 03, Seite 5
  29. ↑ vgl. Quellangabe Nr. 01, Seite 4
  30. ↑ vgl. Quellangabe Nr. 101
  31. ↑ vgl. Quellangabe Nr. 01, Seite 4
  32. ↑ vgl. Quellangabe Nr. 100
  33. ↑ vgl. Quellangabe Nr. 02, Seite 193f.
  34. ↑ vgl. Quellangabe Nr. 01, Seite 304
  35. ↑ vgl. Quellangabe Nr. 04

8 Literatur- und Quellenverzeichnis

Nr.Quellebezeichnung
01Buch "Software Automatisch Testen" von Dustin Elfriede, Rashka Jeff, Paul John (2000) ISBN-13: 978-3540676393
02Buch "Software Qualität Testen, Analysieren und Verifizieren von Software" von Peter Liggesmeyer (2009) ISBN-13: 978-3827420565
03Buch "Werkzeuge zur Testautomatisierung" von Werner Hommes (2003) ISBN:978-3-638-69941-9
04Buch "Testing Applications on the Web. 2nd edition" von Hung Q.Nguyen, Bob Johnson, Michael Hackett (2003) ISBN-13: 978-0471201007
05Buch "Basiswissen Softwaretests" von Andreas Spillner, Tilo Linz (2005), 3. Auflage, dpunkt.verlag, ISBN: 3-89864-358-1
06Buch "Software-Qualität" von Prof. Fr. Dirk W. Hoffmann (2008), eXamen.press, ISBN: 978-3-540-76322-2
07Buch "Analytische Softwarequalitätssicherung in Theorie und Praxis" von Peter Riotzsch (2005), MV-Verlag, ISBN: 3-86582-202-9
08Buch "Grundkurs Wirtschaftsinformatik" von Dietmar Abts und Wilhelm Mülder (2004), 5.Auflage, vieweg, ISBN: 3-528-45503-9
100Internet "http://soatoolbox.com/userguide/functional/testsuites.html" Zugriff : 24.11.2009
101Internet "http://www.web2test.de/knowledgebase/manual-vs-automated-web-testing/" Zugriff : 12.01.2010

9 Anhang

ppt datei

Von „http://winfwiki.wi-fom.de/index.php/Automatisiertes_Testen_von_Web-Applikationen“
Persönliche Werkzeuge