Steigern Sie die Softwarequalität & sparen Sie Zeit mit Infrastrukturtests

Die banalsten Dinge – Zugangscodes oder Smartcards, die Zutritt zu Gebäuden ermöglichen – können kritisch werden, wenn sie nicht vorhanden sind.

Infrastruktur existiert in all ihrer Vielfalt, um die Entwicklung, das Testen, die Bereitstellung und den Betrieb Ihrer Systeme zu unterstützen. Sie ist entweder kritisch für das Testen oder muss selbst getestet werden.

Im nächsten Artikel schauen wir uns Werkzeuge für Entwicklung, Test und Zusammenarbeit an. In diesem Artikel betrachten wir das, was die meisten als Testumgebungen verstehen, und werfen einen kurzen Blick auf das sogenannte Infrastruktur-Testing. Ich werde Folgendes behandeln:

• Testumgebungen
• Entwicklungsumgebungen
• System-Testumgebungen
• Datenumgebungen
• Infrastruktur-Testing

Los geht's.

Testumgebungen

Alle Tests beruhen auf einer impliziten, entscheidenden und vereinfachenden Annahme: dass unsere Tests in einer bekannten Umgebung ausgeführt werden.

Was ist eine Umgebung?

Alle Systeme müssen im Kontext getestet werden. Damit ein Test aussagekräftig ist, muss das System in einer realistischen Umgebung installiert, eingerichtet, bereitgestellt oder gebaut sein, die die reale Welt, in der es genutzt wird, simuliert. 

Wir könnten Test-Szenarien verwenden, die die Fähigkeiten des Systems hinsichtlich Funktionalität, Performance oder Sicherheit herausfordern – das sind jedoch Eigenschaften der Tests, nicht der Umgebung.

Eine realistische Umgebung würde sämtliche geschäftlichen, technischen und organisatorischen Rahmenbedingungen nachbilden. Vieles davon besteht aus Daten, die zur Steuerung der Geschäftsprozesse, zur Konfiguration des Systems und als Referenzdaten dienen.

Aber vollkommen realistische Umgebungen sind meist nicht praktikabel oder viel zu teuer (selbst Tester von hochkritischen Systemen wie Flugzeugen, Kernreaktoren oder Hirnscannern müssen irgendwann Kompromisse machen). Fast alle Tests finden in Umgebungen statt, die die reale Welt mit einem akzeptablen Kompromiss simulieren.

Autos werden auf Rollenprüfständen, in Windkanälen, auf Vibrationsbänken und privaten Teststrecken getestet, bevor sie auf der Straße erprobt werden. Computersysteme werden von Programmierern und Softwaretestern im Labor getestet, bevor Endanwender sie in einer produktionsähnlichen Umgebung ausprobieren.

Um sicherzustellen, dass Ihre Testumgebungen den Branchenstandards entsprechen, sollten Sie die Integration einer dieser Top-Testmanagement-Plattformen in Erwägung ziehen.

JOIN THE COMMUNITY

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Sign up with LinkedIn

Or sign up with email:

Email

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Testen in realistischen Umgebungen

Simulierte Umgebungen sind fehlbar – wie unsere Anforderungen und Testmodelle auch –, aber wir müssen damit leben.

Wir müssen Tests so gestalten, dass sie in den vorhandenen Umgebungen aussagekräftig sind – und die Testergebnisse bedeuten das, was wir daraus lesen.

Die Zuverlässigkeit der Testergebnisse hängt von der Umgebung ab, in der die Tests durchgeführt werden. Wenn ein Test in einer Umgebung läuft, die falsch konfiguriert ist:

• Ein Test, der fehlschlägt, kann darauf hindeuten, dass das System fehlerhaft ist, obwohl es in Wirklichkeit korrekt ist.
• Ein Test, der besteht, kann darauf hindeuten, dass das System korrekt ist, obwohl es tatsächlich fehlerhaft ist.

