Testkonzept - Testumgebung

Für alle im Rahmen einer Testdurchführung anstehenden Aktivitäten muss eine Testumgebung bereitgestellt werden, die alle Anforderungen des Testvorhabens abdeckt.

Die Anforderungen und Informationen - die für den Aufbau der benötigten Testumgebungen notwendig sind - müssen von daher zusammengestellt werden.

Für jedes Teilsystem und für jede Teststufe sollte möglichst eine eigene Testumgebung bereitgestellt werden, damit der Test ohne Einflüsse von Entwicklern und Testern anderer Teilsysteme und Teststufen ausgeführt werden kann.

Aufbau einer Testumgebung

Unter einer Testumgebung ist die Gesamtheit aller Hardwarekomponenten und Softwarekomponenten verstehen, die notwendig sind, um Testfälle durchführen zu können. Dazu gehören insbesondere die Testobjekte, die notwendige Testdaten, entsprechende Hardware und Betriebssysteme sowie eine geeignete Test Software.

Für den Aufbau einer Testumgebung müssen alle relevante Anforderungen und Informationen zusammengestellt werden, die notwendig sind. Nicht jedes Teilsystem benötigt jedoch eine vollständige Testumgebung; so müssen z.B. Testumgebungen im Batch Bereichen - im Gegensatz zu Online-Bereichen - oft nur aus einer Datenbasis bestehen.

Die Organisation der Testumgebung ist für jedes Projekt individuell festzulegen.

Folgende Schritte sind im Rahmen der Testumgebungsorganisation durchzuführen:

Zusammentragen der Anforderungen zum Aufbau der Testumgebungen

» Soll innerhalb einer Umgebung parallel getestet werden?

» Kann für jeden Tester eine separate Testumgebung zur Verfügung gestellt werden?

» Wie viele logische Datenbanken werden benötigt?

» Welche Systeme zur Transaktionsbearbeitung werden verwendet?

» Welche Datenbanksysteme werden benutzt?

» Welche Dateitypen werden benötigt?

» Werden Treiber benötigt?

» Werden permanente Systemdateien eingesetzt?

» Werden Hilfsprogramme (z.B. zum Auslesen der Datenbank) benötigt?

» Sollen Capture-/Replay-Tools für Automatisierung des Testablaufs eingesetzt werden?

» Welche Schnittstelle müssen/können innerhalb der Testumgebung aufgebaut werden?

Optimaler Weise wird jedes Teilsystem und für jede Teststufe eine eigene Testumgebung benötigt, damit der Test ohne Einflüsse von Entwicklern und Testern anderer Teilsysteme/Teststufen ausgeführt werden kann.

Zur Entwicklungsumgebung müssen mindestens zwei zusätzliche Testumgebungen eingerichtet werden: Eine für den Funktionstest und sowie eine für den Funktionskettentest, an welchem unter Umständen mehrere Anwendungssysteme beteiligt sind.

Für einen Funktions- und den Funktionskettentest sollten eine bis mehrere Umgebungen zur Verfügung gestellt werden. Der Aufbau dieser Umgebungen richtet sich nach den benötigten technischen Komponenten, die von Anwendungssystem zu Anwendungssystem unterschiedlich sein können.

Optimaler Weise steht jedem Tester eine eigene Testumgebung - in der von ihm für die Ausführung seiner Testobjekte benötigten Ausprägung - zur Verfügung.

Bereitstellen von Testdaten in der Testumgebung

In Rahmen dieser Aktivitäten wird festgelegt, welche Anforderungen aus Sicht des Testvorhabens an die Testdatenorganisation zu stellen sind, sowie welche Möglichkeiten der Testdatenorganisation (Zugriffe, Bereitstellung, Archivierung, Wiederherstellung) im Projekt bestehen.

Anforderung an eine Testumgebung

» Testumgebungsschaubild

» Betroffene Schnittstellen für technische Anbindungen

» Parametrisierung der Schnittstellen, die den Austausch der benötigten Daten ermöglichen

Basierend auf den Vorgaben aus der Testdatendefinition sind für die Testausführung, durch den Fachbereich in Verbindung mit der IT, Testdaten in der Testumgebung bereitzustellen.

Spätestens jetzt muss das für die Testdatendefinition genutzte logische Datenmodell auf das für die Anwendung genutzte physische Datenmodell angepasst werden, damit im optimalen Fall die definierten Testdaten automatisiert in der Testumgebung bereitgestellt werden können.

Ziel der systematischen Organisation und Verwaltung der Testdaten ist:

» Eine eindeutige Orientierung im gesamten Testdatenbestand zu ermöglichen

» Durch Mehrfachverwendung Gesamtaufwand zur Bereitstellung von Testdaten verringern

» Parallele Testausführung von Testobjekten, die gleiche Datenobjekte benutzen

Die Anforderungen für die Festlegung der Konsistenzanforderungen an den Testdatenbestand bzw. an den Umfang an Datenobjekten - in dessen Rahmen die Daten konsistent sein müssen – sind je Teststufe unterschiedlich. Für den Funktionstest ist beispielsweise die Konsistenz über das Testobjekt ausreichend.

Möglichkeiten zur Erzeugung eines Testdatenbestand
» Produktionsabzug
	Steuerungsdaten werden als Gesamtbestand eines oder mehrerer Datenobjekte benötigt und dementsprechend als 1:1 Kopie der Produktionsdaten in der Testumgebung benutzt.
