Testplanung
Testplanung
1.Zweck des Dokuments
2.Testziele
3.Teststrategie
4. Inkrementeller Test
5. Dokumentation der Tests
6. Performance Test
7. Literaturreferenzen
1. Zweck des Dokuments
Dokumentation der Teststrategie für das Projekt
 Festlegung der Vorgehensweisen bei der Organisation
und Planung
Festlegung der Art und Weise der Testdurchführung
2. Testziele



Fehler finden
Erstellung eines fehlerfreien
komplexen
Programms wie möglich
Erfüllbarkeit der
Benutzeranforderungen nach der
Spezifikation
3.Teststrategie
Folgende Regeln muessen von allen am Test
beteiligten eingehalten werden:
 Jeder, der eine Klasse implementiert, ist für den
Klassentest zustaendig.


Ein Test wird in einem Testprotokoll festgehalten.
Wird ein Fehler gefunden, wird zusätzlich ein
Fehlerprotokoll ausgefüllt. Dieses wird über einen
Verantwortlichen an den jeweiligen
Implementator weitergeleitet. Dieser behebt den
Fehler und beendet das Fehlerprotokoll.
3.Teststrategie(fort.)


Es duerfen nur getestete Klassen in CVS
eingechecked werden.
Jedes Testprotokoll umfaßt jeweils nur eine
Schicht.
4.Inkrementeller Test

Das zu testende System ist in 4
Schichten oder Ebenen eingeteilt.
1. GUI
2. Ctrl.
3. Datenverarbeitung bzw. Player
4. Datenbank (DVW und Playlist)
4.Inkrementeller Test (fort.)
Ebene 1
GUl
Ebene 2
Ebene 3
Ebene 4
Ctrl
Datenverarbeitung bzw. Player
DVW und Playlist
Datenbanke
4.Inkrementeller Test (fort.)
Actung :
Es erfolgt ein inkrementeller Test, der in folgenden 3
Schritten ablaeuft.
1.Schritt: Komponententest
2.Schritt: Integrationstest:
3.Schritt: Systemtest:
Erst wenn alle Tests eines Schrittes erfolgreich verlaufen
sind, dürfen die Test des naechsten Schrittes ausgeführt
werden
4.Inkrementeller Test (fort.)
Systemtest
Schrittweise
Integrationstest
Komponententest(Modultest)
Funktionale Tests
Strukturelle Tests
4.Inkrementeller Test (fort.)
4.1:Komponententest
Im ersten Schritt werden die kleinsten Einheiten,die
Klassen, unabhängig voneinander getestet. Dabei
werden alle Methoden getestet.
Es muessen geeignete Datensaetze erschaffen
werden, die an die Methoden der zu testenden
Klassen übergeben werden.
4.1:Komponententest(fort.)
4.1.1 Es werden klassenweise alle Methoden
getestet.
 Zuerst werden die Klassen der Datenbankschicht
(DVW und Playlist) getestet.
Ebene 4
Prüfen
Ausgabe
Eingabe
Klasse
DVW und Playlist
Schreiben in
Lesen von
Datenbanke
4.1:Komponententest(fort.)

4.1.2 Es folgt der Test der Player-Ebene
Ebene 2
Prüfen
Eingabe
Ausgabe
Klasse
Player
4.1:Komponententest(fort.)

4.1.3 Es folgt der Test der Ctrl-Ebene
Ebene 3
Prüfen
Eingabe
Ausgabe
Klasse
Ctrl
4.1:Komponententest(fort.)
4.1.4 Schliesslich folgt der Test der GUI.
Ebene 1
Prüfen
Eingabe
Ausgabe
Klasse
GUI
4.1:Komponententest(fort.)
Testmethode
Blackbox Test
 Whitebox Test
 Bestimmen der Testreinfolge
1. durch der Art von Methode

Konstruktor
private
Observer
protected
Mutator
public
4.1:Komponententest(fort.)
2. Methodenaufruf-beziehungen
Zuerst: die Methoden, die keine anderen
Methoden aufgerufen.
Danach: die Methoden, die die anderen
Methoden aufgerufen.
Werkzeug:
JUnit
4.2. Integrationstest

