Warum Threat Stack Microservices-Tests mithilfe von Containern automatisiert

Auch bei korrekter Konzeption kann das Testen von Microservices eine Herausforderung sein. Wenn sich die Systemarchitektur jedoch soweit entwickelt, dass Dutzende oder Hunderte verbundener Dienste eine Softwareplattform in einer sich ständig verändernden Infrastruktur bilden, wird das Testen des Produkts, für das Sie und Ihr Team verantwortlich sind, zu einer monumentalen, komplexen Aufgabe. Das Schreiben von Testautomatisierungen für diese Umgebungen ist schwierig. Sie möchten daher sicherstellen, dass Sie den größtmöglichen Nutzen aus den Tests ziehen, die Sie schreiben.

Bei Threat Stack schreiben wir Systemintegrationstests, eine Form von Gray-Box-Funktionstests, und wir wählen Docker zum Ausführen der containerisierten Testumgebung.

Was ist falsch an anderen Testarten?

Einige Organisationen verlassen sich immer noch auf das traditionelle Testmodell, bei dem White-Box- und Black-Box-Tests als ausreichende ergänzende Teststrategie angesehen werden. Sie spielen zwar noch immer eine wichtige Rolle bei der Qualifizierung von Software, reichen jedoch nicht mehr aus, um Ihnen das Feedback zu geben, das Sie für die sichere Veröffentlichung von Software benötigen.

In dieser Art von Umgebung ist der Fokus auf Black-Box-Benutzerakzeptanztests zu weit gefasst, und sich darauf zu verlassen, kann schwerwiegende Auswirkungen auf die Time-to-Market-Strategien haben:

• Es bietet keine ausreichende Abdeckung, da in der für die Tests vorgesehenen Zeit zu viele mögliche Szenarios getestet werden müssen.
• Die Ausführung dauert lange Zeit und kann aufgrund von Faktoren, auf die Ihre Anwendung keinen Einfluss hat, häufig zu einer Zeitüberschreitung führen.
• Es muss nach der Bereitstellung des Dienstes und nicht zum Build-Zeitpunkt ausgeführt werden. Dadurch wird das Feedback noch stärker von der Produktentwicklung getrennt. Im Zuge der in der Testentwicklung vorherrschenden Shift-Left-Philosophie wird die Wettbewerbsfähigkeit Ihres Unternehmens eingeschränkt, wenn Sie sich auf diese Tests verlassen.
• Da es sich um Black-Box-Tests handelt, kann die Ermittlung der Fehlerursache eine äußerst schwierige Aufgabe sein.
• Sie lassen sich von Entwicklern nicht einfach schreiben oder pflegen.

Andererseits ist der White-Box-Unit-Test zu eng fokussiert und wird häufig fälschlicherweise eingesetzt, um die Funktionalität von Softwaresystemen zu qualifizieren:

• Das reale Verhalten von Diensten, die mit Komponenten oder anderen Diensten interagieren, wird nicht berücksichtigt.
• Es können bedeutungslose Szenarien getestet werden, deren Wert für die Wartung nicht ausreicht.
• Dies kann für Entwickler sehr aufwändig sein, da sie bei kleinen Codeänderungen ständig große Testsammlungen aktualisieren müssen.
• Es lässt sich für Testingenieure weder einfach schreiben noch pflegen.

Warum den Schwerpunkt auf Systemintegrationstests legen?

Die Testingenieure von Threat Stack verlassen sich zunehmend auf Systemintegrationstests, um alle diese Dienste auf eine Weise zu testen, die die Testabdeckung maximiert und gleichzeitig die Geschwindigkeit und Spezifität bietet, die wir brauchen, um sicherzustellen, dass die Anwendung unter vielen Betriebsbedingungen ordnungsgemäß funktioniert.

Ein Integrationstest ist ein Gray-Box-Test, der sich auf das Verhalten der getesteten Software oder des getesteten Systems bei der Schnittstelle mit externen Komponenten konzentriert. Zum Beispiel:

• Ein Datenspeicher, z. B. PostgreSQL, Cassandra, ElasticSearch
• Ein Message Broker, z.B. Kafka
• Ein HTTP-Server

Mit anderen Worten: Software, mit der Sie interagieren können, um Verhalten zu validieren. Bei Threat Stack führen wir in erster Linie Funktionstests durch, die reale Situationen nachbilden. Die getesteten Verhaltensweisen werden jedoch an den Grenzen der Containerumgebung gestoppt, um unerwünschte externe Interaktionen zu vermeiden.

Und da diese Tests eng mit dem Microservice verknüpft sind, haben Sie den Vorteil, dass Sie Code des zu testenden Services in den automatisierten Tests untersuchen und integrieren können, um durchgängig Bereiche des Codes zu identifizieren, die getestet werden müssen. Darüber hinaus können diese Tests als Benutzerakzeptanztests geschrieben werden, sodass Nicht-Entwickler wie Produktmanager und QA-Ingenieure das getestete Verhalten leichter verstehen können.

Mit anderen Worten:

Gegeben sind einige Bedingungen

Wenn der Dienst diese Eingabe empfängt (ODER dieser Zustand den Dienst beeinflusst)

Dann verhält sich der Dienst wie erwartet und erzeugt die erwarteten Nebenwirkungen.

Diese Funktionstests sind nicht nur leicht zu verstehen und zu schreiben, sie sind auch eng mit dem Code des Microservices verknüpft, sodass sie von Entwicklern während des gesamten Entwicklungsprozesses oder anschließend von dedizierten Testingenieuren problemlos ausgeführt und aktualisiert werden können.

Warum Container verwenden?

Container sind für Testsysteme äußerst nützlich, da Sie damit Ihre Testumgebung für die Dauer der Tests schnell und mit minimalen Ressourcen reproduzieren und nach Abschluss der Tests problemlos bereinigen können. Im Gegensatz zu vielen Black-Box-Testautomatisierungen benötigen Sie für die Durchführung Ihrer Integrationstests keine teure, ständig aktive Testumgebung. Wenn Sie die Tests ausführen, kann das Verhalten des Microservices in der Testumgebung reproduziert werden. 

Sobald Sie eine Containerumgebung definiert haben, die die Produktionsumgebung des Microservices widerspiegelt, wird Ihr Testframework zu den externen Clients oder Mock-Services, die mit den zu testenden Komponenten oder Microservices interagieren. Dadurch wird sichergestellt, dass der Testcode alle Aspekte der Tests steuert, wodurch Sie viele weitere Aspekte des Tests steuern können.

Für den Anfang ist Docker eine gute Plattform, um schnell eine Containerumgebung aufzubauen. Mit Docker Compose können Sie die zu testenden Abschnitte Ihrer Anwendung einfach definieren und ausführen, entweder lokal oder in CI mit demselben Code. Zum Bereitstellen Ihrer Testumgebung können auch andere Tools und Dienste für die Container-Infrastruktur verwendet werden, z. B. Kubernetes , AWS EKS oder AWS Fargate , sofern Ihre Organisation deren Verwendung unterstützt.

Abschluss

Die Entscheidung, den Testaufwand auf Integrationstests statt auf andere Arten der Automatisierung zu konzentrieren, bietet Ihnen letztlich zwei große Vorteile:

• Ihre Microservices-Tests werden nach links verschoben, sodass sie vor der Bereitstellung ausgeführt werden. Dadurch erhalten Sie schnelleres Feedback für die iterative Entwicklung.
• Sie führen weiterhin Tests mit echten Diensten und Komponenten durch. Das heißt, Sie reduzieren Lücken in der Testabdeckung, führen aber dennoch Funktionstests durch.