Die Herausforderungen beim Testen von Microservices meistern und die Vorteile maximieren

Microservices sind seit Jahren ein Branchentrend, doch Unternehmen nutzen die Vorteile des Ansatzes nicht und kämpfen mit fehlgeschlagenen Releases. Diese Fehler laufen oft darauf hinaus, dass es schwierig ist, die Schnittstellen zwischen Diensten zu testen, um die erwartete Qualität, Sicherheit und Leistung zu erzielen.

Letztendlich ist es ein Versäumnis, diese APIs robust genug zu testen. Der Silberstreif am Horizont ist, dass die Testkonzepte und -lösungen zwischen Legacy-SOA-Tests und Microservices-Tests identisch sind. Wenn Sie Ihre API-Testprobleme lösen können, können Sie Ihre Microservice-Releases verbessern.

Microservices stellen neue Herausforderungen dar

Heutzutage ist es üblich, Hunderte, wenn nicht Tausende von Microservices zu sehen, die gruppiert sind, um eine moderne Architektur zu definieren.

Hochgradig verteilte Unternehmenssysteme haben große und komplexe Bereitstellungen, und diese Komplexität der Bereitstellung wird oft als Grund dafür angesehen, Microservices NICHT zu implementieren. Tatsächlich zerfällt die Komplexität innerhalb des Monolithen, den Sie zerlegen, in eine noch komplexere Bereitstellungsumgebung.

Zur Enttäuschung der Uneingeweihten verschwindet die Komplexität nicht wirklich, sondern verwandelt sich in eine neue Art von Komplexität.

Während Microservices versprechen, die Effizienz der parallelen Entwicklung zu steigern, bringen sie ihre eigenen neuen Herausforderungen mit sich. Hier sind einige Beispiele.

• Viele weitere Interaktionen zum Testen auf der API-Ebene, während API-Tests zuvor nur auf das Testen von extern exponierten Endpunkten beschränkt waren.
• Blockaden der parallelen Entwicklung die die Time-to-Market-Vorteile des Aufbrechens des Monolithen begrenzen. Abhängigkeiten von anderen Diensten und komplexe Bereitstellungsumgebungen reduzieren die Parallelität in der Realität.
• Auswirkungen auf die traditionellen Testmethoden die innerhalb des Monolithen erfolgreich waren (z. B. End-to-End-UI-Tests), müssen nun auf die API-Schicht verlagert werden.
• Weitere potenzielle Fehlerquellen aufgrund von verteilten Daten und Computern, was die Fehlersuche und Ursachenanalyse schwierig und komplex macht.

3 wichtige Schritte zum Testen von Microservices

Was sind die drei wichtigsten Schritte zum Testen von Microservices? Um sie einfach zu beschreiben, sind diese Schritte:

1. Rekord
2. Überwachen
3. Control

Aufzeichnung, Überwachung und Kontrolle helfen Ihnen dabei, Testansätze so effizient umzusetzen Finden Sie heraus, welche Tests erstellt werden müssen Gleichzeitig hilft es Ihnen, Komponententests zu automatisieren, wenn es nachgelagerte APIs gibt, von denen Sie isolieren müssen.

Die dafür notwendige Technologie ist die Service-Virtualisierung. Die Service-Virtualisierung erweckt alle drei dieser Konzepte durch eine grundlegende Funktion zum Leben: Nachrichten-Proxys.

Durch die Verwendung von Nachrichtenproxys in Ihrer Bereitstellungsumgebung können Sie den Nachrichtenfluss zwischen APIs überwachen und aufzeichnen sowie die Ziele steuern, an die Nachrichten gesendet werden.

Wie funktioniert ein Nachrichten-Proxy?