4.2. Integrationstest:
4.2.1 Das Zusammenspiel von Klassen, die sich in
verschiedenen Schichten befinden,wird getestet.
Ebene n
Bsp.
Klasse1
Klasse4
Klasse2
Klasse3
Klasse5
4.2. Integrationstest(fort.)
4.2.2 Imlizit werden hiermit die
Schnittstellen der 4 Schichten
getestet.

Testmethode:
Die einzelnen Aktionen der
Anforderungsdefinition werden fuer die
Tests verwendet.
4.2. Integrationstest(fort.)

DVW und Ctrl sowie Playlist
DVW

Playlist
Palylist und Ctrl sowie Player
Playlist

Ctrl
Ctrl
Player und Ctrl sowie GUI
Player
usw.
Player
Ctrl
GUI
4.3. Systemtest

4.3. Systemtest:
Beim Sytemtest wird das Gesamtsystem,
aufbauend auf den Benutzeranforderungen,
getestet.
Es werden erdenklichen Tests durchgefuehrt, um
das System auf "Herz und Nieren" zu testen.
4.3. Systemtest(fort.)
Datenverarbeitung
GUI
Ctrl
Datenbank
Playlist
Methode: Alls ausprobiert
5.Dokumentation der Tests
5.1.Dokumentation für den durchgefuehrten
Tests
Tester
Implementator der Klasse
Datum
Schicht
Zu testende Klasse
zu testende Methoden
Testdatensatz
erwartete Ergebnisse
eingetretene Ergebnisse
Soll/Ist − Vergleich
5.Dokumentation der Tests(fort.)
5.2. Fehlerprotokoll,Wenn Fehler
aufgetreten sind
Ref.−Nr auf Test
 Tester
 Implementator
 Datum
 Fehlerklasse:
Unvollstaendigkeit (U),
falsche Information (F),
Ueberspezifikation und irrelevante Informationen
(R),
Inkonsistenzen und Widersprueche (I), sonstige
Fehler (S)
 Fehlerbeschreibung
 Vorschlag zur Fehlerbehebung
6. Performance









Test
Qualität &Streß Test
-- Reagierende Zeit für Methode aufrufen
-- Ob alle Funktion nach geplante Zeit fertig sein ?
-- Wie System Belastung ist?
Methode:
-- Wie? Wann Ein Benutzer ein Event aufrufen?
-- Wie? Wann Mehre Benutze gleichzeitig eine
Event aufrufen?
-- Wie? Wann eine Benutzer verschiedene
Event gleichzeitig aufrufen?
-- Wie? Wann Mehre Benutze gleichzeitig viele
Events gleichzeitig aufrufen?
Sicherheits und Zugriffrecht test.


Systemzugriff
Datenbankzugriff
Informatiker
System
Datenbank
Benutzer
6.Literaturreferenzen

[Balzert, 1998] Balzert, Helmut: Lehrbuch der Software-Technik 1/2, Spektrum
Akademischer Verlag, Band 1 und 2, 1998/2000, ISBN: 3827403014.

[Henderson, 1995] Henderson-Sellers, Brian: "Object-Oriented Metrics: Measures of
Complexity", Prentice Hall, ISBN 0132398729, 1995.



[Holzmann, 2002] Holzmann, Clemens: „Seminar Programmierstil: Metriken“,
http://www.ssw.uni-linz.ac.at/Teaching/Lectures/Sem/2002/reports/Holzmann/.
[IESE, 2003] Fraunhofer Institut für Experimentelles Software-Engineering: „Der VModell-Guide“, http://www.iese.fhg.de/VModell/.
[Pol et al., 2000] Pol, Martin; Koomen, Tim ; Spillner, Andreas: “Management und
Optimierung des Testprozesses: ein praktischer Leitfaden für Testen von Software, mit
TPI und TMap”, dPunkt,2000, ISBN 3-932588-65-7.

[Rätzmann, 2002] Rätzmann, Manfred: „Software-Testing - Rapid Application
Testing,Softwaretest, Agiles Qualitätsmanagement“, Galileo, 2002, ISBN 3898422712.

[Schaefer, 1996] Schaefer, H.: „Surviving under time and budget pressure“, Proceedings
Euro-STAR Conference, Amsterdam, 1996.

Testplanung