| Home | Projekt ecwin7 | Anforderungsanalyse | Implementierung | Abnahmetest | |
Das Projekt ecwin7
Der hier vorbereitete Test dient dem Hersteller zum Nachweis der fehlerfreien Funktion, es ist also die Aufgabe, in die technische Ecken des Produkts zu testen. Ein Abnahmetest für den Kunden würde sich eher auf fachlicher Ebene bewegen. Der Herstellertest ist die umfangreichere Variante.
Jeder Abnahmetest stützt sich auf Grundannahmen über die Vertrauenswürdigkeit der Implementierung. Im vorliegenden Fall wird angenommen, dass in der Implementierung keine Fallen und Tricksereien enthalten sind, die von außen nicht erkennbare Zusammenhänge im Produkt schaffen. Der hier erstellte Test prüft möglichst vollständig in der Breite. Die Testtiefe zu vergrößern wäre jederzeit aus der vorliegenden Spezifikation möglich, es bedarf dazu keiner anderen Verfahrensweise als der hier vorgestellten und ist nur eine Frage von Zeit und Geld. Angesichts der geradlinigen Implementierung im vorliegenden Fall würde für einen tieferen Test allerdings nicht viel Substanz übrigbleiben.
Eigenschaften des zu Grunde liegenden Fensterverwaltungssystems (Java Swing) werden nicht getestet, von der Fehlerfreiheit wird ausgegangen bis zum Beweis des Gegenteils. Es kann Situationen geben, in denen Manipulationen außerhalb des Testablaufs erforderlich sind, z.B. wenn ein Fenster ein anderes verdeckt und das benötigte erst sichtbar gemacht werden muss. Auch solche Situationen gehören nicht in den Test des Produkts und werden erst dann relevant, wenn der Test mangels Lösungsmöglichkeit nicht mehr fortgeführt werden kann.
Die Testschritte sind in längere Testprozeduren zusammengefasst. Grundsätzlich wäre eine Teststrategie möglich, in der jedes einzelne Feature in einer eigenen Testsuite geprüft wird mit Voreinstellung der Testsituation, Testschritt, Kontrolle und Rückführung auf einen definierten Zustand. Dies wäre hier keine passende Teststrategie, da die Wechselwirkungen im Produkt einen wesentlichen Bestandteil der Tests ausmachen. Das Risiko, bei einer nachträglichen Änderung am Produkt eine ganze Testprozedur neu erstellen zu müssen ist leichter zu tragen als die hochgradige Ineffizienz bei kleinen separaten Testfällen für Systeme dieser Art.
In einem Projekt würde der Tester den Implementierungsprozess verfolgen um Abweichungen zwischen dem Tester-Verständnis und der Implementierung frühzeitig und kostengünstig zu klären. In dem vorliegenden Projekt wurde während der Testerstellung bewusst auf den Abgleich mit dem bereits vorhandenen Produkt verzichtet. Der Ausgangspunkt des Tests ist allein die Tango-Spezifikation.
In einem Test muss erkennbar sein, aus welchen Anforderungen sich der Testfall ableitet. Diese Rückverfolgung ist automatisch gewährleistet, wenn in den Testfällen die Tango-Notation verwendet wird und die Bezeichnungen aus der Spezifikation beibehalten werden. Die Tango-Spezifikation ist nach Bedienungs-Gesichtspunkten gegliedert, und im Test wird eben diese Bedienung nachvollzogen. Die Beschreibung des Testfalls ist damit gleichzeitig der Pfad, der in die Tango-Spezifikation führt.
Der umgekehrte Weg vom Requirement zum Testfall ist wünschenswert, um die Vollständigkeit der Testfälle zu überprüfen. Im Falle einer Testfall-Beschreibung mit Tango würde aus den Testfällen die Spezifikation rekonstruiert, und das Ergebnis mit der ursprünglichen Spezifikation verglichen. Im vorliegenden Fall wird auf diesen Weg verzichtet, da die Ableitung direkt aus der Tango-Spezifikation erfolgt ist und nicht genügend Freiräume vorhanden waren, um die Testabdeckung ernsthaft in Frage zu stellen. Sollten sich im Projektverlauf Zweifel an der sorgfältigen Umsetzung ergeben, so müsste dieser Schritt nachgereicht werden.
Die Ableitung der Testprozeduren aus der Tango-Spezifikation wird im Folgenden pragmatisch vorgestellt, dies ist keine Einführung in die Testanalyse. Die durchgeführten Schritte werden kurz vorgestellt, anschließend das meist längliche Ergebnis präsentiert. Grundsätzlich muss für diese Analyse nicht unbedingt Tango verwendet werden, die Methodik entstammt der werkzeugunabhängigen Entwicklung von Softwaretests. Die Testprozeduren entstehen, indem die Tango-Spezifikation mehrfach zerpflückt wird, und es dient der Rückverfolgung von Testfall zur Spezifikation, wenn die Beschreibungsmethode dabei gleich bleibt.
Alle Eingaben, Ausgaben und Wirkmöglichkeiten zwischen Produkt und Außenwelt werden zusammengestellt. Dies sind
Die Liste aus Schritt 1 wird ergänzt um die Wirkungen, die an den Aktivatoren ausgelöst werden.
Die Wirkungen werden ohne Berücksichtigung des aktuellen Gesamtzustands beschrieben, deshalb müssen Alternativen hier in einer Bedingung, Verzweigung oder einer unbestimmten formlosen Beschreibung notiert sein.
Es sollen nur relevante Situationen im Test berücksichtigt werden, also diejenigen Situationen, in denen offene Fenster eine Wechselwirkung miteinander haben. Damit werden wirkungsidentische Permutationen von Zuständen vermieden.
Aus direkten Abhängigkeiten lassen sich Abhängigkeitsketten bilden und daraus die testrelevanten Fensterkombinationen.
Abhängigkeiten, die durch innere Zustände des Produkts entstehen, werden hier nicht betrachtet, diese stecken implizit in den Alternativen von Schritt 2.
Durch Berücksichtigung der Anfangszustände werden die in Schritt 2 gesammelten Beschreibungen konkreter. Es bleiben immer noch Alternativen offen, wenn auf Zustände im Produkt Bezug genommen wird, die nicht durch Fenster abgebildet werden. Die Liste der möglichen Manipulationen genügt, da die Wirkungen bereits im Schritt 2 beschrieben sind.
Alle nicht in der Liste der relevanten Testzustände in Schritt 3 aufgeführten Kombinationen sind gemischte Zustände, sie treten nicht als Anfangszustand eines Tests auf. In besonderen Situationen können sie aber notwendig sein, um einen relevanten Zustand zu erreichen, in diesem Fall werden sie als transiente Zustände bezeichnet.
Die Zuordnung von Manipulationen zu relevanten Testzuständen bedeutet noch nicht, dass dafür ein separater Testschritt durchgeführt werden muss. Die Handlungen werden durchnummeriert, um in den Testprozeduren darauf Bezug nehmen zu können.
In diesem Beispiel werden die Testprozeduren aufgabenbezogen konstruiert, deshalb können sie mit einer nutzungsbezogenen Überschrift versehen werden. Ein Testschritt in der Prozedur dient gleichzeitig der Vorbereitung des nächsten Testschritts.
Die Überschriften werden nicht vorab festgelegt, sondern sie ergeben sich iterativ:
Die Liste der Testprozeduren ist in der Reihenfolge der Nummerierung auf diese Weise erstellt worden:
| Kennung | Überschrift / Thema |
|
of1 |
+ohneFenster.ProgrammStarten |
|
of2+ |
Alle default-Einstellungen der Fenster prüfen |
|
of3+ |
Geänderte Einstellungen der Fenster prüfen |
|
of4+ |
Applikation beenden |
|
of5+ |
Fenster öffnen, schließen und Aufbau |
|
of6+ |
Kundenliste ergänzen und anzeigen |
Die Testschritte werden mit der Nummer aus der Liste zustandsabhängiger Manipulationen aus Schritt 4 markiert. Gemischte Anfangszustände haben keine nummerierten Manipulationen, es wird eine Manipulation aus einem vergleichbaren Fall verwendet und mit "x" am Ende markiert.
Das pod-ähnliche Format teilt die Testprozedur in Bereiche mit folgenden Funktionen:
|
=case |
Kennzeichnung des Testfalls und Beschreibung der Intention |
|
=pre |
Schritte, die nicht geprüft werden, sondern nur helfen, den gewünschten Anfangszustand zu erreichen |
|
=step |
der Testschritt, der die zu prüfende Wirkung hat |
|
=check |
Parameter der zu prüfenden Situation |
|
=next |
aktueller Stand, mit dem die Prozedur abschließt, bei dieser Testmethodik irrelevant |
|
=post |
Rückführung auf einen definierten Zustand, mit dem diese Prozedur abschließt, bei dieser Testmethodik irrelevant |
Die Arbeit mit Tango ist an dieser Stelle beendet. Die Testprozeduren können manuell oder mit einem geeigneten Werkzeug als Skript ausgeführt werden. Testprozeduren können in eine geeignete Skriptsprache oder als Text in natürlicher Sprache zur Prüfung durch den technik-unbelasteten Kunden konvertiert werden. Bei der Testdurchführung aufgetretene Abweichungen werden z.B. im gedruckten Exemplar einer Testprozedur vermerkt oder als Fall in ein Change-Management-Werkzeug eingespeist. Für einen Abnahmetest durch den Kunden wird im Ausdruck jeder Testprozedur noch Platz für Datum und Unterschrift gelassen.
| Home | Projekt ecwin7 | Anforderungsanalyse | Implementierung | Abnahmetest | |