Beide Situationen sind natürlich höchst unerwünscht.

Umgebungen rechtzeitig einrichten und bereitstellen

Selbst mit dem Aufkommen von Cloud-Infrastruktur können Testumgebungen schwierig und teuer einzurichten und zu warten sein.

Wenn Support-Teams an der neuen Produktionsumgebung arbeiten, fordern die Tester Testumgebungen (und vielleicht mehrere davon). Später während der Tests treten häufig konkurrierende Anforderungen an die Support-Teams auf.

Entwicklungsumgebungen oder spätere Testaktivitäten werden möglicherweise zu spät oder gar nicht bereitgestellt, oder sie sind nicht wie erforderlich konfiguriert oder gesteuert. Unweigerlich verzögert dies die Tests und/oder untergräbt das Vertrauen in jegliche Testergebnisse.

Eine kritische Aufgabe ist es, den Bedarf und die Anforderungen an eine für Tests zu nutzende Umgebung so früh wie möglich festzulegen – inklusive eines Mechanismus zur Verwaltung von Änderungen an dieser Umgebung.

Infrastructure as Code ist eine neuere Entwicklung, mit der Umgebungen mithilfe von Tools und deklarativem Code nach festgelegten Verfahren aufgebaut werden können. 

Zwar können Basis-Betriebssystemplattformen (Server) in der Cloud oder als virtuelle Maschinen in der eigenen Umgebung leicht erstellt werden, aber vollständig spezifizierte, zweckgebundene Server mit aller notwendiger Software, Daten, Konfiguration und Schnittstellen erfordern mehr Aufwand.

Beim Aufbau Ihrer Testinfrastruktur ist es entscheidend, zuverlässige Datenbankmanagement-Software zu integrieren, um eine optimale Leistung zu gewährleisten

Sind diese jedoch einmal eingerichtet, ermöglichen sie eine hocheffiziente Erstellung von Umgebungen. Infrastruktur-Code kann wie jeder andere Anwendungscode versioniert und durch Änderungsmanagement gesteuert werden.

Ein zentrales Prinzip von Continuous Delivery ist, dass so früh wie möglich erste Software – auch wenn sie noch keinen Nutzen hat – durch die Bereitstellungspipeline geschoben werden sollte, um die Funktionsfähigkeit der Abläufe nachzuweisen. 

Dazu werden natürlich funktionierende Umgebungen für Build-Prozesse, Continuous-Integration-Werkzeuge, systemweite Tests und Deployments benötigt. Das Ziel ist es, Test- und Produktionsumgebungen uneingeschränkt bereitstellen zu können. Sobald die Umgebungsdefinitionen und Bereitstellungsprozesse festgelegt sind, wird das Erzeugen von Umgebungen automatisiert und zu einer Routineaufgabe.

Unter allen Umständen sind diese Umgebungsdefinitionen ein frühes Arbeitsergebnis des Projekts.

Entwicklungsumgebungen

Das Testen durch Entwickler konzentriert sich auf den Aufbau von Softwarekomponenten, die intern oder an der Benutzeroberfläche Funktionalitäten für die Anwendung bereitstellen. 

Solche Tests basieren meist auf dem Wissen über die innere Struktur des Codes und können darauf verzichten, mit ‘realistischen’ Daten zu arbeiten. Tests von Komponenten oder Diensten auf niedriger Ebene werden in der Regel über eine API mithilfe eigens erstellter oder proprietärer Treiber oder Tools ausgeführt.

Das Angebot an Entwicklungstools, Plattformen und sogenannten integrierten Entwicklungsumgebungen (IDEs) ist enorm. In diesem Artikel können wir nur einige der wichtigsten testrelevanten Anforderungen und Funktionen von Umgebungen anreißen.