Es ist so konzipiert, dass es einen bestimmten Endpunkt oder eine bestimmte Warteschlange abhört und dann empfangene Nachrichten an einen Zielendpunkt oder eine Warteschlange weiterleitet. Im Grunde ist es ein Man-in-the-Middle für Ihre APIs. Sie entscheiden sich aktiv dafür, eines zwischen Ihren integrierten Systemen einzufügen. Sobald es eingerichtet ist, können Sie es nutzen.

API- und Microservices-Tests

APIs testen und die Bewältigung der damit verbundenen Herausforderungen ist nicht so unterschiedlich, unabhängig davon, ob Ihre Umgebung stark verteilt, einigermaßen verteilt oder überwiegend monolithisch ist. Je größer die Zahl der vorhandenen Integrationen ist, desto akuter werden einige Herausforderungen, aber die grundlegenden Ansätze sind dieselben.

Beim Nachdenken über ein API oder Microservice Als Blackbox können wir es auf die Clients Ihres Dienstes und die Abhängigkeiten Ihres Dienstes herunterbrechen. Das Testen Ihrer API als Blackbox bedeutet, dass Ihr Testrahmen als Client für Ihren Dienst fungiert, dessen Aufgabe es ist, zu überprüfen, ob er die richtigen Antworten zurückerhält. Die Abhängigkeiten sind das, was Ihr Dienst integrieren muss, um ordnungsgemäß zu funktionieren. Sowohl auf der Client-Seite als auch bei den Abhängigkeiten sind Optimierungen vorzunehmen.

Bevor wir diese Optimierungen untersuchen, beginnen wir mit der Entwurfsphase, wo der Microservice geplant wird und wo die Teststrategie beginnen sollte.

Der Microservice-Lebenszyklus

Entwurfsphase: Definieren Sie Anforderungen für Klarheit

Eine anerkannte Best Practice für die API-Entwicklung ist die Implementierung einer Dienstdefinition während der Designphase. Für RESTful-Dienste wird häufig die OpenAPI-Spezifikation verwendet.

Diese Dienstdefinitionen werden von Ihren Clients verwendet, um zu verstehen, welche Ressourcen und Vorgänge Ihr Dienst unterstützt und wie Ihr Dienst Daten empfangen und senden soll. In den Dienstdefinitionen für REST-Dienste befinden sich JSON-Schemas, die die Struktur der Nachrichtentexte beschreiben, sodass Clientanwendungen wissen, wie sie mit Ihrer API arbeiten.

Aber Dienstdefinitionen sind nicht nur wichtig, um anderen Teams zu helfen, die Funktionsweise Ihrer API zu verstehen, sie wirken sich auch positiv auf Ihre Teststrategie aus.

Sie können sich die Dienstdefinition wie einen Vertrag vorstellen. Das ist die Grundlage, um mit dem Aufbau einer Strategie für die API-Governance zu beginnen. Eine der größten Herausforderungen beim API-Testen ist, wie bei jedem Softwaretest, der Umgang mit Änderungen.

Mit der Popularität agiler Praktiken war der Wandel noch nie so schnell. Die Durchsetzung dieser Verträge ist der erste Schritt, um Ordnung in das Chaos zu bringen, wenn Sie versuchen, viele Teams zu streiten, die APIs entwickeln, und dann erwarten, dass all diese APIs irgendwie gut miteinander spielen.

Validierung und Durchsetzung von Verträgen

Wie geht man bei der Vertragsdurchsetzung vor?

Als Teil jeder automatisierten Regressionssuite sollten Sie prüfen, ob die von Ihrem Team geschriebene Servicedefinition Fehler enthält. Swagger und OpenAPI haben eigene Schemas, die definieren, wie die Dienstdefinition geschrieben werden muss. Sie können sie verwenden, um diese Prüfungen früh im API-Entwicklungslebenszyklus zu automatisieren.

Dann möchten Sie neben der Überprüfung des Vertrags selbst überprüfen, ob die Antworten, die Ihr Dienst zurückgibt, auch dem Vertrag entsprechen. Ihr API-Testframework sollte über eine integrierte Unterstützung verfügen, um Instanzen abzufangen, in denen Ihre API eine Antwort zurückgibt, die vom Schema ihrer Dienstdefinition abweicht.

