Aktivität 
Qualitätssicherung, Test, Abnahmen
| A-256 Testkonzept erstellen
| |
Das Testkonzept wird initial erstellt. Es bildet den Rahmen für alle weiteren Testaktivitäten.
Aktivität muss durchgeführt werden in Entwurf-/Architekturphase (Startphase) (Iterative Aktivität)
Der für das Projekt verantwortliche Qualitätsmanager erstellt ein Testkonzeptes für das anstehende Projekt. Es bildet die Basis zur Abschätzung von Aufwänden durch QS-Aktivitäten und definiert die notwendigen Prozesse in der Entwicklung und der QS.
Im Testkonzept werden die Fragen beantwortet,
- wer
- was
- wann
- mit welchem Ziel
- wie und
- wo
zu testen hat.
Konzept
Das konkrete Testkonzept zerfällt in zwei Teile:
- Systemtest und
- Entwicklertest.
Mögliche Tests sind:
- White- und Grey-Box-Tests durch die Entwicklung
- Unit-Test einer einzelnen Klasse
- Kettentest einer Klasse und ihrer direkten Umgebung
- Modultest einer kohärenten Gruppe von Klassen
- Black-Box-Tests durch die QS und den Anwender
- Integrationstest eines (Teil-)Systems und seiner Module
- Systemtest
Wenn möglich, sollte Test getrieben vorgegangen werden, da so die nachfolgende Wartung optimal unterstützt werden kann.
Systemtest bzw. Subsystemtest oder Freigabetest (Black-Box-Tests)
Wurde in der Vorbereitungsphase bereits ein grobes Testkonzept entworfen, kann dies weiter detailliert bzw. weiter entwickelt werden (s. dazu auch Testkonzept entwerfen).
Es ist zu bestimmen, wer mit welchen Grundlagen Testfälle schreibt. Basis für die Testfall-Erzeugung sind die Anwendungsfälle aus der Analyse -und davon sind insbesondere ihre formalen Ablaufbeschreibungen zu verwenden. Dort sollten alle fachlichen Ausnahmen beschrieben sein.
Daneben sind auch
- das Testumfeld bzw. Testlabor sowie die Vorbereitung der (Sub-)Systemtests,
- die Testziele bzgl. der zu erreichenden Testabdeckungen,
- die Testende-Kriterien,
- die einzusetzenden Testmethoden wie z.B.
- Extrem- und Grenzwertbestimmung,
- Äquivalenzklassenbestimmung oder
- Ursache-Wirkungs-Graphen und
- die Testmannschaft festzulegen.
Neben den fachlichen Anforderungen, also der Funktionalität, sind auch noch die Abläufe aus der Installation, Konfigration und Administration zu testen sowie technische Aspekte wie z.B.:
- Benutzer-Zugriffsrechte oder
- Performance und Lastverhalten.
Entwicklertest bzw. Unit-Test oder Modultest (White-Box-Tests)
Die Testumgebung ist mehr als nur ein Automatisierungstool. Es gilt, eine große Anzahl von Testfällen zu verwalten und ggf. eigene Konzepte zur Testdatenverwaltung umzusetzen.
Die Entwickler testen ihre Klassen bzw. deren Methoden selber. Dazu ist ein Testautomatisierungstool wie z.B. JUnit zu verwenden und in die Entwicklungsumgebung einzubinden. Sinnvollerweise gehen die Entwickler testgetrieben vor, d.h., sie programmieren erst die Methodentests, bevor die Methode erstellt bzw. weiterentwickelt wird.
Im Testkonzept ist zu spezifizieren,
- wie und mit welchen Mitteln die Entwicklung ihre Klassen testet (Testumgebung) und
- wie die Entwicklungsresultate zum Systemtest weitergegeben werden.
Wie beim Systemtest sind auch für die Entwicklung die Testmethoden festzulegen, die für die Anwendung sinnvoll erscheinen und die kombinatorische Problematik vieler Tests auf ein handhabbares Maß reduzieren, wie z.B.
- Extrem- und Grenzwertbestimmung,
- vereinfachte Pfadüberdeckung bei Schleifen oder
- Termüberdeckung für den Test von Bedingungen.
Daneben sind die Überdeckungskriterien und der Grad ihrer Erfüllung festzulegen. Mögliche Überdeckungen wären:
- Zweigüberdeckung des zu testenden Codes der Testfälle
- Klassenüberdeckung der Testfälle
- Methodenüberdeckung der Testfälle
- Ausnahmenüberdeckung (Eceptions) der Testfälle
Die Entwicklertest-Erstellung erfolgt folgendermaßen:
- Bestimme, welche Operationen in der Komponentenschnittstelle von welcher Klasse zu verantworten sind.
- Definiere Vor- und Nachbedingungen der Operationen sowie notwendige Invarianten der Klassen.
- Entwickle automatisierbare Tests für alle Operationen.
Aus den programmierten Ablauftests haben sich bereits einige Operationen ergeben. Bei der weiteren Detaillierung und Implementierung dieser Operationen ergeben sich wiederum neue Operationen und der Bedarf, die vorhandenen gegebenenfalls umzustrukturieren.
Hilfreiche Fragen beim Identifizieren der Operationen:
- Welche Serviceleistungen werden vom Objekt erwartet (z.B. Setzen einer Standardanschrift)?
- Welche Zustandsübergänge kommen für das Objekt in Frage?
- Wann beginnt der Lebenszyklus eines Objektes, wann endet er?
- Für welche Beziehungen zu anderen Objekten sindHinzufügungs- und Entfernungsoperationen notwendig (z.B. Vertrag anfügen)?
- Welche Auskünfte muss das Objekt erteilen können?
- Welche Dateninhalte sind änderbar? Datenänderungen geschehen über
Operationen, die dann u.a. auch die formale und inhaltliche Prüfung der Datenänderung übernehmen können.
Beim Ermitteln der Operationen kommt es immer wieder zu neuen Einsichten und zu einem neuen Verständnis der Beziehungen zwischen den Klassen. Assoziationen, Aggregationen und Vererbungshierarchie werden als Folge davon gegebenenfalls angepasst.
Zu der Spezifikation einer Operation gehören:
- Signatur
Beschreibt den Namen, die Argumente und den Rückgabetyp der Operation.
- Vorbedingung
Beschreibt den Objektzustand, der vor der Ausführung der Operation gegeben sein muss.
- Nachbedingung
Beschreibt den Objektzustand, der nach der Ausführung der Operation gegeben ist.
- Invariante
Beschreibt den Objektzustand, der während der Ausführung der Operation sowie ganz allgemein gegeben sein muss. Hierzu gehören unter anderem auch Typprüfungen und spezielle Werteprüfungen für die Operationsparameter.
- Semantik
Beschreibt kommentierend die Aufgabe und Bedeutung der Operation.
OEP - Object Engineering Process, v3.0, 06.11.2006 11:04:50, Copyright © 2006 by oose Innovative Informatik GmbH