Um die Entwicklung und die für Entwickler relevanten Tests zu unterstützen, müssen Umgebungen folgende Aktivitäten ermöglichen. Dies ist nur eine Auswahl – je nach Situation können weitere oder leicht abweichende Aktivitäten erforderlich sein:

• Eine „Sandbox“-Umgebung zum Experimentieren mit neuer Software. Sandboxes werden oft genutzt, um neue Bibliotheken zu testen, Wegwerf-Prototypen zu entwickeln oder Programmiertechniken zu üben. Alle gängigen Programmiersprachen verfügen über Hunderte oder Tausende von Softwarebibliotheken. Sandboxes werden auch verwendet, um Software zu installieren und auszuprobieren, die nicht Teil der Hauptentwicklung ist, um sie zu bewerten und praktisch kennenzulernen. Diese Umgebungen werden meist als Wegwerf-Umgebungen betrachtet.
• Lokale Entwicklungsumgebung. Hier pflegen Entwickler eine lokale Kopie eines Teils oder des gesamten Quellcodes ihrer Anwendung aus einem gemeinsamen Code-Repository und können Systembuilds zum lokalen Test erzeugen. In dieser Umgebung können Entwickler Änderungen vornehmen und ihre Änderungen testen. Manche Tests sind Ad-hoc-Tests und werden nie wiederholt. Andere Tests sind automatisiert. Automatisierte Tests werden in der Regel dauerhaft beibehalten – besonders, wenn sie einem Testgetriebenen Ansatz folgen.
• Geteilte (Continuous-)Integration-Umgebung. Sobald Entwickler sicher sind, dass ihr Code bereit ist, werden ihre Änderungen in das gemeinsame, kontrollierte Code-Repository übertragen. Die CI-Umgebung führt automatisierte Builds und Tests mithilfe des Repositories aus. An diesem Punkt wird der neue oder geänderte Code integriert und getestet. Das CI-System führt automatische Tests auf Anforderung, stündlich oder täglich durch, und das gesamte Team wird informiert und kann den Status der Tests der letzten Integration einsehen. Fehler werden umgehend sichtbar und umgehend behoben.

Eine Entwicklungs- oder CI-Umgebung unterstützt das Entwicklertesten, aber andere Anwendungsserver, Webdienste, Messaging- oder Datenbankserver, die das System komplettieren, stehen möglicherweise nicht zur Verfügung. 

Wenn diese Schnittstellensysteme nicht existieren, weil sie noch nicht gebaut wurden oder weil sie einem Partnerunternehmen gehören und es nur ein Live-System, aber keine Testversion gibt, müssen Entwickler diese Schnittstellen stubben oder mocken, um zumindest ihren eigenen Code testen zu können. 

Mocking-Tools können ausgeklügelt sein, aber gemockte Schnittstellen unterstützen in der Regel keine Tests, die integrierte Daten über mehrere Systeme hinweg erfordern.

Wenn Entwicklern eine Schnittstelle zu einem Testdatenbankserver zur Verfügung steht, sind deren Testdaten möglicherweise minimal, nicht integriert oder konsistent und nicht repräsentativ für die Produktivdaten.

Entwicklungsdatenbanken, die von einem Team gemeinsam genutzt werden, sind in der Regel unbefriedigend. Fehlt ein gutes Verfahren zur Verwaltung dieser gemeinsamen Ressource, könnten Entwickler gegenseitig ihre Daten wiederverwenden, zerstören oder löschen.

System-Level-Testumgebungen

Das System-Level-Testing konzentriert sich auf die Integration von Komponenten und Subsystemen in Zusammenarbeit. 

Diese Umgebungen bieten eine Plattform zur Unterstützung der Ziele groß angelegter Integration, Validierung der Funktionalität und Systembetrieb im Kontext von Benutzer- oder Geschäftsprozessen.

Umgebungen können auch für die Prüfung nicht-funktionaler Aspekte des Systems reserviert sein, wie zum Beispiel Performance, Sicherheit oder Service-Management.

