Vorteile der Service-Virtualisierung über Stubbing & Mocking hinaus

Servicevirtualisierung (SV) ist eine Methode, die DevOps-Teams verwenden, um Komponenten des Verhaltens einer App zu simulieren. Komponenten sind APIs, Datenbanken, Netzwerke, Geräte und mehr. Teams verwenden SV, weil einige Komponenten des Projekts aus einer Reihe von Gründen möglicherweise nicht verfügbar sind, darunter:

• Entwickler entwickeln sie immer noch.
• Es kann problematisch sein, sie einzurichten.
• Sie können schwer zugänglich sein.
• Dritte können sie besitzen.
• Sie können teuer oder eingeschränkt sein.

Service-Virtualisierung ist wie ein Flugsimulator für Anwendungen. Ziel ist es, dass Tester während der Entwicklung auf Funktionalität und Mängel testen und potenzielle Probleme erkennen und so früh wie möglich angehen, damit das Flugzeug nicht abstürzt.

Die Verwendung von SV spart Zeit, Geld, Kopfschmerzen und Frustration. DevOps-Teams enden nicht mit einer „wir gegen sie“-Haltung, wenn die Entwicklung zum Erliegen kommt, während sie darauf warten, dass ihre Teamkollegen ihren Teil davon abschließen.

Service-Virtualisierung: Ein Blick ins Detail

• Ein virtueller Dienst ist ein „Testdouble“. Es ist oft eine Software as a Service (SaaS) und arbeitet im Prozess nie direkt mit Funktionen oder Methoden.
• Um virtuelle Services und Assets zu erstellen, können Entwickler den Datenverkehr mit einer Service-Virtualisierungsplattform aufzeichnen, anstatt das Interaktionsmuster von Grund auf neu zu erstellen.
• Die Dienstvirtualisierung unterstützt normalerweise mehrere Protokolle wie MQ, HTTP, TCP und andere. Ein Mock oder Stub unterstützt oft nur einen.
• Service-Virtualisierungstools verfügen häufig über Benutzeroberflächen, die es Nicht-Entwicklern ermöglichen, die Tools zum Testen zu verwenden, ohne die Details des Projekts kennen zu müssen.

Service-Virtualisierungstools können auch nicht funktionale Aspekte des Systems replizieren, wie z. B. hohe Aktivitätslasten oder langsame Verbindungen und Reaktionszeiten. Einige virtuelle Dienste haben eine Gruppe von Stub-Antworten für bereitgestellte Anforderungskriterien und senden alle anderen Anforderungen an ein funktionierendes Backend-System. Dies wird als partielles Stubbing bezeichnet.

Wie Mocks kann auch die Service-Virtualisierung komplexe Request-Matcher beinhalten. Diese ermöglichen es dem Test, eine Antwort für viele Arten von Anforderungen zurückzugeben. Über einfaches Mocking hinaus simuliert die Service-Virtualisierung das Verhalten eines Systems, wenn es Antworten auf der Grundlage von Anforderungsdaten und -attributen erstellt und zurückgibt.

Vergleich von Stubs und Mocks

Stubs und Mocks führen einige der gleichen Funktionen aus wie die Service-Virtualisierung, sind aber, wie wir anmerken, nicht so gründlich oder so flexibel.

Was sind Stummel?

Ein Stub führt minimal eine Schnittstelle aus und gibt fest codierte Informationen zurück, die eng mit der Testsuite verbunden sind. Testteams finden Stubs sind am hilfreichsten wenn die Testsuite unkompliziert ist und die Beibehaltung der hartcodierten Informationen im Stub kein Problem darstellt.

Entwickler schreiben Stubs, normalerweise für den persönlichen Gebrauch, und geben sie normalerweise nicht weiter, weil die Stubs nicht zwischen Plattformen funktionieren können und weil es fest codierte Infrastrukturabhängigkeiten gibt.

Was sind Mocks?

Ein Mock ist ein „Beobachter“ einer programmierbaren Schnittstelle, der überprüft, ob die Ausgabe der Entwicklung den Erwartungen entspricht, die der Test definiert hat. Testtools erstellen Mocks mit einer Bibliothek eines Drittanbieters, z. B. JMock, Mockito oder WireMock.

Tester verwenden Mocks, wenn sie über große Testsuiten verfügen, bei denen die Verwendung eines Stubs nicht funktioniert (weil jeder Test eine andere Dateneinrichtung erfordert) oder die Aufbewahrung in einem Stub zu teuer wäre. Entwickler schreiben auch Mocks für ihren eigenen persönlichen Gebrauch und teilen sie normalerweise nicht aus dem gleichen Grund, aus dem sie keine Stubs teilen, wie oben erwähnt.

