Verbessern Sie Stubbing & Mocking mit Service-Virtualisierung

Wie verhält sich Service-Virtualisierung zu Stubbing und Mocking?

Deadlocks sind in parallelen und agilen Entwicklungsumgebungen endemisch, in denen verschiedene Teams gleichzeitig an miteinander verbundenen Systemkomponenten arbeiten - und jedes Team muss auf die Komponenten des anderen zugreifen, um seine eigenen Aufgaben zu erledigen. Wenn ein Team jedoch auf den Zugriff auf abhängige Funktionen wartet, wird die Agilität beeinträchtigt.

Ein Ansatz zur Umgehung solcher Konflikte beim Testen von Ressourcen besteht darin, dass jedes Teammitglied einfache Stubs oder Mocks erstellt, um die abhängige Ressource zu ersetzen. Mit diesem Ansatz sind jedoch ernsthafte Risiken verbunden:

• Der Stub repräsentiert möglicherweise nicht den vollen Umfang des endgültigen Verhaltens der Komponente.
• Verschiedene Teammitglieder können unterschiedliche Stubs entwickeln und bearbeiten, basierend auf unterschiedlichen Annahmen.

In beiden Fällen ist das Endergebnis, dass Qualität und / oder Produktivität beeinträchtigt werden. Wenn die Anwendung gegen eine fehlerhafte Annahme erstellt wird, können Fehler auftreten (wenn diese Diskrepanz nicht erkannt wird) oder Nacharbeiten erforderlich sind (wenn die Diskrepanz erkannt wird). Wenn die Anwendung gegen eine fehlerhafte Annahme getestet wird, besteht außerdem ein erhebliches Risiko, dass die „validierte“ Funktionalität möglicherweise nicht wie erwartet funktioniert und andere Fehler möglicherweise übersehen wurden.

Wie Service-Virtualisierung beim Verspotten / Stubben hilft

Während Stubs aus der Perspektive der Testsuite erstellt werden, um nicht verfügbare Systemkomponenten zu „überspringen“, umfasst die Servicevirtualisierung die Erstellung virtueller Assets, um das Verhalten eingeschränkter Komponenten dem gesamten Team zur Verfügung zu stellen.

Benutzer können das Asset erstellen und dieses Verhalten bei Bedarf mit den abhängigen Parteien überprüfen. Wenn das Asset zentral bereitgestellt wird, greifen alle Teammitglieder auf dasselbe Asset zu, was das erwartete Verhalten ausdrückt. Dies ermöglicht eine absolute Konsistenz und ein geringeres Risiko, dass Fehler in das Endprodukt gelangen.

Wirklich skriptlose Service-Virtualisierung beschleunigt die Einführung der Virtualisierung, unabhängig davon, ob einfache oder komplexe Test-Assets erforderlich sind. Eine Vielzahl von Nachrichtentypen bedeutet eine bessere Unterstützung für Ihre beabsichtigte Anwendungsdomäne.

Service-Virtualisierung emuliert ein realistischeres Verhalten

Darüber hinaus kann die Service-Virtualisierung ein viel realistischeres Verhalten darstellen als einfache Stubs und Mocks. Sie können das aktuelle Verhalten von Live-Systemen oder aufgezeichnetem Datenverkehr erfassen, das Verhalten nach Bedarf aktualisieren, um die beabsichtigten Änderungen abzudecken, und dann dieses virtuelle Asset konfigurieren, indem Sie das bedingte Verhalten, die Leistungskriterien und die Testdaten parametrisieren.

Sie können das virtuelle Asset auch einfach ändern, um die entsprechende Auswahl an Fehlerbedingungen, Ausnahmen usw. zu erstellen, die ausgeführt werden sollten, um das gesamte Systemverhalten zu validieren - einschließlich der Fähigkeit, korrekt zu reagieren (oder zumindest ordnungsgemäß zu versagen) verschiedene Ausnahmesituationen.

Die Virtualisierung ermöglicht komplexe Testbedingungen (z. B. Was-wäre-wenn-, Sicherheits-, Failover-, Leistungs- und negative Testszenarien) und deckt versteckte Leistungsprobleme in Ihrer zu testenden Anwendung auf, indem die Leistung des Dienstes für Lasttests oder langsame Tests gesteuert wird Netzwerksimulation. Benutzer können auf einfache Weise eine Vielzahl von Szenarien konfigurieren, indem sie die Virtualisierung von Diensten aus externen Datenquellen oder der integrierten Datenrepository-Infrastruktur dynamisch steuern.

Service-Virtualisierung repräsentiert zusammengesetztes Verhalten

Aus der Servicevirtualisierung erstellte virtuelle Assets müssen nicht als Silos betrieben werden. Sie können zusammengesetztes Verhalten darstellen. Beispielsweise kann ein Aufruf zum Überweisen von Geldern an einem virtuellen Endpunkt eine Aktualisierung des Kontostands an einem anderen Endpunkt auslösen. Auf diese Weise können sich virtuelle Assets zustandsbehaftet verhalten und das Verhalten eines gesamten Systems auf einfache Weise modellieren - selbst wenn das Verhalten mehrere Verbindungen, Protokolle oder Schnittstellen überschreitet.

Ein kritischer Teil der Erstellung realistischer virtualisierter Abhängigkeiten ist ein zustandsbehaftetes Verhalten. Mit anderen Worten, eine virtualisierte Abhängigkeit behält ihren Status von Testlauf zu Testlauf bei. Um vertrauenswürdige und wiederverwendbare virtualisierte Dienste zu haben, ist es wichtig, dass sie den realen Dienst ausreichend nachahmen können, um aussagekräftige Ergebnisse für die zu testende Anwendung zu liefern, was wiederum ein zustandsbehaftetes Testen erfordert. Zusätzlich zur Statefulness besteht auch die Notwendigkeit, Zustandsänderungen basierend auf verschiedenen potenziellen Eingaben zu simulieren. Der virtualisierte Dienst muss dieses Stateful-Verhalten erweitern, um Statusübergangstests zu ermöglichen.

Service-Virtualisierung ermöglicht Grenztests

Manchmal werden zur Reproduktion eines Fehlers Daten benötigt, die in der realen Umgebung normalerweise nicht vorhanden sind. Durch das Laden synthetischer Daten in virtuelle Dienste sind alle Arten von Antworten außerhalb der Grenzen möglich, die in der Realität extreme Randfälle darstellen. Dies erleichtert die Durchführung von Sicherheits- und Randbedingungstests erheblich, da Sie genau die Antworten simulieren können, nach denen Sie suchen.