Einer der häufigsten Testfehler ist, wenn ein Systemtester in seiner Umgebung auf einen Fehler stößt, den der Entwickler oder Tester in der Entwicklungsumgebung – ganz gleich wie sehr sie sich bemühen – nicht reproduzieren kann.

Dies wird fast immer durch fehlende Übereinstimmung der beiden Umgebungen verursacht. Die Unterschiede im Verhalten können durch Konfiguration, Softwareversionsunterschiede oder Unterschiede in den Datenbanken entstehen.

Unterschiede in den Daten, die zu Problemen führen, sollten als Erstes überprüft werden. Sie sind meist leicht zu erkennen und lassen sich oft zügig beheben.

Handelt es sich um einen Versions- oder Konfigurationsunterschied der Software, können Tester und Entwickler sehr viel Zeit darauf verschwenden, die Ursache für das abweichende Verhalten zu finden.

Treten diese Probleme auf, deutet das oft auf eine mangelnde Kommunikation zwischen Entwickler und Test hin. Es kann auch auf ein mangelndes Konfigurationsmanagement bei der Einrichtung der Entwickler- oder Testumgebungen oder des Bereitstellungsprozesses hinweisen.

Infrastructure as Code und die automatisierte Bereitstellung von Umgebungen werden Konsistenzprobleme künftig der Vergangenheit angehören lassen.

Arten dedizierter Testumgebungen

Um System-, Abnahme- und nicht-funktionale Tests zu unterstützen, müssen die Umgebungen folgende Aktivitäten ermöglichen (je nach Organisation können es noch weitere sein):

• (Funktionale) Systemtestumgebung. In dieser Umgebung wird das System gegen die dokumentierten Anforderungen für das Gesamtsystem validiert. Anforderungen können umfangreiche Textdokumente mit tabellarisch definierten Testfällen für einen Systemtest sein. In agilen Projekten kann diese Umgebung erforderlich sein, damit Tester das integrierte System erkunden können, ohne sich auf bestimmte Funktionen zu beschränken.
• End-to-End-Test-Umgebung. Während in der CI-Umgebung Komponenten mit Subsystemen integriert werden können, erfordern Geschäftsprozesse möglicherweise andere Schnittstellensysteme (die nicht unter der Kontrolle der Entwickler stehen). Für groß angelegte Integrations-, Geschäftsprozess- oder Akzeptanztests sind vollständige Umgebungen notwendig. In der Regel handelt es sich bei den Daten um eine Kopie der Live-Daten oder um Daten mit angemessenem Umfang. Wenn groß angelegte Integration nachgewiesen werden muss, werden die Daten- und Steuerungsflüsse mit längeren Benutzerwegen und unabhängigen Abgleichen der Daten über integrierte Systeme hinweg überprüft. Das Management von Testdaten in Testumgebungen ist entscheidend. Wenn Sie bereits Jira verwenden, sollten Sie Ihre Datenmanagement-Fähigkeiten mit fortschrittlichen Testmanagement-Tools für Jira erweitern.
• Performance-Umgebung. Diese Umgebungen müssen eine aussagekräftige Plattform zur Bewertung der Performance eines Systems (oder ausgewählter Subsysteme) bieten. Kompromisse in der Architektur sind möglich, wenn Redundanz oder Serverklone vorhanden sind. Allerdings müssen die Datenmengen auf Produktionsniveau sein, auch wenn es sich um synthetische Daten handelt. Die Umgebung muss jedenfalls groß genug sein, um Produktions-Transaktionsvolumen zu unterstützen und eine sinnvolle Vorhersage der System-Performance im Produktivbetrieb zu ermöglichen.
• Verfügbarkeits-, Resilienz- und Verwaltungsumgebungen (ARM). In mancher Hinsicht ähneln diese Umgebungen Performance-Umgebungen, aber je nach Testziel sind Abweichungen unvermeidlich. Verfügbarkeitstests sollen nachweisen, dass das System über längere Zeiträume ohne Ausfall funktioniert. Resilienztests (oft auch Failover-Tests genannt) prüfen, dass der Ausfall von Systemkomponenten nicht zu einer unakzeptablen Störung des bereitgestellten Dienstes führt. Verwaltungs- oder Betriebstests verfolgen das Ziel, zu demonstrieren, dass administrative, Management- sowie Backup- und Wiederherstellungsprozeduren des Systems effektiv funktionieren.