Stellen Sie sich das so vor. Ein Auto besteht aus tausenden Einzelteilen, die alle perfekt zusammenpassen müssen.

Wenn das für die Antriebseinheit verantwortliche Team einen Motor liefert, der von der Designspezifikation abweicht, werden Sie wahrscheinlich große Probleme haben, wenn Sie versuchen, das Getriebe anzuschließen, das ein anderes Team gebaut hat, weil sie sich auf das Design des Motors bezogen haben, um es zu wissen wo die Schrauben ausgerichtet werden müssen.

Das ist es, wonach Sie hier suchen. Dies sind die Arten von Integrationsproblemen, die Sie durch eine gute API-Governance vermeiden können. Das Entwerfen und Einhalten dieser Verträge sollte eines der ersten Anliegen Ihrer API-Testpraxis sein.

Servicedefinitionsverträge können auch dazu beitragen, dass Ihr Testprozess widerstandsfähiger gegenüber Änderungen ist. Die Zeit, die zum Refactoring von Testfällen für die Änderungen in einer API benötigt wird, könnte einen enormen Einfluss auf das Testen haben, sodass es aus dem Sprint herausgeschoben wird.

Dies ist sowohl ein Qualitäts- als auch ein Sicherheitsrisiko. Es bedeutet auch ungeplante Zeit für zusätzliche Tests. Bei der Verwendung eines API-Testframeworks muss es Teams dabei unterstützen, bestehende Testfälle in großen Mengen umzugestalten, wenn sich das Design einer API ändert, damit sie mit dem schnellen Tempo von Agile- und In-Sprint-Tests Schritt halten können. Wartungsverträge und die richtigen Werkzeuge können dies viel weniger schmerzhaft machen.

Implementierungsphase: Best Practices anwenden

Die Entwicklung von Microservices impliziert keine Freikarte zum Überspringen von Komponententests. Code ist Code und Unit-Tests sind eine grundlegende Qualitätspraxis. Es hilft Teams, Regressionen schnell, frühzeitig und auf eine Weise zu erkennen, die für Entwickler einfach zu beheben ist – unabhängig von der Art der Software.

Die hässliche Wahrheit ist, dass Softwareteams mit nicht vorhandenen oder reaktiven Unit-Testing-Praktiken dazu neigen, qualitativ schlechte Ergebnisse zu erzielen. Der Overhead für Unit-Tests wird als zu hoch angesehen und daher priorisieren ihn viele Manager und Führungskräfte nicht.

Dies ist bedauerlich, da der Markt für Tools gereift ist, wo das Leben eines Entwicklers viel einfacher und produktiver ist, während Unit-Tests und der Kompromiss zwischen Kosten und Qualität viel geringer sind als früher. Unit-Tests bilden die Grundlage einer soliden Testpraxis und sollten nicht zu kurz kommen.

Darüber hinaus sind Softwarequalitätspraktiken für Entwickler mit speziellen Codierungsstandards für die API-Entwicklung gereift. Im Jahr 2019 veröffentlichte die internationale gemeinnützige Organisation OWASP die OWASP Top 10 API-Sicherheitsstandard.

Codierungsstandards wie dieser helfen Microservices-Teams dabei, allgemeine Sicherheits- und Zuverlässigkeits-Antimuster zu vermeiden, die ein Geschäftsrisiko für ihre Projekte darstellen könnten. Der Versuch, einen Codierungsstandard ohne Tools zu übernehmen, ist nahezu unmöglich.

Glücklicherweise bleiben moderne statische Analysetools, auch bekannt als Tools für statische Anwendungssicherheitstests (SAST), auf dem neuesten Stand der Industriestandards und werden diesen Standard unterstützen. Entwickler können ihren Code während des Schreibens und als Teil ihres kontinuierlichen Integrationsprozesses scannen, um sicherzustellen, dass nichts übersehen wird.

