Servicevirtualisierung
Was ist Servicevirtualisierung?
Bei der Servicevirtualisierung werden Repliken von Systemen erstellt, von denen neue Anwendungen abhängen, um zu testen, wie gut sich die Anwendung und die Systeme integrieren lassen. Sie wird in erster Linie für die Integration von Anwendungen eingesetzt, die von Cloud- und serviceorientierten Architekturen abhängen, oder für Anwendungen, die mit Daten und APIs von Drittanbietern kommunizieren. Beispiele für solche Systeme sind Customer Relationship Management Services wie Salesforce Service Cloud, Enterprise Resource Planning Services wie SAP ECC und interne Systeme, die sich noch in der Entwicklung befinden.
Entwickler können ein virtuelles Abbild des abhängigen Systems implementieren, damit Integrationstester sehen, wie gut ihre Anwendung integriert ist. Auf diese Weise können Entwicklungsteams Geld und Zeit sparen, indem sie während des gesamten Entwicklungsprozesses testen. Andernfalls müssten sie mit den Integrationstests warten, bis diese abhängigen Systeme verfügbar sind, was lange dauern kann, weil ein Dritter sie kontrolliert oder sie sich noch in der Entwicklung befinden.
Im Gegensatz zur Servervirtualisierung werden bei der Servicevirtualisierung nur bestimmte Schnittstellen, Interaktionen und Verhaltensweisen nachgebildet – Situationen, in denen ein Server mit einer Anwendung interagieren kann – und nicht ein kompletter Server.
Wie funktioniert die Servicevirtualisierung?
Servicevirtualisierungs-Tools überwachen den Datenverkehr zwischen dem abhängigen System und der Anwendung. Sie verwenden Protokolldaten, um ein Modell zu erstellen, das die Antworten und das Verhalten des abhängigen Systems replizieren kann, wobei Inputs wie SQL-Anweisungen für Datenbanken und XML- oder Extensible-Markup-Language-Nachrichten für Webservices verwendet werden. Wenn die Entwickler die neue Anwendung testen, erzeugt der virtuelle Service die gleichen Antworten wie der reale Service.
Die Entwickler nutzen diese Situation, um zu testen, wie sich eine neue Anwendung, ein neuer Service oder eine neue Funktion in die bestehende Infrastruktur einfügt. Die Servicevirtualisierung beseitigt einen bedeutenden Entwicklungsengpass, indem sie sicherstellt, dass die Tester nicht warten müssen, um mit den Tests zu beginnen. Auf diese Weise können Teams Produkte mit weniger Fehlern pünktlich und ohne Unterbrechung des Services veröffentlichen.
Die Tester können auch Sonderfälle einbauen, die ein hohes Verkehrsaufkommen oder langsame Verbindungen simulieren. Sobald die Anwendung für die Integration bereit ist, können die Entwickler die Simulation durch die reale Situation ersetzen.
Anbieter und Produkte der Servicevirtualisierung
Parasoft entwicklte 2003 eines der ersten Produkte mit Servicevirtualisierungsfunktionen, aber ITKO erfand den Begriff im Jahr 2007. Seitdem haben große Unternehmen ihre eigenen Tools zur Servicevirtualisierung entwickelt oder erworben. IBM übernahm Greenhat, CA Technologies übernahm ITKO und Hewlett Packet Enterprises entwickelte seine eigene Technologie. Andere Unternehmen, die Tools zur Servicevirtualisierung anbieten, sind Hoverfly, Traffic Parrot, WireMock und SmartBear.
Vorteile der Servicevirtualisierung
Die Vorteile der Servicevirtualisierung kommen vor allem in Szenarien mit schneller Bereitstellung und kontinuierlicher Lieferung zum Tragen. Sie ermöglicht es Teams, Testergebnisse während des gesamten Entwicklungsprozesses schnell zu wiederholen, was für DevOps und agile Teams von Vorteil sind. Die Servicevirtualisierung hilft diesen Teams, Fehler während der Entwicklung zu vermeiden, bessere Systeme mit weniger Fehlern zu erstellen und die Verantwortung für das Testen der Produktqualität abteilungsübergreifend zu teilen.
Die Vorteile der Servicevirtualisierung erstrecken sich auch auf Unternehmen außerhalb dieser schnellen Arbeitsabläufe. Wenn ein Unternehmen beispielsweise seine Backend-Systeme aktualisieren möchte, riskiert es, dass es zu Integrationsproblemen kommt, sobald diese Systeme wieder online sind. Mit der Servicevirtualisierung können Entwickler das Backend testen, während sie es verbessern, und seine Interaktionen mit dem Frontend vor der vollständigen Integration testen.
Mit der Servicevirtualisierung können Entwickler mit der Anwendungsentwicklung Schritt halten, wenn auch Komponenten fehlen. Vor der Servicevirtualisierung mussten Tester auf Anwendungen warten, die fast fertig waren. Verschiedene Teams mit unterschiedlichen Zeitplänen, Prioritäten und Anforderungen mussten die Anwendung oft erst fertigstellen und zusammenbauen, bevor die Tester darauf zugreifen konnten.
Das schnelle, integrierte Testen, das die Servicevirtualisierung ermöglicht, hilft den Entwicklungsteams, ihre Fristen einzuhalten und das Produkt schneller auf den Markt zu bringen. Die Tester können ein potenziell störendes Problem früher erkennen, was dazu beiträgt, dass die Entwicklungspläne im Zeitplan bleiben. Durch die Servicevirtualisierung können Unternehmen außerdem die Einrichtung teurer Testbots vermeiden.
Nachteile der Servicevirtualisierung
Zu den Nachteilen der Servicevirtualisierung gehören die Kosten und die Implementierung. Die Budgetierung für die Implementierung der Servicevirtualisierung kann sich als schwierig erweisen, da die Nutzung viele verschiedene Abteilungen betrifft. Es kann schwierig sein zu beurteilen, wer die Verantwortung für das Testen trägt und wer die Servicevirtualisierung beaufsichtigen sollte.
Außerdem ersetzt die Servicevirtualisierung keine vollständigen Integrationstests mit den tatsächlich abhängigen Systemen. Die Servicevirtualisierung ermöglicht Integrationstests während des gesamten Entwicklungsprozesses, was die abschließenden Tests beschleunigt, aber ein abschließender Testprozess ist immer noch notwendig.
Servicevirtualisierung versus Mocking und Stubbing
Mocking und Stubbing sind mit der Servicevirtualisierung vergleichbar, funktionieren aber in kleinerem Maßstab. Bei Mocking und Stubbing geht es in der Regel darum, bestimmte Verhaltensweisen in einem begrenzten Kontext zu testen, während bei der Servicevirtualisierung Systeme im Produktionsmaßstab nachgebildet werden.
Die wachsende Beliebtheit serviceorientierter Architekturen und agiler Entwicklung zeigt die Grenzen von Mocking und Stubbing auf. Die Servicevirtualisierung setzt beim Testen auf der Infrastrukturebene an und erstellt Modelle, die von verschiedenen Teams unter verschiedenen Umständen wiederverwendet werden können. Mocks und Stubs erfordern in der Regel eine manuelle Entwicklung für jeden Anwendungsfall. Service-Architekturen erfordern in der Regel zu viele abhängige Variablen, als das Mocking und Stubbing praktikabel wären, und agile Workflows verlangen eine Geschwindigkeit, die diese Methoden nur schwer erreichen können.
Darüber hinaus ist es für Entwickler wahrscheinlicher, Fehler in Stubs und Mocks einzubauen, die auf ihren Annahmen darüber beruhen, wie die Anwendung in der jeweiligen Situation reagieren sollte. Qualitätssicherungs-Teams können beide Technologien integrieren, wenn sie Servicevirtualisierung verwenden, wenn sie Systeme emulieren müssen, und Mocking oder Stubbing, wenn sie nur einfache, kontextspezifische Unit-Tests benötigen.