Daten in Umgebungen

In sehr großen Projekten kann es bis zu 20 oder sogar 30 groß angelegte Umgebungen geben, die verschiedenen Aspekten wie Tests, Schulungen, Datenmigration und Probeumstellungen dienen. In kleineren Projekten gibt es weniger Umgebungen, vielleicht nur eine gemeinsame Umgebung oder ein Continuous-Delivery-Regime – und sämtliche Tests könnten automatisch in kurzzeitig erzeugten und danach wieder entfernten Umgebungen ablaufen.

Alle Umgebungen benötigen Daten, aber Umfang und Realitätsgrad dieser Daten können variieren. Im Folgenden sind einige gängige Muster für die Beschaffung und Verwaltung von Testdaten aufgeführt. Diese Muster fokussieren auf Besitzverhältnisse (lokal oder geteilt), Art der Erstellung (manuell, automatisiert oder aus Produktion kopiert) und Umfang:

• Lokale, manuell erstellte, kleinvolumige Daten – geeignet für Ad-hoc-Tests durch Entwickler oder Tester.
• Lokale, automatisiert erstellte, synthetische Daten. Geeignet für automatisierte Entwicklertests oder Umgebungen, in denen die Funktionalität spezifischer Module oder Features abgedeckt werden kann.
• Geteilte, manuell erstellte Daten. Eingesetzt in Integrations- und Systemtestumgebungen, oft dort, wo sich Testdaten parallel zu manuellen Tests entwickeln. Sie werden bei Bedarf gesichert und wiederhergestellt.
• Geteilte, automatisiert erzeugte Daten. Eingesetzt in Integrations- und Systemtestumgebungen, in denen sich Testdaten parallel zu automatisierten oder manuellen Tests weiterentwickeln. Sie werden bei Bedarf erzeugt und/oder aus Backups wiederhergestellt.
• Geteilte, großvolumige synthetische/zufällige Daten. Performance- und ARM-Tests erfordern konsistente Daten in großem Umfang. Diese Daten müssen in der Regel nicht inhaltlich sinnvoll sein – randomisierte Daten sind ausreichend und werden bei Bedarf erzeugt oder initial generiert und dann aus Backups wiederhergestellt.
• Geteilte, großvolumige, sinnvolle Daten. End-to-End-Tests, Abnahme- oder Benutzertests benötigen üblicherweise große Mengen sinnvoller Daten. Manchmal werden Kopien oder Auszüge aus Echtdaten verwendet. Achten Sie jedoch darauf, keine Datenschutzvorschriften zu verletzen, wenn Sie die Daten nicht maskieren oder anonymisieren.
• Für Wiederholungs- und Regressionstests wird ein bekannter, kontrollierter Datenbestand in einem definierten Zustand benötigt, daher wird dieser meist aus Backups wiederhergestellt. Dies gilt für jede der oben genannten Umgebungen, da diese Tests mit Daten in einem bekannten Zustand wiederholt werden müssen, um Fehler zuverlässig zu reproduzieren.

Infrastruktur-Testing

Zu Beginn dieses Artikels haben wir betrachtet, was zur Infrastruktur gehört. Seitdem lag unser Hauptfokus auf den technischen Komponenten, also den Softwaresystemen, wobei wir annehmen, dass die Hardware – real oder virtuell – zur Verfügung steht.