Komponententestphase: Verwenden Sie Proxys für API-Abhängigkeiten

Das Testen von Komponenten bedeutet, dass Sie Ihren Microservice isoliert testen. Um eine echte Isolation zu erreichen, müssen Sie wissen, was mit den Abhängigkeiten Ihres Microservices zu tun ist. Darüber hinaus ist eines der schwierigsten Dinge, die man als Microservice-Entwickler vorhersehen muss, genau zu verstehen, wie Ihre API von anderen Systemen verwendet wird.

Client-Anwendungen für Ihre API werden wahrscheinlich kreative Verwendungen Ihrer Microservices finden, die nie in Betracht gezogen wurden. Dies ist sowohl ein geschäftlicher Segen als auch ein technischer Fluch und genau deshalb ist es wichtig, Energie aufzuwenden, um die Anwendungsfälle für Ihre API zu verstehen.

API-Governance während der Designphase ist ein wichtiger erster Schritt, aber selbst mit gut definierten Verträgen und automatisierter Schemavalidierung der Antworten Ihres Microservices können Sie nie vollständig vorhersagen, wie sich die Anforderungen des End-to-End-Produkts entwickeln weiterentwickeln und wie sich das auf die Microservices in Ihrer Domäne auswirken wird.

Aufzeichnung, Überwachung und Steuerung helfen Ihnen bei der Implementierung von Testansätzen, die effizient erkennen, welche Tests erforderlich sind, und helfen Ihnen gleichzeitig, Komponententests zu automatisieren, wenn es nachgelagerte APIs gibt, von denen Sie isolieren müssen. Die Enabling-Technologie dazu dient die Service-Virtualisierung.

Die Service-Virtualisierung erweckt alle drei dieser Konzepte durch eine grundlegende Funktion zum Leben: Nachrichten-Proxys. Mithilfe von Nachrichten-Proxys können Sie den Nachrichtenfluss zwischen APIs überwachen und aufzeichnen sowie die Ziele steuern, an die Nachrichten gesendet werden.

Orchestrierte vs. choreografierte Dienste

Orchestrierte und choreografierte (oder reaktive) Dienste sind ausgefallene Begriffe, die synchrone oder asynchrone Nachrichtenmuster beschreiben.

Wenn Ihr Dienst über einen Nachrichtenbroker mit Protokollen wie AMQP, Kafka oder JMS kommuniziert, testen Sie einen choreografierten oder reaktiven Dienst.

Wenn Sie eine REST- oder GraphQL-Schnittstelle testen, handelt es sich um einen orchestrierten oder synchronen Dienst.

Für die Zwecke dieses Beitrags spielt es keine Rolle, mit welchem ​​Protokoll und Nachrichtenaustauschmuster Sie es zu tun haben. Es kann jedoch schwieriger sein, diese Prinzipien mit asynchronem Messaging anzuwenden, wenn Ihr API-Testframework die Protokolle, für die sich Ihre Organisation entschieden hat, nicht unterstützt.

Erfassen Sie Client-Nutzungsszenarien

Für ein Microservice-Team ist es schwierig vorherzusagen, wie andere Teams ihre API verwenden werden. Wir wissen, dass vollintegrierte End-to-End-Tests teuer und langsam sind. Mit den Message-Proxying-Funktionen von Service-Virtualisierungstools können Sie den Datenverkehr von Upstream-Client-Anwendungen aufzeichnen, sodass Sie realistische Nutzungsszenarien erfassen können, die Ihr Wissen darüber, welche Tests in Ihrer CI/CD-Pipeline ausgeführt werden sollten, erheblich verbessern, ohne dass diese Client-Anwendungen dies erfordern immer präsent sein, um diesen Datenverkehr auszulösen.