Die Vorteile und Herausforderungen der Service-Virtualisierung

Zu den vielen Vorteilen der Service-Virtualisierung gehören:

• Stellt eine Gemeinsamkeit her, damit Entwicklungsteams mit anderen Entwicklungs- und Testteams kommunizieren und Artefakte gemeinsam nutzen können. Teams können auch problemlos SV-Assets innerhalb des Unternehmens austauschen.
• Einfach zu erlernen, auch für Nicht-IT-Leute, sodass Entwickler ihre Arbeit fortsetzen können, während Tester SV verwenden, um alle Aspekte eines Projekts zu testen, was zu einer Reduzierung der Arbeitskosten führt.
• Unterstützt viele Protokolle und kann Datenverkehr aufzeichnen. Idealerweise können diese Verkehrsaufzeichnungen dazu verwendet werden, automatisch virtuelle Assets zu generieren.
• Reduziert die Abhängigkeit von der Verfügbarkeit von Komponenten von Drittanbietern und es fallen keine Servicegebühren für Datenbanken, APIs oder Dienste von Drittanbietern an.
• Verkürzt die Markteinführungszeit, da SV das Testen und damit die Entwicklungszeit verkürzt.
• Erhöht die Qualität, da die Tests gründlicher und genauer sind.

Einige Leute sagen, dass die Verwendung von Service-Virtualisierung zu viele Herausforderungen mit sich bringt. Parasoft bietet Lösungen.

Herausforderung: „Im Gegensatz zu Testern oder Entwicklern, die einen Stub oder Mock erstellen, um das Projekt zu testen, kosten SV-Tools nicht mehr?“

Lösung: Die Nichtverwendung von SV erschwert das Testen und erhöht die Kosten. Sehen Sie sich an, wie Parasoft Probleme angeht von Komplexität, Kosten und anderen potenziellen Problemen hier.

Herausforderung: „SV-Systeme sind groß und möglicherweise nicht das Richtige für mein kleines Unternehmen.“

Lösung: Die einfache, wertbasierte Lizenzierung von Parasoft passt sich den Anforderungen Ihres Unternehmens an und unterstützt große und kleine Bereitstellungen mit a Mischung von Angeboten.

Herausforderung: „Wie kann mein Unternehmen sicherstellen, dass das von mir gewählte Service-Virtualisierungspaket meinen Anforderungen entspricht, um eine schlechte Benutzererfahrung zu vermeiden?“

Lösung: Die Experten von Parasoft erläutern die Aspekte, die bei der Auswahl des richtigen Service-Virtualisierungstools für die Anforderungen Ihres Unternehmens zu berücksichtigen sind dieses Whitepaper.

Virtualisierung von Daten- und API-Diensten

DevOps-Teams verwenden häufig zwei Haupttypen von SV:

• Virtualisierung von Datendiensten
• Virtualisierung von API-Diensten

Datenvirtualisierung

Die Wartung und Bereitstellung von Datenbanken ist oft problematisch. Datenbankadministratoren fehlen möglicherweise die Ausbildung, die sie in diesen Tagen des Cloud-basierten Betriebs benötigen, oder die Fähigkeiten, die sie benötigen, um effizient und effektiv wiederverwendbare Testdaten zu erstellen. Die Virtualisierung von Datenbankdiensten ermöglicht es Testern, Datenbankebenen zu „entkoppeln“, was es anschließend Teammitgliedern ermöglicht, die Ressourcen von Datenbanken nach Bedarf zu teilen und aufzuteilen.

Durch die Virtualisierung von Datenbankdiensten können Teams mit dem Erstellen und Testen mit realistischen Datenbeispielen fortfahren, selbst wenn keine Datenquellen verfügbar sind. Sobald der Entwickler die Datenquelle identifiziert hat, gibt er/sie die Attribute an, die die Quelle enthält. Wenn eine Anforderung an das virtuelle Asset übergeben wird, verwendet es die simulierte Datenquelle, um umgebungsspezifische Antworten zu erzeugen, die auf Anforderungsfaktoren basieren. Wenn der Tester die Datensätze modifiziert, werden die simulierten Antworten automatisch aktualisiert.

Die Datenbankvirtualisierung verringert die Reibung im Team, die häufig durch Abhängigkeiten verursacht wird. Die Arbeit an der Entwicklung kann voranschreiten, obwohl die eigentlichen Datenquellen nicht vor Ort sind. Teams können auch eine virtuelle Datenbank verwenden, um ohne Unterbrechung von einem Server auf einen anderen zu migrieren. Dies ist eine Gelegenheit, die hohen Infrastrukturkosten einzusparen, die häufig für die herkömmliche Datenbankverwaltung anfallen.

