Testumgebung

Im Allgemeinen sollen Testumgebungen zwei Grundprinzipien erfüllen:

• Die Testumgebung soll von der Produktionsumgebung möglichst weitgehend getrennt sein, damit die zu testende Software keinen Schaden für den produktiven Betrieb anrichten kann. Siehe auch Sandbox.
• Andererseits sollte die Testumgebung der Produktionsumgebung so ähnlich wie möglich sein, damit Probleme im Zusammenhang mit der technischen Ablaufumgebung bereits im Test erkannt (und behoben) werden können.

Vollständiges Erfüllen beider Anforderungen ist aus ökonomischen Gründen in der Praxis eher selten anzutreffen.

Testumgebungen und ihre Organisation können sich, abhängig von der technischen Basis, auf der die entwickelte Software eingesetzt werden soll, und abhängig von anderen Faktoren, erheblich voneinander unterscheiden:

• In großen Organisationen mit mächtiger IT-Infrastruktur und für große Projekte sind das Planen, das Einrichten und der Betrieb von Testumgebungen eine hochkomplexe Aufgabe mit vielen Verantwortlichen und hohem Abstimmungsaufwand.
• Einfache PC-Anwendungen, evtl. mit nur lokaler Einsatzbreite bedürfen dagegen meist keiner größeren oder besonderen Test-Infrastruktur.
• Für Testumgebungen über mehrere technische Plattformen hinweg können häufig produktionsähnliche Strukturen und Schnittstellen nicht oder nur mit großem Aufwand hergestellt werden.
• Für verschiedene Teststufen können unterschiedliche Testumgebungen mit unterschiedlicher Ausstattung erforderlich sein.
• Testumgebungen können exklusiv für ein Projekt oder für mehrere / viele / alle Projekte betrieben werden, nur temporär (für die Projektdauer) oder dauerhaft.

Vom Produktionssystem unabhängige Testumgebungen werden meist mit (im Vergleich zur Produktionsumgebung) geringer dimensionierten Komponenten (Rechner, Speicherkapazität etc.), die damit auch kostengünstiger sind, betrieben. Beispiele: Ein PC statt eines Servers, ein einzelner Server statt eines Server-Clusters, eine Virtualisierungs-Software (z. B. von VMware). Je nach Rechnersystem werden Testumgebungen u. U. nur bedingt unabhängig betrieben, sondern in technisch getrennt verwalteten Systembereichen (Begriffe hierfür: Region, Task, Domäne etc.).

Testumgebungen sind bezüglich ihrer technischen Basis ähnlich wie Systeme im produktiven Einsatz. Trotzdem unterscheidet sich eine TU und ihr Betrieb in vielerlei Hinsicht von der 'IT-Produktion' – was auch als Anforderungen an Testumgebungen gelten kann:

• Programme sind schnell und unkompliziert in die Testumgebung übertragbar.
• In den Tests werden die 'Testobjekte' (zu testende Programme) zusammen mit anderen Komponenten gemischt ausgeführt.
• Die Dimension Zeit wird flexibel behandelt, um Funktionen mit Zeitbezug (ein ganzer Arbeitstag, Monats- oder Jahreswechsel) unabhängig vom realen Zeitverlauf testen zu können.
• Schnittstellen zu anderen (auch externen) Systemen sollten nach Möglichkeit verfügbar sein. Alternativ werden sie ggf. simuliert.
• Das Ausführen von Programmen wird in der Regel nicht vollautomatisch gesteuert (z. B. zu bestimmten Terminen, in streng definierter Ablauffolge), sondern von den Testern individuell aktiviert und kontrolliert.
• Die zu testenden Funktionen werden i. d. R. viele Male hintereinander, jeweils in anderen Konstellationen (gem. Festlegung in den Testfällen) ausgeführt.
• Zur Kontrolle von Testergebnissen müssen diese jeweils nach Test-Ende mit Hilfe besonderer Werkzeuge 'sichtbar' gemacht und konserviert werden.
• Systemeinstellungen, System-Identifikationen (Pfadnamen etc.) und Parameter müssen sowohl wegen technischer Bedingungen als auch zu Testzwecken (mehrere Konstellationen) modifiziert werden (können). Zu Testzwecken sollten andererseits möglichst wenige Anpassungen (gegenüber der späteren Produktivversion) erforderlich sein, weil in diesen Modifikationen neue Fehlerrisiken 'schlummern'.

Besondere Anforderungen müssen beim Betrieb gemeinsamer Testumgebungen für mehrere Projekte beachtet werden:

• Die Zuordnung von Testdaten zu bestimmten Teststufen, Testarten, Projekten etc. muss geregelt sein – um gegenseitiges Verändern von Daten und damit falsche Testergebnisse zu verhindern.
• Die Tests müssen (besonders bei großen Projekten) inhaltlich, in ihrer Ablauffolge und terminlich (nicht selten auf Stundenbasis) geplant und mit den Beteiligten aus dem eigenen oder auch anderen Projekten abgestimmt werden.

Bei überbetrieblich tätigen Unternehmen und Organisationen erfordern Änderungen in der Software häufig besondere Vorkehrungen und Regeln, nach denen Beteiligte koordiniert testen können/müssen. Siehe Beispiel Bundesbank.[1]