Mit anderen Worten, die Aufzeichnung ermöglicht es Ihnen, diese Integrationsszenarien für automatisierte Regressionstests abzuspielen, was viel einfacher und einfacher zu verwalten ist, als Kunden zu bitten, ihre Tests auszuführen, die Ihre API transitiv testen. Aus diesem Grund sind Tools, die Servicevirtualisierung mit API-Tests kombinieren, so beliebt. Sie machen es einfach, diesen API-Datenverkehr aufzuzeichnen und ihn dann für Tests von API-Szenarien zu nutzen, die unter Ihre Kontrolle gebracht werden.

Machen Sie Abhängigkeiten überschaubar

Das Testen Ihres Dienstes wird schnell schwierig, da er auf andere APIs in einer Testumgebung angewiesen ist, was Probleme mit der Verfügbarkeit, realistischen Testdaten und der Kapazität mit sich bringt.

Dies kann den Testaufwand aus dem Sprint verdrängen und es für Teams schwierig machen, Integrationsprobleme früh genug zu erkennen, damit sie Zeit haben, sich darum zu kümmern. Dies ist der traditionelle Anwendungsfall für die Service-Virtualisierung, bei dem die Technologie das Simulieren oder Mocken der Antworten nachgelagerter APIs ermöglicht (und dabei eine virtuelle Version des Service erstellt) und eine Isolation bietet, sodass Sie Ihre API früher und einfacher vollständig testen können Ihre CI/CD-Pipeline.

Wenn Nachrichten-Proxys in einer Umgebung bereitgestellt werden, können Teams den API-Datenverkehr aufzeichnen und dann virtuelle Dienste erstellen, die treu und realistisch auf den Microservice reagieren (einschließlich zustandsbehafteter Transaktionen, bei denen die simulierte Abhängigkeit PUT-, POST- und DELETE-Operationen ordnungsgemäß verarbeiten muss), ohne die realen zu haben Abhängigkeit vorhanden.

Stateful Service Virtualization ist ein wichtiges Feature, um den realistischsten virtuellen Service zu erstellen, der alle Ihre Testanwendungsfälle abdeckt.

Integrierte Testphase: Kontrollieren Sie die Testumgebung

Verkleinern wir nun den Testumfang etwas weiter zum Integrationstest. In dieser Phase, die manchmal als Systemintegrationstest oder SIT-Phase bezeichnet wird, ist die Testumgebung eine produktionsähnliche Umgebung, die sicherstellt, dass keine Fehler übersehen werden.

Sie sollten davon ausgehen, dass Nachrichtenproxys die Kontrolle darüber bieten, ob Sie eine isolierte oder eine reale Verbindung zu Abhängigkeiten wünschen. Ein weiterer Aspekt der Kontrolle besteht darin, sicherzustellen, dass die Nachrichten-Proxys einfach über die API verwaltet werden können. Organisationen mit einem hohen Reifegrad in ihren CI/CD-Prozessen automatisieren Bereitstellungs- und Zerstörungs-Workflows, bei denen die programmgesteuerte Steuerung des Nachrichten-Proxys eine unverzichtbare Anforderung ist.

Welche Optimierungen können Sie aus der Sichtbarkeit – oder Beobachtbarkeit – extrahieren, die die Nachrichten-Proxys offenlegen, wenn Sie sich in der Integrationstestphase befinden?

Hier sind Überwachungsfunktionen für eine Servicevirtualisierungslösung, die automatisierte Tests unterstützt, unerlässlich. Die Überwachung von Nachrichten-Proxys legt die inneren Abläufe dieser komplexen Workflows offen, sodass Sie einen besseren Test implementieren können, der Ihnen sagt, wo das Problem liegt, und nicht nur, dass ein Problem besteht.