API-Service-Virtualisierung

APIs (Application Programming Interfaces) sind Softwarevermittler, die es zwei Anwendungen ermöglichen, miteinander zu kommunizieren. Wenn Sie auf Ihrem PC mit Facebook interagieren oder auf Ihrem Telefon eine Transaktion auf einer Bank-Website durchführen oder die Nachrichten abrufen, sind APIs am Werk, entweder vor oder hinter den Kulissen. Komplexe Anwendungen können viele verschiedene Arten von APIs verwenden, was die Schwierigkeit gründlicher Tests erhöht.

Wenn Tester Service-Virtualisierung zum Testen von APIs verwenden, schreitet die Entwicklung schnell voran und die Qualität steigt. Leistungstests, Sandboxing von Drittanbietern und Lasttests helfen Entwicklern dabei, die vollen Fähigkeiten einer API während Verzögerungen und Situationen mit hoher Auslastung und starkem Datenverkehr zu verstehen. Tester können die Dienstvirtualisierung verwenden, um verschiedene Nachrichtentypen und verschiedene Protokolle wie JSON, JMS, WADL und REST zu testen. Sie können es für End-to-End-Tests verwenden, die eine mehrschichtige Validierung über eine Vielzahl von Endpunkten hinweg ermöglichen. Andere Möglichkeiten, wie Entwickler API-Service-Virtualisierung verwenden, umfassen die Ermöglichung von Testern zu:

• Sehen Sie, wie verschiedene Ereignisse und Nachrichten komplizierte Architekturen durchlaufen.
• Testen Sie auf Extremfälle wie große Anrufmengen oder schlechte Konnektivität.
• Untersuchen Sie Fehler wie langsame Reaktionszeiten, Ausfallzeiten oder Unzugänglichkeit einer nachgelagerten Integration.
• Test auf Sicherheitslücken.
• Testen Sie auch dann, wenn einige der Systemkomponenten nicht verfügbar sind.
• Testen Sie ein Konzept, bevor Sie tatsächlich ein Stück bauen.
• Finden Sie die beste API für die Integration.

API-Microservice-Dienstvirtualisierung

Unternehmen haben festgestellt, dass das Testen von Microservices mithilfe von Servicevirtualisierung sehr wertvoll ist. Microservices sind kleine Teile eines größeren Systems, die Unternehmen unabhängig voneinander veröffentlicht oder zu verschiedenen Zeiten geändert oder implementiert haben. Wenn jeder Dienst von einem anderen Ort und einer anderen Umgebung stammt, ist das Testen schwierig. Mithilfe der API-Microservices-Virtualisierung installieren Tester nur den Microservice, an dem sie gerade arbeiten, und virtualisieren dann den Rest, was Stunden an Zeit spart.

Verringerung von Abhängigkeiten

Das Reduzieren von Abhängigkeiten ist ein weiterer Vorteil des SV-API-Testens. Wenn Entwickler „nach links wechseln“ und QA von Anfang an in die Systemerstellung einbeziehen, ermöglicht SV API-Testing der QA, direkt einzusteigen und „work in progress“ in einer exakten Nachbildung der Umgebung zu testen – selbst wenn die Entwickler keine Programmdetails veröffentlicht haben. Dies beinhaltet die Durchführung automatisierter Tests oder kontinuierlicher Tests für direktes Feedback.

Stärkung von CI/CD-Tests

Es reicht nicht aus, sicherzustellen, dass die Anwendung ordnungsgemäß funktioniert. Es muss auch die Systemanforderungen und die umfassenderen Geschäftsziele des Projekts erfüllen und sicherstellen, dass alle Integrationen kontinuierlich und stabil sind. Die API-Service-Virtualisierung befähigt die QA zum Testen, selbst wenn die Entwickler die API noch erstellen. Außerdem hilft es App-Testern sicherzustellen, dass APIs erfolgreich in APIs von Drittanbietern integriert werden können, selbst wenn diese Apps noch nicht zur Veröffentlichung bereit sind.

Verbesserung der DevOps-Transformation

Um CI/CD (Continuous Integration/Continuous Delivery) zu realisieren, ist ein Ziel, 80 % der Tests zu automatisieren, optimal. Das Testen von APIs ist enorm wichtig, da es dabei hilft, sicherzustellen, dass die gesamte Pipeline immer noch korrekt funktioniert, nachdem das Team neue Funktionen hinzugefügt hat. Dies umfasst sowohl externe als auch interne APIs. Betrieb und Entwicklung werden immer stärker integriert, sodass es häufiger zu Feedbackschleifen und Releases kommt. Aber wenn diese Teams nur UI-Testsuites ausführen, können die Feedback-Schleifen unterbrochen werden. Durch die API-Service-Virtualisierung können DevOps-Teams frühzeitig Abhängigkeiten simulieren, damit sie im Verlauf der Entwicklung automatisierte Tests implementieren können.

