Eine Testumgebung spielt eine entscheidende Rolle beim Software-Testing. Sie bietet eine kontrollierte Umgebung, in der Tests durchgeführt werden können, um die Qualität und Funktionalität einer Software zu überprüfen. Der folgende Beitrag beschreibt, wie sich die zunehmenden CI/CD-Prozesse (Continuous Integration / Continuous Development) auf die Funktionen und Anforderungen der Testumgebung auswirken.

Testumgebung und Testfalldaten

Wir sprechen von einer Testumgebung, wenn sie den gesamten technologischen Umfang für eine oder mehrere Anwendungen enthält, so wie es auch in der Produktion gegeben ist. Bei einer gewöhnlichen Unternehmensanwendung sieht eine Testumgebung dann typischerweise so aus (s. Abb1): Wir haben die Persistenzschicht (persistance layer) als Datenbasis, darüber eine oder mehrere Service- bzw. Anwendungsschichten (service layer) und eine Grafische Benutzeroberfläche (GUI) im Frontend. Die Testumgebung ist also kein komplettes Mock-up, sondern ein Abbild der tatsächlichen Situation bzw. Produktion.

Das Gleiche gilt auch für die Daten. Diese können im produktiven Umfeld je nach Anwendung in verschiedenen Datenbanken und in verschiedenen Formaten gespeichert sein. Es kann z.B. mehrschichtige Anwendungen geben, die auf Daten in verschiedenen Datenbanken zurückgreifen. Gleichzeitig gibt es vielleicht kleine Anwendungen, deren Daten sich in einer einzigen Datenbank befinden.

Wenn wir realistische Testfälle für unsere Testumgebung brauchen, dann müssen die einzelnen Komponenten der Datensätze aus den verschiedenen Speicherorten extrahiert und zusammengeführt werden. Betrachten wir also eine Anwendung, deren Daten in mehreren Tabellen liegen, dann sind diese Tabellen in irgendeiner Weise miteinander verbunden. Die Daten eines Testfalls kann man sich nun als eine oder mehrere Zeilen in mehreren dieser Tabellen vorstellen.

Beispiel: Kfz-Versicherung

Nehmen wir eine Autoversicherung. Abb 2 zeigt die verschiedenen Tabellen und Zeilen, in denen der Datensatz eines spezifischen Versicherungskunden liegt. In den verschiedenen Zeilen links sind z.B. die Details der Autoversicherung abgespeichert. Diese haben wiederum einen Bezug zu den Basisdaten des Versicherungsnehmers (rechts), die wiederum mit dessen detaillierten persönlichen Daten verknüpft sind. Um einen sinnvollen Testdatenfall zu bekommen, müssen alle diese Daten aus den einzelnen Zeilen herangezogen werden, ohne ihre Beziehungen aufzulösen. Die entstandenen Testfalldaten können dann in die Testumgebung transportiert werden.

Es gibt also immer irgendwie Beziehungen zwischen den Daten in der Datenbank Nr. 1 und den Daten in der Datenbank Nr. 2 (s. Abb 1) etc. Ganz egal, welche Kombination vorliegt: Diese Beziehungen müssen in der Testumgebung konsistent über die verschiedenen Datenbanken hinweg bereitgestellt werden.

Nur so können sinnvolle, d.h. realistische Tests durchgeführt werden. Und nur so erhält man bei der Anwendung über die Benutzeroberfläche die richtigen Daten aus den zugrunde liegenden Datenbanken. Diese Zusammenhänge bilden die Anforderungen für alle Testumgebungen.

Statische und dynamische Testumgebungen

Wir können nun zwei Arten von Testumgebungen unterscheiden: eine statische und eine dynamische Testumgebung.

Klassisch weit verbreitet ist die statische Testumgebung. Sie ist ständig verfügbar, hat eine statische URL im Intranet und eine feste Struktur. Alle bisherigen Anwendungsversionen wurden dort i.d.R. inkrementell umgesetzt. Sie dient der linearen Entwicklung der Anwendungen von Version 1 bis Version n. D.h. alle Release-Versionen in der Produktion durchliefen zuvor diese statische Testumgebung.

Neben der statischen gibt es aber auch eine dynamische Testumgebung, die den Bedürfnissen des heutigen CI/CD besser entspricht. Diese kontinuierliche Entwicklung und Implementierung bedeutet eben nicht mehr die komplette Überarbeitung und lineare Fortschreibung einer kompletten Anwendung. Vielmehr werden konstant einzelne Komponenten weiterentwickelt und kontinuierlich live geschaltet.

Und aufgrund dieser Entwicklung gewinnt die dynamische Testumgebung immer mehr an Bedeutung. Sie wird je nach Bedarf im Rahmen eines kontinuierlichen Integrations- und Entwicklungsprozesses ad hoc erzeugt.

Wir wollen beispielsweise ein neues Upgrade von Service 2 (s. Abb. 1) testen. Dazu erzeugen wir eine Umgebung, in der Service 1 und Service 3 in ihrer aktuellen Produktionsversion – also unverändert – gestartet werden. Gleichzeitig starten wir die neue Version von Service 2. Damit haben wir eine dynamische Umgebung geschaffen, in der wir die Integration des neuen Service 2 im Rahmen des aktuellen Produktionsstatus prüfen können.

Diese dynamische Vorgehensweise stellt ganz andere Anforderungen an die Testumgebung wie übrigens auch an die Beschaffung von Testdaten bzw. Testfalldaten. Um einzelne Komponenten in einem solchen Integrationstest in einer dynamischen Testumgebung zu prüfen, braucht es eher feingliedrige und hochgradig konsistente Testfalldaten. Im Gegensatz zu einem groß angelegten Release-Test, der mit Massendaten arbeitet.

Fazit

Statische Testumgebungen finden wir in den meisten Unternehmen. Es gibt eine Produktionsumgebung, eine Art Vorproduktions- oder Release-Testumgebung, eine Integrations-Testumgebung, eine Art Entwicklungs-Umgebung. All das sind statische Umgebungen. Durch die Zunahme von CI/CD-Prozessen kommen nun die dynamischen Testumgebungen hinzu. Diese werden ad hoc geschaffen und bestehen jeweils für eine kurze Zeit, wenn ein Server-Upgrade oder ein neues Anwendungs-Objekt gestartet wird.

Das ist etwas, was viele unserer Kunden gerade aufbauen. Und unsere Testdatenmanagement-Software XDM unterstützt diese Anwendungen und Anforderungen in vollem Umfang.