Wenn wir Systeme initial aufbauen, gehen wir davon aus, dass die Infrastruktur existiert und korrekt funktioniert, leistungsfähig, sicher und widerstandsfähig ist, usw.

All diese Aspekte können wir testen, sobald wir unsere Anwendung integriert haben, und zweifellos werden wir dabei Schwachstellen in der Infrastruktur aufdecken – allerdings in einem im Projektverlauf relativ späten Stadium. Dabei ist das Auftreten von Infrastrukturproblemen zu einem derart späten Zeitpunkt meist äußerst störend.

• Änderungen zur Behebung von Fehlern in der Infrastruktur können eine erhebliche Neugestaltung und Änderungen an unserer Anwendung erfordern.
• Ergebnisse aus Tests unserer Anwendung oder des Gesamtsystems müssen wiederholt werden.
• Wenn Komponenten von Drittanbietern wie Datenbank-, Web-, Netzwerk- oder Messaging-Dienste ausfallen, sind wir auf die Lieferanten (oder die Open-Source-Community) angewiesen, die diese unterstützen.

Um sicherzustellen, dass unser Vertrauen in Infrastrukturkomponenten gut begründet ist, können wir uns auf unsere (oder die von anderen) Erfahrung mit ihrer bisherigen Nutzung verlassen. Alternativ müssen wir—durch Tests—ihre Zuverlässigkeit bewerten, bevor wir uns für den Einsatz im Design und Bau unseres Systems entscheiden.

Abhängig von der zu untersuchenden Infrastruktur kann die von uns genutzte Umgebung variieren—von einem einzelnen Server bis hin zu einer nahezu vollständigen Infrastrukturplattform. 

Obwohl einige Tests manuell durchgeführt werden, nutzen wir meist Tools, Treiber oder Roboter, um die Transaktionslast zu simulieren, die unsere Anwendung erzeugen würde. Diese Schnittstellen müssten wir mocken oder als Platzhalter einbauen:

• Schnittstellen, die derzeit nicht verfügbar sind
• Schnittstellen zu Komponenten, denen wir vertrauen und die einfach zu simulieren sind
• Schnittstellen, die nicht im Geltungsbereich liegen und die die getestete Infrastruktur nicht beeinflussen.

Infrastruktur, selbstverständlich, arbeitet in der Regel nicht über eine Benutzer- oder GUI-Schnittstelle.

Die Anbindung unserer Anwendung an die Infrastruktur erfolgt meist über Messaging oder entfernte Serviceaufrufe. Häufig muss der zu simulierende Datenverkehr API-Aufrufe an Web- oder Anwendungsserver, Nachrichten- oder Datenbankserver oder über die Cloud bzw. entfernte Standorte erbrachte Dienste beinhalten.

Performance- und ARM-Ziele können bekannt sein, in diesem Fall können Tests durchgeführt werden, um sicherzustellen, dass diese Ziele erreicht werden.

Allerdings wird Infrastruktur oft gemeinsam mit anderen Anwendungen als unserer genutzt, daher hilft das Wissen um die maximale Kapazität einzuschätzen, wie viel Kapazität bleibt, wenn unsere Anwendung bereitgestellt wird.

In diesem Fall adressiert das Infrastruktur-Testing das Risiko für unsere eigene und vielleicht auch für andere künftige Anwendungen, die darauf aufbauen werden. 

Melde dich für den The QA Lead Newsletter an, um benachrichtigt zu werden, wenn neue Teile der Serie erscheinen. Diese Beiträge sind Auszüge aus Pauls Leadership In Test Kurs, den wir wärmstens empfehlen, um tiefer in dieses und andere Themen einzutauchen. Wenn du mitmachst, nutze unseren exklusiven Gutscheincode QALEADOFFER, um $60 Rabatt auf den regulären Kurspreis zu erhalten!

Empfohlene Lektüre: 10 BESTE OPEN-SOURCE TESTMANAGEMENT-TOOLS