Iterative Designs

Wenn Ihre Designumgebung iterativ ist, ziehen Sie die Dienstvirtualisierung in Betracht. Es ermöglicht Ihnen, schnell mit neuen Ideen und Ansätzen zu experimentieren, ohne die gesamte API zu erstellen. Das Ergebnis ist eine agile Methode, um zu sehen, ob neue Kollaborationen und Funktionen funktionieren – ohne große Investitionen in Zeit und Ressourcen.

Beschleunigung von UI-Tests

Die Servicevirtualisierung ermöglicht es Teams, gemeinsame Benutzeroberflächenintegrationen mit Webpaketen wie SOA und AJAX zu beschreiben. Auf diese Weise können sie UI-Tests jederzeit und überall ohne Unterbrechungen ausführen. Teams können externe Umgebungen simulieren und so mehr Kontrolle über die Daten erhalten, die die Webdienste zurückgeben. Außerdem können Teams sogar UI-Integrationen erstellen und testen, bevor die Webdienste verfügbar werden.

API-Mocking vs. Service-Virtualisierung

Beim API-Mocking werden Komponenten von Software nachgeahmt, damit Entwickler die Funktionsfähigkeit testen können. Die Funktionen des Spotts sind normalerweise kontextspezifisch. Mit anderen Worten, die Funktionen ahmen eine Verhaltensreaktion nach, um eine bestimmte Entwicklungsanforderung zu erfüllen. Darüber hinaus isoliert das API-Mocking nur einen einzelnen Teil der Anwendung. Es ist zu einfach und zwingt Entwickler, neue Schnittstellen zu erstellen, was kompliziert ist.

Stubs sind ähnlich simpel und umständlich. Die Verwendung von Mocks und Stubs ist im Vergleich zur API-Service-Virtualisierung zeitaufwändiger und in ihrer Effektivität begrenzt.
Die API-Service-Virtualisierung erzeugt eine wesentlich funktionsreichere, realistischere replizierte Umgebung. Zu den Vorteilen gehören:

• Mehr Flexibilität, da es nicht an bestimmte Kontexte oder Daten gebunden ist.
• Entwickler können API SV während der Produktion und beim Testen verwenden.
• Wiederverwendbar.
• Kann automatisiert werden.
• Erfordert keine Testskripte oder Klassen.

Beispiele für Service-Virtualisierung

Beispiel 1. Ihr Team arbeitet an einer großen, komplexen Legacy-App mit vielen Abhängigkeiten. Die aktuelle Testabdeckung ist gering, insbesondere wenn die Systemabhängigkeiten durchgängig nicht verfügbar sind.

Die Dienstvirtualisierung ermöglicht es Ihnen, Datenverkehr zu protokollieren, wenn die Abhängigkeiten verfügbar werden. Dadurch kann das Team später mit virtuellen Diensten testen, wenn Sie den Datenverkehr wiedergeben. Dadurch wird der Einfluss der Ausfallzeiten der Abhängigkeiten für das Team und die Tester.

Beispiel 2. Ihr Team arbeitet in einer Architektur vom Typ Microservices. Eine Abteilung hat 10 Tester und 20 Entwickler. Die Gruppe ist für die Bereitstellung von 70 kleinen Apps verantwortlich, die ein Produkt bilden.

Arbeitsteams testen die Anwendungen einzeln und isoliert. Während das CI/CD-System Ihres Teams gut funktioniert, ist die Außenumgebung nicht agil. Ihre APIs sind langsam und oft nicht verfügbar, was die Einrichtung von Testdaten erschwert.

Um das Problem zu lösen, verwendet jedes Team, das mit den Drittanbietern kommuniziert, SV-Tools, und die Akzeptanztester verwenden sie während des CI-Builds. Die Entwickler nutzen sie auch für manuelle explorative Tests. Das Team verwendet dann die Tools im primären Integrations-Build, der alle Anwendungen ausführt. Schließlich verwenden die Leistungstestteams die SV-Tools in den Full-Stack-Leistungstests.

Zusammenfassung

Service-Virtualisierung ist besser als Mocks und Stubs und leistet Ihrem Unternehmen gute Dienste, da sie kontinuierliches Testen ermöglicht, gemeinsam nutzbarer und wiederverwendbar ist. Als Ergänzung zu Ihrem CI/CD-Workflow senkt SV die Kosten und verkürzt die Markteinführungszeit.