Testplanung

Testplanung

1.Zweck des Dokuments 2.Testziele3.Teststrategie4. Inkrementeller Test5. Dokumentation der Tests6. Performance Test7. Literaturreferenzen

Testplanung

Dokumentation der Teststrategie für das Projekt Festlegung der Vorgehensweisen bei der Organisation und Planung Festlegung der Art und Weise der Testdurchführung

1. Zweck des Dokuments

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 Fehlerpr

otokoll 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.)

DVW und Playlist Datenbanke

Datenverarbeitung bzw. Player

Ctrl

Ebene 4

Ebene 3

Ebene 2

Ebene 1 GUl

Actung :Es erfolgt ein inkrementeller Test, der in folgenden 3 Schritten ablaeuft.1.Schritt: Komponententest2.Schritt: Integrationstest:3.Schritt: Systemtest:

Erst wenn alle Tests eines Schrittes erfolgreich verlaufen sind, dürfen die Test des naechsten Schrittes ausgeführt werden



Integrationstest

Komponententest(Modultest)

Systemtest

Funktionale Tests

Strukturelle Tests

Sc

hrittw

eise


4.1:KomponententestIm 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 (DV

W und Playlist) getestet.

Klasse

DVW und Playlist

Eingabe

Datenbanke

Ausgabe

Ebene 4

Prüfen

Schreiben in Lesen von

4.1.2 Es folgt der Test der Player-Ebene


Klasse

Player

Eingabe Ausgabe

Ebene 2

Prüfen

4.1.3 Es folgt der Test der Ctrl-Ebene


Klasse

Ctrl

Eingabe Ausgabe

Prüfen

Ebene 3

4.1.4 Schliesslich folgt der Test der GUI.


Klasse

GUI

Eingabe Ausgabe

Prüfen

Ebene 1


Testmethode Blackbox Test

Whitebox Test Bestimmen der Testreinfolge 1. durch der Art von Methode

Konstruktor MutatorObserver

private publicprotected


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.

Klasse1 Klasse3

Klasse5Klasse4

Klasse2Bsp.

Ebene n

4.2. Integrationstest(fort.)

4.2.2 Imlizit werden hiermit die Schnittstellen der 4 Schichten getestet.

Testmethode: Die einzelnen Aktionen der Anforderungsdef

inition werden fuer die Tests verwendet.

4.2. Integrationstest(fort.) DVW und Ctrl sowie Playlist

Palylist und Ctrl sowie Player

Player und Ctrl sowie GUI

usw.

DVW PlaylistCtrl

PlayerCtrlPlaylist

GUICtrlPlayer

4.3. Systemtest

4.3. Systemtest: Beim Sytemtest wird das Gesamtsystem, aufbauend a

uf den Benutzeranforderungen, getestet. Es werden erdenklichen Tests durchgefuehrt, um das S

ystem auf "Herz und Nieren" zu testen.

Ctrl

Playlist

Datenverarbeitung GUI

Datenbank

Methode: Alls ausprobiert

4.3. Systemtest(fort.)

5.Dokumentation der Tests

5.1.Dokumentation für den durchgefuehrten Tests TesterImplementator der KlasseDatumSchichtZu testende Klassezu testende MethodenTestdatensatzerwartete Ergebnisseeingetretene ErgebnisseSoll/Ist − Vergleich

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

5.Dokumentation der Tests(fort.)

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

System

Datenbank

Informatiker

Benutzer

6.Literaturreferenzen [Balzert, 1998] Balzert, Helmut: Lehrbuch der Software-Technik 1/2, Spektrum Akademischer Verlag, B

and 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 V-Modell-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.

Documents

Testplanung