Softwarequalität steigern & Zeit sparen mit Infrastrukturtests
Anmerkung der Redaktion: Willkommen bei der Serie „Führung im Test“ des Experten und Beraters für Softwaretests Paul Gerrard. Die Serie soll Testern mit einigen Jahren Erfahrung – insbesondere solchen in agilen Teams – dabei helfen, ihre Aufgaben als Testleiter und im Testmanagement erfolgreich zu meistern.
In einem früheren Artikel habe ich dich durch die Vorgehensweise beim Management von Leistungstests geführt. Jetzt besprechen wir IT-Infrastruktursoftware, Testinfrastruktur und Testumgebungen.
Melde dich für den Newsletter von The QA Lead an, um benachrichtigt zu werden, wenn neue Teile der Serie veröffentlicht werden. Diese Beiträge sind Auszüge aus Pauls Kurs „Führung im Test“, den wir dringend empfehlen, um tiefer in dieses und andere Themen einzusteigen. Wenn du das tust, verwende unseren exklusiven Gutscheincode QALEADOFFER und spare 60 $ vom vollständigen Kurspreis!
Infrastruktur ist der Begriff, mit dem wir sämtliche Hardware, Cloud-Dienste, Netzwerke, unterstützende Software und unsere zu testende Anwendung beschreiben, die für die Entwicklung, das Testen, die Bereitstellung und den Betrieb unserer Systeme erforderlich sind.
Allerdings ist es sinnvoll, unsere Definition nicht auf Technologie zu beschränken. Rechenzentren, Büroräume, Schreibtische, Desktop-Computer, Laptops, Tablet-Computer und Mobiltelefone mit ihren jeweils installierten Softwarepaketen sind allesamt Teil des Ökosystems, das für die Entwicklung, das Testen und die Bereitstellung von Systemen erforderlich ist.
Wenn du Entwicklertools, DevOps-Werkzeuge und -Verfahren, Testtools sowie die erforderlichen Geschäftsprozesse und Fachkenntnisse einbeziehst, gehört noch mehr dazu.
Möchten Sie mehr vom The CTO Club?
Erstellen Sie ein kostenloses Konto, um diesen Beitrag fertigzulesen und einer Community von CTOs und Technikleitern beizutreten, die praxisnahe Frameworks, Tools und Einblicke für die Entwicklung, Einführung und Skalierung KI-gesteuerter Technologien teilen.
Have an account? Log In
Die banalsten Dinge – etwa Zugangscodes oder Chipkarten, die für den Zutritt zu Gebäuden verwendet werden – können kritisch werden, wenn sie nicht vorhanden sind.
Infrastruktur in all ihren Ausprägungen dient der Unterstützung der Entwicklung, des Testens, der Bereitstellung und des Betriebs deiner Systeme. Sie ist entweder für das Testen von entscheidender Bedeutung oder muss selbst getestet werden.
Im nächsten Artikel betrachten wir Tools für Entwicklung, Tests und Zusammenarbeit. In diesem Artikel befassen wir uns mit dem, was die meisten Menschen als Testumgebungen betrachten, und werfen einen kurzen Blick auf das, was häufig als Infrastrukturtests bezeichnet wird. Ich werde folgende Themen behandeln:
- Testumgebungen
- Entwicklungsumgebungen
- Testumgebungen auf Systemebene
- Datenumgebungen
- Infrastrukturtests
Beginnen wir.
Testumgebungen
Jedes Testen beruht 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 in ihrem Kontext getestet werden. Damit ein Test aussagekräftig ist, muss das System in einer realistischen Umgebung installiert, eingerichtet, bereitgestellt oder erstellt werden, die die reale Welt simuliert, in der es eingesetzt wird.
Wir könnten beispielsweise Testszenarien verwenden, die die Leistungsfähigkeit der Systeme im Hinblick auf Funktionalität, Leistung oder Sicherheit auf die Probe stellen, doch dies sind Eigenschaften der Tests und nicht der Umgebung.
Eine realistische Umgebung würde sämtliche geschäftlichen, technischen und organisatorischen Umgebungen nachbilden. Ein großer Teil davon besteht aus Daten, die zur Steuerung von Geschäftsprozessen, zur Konfiguration des Systems und zur Bereitstellung von Referenzdaten verwendet werden.
Perfekt realistische Umgebungen sind jedoch meist unpraktisch oder viel zu teuer (selbst Tester von Systemen mit hoher Kritikalität, etwa von Flugzeugen, Kernreaktoren oder Gehirnscannern, müssen irgendwann Kompromisse eingehen). Fast alle Tests finden in Umgebungen statt, die die reale Welt mit einem akzeptablen Maß an Kompromissen simulieren.
Autos werden auf Rollenprüfständen, in Windkanälen, auf Schwingungsprüfständen und auf privaten Teststrecken getestet, bevor sie auf öffentlichen Straßen getestet werden. Computersysteme werden von Programmierern und Softwaretestern in Softwarelaboren getestet, bevor Endbenutzer dazu eingeladen werden, sie in einer produktionsähnlichen Umgebung auszuprobieren.
Um sicherzustellen, dass deine Testumgebungen den Branchenstandards entsprechen, solltest du die Integration einer dieser bestbewerteten Testmanagementplattformen in Betracht ziehen.
Testen in realistischen Umgebungen
Simulierte Umgebungen sind ebenso fehleranfällig wie unsere Anforderungen und Testmodelle, doch damit müssen wir leben.
Wir müssen Tests durchführen, die in den verfügbaren Umgebungen aussagekräftig sind, und die Testergebnisse bedeuten genau das, was wir aus ihnen ableiten.
Die Zuverlässigkeit von Testergebnissen hängt von der Umgebung ab, in der die Tests ausgeführt werden. Wird ein Test in einer falsch eingerichteten Umgebung ausgeführt:
- Ein Test, der fehlschlägt, kann den Eindruck erwecken, dass das System fehlerhaft ist, obwohl es tatsächlich korrekt funktioniert.
- Ein Test, der erfolgreich ist, kann den Eindruck erwecken, dass das System korrekt funktioniert, 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-Infrastrukturen können Testumgebungen schwierig und kostspielig einzurichten und zu warten sein.
Wenn Supportteams an der neuen Produktionsumgebung arbeiten, fordern die Tester Testumgebungen an (und möglicherweise mehrere davon). Im weiteren Verlauf der Tests haben Supportteams häufig konkurrierende Anforderungen.
Entwicklungsumgebungen oder spätere Testaktivitäten werden möglicherweise verspätet oder gar nicht bereitgestellt oder nicht wie erforderlich konfiguriert oder kontrolliert. Dies wird unweigerlich die Tests verzögern und/oder das Vertrauen in ein beliebiges Testergebnis untergraben.
Eine zentrale Aufgabe besteht darin, den Bedarf und die Anforderungen für eine zum Testen verwendete Umgebung einschließlich eines Mechanismus zur Verwaltung von Änderungen an dieser Umgebung festzulegen – so früh wie möglich.
Infrastruktur als Code ist eine neuere Entwicklung darin, wie Umgebungen mit Werkzeugen erstellt werden können, die Verfahren befolgen und deklarativen Code verwenden, um die Einrichtung der Umgebung zu definieren.
Obwohl Basisplattformen von Betriebssystemen (Server) problemlos in der Cloud oder als virtuelle Maschinen in der eigenen Umgebung erstellt werden können, erfordern vollständig spezifizierte Spezialserver mit sämtlicher erforderlicher Software, allen Daten, Konfigurationen und Schnittstellen mehr Aufwand.
Bei der Einrichtung Ihrer Testinfrastruktur ist es entscheidend, zuverlässige Software zur Datenbankverwaltung für eine optimale Leistung zu integrieren
Sobald sie jedoch eingerichtet sind, bieten sie eine äußerst effiziente Möglichkeit zur Erstellung von Umgebungen. Infrastrukturcode kann ebenso wie jeder Anwendungscode in der Versionsverwaltung gespeichert und durch Änderungen verwaltet werden.
Ein wesentlicher Grundsatz der kontinuierlichen Bereitstellung besteht darin, dass so früh wie möglich irgendeine Software – nicht einmal etwas Nützliches – durch die Bereitstellungspipeline geschoben werden sollte, um nachzuweisen, dass die Prozesse funktionieren.
Dies erfordert natürlich geeignete Umgebungen für Builds, Werkzeuge für kontinuierliche Integration, Tests auf Systemebene und die Bereitstellung. Ziel ist es, Test- und Produktionsumgebungen ohne Einschränkungen bereitzustellen. Sobald die Umgebungsdefinitionen und Bereitstellungsprozesse eingerichtet sind, wird die Erstellung von Umgebungen zu einer automatisierten und routinemäßigen Aufgabe.
Unter allen Umständen gehören die Definitionen dieser Umgebungen zu den frühzeitig im Projekt zu liefernden Ergebnissen.
Entwicklungsumgebungen
Entwicklertests konzentrieren sich auf die Erstellung von Softwarekomponenten, die Funktionen intern für die Anwendung oder auf der Benutzer- bzw. Präsentationsebene bereitstellen.
Tests werden in der Regel durch Kenntnisse der internen Struktur des Codes bestimmt und verwenden möglicherweise keine „realistischen“ Daten oder benötigen diese nicht für ihre Ausführung. Tests von Komponenten oder Diensten auf niedriger Ebene werden üblicherweise über eine API mit speziell entwickelten oder proprietären Treibern oder Werkzeugen ausgeführt.
Die Bandbreite an Entwicklungswerkzeugen, Plattformen und sogenannten Integrierten Entwicklungsumgebungen (IDEs) ist enorm. In diesem Artikel können wir nur einige der wichtigsten testbezogenen Anforderungen und Funktionen von Umgebungen ansprechen.
Um die Entwicklung und die für Entwickler vorgesehenen Tests zu unterstützen, müssen Umgebungen die folgenden Aktivitäten unterstützen. Dies ist nur eine Auswahl – in Ihrer Situation kann es zusätzliche oder abweichende Aktivitäten geben:
- Eine „Sandkasten“-Umgebung zum Experimentieren mit neuer Software. Sandkästen werden häufig verwendet, um neue Bibliotheken zu testen, wegwerfbaren Prototypcode zu entwickeln oder Programmiertechniken zu üben. Alle gängigen Programmiersprachen verfügen über Hunderte oder Tausende von Softwarebibliotheken. Sandkästen werden verwendet, um Software zu installieren und zu testen, die noch nicht Bestandteil des Hauptentwicklungszweigs ist, um sie zu bewerten und ihren Einsatz zu üben. Diese Umgebungen können als Wegwerf-Umgebungen behandelt werden.
- Lokale Entwicklungsumgebung. Hier verwalten Entwickler eine lokale Kopie eines Teils oder des gesamten Quellcodes ihrer Anwendung aus einem gemeinsam genutzten Code-Repository und können System-Builds für lokale Tests erstellen. Diese Umgebung ermöglicht es Entwicklern, Änderungen am Code in ihrer lokalen Kopie vorzunehmen und ihre Änderungen zu testen. Einige Tests sind Ad-hoc-Tests und werden möglicherweise nie wiederholt. Andere Tests sind automatisiert. Automatisierte Tests werden in der Regel dauerhaft aufbewahrt, insbesondere wenn sie einem testgetriebenen Ansatz folgen.
- Gemeinsam genutzte Umgebung für die kontinuierliche Integration. Wenn Entwickler darauf vertrauen, dass ihr Code bereit ist, übertragen sie ihre Änderungen in das gemeinsam genutzte, kontrollierte Code-Repository. Die CI-Umgebung führt automatisierte Builds durch und führt mithilfe des Repositorys automatisierte Tests aus. Zu diesem Zeitpunkt ist der neue oder geänderte Code integriert und getestet. Das CI-System führt automatisierte Tests nach Bedarf, stündlich oder täglich aus, und das gesamte Team erhält Benachrichtigungen und kann den Teststatus des neuesten integrierten Builds einsehen. Fehler werden umgehend sichtbar gemacht und dringend behoben.
Eine Entwicklungs- oder CI-Umgebung unterstützt Entwicklertests, aber andere Anwendungsserver, Webdienste, Messaging- oder Datenbankserver, die das System vervollständigen, sind möglicherweise nicht verfügbar.
Wenn diese Schnittstellensysteme nicht existieren, weil sie noch nicht entwickelt wurden oder weil sie einem Partnerunternehmen gehören und nur ein Produktivsystem, aber keine Testversion vorhanden ist, müssen Entwickler diese Schnittstellen stubben oder mocken, um zumindest ihren eigenen Code testen zu können.
Mocking-Tools können anspruchsvoll sein, aber gemockte Schnittstellen können normalerweise keine Tests unterstützen, 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 Produktionsdaten.
Gemeinsam genutzte Entwicklungsdatenbanken innerhalb eines Teams sind normalerweise unbefriedigend. Wenn es keine gute Regelung für die Verwaltung dieser gemeinsam genutzten Ressource gibt, könnten Entwickler die Daten der jeweils anderen wiederverwenden, beschädigen oder löschen.
Tests auf Systemebene
Tests auf Systemebene konzentrieren sich auf die Integration von Komponenten und Teilsystemen im Zusammenspiel.
Diese Umgebungen bieten eine Plattform zur Unterstützung der Ziele einer groß angelegten Integration, der Funktionsvalidierung und des Systembetriebs im Kontext von Benutzer- oder Geschäftsprozessen.
Umgebungen können auch den nichtfunktionalen Aspekten des Systems gewidmet sein, etwa Leistung, Sicherheit oder Servicemanagement.
Eine der häufigsten Tücken beim Testen tritt auf, wenn ein Systemtester in seiner Umgebung eine bestimmte Art von Fehler feststellt, der Entwickler oder Tester den Fehler jedoch trotz aller Bemühungen in der Entwicklungsumgebung nicht reproduzieren kann.
„Bei mir funktioniert es!“
„Ja, natürlich.“
Dies wird fast sicher durch mangelnde Konsistenz zwischen den beiden Umgebungen verursacht. Der Unterschied im Verhalten könnte durch die Konfiguration, Unterschiede bei Softwareversionen oder Unterschiede in den Datenbanken verursacht werden.
Unterschiede bei den Daten, die Probleme verursachen, sollten als Erstes überprüft werden. Sie lassen sich normalerweise leicht identifizieren und können oft schnell behoben werden.
Wenn eine Abweichung bei der Softwareversion oder Konfiguration vorliegt, können Tester und Entwickler viel Zeit damit verschwenden, der Ursache der unterschiedlichen Verhaltensweisen nachzugehen.
Wenn diese Probleme auftreten, bedeutet dies häufig, dass die Kommunikation zwischen dem Entwickler und dem Test fehlschlägt. Es könnte auch auf einen Verlust der Konfigurationskontrolle bei der Einrichtung der Entwickler- oder Testumgebung oder beim Bereitstellungsprozess hindeuten.
Infrastruktur als Code und die automatisierte Bereitstellung von Umgebungen werden Probleme mit der Konsistenz von Umgebungen der Vergangenheit angehören lassen.
Arten dedizierter Testumgebungen
Zur Unterstützung von System-, Abnahme- und nichtfunktionalen Tests müssen Umgebungen die folgenden Aktivitäten unterstützen (in Ihrer Organisation gibt es möglicherweise weitere):
- (Funktionale) Systemtestumgebung. In dieser Umgebung wird das System anhand der für das Gesamtsystem dokumentierten Anforderungen validiert. Anforderungen können umfangreiche Textdokumente mit tabellarisch aufgeführten Testfällen sein, die für einen Systemtest definiert wurden. In agilen Projekten kann diese Umgebung erforderlich sein, damit Tester das integrierte System untersuchen können, ohne sich auf bestimmte Funktionen beschränken zu müssen.
- Ende-zu-Ende-Test-Umgebung. Während die CI-Umgebung die Integration von Komponenten mit Teilsystemen ermöglicht, können die Geschäftsprozesse weitere Schnittstellensysteme erfordern, die nicht der Kontrolle der Entwickler unterliegen und verfügbar sein müssen. Umfassende Umgebungen sind erforderlich, um groß angelegte Integrations-, Geschäftsprozess- oder allgemeine Abnahmetests durchzuführen. In der Regel handelt es sich bei den Daten um eine Kopie der Produktivdaten oder zumindest um Daten in einem angemessenen Umfang. Wenn eine groß angelegte Integration nachgewiesen werden muss, werden die Daten- und Steuerungsflüsse anhand längerer Benutzerabläufe und unabhängiger Abstimmungen der Daten über die integrierten Systeme hinweg überprüft. Die Verwaltung von Daten in Testumgebungen ist entscheidend. Wenn Sie bereits Jira verwenden, sollten Sie erwägen, Ihre Datenverwaltungsfunktionen mit erweiterten, für Jira entwickelten Testverwaltungswerkzeugen zu verbessern.
- Leistungsumgebung. Diese Umgebungen müssen eine aussagekräftige Plattform zur Bewertung der Leistung eines Systems (oder ausgewählter Teilsysteme) bereitstellen. Bei Redundanz oder Klonen von Servern sind möglicherweise Kompromisse bei der Architektur zulässig. Die Datenmengen müssen jedoch dem Produktionsumfang entsprechen, selbst wenn die Daten synthetisch erzeugt wurden. Die Umgebung muss selbstverständlich so dimensioniert sein, dass sie das Transaktionsvolumen der Produktion unterstützt, um eine nützliche Vorhersage der Systemleistung in der Produktion zu ermöglichen.
- Umgebungen für Verfügbarkeit, Ausfallsicherheit und Verwaltbarkeit (ARM). In mancher Hinsicht ähneln diese Umgebungen den Leistungsumgebungen, doch je nach Testziel können Abweichungen unvermeidlich sein. Verfügbarkeitstests zielen darauf ab, zu überprüfen, ob das System über längere Zeiträume ohne Ausfälle betrieben werden kann. Ausfallsicherheitstests (oft als Umschalttests bezeichnet) prüfen, ob der Ausfall von Systemkomponenten keine unakzeptable Unterbrechung des bereitgestellten Dienstes verursacht. Verwaltungs- oder Betriebstests sollen nachweisen, dass administrative Systemverfahren sowie Verfahren für Verwaltung, Sicherung und Wiederherstellung effektiv funktionieren.
Daten in Umgebungen
In einigen sehr großen Projekten kann es bis zu 20 oder sogar 30 groß angelegte Umgebungen geben, die unterschiedlichen Aspekten von Tests, Schulungen, Datenmigrationen und probeweisen Umschaltungen gewidmet sind. In kleineren Projekten gibt es weniger Umgebungen, möglicherweise nur eine gemeinsam genutzte Umgebung oder eine kontinuierliche Bereitstellungspraxis – und sämtliche Tests könnten automatisch in Umgebungen durchgeführt werden, die für eine einmalige Nutzung instanziiert und anschließend wieder entfernt werden.
Alle Umgebungen benötigen Daten, aber Umfang und Realitätsnähe dieser Daten können variieren. Im Folgenden finden Sie einige gängige Muster für die Beschaffung und Verwaltung von Testdaten. Diese Muster konzentrieren sich auf den Besitz (lokal oder gemeinsam genutzt), die Art der Erstellung (manuell, automatisiert oder aus der Produktion kopiert) und den Umfang:
- Lokal, manuell erstellte Daten kleinen Umfangs – geeignet für Ad-hoc-Tests durch Entwickler oder Tester.
- Lokale, automatisiert erzeugte synthetische Daten. Geeignet für automatisierte Entwicklertests oder Umgebungen, in denen die Funktionen bestimmter Module oder Funktionen abgedeckt werden können.
- Gemeinsam genutzte, manuell erstellte Daten. Werden in Integrations- und Systemtestumgebungen verwendet, häufig dort, wo sich die Testdaten parallel zu manuell ausgeführten Tests entwickelt haben. Bei Bedarf werden sie gesichert und wiederhergestellt.
- Gemeinsam genutzte, automatisch erstellte Daten. Werden in Integrations- und Systemtestumgebungen verwendet, in denen sich die Testdaten parallel zu automatisiert oder manuell ausgeführten Tests entwickelt haben. Sie werden bei Bedarf erzeugt und/oder aus Sicherungskopien wiederhergestellt.
- Gemeinsam genutzte synthetische/zufällige Daten großen Umfangs. Leistungs- und ARM-Tests erfordern konsistente Daten in großen Mengen. Diese Daten müssen normalerweise nicht aussagekräftig sein – randomisierte Daten funktionieren problemlos und werden bei Bedarf erzeugt oder zunächst generiert und aus Sicherungskopien wiederhergestellt.
- Gemeinsam genutzte aussagekräftige Daten großen Umfangs. Für Ende-zu-Ende-, Abnahme- oder Benutzertests werden in der Regel aussagekräftige Daten in angemessenem Umfang benötigt. Manchmal werden Kopien oder Auszüge aus den Produktivdaten verwendet. Achten Sie jedoch darauf, nicht gegen Datenschutzbestimmungen zu verstoßen, wenn Sie die Daten nicht verschleiern/anonymisieren.
- Erneute Tests und Regressionstests. Sie benötigen einen bekannten, kontrollierten Datensatz in einem bekannten Zustand, der daher normalerweise aus Sicherungskopien wiederhergestellt wird. Dies gilt für jede der oben genannten Umgebungen, da diese Tests mit Daten in einem bekannten Zustand erneut ausgeführt werden müssen, um Fehler zuverlässig zu reproduzieren.
Infrastrukturtests
Zu Beginn dieses Artikels haben wir betrachtet, was zur Infrastruktur gehört, und uns seitdem hauptsächlich auf die technischen Komponenten, nämlich die Softwaresysteme, konzentriert und vorausgesetzt, dass die Hardware – real oder virtuell – verfügbar ist.
Wenn wir Systeme zunächst aufbauen, gehen wir davon aus, dass die Infrastruktur vorhanden ist und korrekt funktioniert, leistungsfähig, sicher und ausfallsicher ist usw.
Wir können all diese Aspekte testen, sobald wir unsere Anwendung integriert haben, und zweifellos Schwachstellen in der Infrastruktur relativ spät in unseren Projekten aufdecken. Infrastrukturprobleme jedoch so spät in einem Projekt zu finden, ist gewöhnlich äußerst störend.
- Änderungen zur Behebung von Fehlern in der Infrastruktur können eine umfassende Neugestaltung und Änderungen an unserer Anwendung erfordern.
- Die Ergebnisse unserer Anwendungs- oder Gesamtsystemtests müssen erneut durchgeführt werden.
- Wenn Komponenten von Drittanbietern wie Datenbank-, Web-, Netzwerk- oder Messaging-Dienste ausfallen, sind wir auf die Anbieter (oder die Open-Source-Community) angewiesen, die diese unterstützen.
Um sicherzustellen, dass unser Vertrauen in Infrastrukturkomponenten begründet ist, können wir auf unsere eigene oder die Erfahrung anderer mit ihrer früheren Nutzung zurückgreifen. Oder wir müssen ihre Zuverlässigkeit durch Tests bewerten, bevor wir uns in der Planung und Entwicklung unseres Systems zu ihrem Einsatz verpflichten.
Je nach der untersuchten Infrastruktur kann die von uns verwendete Umgebung variieren – von einem einzelnen Server bis hin zu einer nahezu vollständigen Infrastrukturplattform.
Obwohl einige Tests manuell durchgeführt werden, verwenden wir meist Werkzeuge, Treiber oder Roboter, um die Transaktionslast zu simulieren, die unsere Anwendung erzeugen würde. Wir müssten diese Schnittstellen nachbilden oder durch Stubs ersetzen:
- Schnittstellen, die derzeit nicht verfügbar sind
- Schnittstellen zu Komponenten, denen wir vertrauen und die einfach zu simulieren sind
- Schnittstellen außerhalb des Umfangs, die keinen Einfluss auf die getestete Infrastruktur haben.
Die Infrastruktur arbeitet natürlich in der Regel nicht über eine Benutzer- oder grafische Benutzeroberfläche.
Die Integration unserer Anwendung in die Infrastruktur erfolgt größtenteils in Form von Nachrichten oder Aufrufen entfernter Dienste. Häufig erfordert der zu simulierende Datenverkehr API-Aufrufe an Web- oder Anwendungsserver, Nachrichten- oder Datenbankserver oder an Dienste, die über die Cloud oder von entfernten Standorten bereitgestellt werden.
Leistungs- und ARM-Ziele sind möglicherweise bekannt; in diesem Fall können Tests durchgeführt werden, um sicherzustellen, dass diese Ziele erreicht werden.
Die Infrastruktur wird jedoch häufig mit anderen Anwendungen als unserer eigenen geteilt. Daher hilft die Kenntnis ihrer letztendlichen Kapazität dabei einzuschätzen, wie viel Kapazität verbleibt, wenn unsere Anwendung bereitgestellt wird.
In diesem Fall befasst sich das Infrastrukturtesten mit dem Risiko für unsere eigene Anwendung und möglicherweise auch für andere Anwendungen, die künftig darauf basieren.
Melden Sie sich für den Newsletter von The QA Lead an, um benachrichtigt zu werden, wenn neue Teile der Serie veröffentlicht werden. Diese Beiträge sind Auszüge aus Pauls Leadership-In-Test-Kurs, den wir sehr empfehlen, um tiefer in dieses und andere Themen einzusteigen. Wenn Sie dies tun, verwenden Sie unseren exklusiven Gutscheincode QALEADOFFER und erhalten Sie 60 $ Rabatt auf den vollständigen Kurspreis!
Lesetipp: DIE 10 BESTEN OPEN-SOURCE-TOOLS FÜR TESTMANAGEMENT
