So führen Sie API-Smoke-Tests in Ihrer Continuous Deployment-Pipeline durch
Jedes Jahr steigen immer mehr Softwareunternehmen auf eine Microservices-Architektur unter Verwendung von Application Programming Interfaces (APIs) um, da APIs es verschiedenen Teams innerhalb eines Projekts einfach machen, gegenseitig auf Ressourcen zuzugreifen. APIs ermöglichen es außerdem, dass Softwareunternehmen oder Einzelpersonen Daten voneinander erhalten: Zum Beispiel stellt Twitter eine API bereit, die von vielen kleinen Unternehmen genutzt wird, um Tweets zu ihrem Geschäft für die Anzeige auf der Unternehmenswebseite abzurufen.
Ein weiterer großer Vorteil von APIs besteht darin, dass sie kleiner als monolithische Anwendungen sind, was bedeutet, dass sie häufiger bereitgestellt werden können. In dem Unternehmen, in dem ich arbeite, hat jedes Team mehrere APIs, und wir haben acht verschiedene Umgebungen, in die wir deployen. Wenn wir uns nur auf manuelle Tests verlassen würden, um zu prüfen, ob die APIs korrekt bereitgestellt wurden, müssten wir acht Testsätze für jede API-Version ausführen. Und wenn wir mehr als eine API gleichzeitig bereitstellen, was häufig vorkommt, da unsere APIs zusammenarbeiten, könnten wir Hunderte von Tests durchlaufen. Und wenn wir alle zwei Wochen deployen, kommt da jede Menge mühsame, sich wiederholende Testarbeit zusammen!
Wir haben dieses Problem gelöst, indem wir automatisierte API-Smoketests eingerichtet haben, die bei jeder Bereitstellung in jeder Umgebung ausgeführt werden. In diesem Artikel beschreibe ich, wie wir entschieden haben, was getestet wird und wie wir unsere Smoketests eingerichtet haben. Wir nutzten Postman, Newman, Powershell und Octopus, um unsere automatisierten Smoketests einzurichten, weshalb ich hier beschreibe, was wir mit diesen Tools getan haben. Diese Strategien können jedoch auf jede Continuous Deployment (CD) Pipeline übertragen werden.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Schritt eins: Entscheiden, was getestet werden soll
Der Hauptzweck von Smoketests ist es, einige einfache, grundlegende Tests durchzuführen, um sicherzustellen, dass die Bereitstellung erfolgreich war. Hier ist nicht der Ort, um jede einzelne Funktionalität Ihrer API zu testen. Bei der Auswahl der Inhalte unserer Smoketests haben wir Folgendes berücksichtigt:
- Wir haben für jeden Endpunkt einen „Happy Path“-Test eingerichtet – also einen Test, bei dem ein erfolgreicher Ablauf erwartet wird. Beispielsweise sollte eine GET-Anfrage für eine Ressource mit einer bestimmten ID diese Ressource zurückgeben. Sie sollten jeden Endpunkt mindestens einmal testen, um sicherzustellen, dass er wie erwartet funktioniert.
- Falls es größere Variationen in der Nutzung eines bestimmten Endpunkts gab, haben wir ein oder mehrere Tests hinzugefügt, um diese Varianten zu prüfen. Beispielsweise haben wir eine Dateiabfrage-API, bei der eine Datei auf zwei verschiedene Arten abgerufen werden kann. Der Endpunkt sieht gleich aus, aber die Requests unterscheiden sich im Aufbau. Daher haben wir für jede Methode einen eigenen Test hinzugefügt.
- Für Endpunkte, die ein bestimmtes Sicherheitsniveau erfordern, haben wir einen Test hinzugefügt, um zu prüfen, dass eine Anfrage ohne entsprechende Authentifizierung KEINE Informationen zurückliefert, sondern stattdessen einen Fehler im 400er-Bereich ausgibt.
- Wir haben keine weiteren negativen Tests, wie etwa einen POST-Request mit ungültigen Daten, aufgenommen, da wir diese nicht für notwendig hielten, um den korrekten Betrieb der API sicherzustellen. Diese Tests werden stattdessen als Teil einer nächtlichen Regressionstest-Suite durchgeführt.
Schritt zwei: Exportieren Sie Ihre Tests
Wir haben Postman verwendet, um unsere API-Tests zu erstellen. Nach der Erstellung der Tests haben wir sowohl die Testsammlung als auch die Testumgebungsdatei als JSON-Dateien exportiert. Für diejenigen, die Postman nicht kennen: Eine Testumgebung ist eine Gruppe von Variablen, auf die in einer Testsammlung Bezug genommen werden kann.
Schritt drei: Schreiben Sie ein Skript zum Ausführen Ihrer Tests
Postman hat mit Newman ein Kommandozeilen-Tool, mit dem eine Testsuite ausgeführt werden kann. Dieses Tool nutzen wir, um unsere Tests laufen zu lassen. Wir haben ein Powershell-Skript geschrieben, das den Newman-Befehl ausführt.
Schritt vier: Erstellen Sie einen Deployment-Schritt, der Ihr Skript aufruft
Sobald das Powershell-Skript fertig war, haben wir in jedem Octopus-API-Deployment-Projekt einen Deployment-Schritt eingerichtet, der das Testskript ausführt. Falls das Skript fehlschlug, schlug auch die Bereitstellung fehl.
Schritt fünf: Organisieren Sie Ihre Variablen
Variablen sind bei der Ausführung von Smoketests in unterschiedlichen Umgebungen oft ein wichtiger Aspekt. Beispiel: In Ihrer QA-Umgebung könnte der Testnutzer die ID 340 haben, in der Staging-Umgebung jedoch die ID 620. Ein weiteres Problem mit Variablen ist, dass Sie aus Sicherheitsgründen manchmal in Produktionsumgebungen keinen Zugang zu Passwörtern oder Schlüsseln haben. Das galt auch für unser Team; zum Glück liegen die für Production benötigten Werte in Octopus vor, sodass wir das Problem lösen konnten, indem Octopus die nötigen Werte an unser Testskript übergibt.
Drei verschiedene Arten von Variablen waren für unseren Smoketest nötig:
- Typ 1: Variablen, die für jede Testumgebung gleichbleibend waren, etwa „firstName“: „Prunella“. Diese Variablen konnten direkt in die Postman-Umgebung aufgenommen werden, sodass mit ihnen nichts Weiteres getan werden musste.
- Typ 2: Variablen, die sich je nach Testumgebung änderten, aber nicht besonders geschützt werden mussten, etwa „userId“: 340. Diese Variablen wurden als Octopus-Variablen wie folgt hinzugefügt: „smoke.userId“, und der Wert wurde je nach Umgebung gesetzt; für QA zum Beispiel auf 340, für Staging auf 620 und für Produktion auf 450.
- Typ 3: Variablen, die sich für jede Testumgebung änderten und sicher aufbewahrt werden mussten, wie zum Beispiel „apiKey“: „b20628a9-3c00-4dad-b38c-0a4d2d85ffab“. Typ 3 Variablen waren bereits in der Octopus-Variablenbibliothek festgelegt.
Wir haben die Variablen dann wie folgt verwendet:
- Als wir das Powershell-Skript in Octopus aufgerufen haben, haben wir die in Octopus gesetzten Variablen an das Skript übergeben.
- Im Powershell-Skript haben wir die übergebenen Octopus-Variablen entgegengenommen und diesen Powershell-Variablen zugewiesen.
- Als wir den Newman-Befehl im Powershell-Skript ausgeführt haben, haben wir die Variablen im Skript an die Postman-Umgebung übergeben.
- Newman hat die übergebenen Variablen aus dem Powershell-Skript zusammen mit den Variablen in der Postman-Umgebung verwendet, um die Postman-Collection auszuführen.
Da unsere API-Smoke-Tests für jede API und in jeder Umgebung in Octopus ausgeführt werden, können wir sicher sein, dass größere Probleme bei einer API-Bereitstellung sofort erkannt werden. Außerdem können wir in Produktionsumgebungen testen, selbst wenn wir keinen Zugriff auf sensible API-Schlüssel haben. Automatisierte Bereitstellungs-Smoke-Tests verschaffen uns Freiraum, um andere Arten von Tests durchzuführen, wie manuelle explorative Tests und Sicherheitstests, sowie um weitere Testautomatisierungen für nächtliche Regressionen zu erstellen.
Für weitere Anleitungen abonnieren Sie den QA Lead Newsletter.
Bleiben Sie neugierig und hören Sie sich diesen Podcast an: WIE OPEN-SOURCE-SOFTWARE DIE INTEGRATION IN DER AUTOMATISIERUNGSTECHNIK VEREINFACHT (MIT JAMES WALKER UND SANJAY KUMAR)