Insbesondere für Websites und Webanwendungen, die auf Client-Server-Architekturen basieren, wurden Testumgebungen entwickelt, die von manchen Herstellern als Inszenierungsumgebung (englisch Staging Environment)[2] bezeichnet werden. Während der zugehörige Datenbankserver mit Testdaten gefüllt wird, die nach bestimmten Kriterien als Stichprobe aus den Produktivdaten gefiltert werden, basiert der eigentliche Testserver auf einer Spiegeltechnik, die Tests an Veränderungen analog zur produktiven Version unter verschiedenen Arbeitsumgebungen ermöglicht und anschließend die automatische Migration der Produktivumgebung ermöglicht.[3][4]

Eine Testumgebung besteht im Allgemeinen aus folgenden Komponenten:

• Die zum Testen erforderliche Hardware und das Betriebssystem (mit allen zum Test erforderlichen Komponenten) bilden die technische Grundlage der Testumgebung.
• Die administrative Infrastruktur muss testspezifisch vorhanden und installiert sein. Beispiele: Testbibliotheken, Ablaufsteuerungskomponenten (wie JCL), Testdatenbanken, Testmandanten, Testuser, Zugriffs- und Rechtekonzepte, Test-Zeitscheiben etc.
• Die zu testenden Programme (neue oder in Wartungsprojekten geänderte Versionen) müssen in der Testumgebung verfügbar sein.
• Zur Durchführung der Tests erforderliche andere Anwendungen/Programme müssen ebenfalls verfügbar sein. Beispiele: Zentrale Unterprogramme, nicht geänderte Programme (in Wartungstests), Anwendungen zur Anzeige von Ergebnisdaten, Anwendungen zur Weiterverarbeitung von Testergebnissen; sie sind keine Testobjekte, sondern Hilfsmittel.
• Zur Vorbereitung, Durchführung und Kontrolle von Tests sind Testwerkzeuge erforderlich, z. B. zur Testfall-Dokumentation, zur Testdatenmanipulation, zur Testautomatisierung und -Überwachung (Debugger), für automatische Datenvergleiche etc.
• Wesentlicher Teil der Testumgebung sind die für die Tests erforderlichen und inhaltlich auf sie abgestimmten Testdaten.
• Im weiteren Sinn gehören auch die definierten Testfälle zur Testumgebung.

Einen besonderen Schwerpunkt für Testumgebungen und das Testen allgemein bilden die Testdaten. Hierbei ist zu unterscheiden zwischen Eingabedaten für Tests (in den über die Testfälle beschriebenen Varianten) und Daten, auf die im Test 'nur' zugegriffen wird; beide Arten müssen zusammenpassen. Hinzu kommen die beim Testen erzeugten Daten – als zu prüfende Testergebnisse, die evtl. mit Soll-Ergebnis-Daten verglichen werden können.

Für Testdaten und die dazu erforderlichen Bereitstellungsprozesse (Testdatenmanagement) sind die nachfolgend genannten Sachverhalte von besonderer Bedeutung:

• Testdaten und Testfälle sollten exakt aufeinander abgestimmt und so definiert sein, dass unbeabsichtigtes Verändern (z. B. in anderen Testfällen) vermieden wird. Nützlich ist die Dokumentation der Zusammengehörigkeit von Testfällen und Testdaten: Welche Testdaten werden für Testfall X verwendet – und umgekehrt?
• Testdaten müssen – neben den lt. den Testfallspezifikationen erforderlichen Ausprägungen/Konstellationen – auch untereinander datenlogisch konsistent sein. Beispiel: Bestelldaten passen zu Kunden- und zu Artikeldaten.
• Diese Konsistenz ist bei Testumgebungen über mehrere technische Plattformen hinweg auch plattformübergreifend nötig.
• Das Testdatenvolumen sollte im Interesse optimalen Testaufwands und effizienter Testkontrollen so klein wie möglich und nur so groß wie nötig sein.
• Durch Verwendung produktiver Daten als Testdaten können praxisnahe Datenkombinationen erreicht werden. Allein die Verwendung solcher Daten (bei denen die Testkonstellationen vom Zufall abhängig sind) erlaubt jedoch keine Qualitätsaussagen (Vollständigkeit) zu den Tests und bedeutet i. d. R. hohen Aufwand zur Ergebniskontrolle. Häufig müssen diese Daten i. d. R. zum Testen anonymisiert werden.
• Für Testwiederholungen sollten Testdaten global oder individuell auf alte Stände zurückgesetzt werden können. Dies ist insbesondere nach sog. „Alterungen“ oder „Zeitreisen“ erforderlich, bei denen z. B. ein Jahreswechsel (mehrfach) getestet werden muss.
• Für Performancetests werden ggf. Vollbestände verarbeitet, evtl. in der Produktionsumgebung.
• Im Fall von Datenstrukturänderungen (z. B. bei Verwendung von Testdaten in Regressionstests) müssen die Testdaten ggf. strukturell der neueren Programmversion angepasst werden.

1. Bundesbank Testumgebung
2. Staging Environment im Unternehmenswiki von Ryte (ryte.com)
3. Beschreibung von Microsoft
4. Stefan Selge: Ohne Bugs von der Idee zur Umsetzung. (Memento des Originals vom 14. November 2017 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/docs.5-anker.com 5 Anker GmbH, 18. Januar 2017