imported>Snookerado: Änderung 224730089 von 2A02:1210:16D2:8900:D0C1:F977:3731:9599 rückgängig gemacht; bitte Wikipedia:Spielwiesenutzen

2022-07-22T18:20:06Z

Änderung 224730089 von 2A02:1210:16D2:8900:D0C1:F977:3731:9599 rückgängig gemacht; bitte Wikipedia:Spielwiesenutzen

Neue Seite

Eine '''Testumgebung''' ({{enS|Test Environment}}) ist die technisch-organisatorische [[IT-Infrastruktur|Infrastruktur]], die zum [[Softwaretest|Testen]] von [[Software]] benutzt wird.

== Allgemeines ==
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 [[Projekt]]e 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 [[Softwaretest#Teststufen|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.).

== Charakteristische Merkmale ==
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 (Informatik)|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 [[Softwaretest#Teststufen|Teststufen]], [[Softwaretest#Klassifikation für Testarten|Testarten]], [[Projekt]]en 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.<ref>Bundesbank ''Testumgebung'' [http://www.bundesbank.de/Navigation/DE/Service/Services_Banken_und_Unternehmen/BBS/Testumgebung/testumgebung.html]</ref>

Insbesondere für Websites und Webanwendungen, die auf [[Client-Server-Architektur]]en basieren, wurden Testumgebungen entwickelt, die von manchen Herstellern als '''Inszenierungsumgebung''' ({{enS|Staging Environment}})<ref>[https://de.ryte.com/wiki/Staging_Environment Staging Environment] im Unternehmenswiki von Ryte (ryte.com)</ref> 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.<ref>[https://msdn.microsoft.com/de-de/library/ms942990%28v=cs.70%29.aspx Beschreibung] von Microsoft</ref><ref>Stefan Selge: {{Webarchiv|url=https://docs.5-anker.com/allgemein/ohne-katastrophen-von-der-idee-zur-umsetzung/ |wayback=20171114202123 |text=''Ohne Bugs von der Idee zur Umsetzung.'' |archiv-bot=2019-05-17 18:55:30 InternetArchiveBot }} 5 Anker GmbH, 18. Januar 2017</ref>

== Bestandteile ==
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 [[Job Control Language|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 [[Softwaretest#Weitere Klassifikationen für Testarten|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 [[#Schwerpunkt Testdaten|Testdaten]].
* Im weiteren Sinn gehören auch die definierten [[Softwaretest#Testspezifikation|Testfälle]] zur Testumgebung.

== Schwerpunkt Testdaten ==
{{Anker|Testdaten}}
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 [[Anonymisierung und Pseudonymisierung|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 [[Regressionstest]]s) müssen die Testdaten ggf. strukturell der neueren Programmversion angepasst werden.

== Einzelnachweise ==
<references />

[[Kategorie:Testen (Software)| ]]

Testumgebung - Versionsgeschichte

imported>Snookerado: Änderung 224730089 von 2A02:1210:16D2:8900:D0C1:F977:3731:9599 rückgängig gemacht; bitte Wikipedia:Spielwiesenutzen