Stellen Sie sich zum Beispiel ein Auftragsabwicklungssystem vor, das mehrere nachgelagerte Dienste wie Bestands-, Rechnungs- und Versandsysteme überprüfen muss, um eine Bestellung auszuführen. Für eine bestimmte Testeingabe können Sie sich gegen bestimmte Verhaltensweisen hinter den Kulissen behaupten, die Entwicklern helfen, festzustellen, warum ein Test fehlschlägt. Wenn Ihr Team weniger Zeit damit verbringt, herauszufinden, warum ein Problem aufgetreten ist, hat es mehr Zeit, es tatsächlich zu beheben.

Fünf Tipps zum Testen von Microservices

Hier sind fünf Tipps, die Ihnen bei der Entwicklung einer Teststrategie für Microservices helfen. Denken Sie daran, dass dies Vorschläge sind. Wie bei allen Arten von Testplänen müssen Sie die Besonderheiten Ihres Setups berücksichtigen.

1. Betrachten Sie jeden Dienst als ein Softwaremodul. Führen Sie Unit-Tests für einen Dienst durch, wie Sie es für jeden neuen Code tun würden. In einer Microservices-Architektur wird jeder Dienst als Black Box betrachtet. Testen Sie daher jedes auf die gleiche Weise.
2. Bestimmen Sie die grundlegenden Verknüpfungen in der Architektur und testen Sie diese. Wenn beispielsweise ein solider Link zwischen dem Anmeldedienst, dem Frontend, das die Details des Benutzers anzeigt, und der Datenbank für die Details besteht, testen Sie diese Links.
3. Testen Sie nicht nur Happy-Path-Szenarien. Microservices können fehlschlagen und es ist wichtig, Fehlerszenarien zu simulieren, um die Ausfallsicherheit Ihres Systems zu erhöhen.
4. Testen Sie phasenübergreifend. Die Erfahrung hat gezeigt, dass Tester, die eine vielfältige Mischung von Testpraktiken anwenden, beginnend in der Entwicklung bis hin zu größeren Testumfängen, nicht nur die Wahrscheinlichkeit erhöhen, dass Fehler aufgedeckt werden, sondern dies auch effizient tun. Dies gilt insbesondere in komplizierten virtuellen Umgebungen, in denen kleine Unterschiede zwischen verschiedenen Bibliotheken bestehen und in denen die zugrunde liegende Hardwarearchitektur trotz der Visualisierungsschicht zu unvorhergesehenen, unerwünschten Ergebnissen führen kann.
5. Verwenden Sie „Canary Testing“ für neuen Code und testen Sie an echten Benutzern. Stellen Sie sicher, dass der gesamte Code gut instrumentiert ist. Und nutzen Sie auch alle Monitoring-Angebote Ihres Plattformanbieters. Dies trifft auf „Shift-left“-Tests mit „Shift-right“-Tests, da Sie auch „in freier Wildbahn“ testen.

Microservices entmystifizieren

Microservices sind gekommen, um zu bleiben. Leider können Organisationen die Vorteile des Ansatzes nicht nutzen. Es läuft auf die Schwierigkeit hinaus, die Schnittstellen zwischen verteilten Systemen (d. h. die APIs) zu testen, um die erwartete Qualität, Sicherheit und Leistung zu erhalten.

Was benötigt wird, ist ein Ansatz für das Testen von Microservices, der die Erkennung, Erstellung und Automatisierung von Komponententests ermöglicht. Die unterstützenden Technologien sind Nachrichten-Proxys und Service-Virtualisierung, die eng in ein funktionsreiches API-Test-Framework integriert sind.

Nachrichten-Proxys ermöglichen die Aufzeichnung des API-Verkehrs, die Überwachung zur Erkennung von Szenarien und Anwendungsfällen sowie die Steuerung zur Verwaltung und Automatisierung von API-Testreihen. In Verbindung mit der Servicevirtualisierung wird das automatisierte Testen von Microservices zu einer realisierbaren Realität.