» Teilsynthetischer Ansatz
	Einige wenige konsistente Datensätze werden als Kopierbasis für die Erstellung aller weiteren benötigten Datensätze benutzt. Diese Sätze werden in ein Testdatenverwaltungstool importiert, vervielfältigt und angepasst. Synthetisch ergänzt werden lediglich die spezifischen Felder, die für die Unterscheidung der gewünschten Datenkonstellationen notwendig sind.
» Synthetischer Ansatz
	Ohne eines möglichen Zugriffs auf Produktionsdaten (z.B. Bei Neuentwicklung) wird für das Testobjekt jedes notwendige Feld jedes Datenobjektes synthetisch definiert.

Für die Erzeugung und Verwaltung der Testdatenbestände müssen ggf. Hilfsmittel (z.B. Abfragetools) bereitgestellt werden. Die Verwaltung von Testdatenbeständen kann beispielsweise über sequentielle Sicherungsbestände erfolgen.

Testdatenorganisation

Die generellen Möglichkeiten der Testdatenorganisation werden für das gesamte Testvorhaben festgelegt. Die tatsächliche Ausprägung der Testdatenorganisation wird für jedes Teilsystem und jede Teststufe/ Testart festgelegt. Pro Teststufe/ Testart werden beispielsweise unterschiedliche Anforderungen an die Konsistenz der Daten gestellt.

Generell sind folgende Anforderungen an die Testdatenorganisation zu stellen:
» Selektive Verwaltung und selektiver Zugriff
	Die benötigten Ausgangszustände sind für jedes Testobjekt getrennt zu verwalten. Das kann bedeuten, dass für ein Testobjekt ein bestimmter Teil der Datenbank reserviert ist.
» Wiederholbarkeit der Testausführung
	Vor jeder Testausführung werden für jedes Testobjekt die Datenobjekte in ihren Ausgangszustand gebracht.
» Unabhängigkeit der Testdatenerstellung von der physischen Datenorganisation
	Die Testdaten sollten so abgelegt sein, dass die Testdatendefinition unabhängig von der physischen Datenhaltung und ihren Erfassungsfunktionen möglich ist. Damit kann mit der Testdatendefinition bereits vor der Einrichtung der Umgebung begonnen werden.
» Pflegbarkeit der Testdaten nach Strukturänderungen
	Nach Strukturänderungen sollten die Testdaten mit möglichst geringem Aufwand gepflegt werden können. Hierfür muss der Informationsfluss bei Strukturänderungen für das Projekt festgeschrieben sein und eingehalten werden. Ein solches Vorgehen ist noch zu definieren.

Um den Aufwand für die Erstellung und Pflege der Testdaten möglichst gering zu halten, ist zu klären, welche unterschiedlichen Testdatenbestandstypen es gibt und wie die einzelnen Testdatenbestandstypen organisiert werden sollen.

Folgende Testdatenbestandtypen können generell unterschieden werden:
» Projektübergreifende Steuerungsdaten
	Diese Daten können identisch mit Produktionsdaten sein, da sie nie kundenspezifische Daten enthalten, und werden von der Anwendung benutzt, aber nicht verändert. Die Daten ändern sich i.d.R. während des gesamten Lebenszyklus nicht und werden von der Anwendung nur gelesen.
» Testobjektübergreifende Daten als Kopierbasis für die einzelnen Testobjekte
	Diese Daten stellen einen repräsentativen Umfang an Bestandsdaten dar, die jede Funktionalität der Anwendung als Ausgangszustand benötigt. Ziel ist es, aus der Menge der zur Verfügung stehenden Datensätze geeignete Sätze für die Verwendung in den Testobjekten bereitzustellen.
» Testobjektspezifische Daten (Primär- und Sekundärdaten):
	Primärdaten werden explizit für jedes Testobjekt erstellt, dabei handelt es sich um die Daten, die zu der Verarbeitung führen, d.h. auf Masken oder in Schnittstellen. Der Sekundärdatenbestand (Daten, die benötigt werden, damit die Verarbeitung laufen kann, Bestandsdaten,...) wird für jedes Testobjekt in erster Linie aus der Kopierbasis erstellt. Testobjektspezifische Anforderungen, die nicht vollständig in der Kopierbasis enthalten sind, sind testobjektspezifisch zu erstellen und zu verwalten. Dazu wird als Ausgangsbasis ein möglichst ähnlicher Satz gewählt, der entweder über eine Anwendung (funktionsgetestet!!) oder über ein entsprechendes Testdaten-Tool angepasst wird.

Die parallele Ausführung von Online-Komponenten ist möglich, sofern die Daten so organisiert sind, dass jedem Testfall eindeutig Testdatenkombinationen (Datensätze) zugeordnet sind und diese Testdatenkombinationen eines Testobjektes unabhängig vom Testdatenbestand der übrigen Testobjekte gesichert und geladen werden können.

Die parallele Ausführung von Batch bzw. Batch und Online-Komponenten ist nicht ohne weiteres ohne gegenseitige störende Einflüsse möglich. Eine Lösungsmöglichkeit besteht in der Definition von abgrenzbaren Clustern für jede Komponente, wobei das betreffende Batch-Programm eine ausschließliche Ausführung aus dem entsprechenden Cluster möglich machen muss, um die Testdatenbestände, die für die übrigen Testobjekte benötigt werden, nicht zu verändern.

Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH

Testkonzept - Testumgebung

Aufbau einer Testumgebung

Bereitstellen von Testdaten in der Testumgebung

Testdatenorganisation

H-UB ERFOLGSGESCHICHTE

H-UB EXPERTENWISSEN

H-UB Leistungskatalog

H-UB SOCIAL MEDIA PRÄSENZ