als DOC

Anleitungen für das Test-Dokument
Test-Nummer: Nummer für diesen Testfall
Items: Was wird getestet?
Beschreibung: Hier wird der Testfall genauer beschrieben.
Bezug: Bezug zum Pflichtenheft (z.B. Use Case "Datei Öffnen" S. X) wo möglich verlangen
bzw. darauf hinweisen, dass möglichst viele Punkte im Pflichtenheft auch durch "Test Cases"
abgedeckt werden. Des Weiteren sollte hier der Bezug zu anderen Tests vermerkt werden,
insbesondere falls es sich um eine Wiederholung eines Testes handelt.
Details: evtl. weitere benötigte Details zum besseren Verständnis oder Ergänzungen.
SOLL-Output: Welches Ergebnis wird erwartet bzw. soll laut Spezifikation erzielt werden.
IST-Output: Welches Ergebnis kommt tatsächlich raus?
Pass?: War der Test erfolgreich?
Wann wurde der Fehler eingebaut?: Falls ein Fehler vorliegt, soll hier aufgeführt werden in
welcher Phase der Fehler eingebaut wurde (Entwurf, Design, Implementierung, Review, Test).
Kommentar: evtl. Kommentare zu den Ergebnissen.
Wer?: Wer hat den Test durchgeführt.
Wann?: Wann wurde der Test durchgeführt?
Bemerkungen:
Damit man besser sieht dass bei ggf. auftretenden Problemen wieder getestet wurde, sollte
nach Modifikationen einer Komponente die Tests auch wiederholt werden, so dass durchaus
mehrere Einträge auftauchen können. Jeder Testfall soll auf einer NEUEN Seite beginnen.
Test-Nummer: 1
Items: Topologieeditor
Beschreibung: Was macht der Topologieeditor mit einer semantisch falschen
Topologiedatei?
Bezug: Pflichtenheft Seite XX. Wiederholung des Tests 42.
Details: Es soll eine Topologiedatei so geändert werden, dass ein Track kein Ende hat, d.h.
der Track endet im NICHTS. Dann wird diese Topologiedatei durch den Topologieeditor
eingelesen.
SOLL-Output: Der Topologieeditor sollte die Datei ohne Probleme einlesen können. Nur
beim erneuten Speichern sollte eine entsprechende Fehlermeldung kommen (das wäre ein
anderer Testfall).
IST-Output:
Pass?:
Wann wurde der Fehler eingebaut?:
Kommentar:
Wer?:
Wann?:
Test-Nummer: 2
Items: Visualisierung - Übersichtlichkeit
Beschreibung: Gibt es ein Ranking, auf dem GLEICHZEITIG ALLE Shuttle zu sehen sind?
Bezug: Pflichtenheft Seite XX.
Details: Es soll in der Visualisierung möglich sein die aktuelle Position (Ranking) bzgl. des
Geldstandes von jedem Shuttle gleichzeitig sehen zu können. Hierzu sollen mind. 3 Shuttles
geladen werden. Hierbei kann es sich auch jeweils um das gleiche Shuttle handeln. Während
des Tests sollten sich das Ranking der Shuttle mind. 1 mal geändert haben.
SOLL-Output: Das Ranking ALLER Shuttle ist GLEICHZEITIG sichtbar. Die Anzeige
kann nach Geldstand sortiert, oder durch eine entsprechende Markierung erfolgen. D.h. die
Reihenfolge bei der Anzeige bleibt gleich. Das Ranking wird durch ein Symbol, eine farbliche
Markierung, o.ä. vorgenommen.
IST-Output:
Pass?:
Wann wurde der Fehler eingebaut?:
Kommentar:
Wer?:
Wann?:
Test-Nummer: 3
Items: Shuttle - Strategie
Beschreibung: Erhält das eigene Shuttle einen Auftrag und wird dieser abgearbeitet.
Bezug: Pflichtenheft Seite XX.
Details: Hier soll das eigene Shuttle mind. 1 Auftrag erhalten und diesen komplett abarbeiten.
D.h. das Shuttle soll bieten und den Zuschlag erhalten. Danach soll der Auftrag KOMPLETT
abgearbeitet werden. Ob dabei eine Strafe gezahlt wird ist unwichtig.
SOLL-Output: Nach einem max. 20 Min. Test soll mind. 1 Auftrag abgearbeitet worden
sein.
IST-Output:
Pass?:
Wann wurde der Fehler eingebaut?:
Kommentar:
Wer?:
Wann?: