Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Wie man Serverless-Funktionen und Anwendungen testet

Beim Testen serverloser Funktionen werden traditionelle Testtypen und -techniken verwendet. Sie müssen jedoch auch das Testen serverloser Anwendungen als Ganzes in Betracht ziehen. Cloud-based Tests bieten das genaueste Maß für die Qualität Ihrer Funktionen und serverloser Anwendungen.

Eine Serverless-Anwendungsarchitektur umfasst verwaltete Services, die über API-Aufrufe wichtige Anwendungsfunktionen bereitstellen. Aus diesem Grund muss Ihr Entwicklungszyklus automatisierte Tests beinhalten, die bei der Interaktion Ihrer Funktionen und Services die Funktionalität überprüfen.

Wenn Sie keine cloud-basierten Tests erstellen, können aufgrund von Unterschieden zwischen Ihrer lokalen Umgebung und der bereitgestellten Umgebung Probleme auftreten. Ihr kontinuierlicher Integrationsprozess muss Tests anhand einer Reihe von Ressourcen durchführen, die in der Cloud bereitgestellt werden, bevor Ihr Code in die nächste Bereitstellungsumgebung wie QA, Staging oder Produktion übertragen wird.

Lesen Sie diesen kurzen Leitfaden weiter, um weitere Informationen zu Teststrategien für Serverless-Anwendungen zu erhalten, oder besuchen Sie das Serverless Test Samples Repository, um praktische Beispiele zu finden, die sich speziell auf die gewählte Sprache und Laufzeit beziehen.

Für serverlose Tests schreiben Sie immer noch Unit-, Integrations - und End-to-End-Tests.

Gezielte Geschäftsergebnisse

Das Testen serverloser Lösungen kann mehr Zeit in Anspruch nehmen, um eingerichtet zu werden. Sie müssen ereignisgesteuerte Interaktionen zwischen Diensten überprüfen. Beachten Sie beim Lesen dieses Handbuchs die folgenden praktischen Geschäftsgründe:

Die Qualität einer Anwendung hängt davon ab, ob viele Szenarien getestet werden. Berücksichtigen Sie Ihre Geschäftsszenarien und automatisieren Sie Tests, um sie mit Cloud-Diensten auszuführen. Dies erhöht die Qualität Ihrer Anwendung.

Bugs und Konfigurationsprobleme kosten weniger, wenn sie früh im Entwicklungszyklus erkannt werden. Probleme, die bis zur Produktion unentdeckt bleiben, erfordern mehr Aufwand und mehr Mitarbeiter, um sie zu beheben.

Eine gute serverlose Teststrategie verbessert die Softwarequalität und beschleunigt Iterationen. Sie überprüft, ob Ihre Lambda-Funktionen und -Anwendungen in der Cloud erwartungsgemäß funktionieren.

Was muss getestet werden?

Wir empfehlen eine Teststrategie, die das Verhalten der verwalteten Dienste, die Cloud-Konfiguration, die Sicherheitsrichtlinien und die Integration mit Ihrem Code testet. Verhaltenstests, auch bekannt als Blackbox-Tests, überprüfen, ob ein System erwartungsgemäß funktioniert, ohne die internen Aspekte zu kennen.

In der traditionellen serverbasierten Architektur testen Teams oft nur den Code, der auf dem Anwendungsserver ausgeführt wird. Sie betrachten andere Komponenten, Dienste oder Abhängigkeiten als extern und außerhalb des Geltungsbereichs.

Serverlose Anwendungen bestehen aus kleinen Arbeitseinheiten. Beispiele hierfür sind Lambda-Funktionen, die Produkte aus einer Datenbank abrufen, Elemente aus einer Warteschlange verarbeiten oder die Größe eines Bilds im Speicher ändern. Jede Komponente wird in ihrer eigenen Umgebung ausgeführt. Teams verwalten viele dieser kleinen Einheiten in einer einzigen Anwendung.

Einige Funktionen können vollständig von verwalteten Diensten wie Amazon S3 übernommen oder ohne benutzerdefinierten Code erstellt werden. Sie müssen diese verwalteten Dienste nicht testen. Sie müssen jedoch testen, wie Ihr Code in sie integriert wird.

So wird Serverless getestet

Sie wissen wahrscheinlich, wie lokal bereitgestellte Anwendungen getestet werden. Sie schreiben Tests gegen Code auf Ihrem Desktop oder in Containern. Beispielsweise könnten Sie einen lokalen Webservice aufrufen und dann die Antwort überprüfen.

Serverlose Lösungen verwenden Ihren Funktionscode und cloudbasierte verwaltete Dienste wie Warteschlangen, Datenbanken, Eventbusse und Messaging-Systeme. Diese Komponenten sind über eine ereignisgesteuerte Architektur miteinander verbunden, in der Nachrichten, sogenannte Ereignisse, von einer Ressource zur anderen übertragen werden. Einige Interaktionen sind synchron, z. B. ein Webservice, der sofort Ergebnisse zurückgibt.

Andere sind asynchron, z. B. das Platzieren von Elementen in eine Warteschlange oder das Starten eines Workflow-Schritts. Ihre Teststrategie muss beide Typen abdecken und die Interaktionen zwischen Diensten testen. Bei asynchronen Interaktionen müssen Sie möglicherweise Nebenwirkungen in nachgelagerten Komponenten erkennen, die nicht sofort sichtbar sind.

Sie können eine Cloud-Umgebung nicht vollständig lokal replizieren. Dazu gehören Warteschlangen, Datenbanktabellen, Eventbusse und Sicherheitsrichtlinien. Unterschiede zwischen lokalen und Cloud-Umgebungen verursachen Probleme. Diese Unterschiede verlängern die Zeit, um Fehler zu reproduzieren und zu beheben.

In serverlosen Anwendungen befinden sich die Komponenten vollständig in der Cloud. Tests mit Cloud-Code und -Diensten sind erforderlich, um Funktionen zu entwickeln und Fehler zu beheben.

Testmethoden

Ihre Teststrategie beinhaltet wahrscheinlich eine Mischung aus Techniken. Sie verwenden schnelle interaktive Tests, um Funktionen in der Konsole zu debuggen. Sie schreiben automatisierte Komponententests, um die Geschäftslogik zu überprüfen. Sie verifizieren Anrufe an externe Dienste mit Mocks. Sie können auch mit Emulatoren testen, die einen Dienst nachahmen.

Testen in der Cloud

Das Testen in der Cloud ist für alle Testphasen wertvoll: Komponententests, Integrationstests und End-to-End-Tests. Tests, die mit cloudbasiertem Code und Diensten ausgeführt werden, bieten das genaueste Maß für Ihre Codequalität.

Eine einfache Möglichkeit, eine Lambda-Funktion in der Cloud auszuführen, ist ein Testereignis in der AWS-Managementkonsole. Ein Testereignis ist eine JSON-Eingabe für Ihre Funktion. Wenn Ihre Funktion keine Eingabe benötigt, kann das Ereignis ein leeres JSON-Dokument ({}) sein. Die Konsole bietet Beispielereignisse für viele Serviceintegrationen. Sie können Ereignisse mit Ihrem Team teilen, um das Testen zu vereinfachen.

Erfahren Sie, wie Sie eine Beispielfunktion in der Konsole debuggen.

Beispiele für die Testautomatisierung sind im Serverless Test Samples Repository verfügbar. Mit der folgenden Befehlszeile wird ein Beispiel für einen Python-Integrationstest automatisch ausgeführt:

python -m pytest -s tests/integration -v

Obwohl der Test lokal ausgeführt wird, spricht er mit cloudbasierten Ressourcen. Diese Ressourcen wurden mithilfe des AWS SAM Befehlszeilentools AWS Serverless Application Model und bereitgestellt. Der Testcode ruft zuerst die bereitgestellten Stack-Ausgaben ab, z. B. den API-Endpunkt, den Funktions-ARN und die Sicherheitsrolle.

Anschließend sendet er eine Anfrage an den API-Endpunkt. Die Antwort enthält eine Liste von Amazon S3-Buckets. Dieser Test wird mit Cloud-basierten Ressourcen durchgeführt, um sicherzustellen, dass sie bereitgestellt, gesichert und funktionsfähig sind.

========================= test session starts =========================
      platform darwin -- Python 3.10.10, pytest-7.3.1, pluggy-1.0.0
      -- /Users/t/code/aws/serverless-test-samples/python-test-samples/apigw-lambda/venv/bin/python
      cachedir: .pytest_cache
      rootdir: /Users/t/code/aws/serverless-test-samples/python-test-samples/apigw-lambda
      plugins: mock-3.10.0
      collected 1 item                                                                                                        

      tests/integration/test_api_gateway.py::TestApiGateway::test_api_gateway 

      --> Stack outputs:

        HelloWorldApi
        = https://p7teqs3162.execute-api.us-east-2.amazonaws.com/Prod/hello/
        > API Gateway endpoint URL for Prod stage for Hello World function

        PythonTestDemo
        = arn:aws:lambda:us-east-2:123456789012:function:testing-apigw-lambda-PythonTestDemo-iSij8evaTdxl
        > Hello World Lambda Function ARN

        PythonTestDemoIamRole
        = arn:aws:iam::123456789012:role/testing-apigw-lambda-PythonTestDemoRole-IZELQQ9MG4HQ
        > Implicit IAM Role created for Hello World function

      --> Found API endpoint for "testing-apigw-lambda" stack...
      --> https://p7teqs3162.execute-api.us-east-2.amazonaws.com/Prod/hello/
      API Gateway response:
      amplify-dev-123456789-deployment|myapp-prod-p-loggingbucket-123456|s3-java-bucket-123456789
      PASSED

      ========================= 1 passed in 1.53s ========================= 
      

Für die Entwicklung cloudnativer Anwendungen bietet das Testen in der Cloud die folgenden Vorteile:

Das Testen in der Cloud hat einige Nachteile. Cloud-Bereitstellungen dauern in der Regel länger als lokale Desktop-Bereitstellungen.

Tools wie AWS Serverless Application Model (AWS SAM) Accelerate, AWS Cloud Development Kit (AWS CDK) Watch-Modus und SST (Drittanbieter) reduzieren diese Latenz. Diese Tools überwachen Ihre Infrastruktur und Ihren Code und stellen dann automatisch Updates für Ihre Cloud-Umgebung bereit.

Im Gegensatz zu lokalen Tests werden beim Cloud-Testen Ressourcen verwendet, die Kosten verursachen können. Isolierte Testumgebungen können für Ihre DevOps Teams zusätzliche Arbeit bedeuten, insbesondere in Organisationen mit strengen Kontokontrollen. Trotzdem kann die Zeit, die Entwickler für die Einrichtung einer komplexen lokalen Umgebung benötigen, mehr kosten als die Verwendung von Cloud-Einwegumgebungen, die mit Infrastructure as Code-Tools erstellt wurden.

Tests in der Cloud sind trotz dieser Überlegungen immer noch der beste Weg, um die Qualität Ihrer Serverless-Lösungen zu gewährleisten.

Testen mit Mocks

Das Testen mit Mocks ist eine Technik, bei der Sie Ersatzobjekte in Ihrem Code erstellen, um das Verhalten eines Cloud-Services zu simulieren.

Sie könnten beispielsweise einen Test schreiben, der ein Modell des Amazon S3-Dienstes verwendet. Der Mock gibt bei jedem Aufruf der CreateObject Methode eine festgelegte Antwort zurück. Es ruft weder Amazon S3 noch andere Service-Endpunkte auf.

Mock-Frameworks generieren häufig Scheinobjekte für Sie. Einige Frameworks sind generisch. Andere zielen auf AWS SDKs ab, wie Moto, eine Python-Bibliothek für Mocking-Dienste AWS .

Scheinobjekte unterscheiden sich von Emulatoren. Entwickler erstellen Mocks als Teil des Testcodes. Emulatoren sind eigenständige Anwendungen, die dieselbe Funktionalität bieten wie die Systeme, die sie nachahmen.

Die Verwendung von Mocks bietet folgende Vorteile:

Mock-Tests haben die folgenden Nachteile:

Lokales Testen mit   AWS SAM CLI

Verwenden Sie AWS SAM CLI für das Testen Ihrer Funktionen in Docker-Containern mit derselben Laufzeitumgebung wie AWS Lambda. Sie können die Funktionslogik und die Ereignisverarbeitung lokal testen, ohne sie in der Cloud bereitstellen zu müssen. Wenn Ihre Funktion API-Aufrufe an andere sendet AWS-Services, erreichen diese Aufrufe echte AWS Ressourcen.

Tests mit lokalen Containern bieten unter anderem folgende Vorteile:

Das Testen mit lokalen Containern hat folgende Einschränkungen:

Testen mit Emulation

Emulatoren sind lokal ausgeführte Anwendungen, die AWS Dienste nachahmen, indem sie ähnliche APIs und Rückgabewerte bereitstellen. LocalStack ist ein beliebtes Emulationstool, das eine vollständige lokale Entwicklungsumgebung zum Testen von Serviceintegrationen bietet.

LocalStack ist ein AWS Cloud-Emulator, mit dem Sie serverlose Anwendungen lokal testen können. Sie können Lambda-Funktionen testen, die in Dienste wie DynamoDB, Amazon S3 und Amazon SQS integriert werden können, ohne eine Verbindung zu den tatsächlichen Diensten herzustellen. AWS Sie können es LocalStack im AWS Toolkit für VS Code verwenden.

Tests mit Emulatoren bieten unter anderem folgende Vorteile:

Das Testen mit Emulatoren hat folgende Nachteile:

Bewährte Methoden

Die folgenden Abschnitte enthalten Empfehlungen für erfolgreiche Tests für Serverless-Anwendungen.

Praktische Beispiele für Tests und Testautomatisierung finden Sie im Serverless Test Samples Repository.

Priorisieren Sie Tests in der Cloud

Tests in der Cloud bieten die zuverlässigste, genaueste und vollständigste Testabdeckung. Bei der Durchführung von Tests im Cloud-Kontext werden nicht nur die Geschäftslogik, sondern auch Sicherheitsrichtlinien, Dienstkonfigurationen, Kontingente und die aktuellsten API-Signaturen und Rückgabewerte umfassend getestet.

Strukturieren Sie Ihren Code zum Testen

Vereinfachen Sie Ihre Tests und Lambda-Funktionen, indem Sie den Lambda-specific Code von Ihrer Kerngeschäftslogik trennen.

Ihr Lambda-Funktions-Handler sollte ein schlanker Adapter sein, der Ereignisdaten aufnimmt und nur die Details an Ihre Geschäftslogikmethode(n) weiterleitet. Mit dieser Strategie können Sie umfassende Tests rund um Ihre Geschäftslogik durchführen, ohne sich Gedanken über Lambda-specific Details machen zu müssen. Für Ihre AWS Lambda-Funktionen sollten Sie keine komplexe Umgebung oder eine große Anzahl von Abhängigkeiten einrichten müssen, um die zu testende Komponente zu erstellen und zu initialisieren.

Im Allgemeinen sollten Sie einen Handler schreiben, der Daten aus den eingehenden Ereignis- und Kontext-Objekten extrahiert und validiert und diese Eingabe dann an Methoden sendet, die Ihre Geschäftslogik ausführen.

Entwicklungs-Feedback-Schleifen beschleunigen

Es gibt Tools und Techniken, um die Entwicklungs-Feedback-Schleifen zu beschleunigen. AWS SAM Accelerate und AWS CDK Watch Mode reduzieren beispielsweise beide die Zeit, die für die Aktualisierung von Cloud-Umgebungen benötigt wird.

Die Beispiele im GitHub Serverless Test Samples-Repository untersuchen einige dieser Techniken.

Wir empfehlen außerdem, dass Sie Cloud-Ressourcen so früh wie möglich während der Entwicklung erstellen und testen — nicht erst, nachdem Sie sich bei der Quellverwaltung angemeldet haben. Diese Praxis ermöglicht ein schnelleres Erkunden und Experimentieren bei der Entwicklung von Lösungen. Darüber hinaus hilft Ihnen die Automatisierung der Bereitstellung von einem Entwicklungscomputer aus dabei, Probleme mit der Cloud-Konfiguration schneller zu erkennen und unnötigen Aufwand für Updates und Code-Review-Prozesse zu reduzieren.

Fokus auf Integrationstests

Beim Erstellen von Anwendungen mit Lambda hat es sich bewährt, Komponenten gemeinsam zu testen.

Tests, die mit zwei oder mehr Architekturkomponenten ausgeführt werden, werden als Integrationstests bezeichnet. Das Ziel von Integrationstests besteht darin, nicht nur zu verstehen, wie Ihr Code komponentenübergreifend ausgeführt wird, sondern auch, wie sich die Umgebung, in der Ihr Code gehostet wird, verhält. End-to-end Tests sind spezielle Arten von Integrationstests, mit denen das Verhalten einer gesamten Anwendung überprüft wird.

Um Integrationstests zu erstellen, stellen Sie Ihre Anwendung in einer Cloud-Umgebung bereit. Dies kann in einer lokalen Umgebung oder über eine CI/CD Pipeline erfolgen. Schreiben Sie dann Tests, um das zu testende System (SUT) zu testen und das erwartete Verhalten zu validieren.

Das zu testende System könnte beispielsweise eine Anwendung sein, die API Gateway, Lambda und DynamoDB verwendet. Ein Test könnte einen synthetischen HTTP-Aufruf an einen API-Gateway-Endpunkt ausführen und überprüfen, ob die Antwort die erwartete Nutzlast enthielt. Dieser Test bestätigt, dass der AWS Lambda-Code korrekt ist und dass jeder Dienst korrekt für die Bearbeitung der Anfrage konfiguriert ist, einschließlich der IAM-Berechtigungen zwischen ihnen. Darüber hinaus könnten Sie den Test so gestalten, dass Datensätze unterschiedlicher Größe geschrieben werden, um zu überprüfen, ob Ihre Service-Kontingente, wie z. B. die maximale Datensatzgröße in DynamoDB, korrekt eingerichtet sind.

Erstellen Sie isolierte Testumgebungen

Tests in der Cloud erfordern in der Regel isolierte Entwicklerumgebungen, sodass sich Tests, Daten und Ereignisse nicht überschneiden.

Ein Ansatz besteht darin, jedem Entwickler ein eigenes Konto zur Verfügung zu stellen. AWS Dadurch werden Konflikte mit der Benennung von Ressourcen vermieden, die auftreten können, wenn mehrere Entwickler in einer gemeinsamen Codebasis arbeiten, versuchen, Ressourcen bereitzustellen oder eine API aufzurufen.

Automatisierte Testprozesse sollten für jeden Stapel eindeutig benannte Ressourcen erstellen. Sie können beispielsweise Skripts oder TOML-Konfigurationsdateien so einrichten, dass die Befehle AWS SAM CLI sam deploy oder sam sync automatisch einen Stack mit einem eindeutigen Präfix angeben.

In einigen Fällen teilen sich Entwickler ein AWS Konto. Dies kann daran liegen, dass Sie Ressourcen in Ihrem Stack haben, deren Betrieb oder Bereitstellung und Konfiguration teuer sind. Beispielsweise kann eine Datenbank gemeinsam genutzt werden, um die Einrichtung und das richtige Seeding der Daten zu vereinfachen

Wenn Entwickler ein Konto gemeinsam nutzen, müssen Sie Grenzen festlegen, um die Inhaberschaft zu ermitteln und Überschneidungen zu vermeiden. Eine Möglichkeit, dies zu tun, besteht darin, den Stack-Namen die Benutzer-IDs der Entwickler voranzustellen. Ein weiterer beliebter Ansatz ist das Einrichten von Stacks, die auf Code-Branches basieren. Aufgrund der Filialgrenzen sind die Umgebungen isoliert, aber Entwickler können dennoch Ressourcen gemeinsam nutzen, z. B. eine relationale Datenbank. Dieser Ansatz ist eine bewährte Methode, wenn Entwickler an mehr als einer Verzweigung gleichzeitig arbeiten.

Das Testen in der Cloud ist für alle Testphasen von Nutzen, einschließlich Einheitentests, Integrationstests und End-to-End-Tests. Das Aufrechterhalten einer ordnungsgemäßen Isolierung ist von entscheidender Bedeutung. Dennoch sollten Sie darauf achten, dass Ihre QA-Umgebung der Produktionsumgebung so nahe wie möglich kommt. Aus diesem Grund fügen Teams den QA-Umgebungen Änderungssteuerungsvorgänge hinzu.

In Vorproduktions- und Produktionsumgebungen werden die Grenzen in der Regel auf Kontoebene gezogen, um Arbeitslasten von „Noisy-Neighbor“-Problemen zu isolieren und Sicherheitskontrollen mit geringsten Berechtigungen zum Schutz sensibler Daten zu implementieren. Für Workloads gibt es Kontingente. Ihre Tests dürfen weder die für die Produktion zugewiesenen Kontingente verbrauchen („Noisy Neighbor“) noch Zugriff auf Kundendaten haben. Lasttests sind eine weitere Aktivität, die Sie von Ihrem Produktions-Stack isolieren sollten.

In jedem Fall müssen die Umgebungen mit Warnungen und Kontrollen konfiguriert werden, um unnötige Ausgaben zu vermeiden. Sie können beispielsweise die Art, Stufe oder Größe der Ressourcen einschränken, die erstellt werden können, und E-Mail-Benachrichtigungen einrichten, wenn die geschätzten Kosten einen bestimmten Schwellenwert überschreiten.

Mocks für isolierte Geschäftslogik verwenden

Mock-Frameworks sind ein wertvolles Tool zum Schreiben schneller Einheitentests. Sie sind besonders nützlich, wenn Tests komplexe interne Geschäftslogiken wie mathematische oder finanzielle Berechnungen oder Simulationen abdecken. Suchen Sie nach Einheitentests, die eine große Anzahl von Testfällen oder Eingabevariationen enthalten, bei denen diese Eingaben das Muster oder den Inhalt von Aufrufen an andere Cloud-Services nicht ändern.

Code, der durch Komponententests mit Mocks abgedeckt wird, muss auch durch Tests in der Cloud abgedeckt werden. Dies wird empfohlen, da ein Entwickler-Laptop oder eine Build-Machine-Umgebung anders konfiguriert werden kann als eine Produktionsumgebung in der Cloud. Beispielsweise beanspruchen Ihre Lambda-Funktionen möglicherweise mehr Speicher oder Zeit als zugewiesen, wenn sie mit bestimmten Eingabeparametern ausgeführt werden. Möglicherweise enthält Ihr Code auch Umgebungsvariablen, die nicht auf die gleiche Weise (oder überhaupt nicht) konfiguriert sind, und die Unterschiede könnten dazu führen, dass sich der Code anders verhält oder fehlschlägt.

Bei Integrationstests ist der Nutzen von Mocks geringer, da der Aufwand zur Implementierung der erforderlichen Mocks mit der Anzahl der Verbindungspunkte zunimmt. End-to-end Beim Testen sollten keine Mocks verwendet werden, da sich diese Tests im Allgemeinen mit Zuständen und komplexer Logik befassen, die mit Mock-Frameworks nicht einfach simuliert werden können.

Vermeiden Sie schließlich die Verwendung von nachgebildeten Cloud-Services, um die ordnungsgemäße Implementierung von Service-Aufrufen zu überprüfen. Führen Sie stattdessen Cloud-Service-Aufrufe in der Cloud durch, um Verhalten, Konfiguration und funktionale Implementierung zu überprüfen.

Emulatoren sparsam verwenden

Emulatoren können für einige Anwendungsfälle praktisch sein, z. B. für ein Entwicklungsteam mit begrenztem, unzuverlässigem oder langsamem Internetzugang. In den meisten Fällen sollten Sie Emulatoren jedoch sparsam verwenden.

Indem Sie Emulatoren vermeiden, können Sie mit den neuesten Servicefunktionen und aktuellen APIs entwickeln und innovieren. Sie müssen nicht auf Versionen von Anbietern warten, um die gleiche Funktionalität zu erreichen. Sie reduzieren Ihre Vorabkosten und Ihre laufenden Ausgaben für den Kauf und die Konfiguration auf mehreren Entwicklungssystemen und Baucomputern. Darüber hinaus vermeiden Sie das Problem, dass für viele Cloud-Dienste einfach keine Emulatoren verfügbar sind. Eine Teststrategie, die auf Emulation basiert, macht es unmöglich, diese Dienste zu nutzen (was zu potenziell teureren Problemumgehungen führt) oder Code und Konfigurationen zu erstellen, die nicht gut getestet wurden.

Wenn Sie die Emulation zum Testen verwenden, müssen Sie dennoch in der Cloud testen, um die Konfiguration zu überprüfen und Interaktionen mit Cloud-Diensten zu testen, die in einer emulierten Umgebung nur simuliert oder nachgeahmt werden können.

Herausforderungen beim Testen vor Ort

Wenn Sie Emulatoren und simulierte Aufrufe zum Testen auf Ihrem lokalen Desktop verwenden, kann es bei der Entwicklung Ihres Codes von Umgebung zu Umgebung in Ihrer Pipeline zu Testinkonsistenzen kommen. CI/CD Bei Komponententests zur Validierung der Geschäftslogik Ihrer Anwendung auf Ihrem Desktop werden wichtige Aspekte der Cloud-Dienste möglicherweise nicht genau getestet.

Die folgenden Beispiele zeigen, worauf beim lokalen Testen mit Mocks und Emulatoren zu achten ist:

Beispiel: Die Lambda-Funktion erstellt einen S3-Bucket

Wenn die Logik einer Lambda-Funktion von der Erstellung eines S3-Buckets abhängt, sollte ein vollständiger Test bestätigen, dass Amazon S3 aufgerufen und der Bucket erfolgreich erstellt wurde.

Die Mock- und Emulations-Setups testen, was die Lambda-Funktion tut, wenn sie Amazon S3 aufruft. Diese Tests überprüfen jedoch nicht, ob die Lambda-Funktion in der Lage ist, den Amazon S3-Bucket erfolgreich zu erstellen. Sie müssen sicherstellen, dass der Rolle, die der Funktion zugewiesen ist, eine Sicherheitsrichtlinie angehängt ist, die es der Funktion ermöglicht, die s3:CreateBucket-Aktion auszuführen. Andernfalls schlägt die Funktion wahrscheinlich fehl, wenn sie in einer Cloud-Umgebung bereitgestellt wird.

Beispiel: Verwenden Sie eine Lambda-Funktion, um Nachrichten aus einer Amazon-SQS-Warteschlange zu verarbeiten.

Wenn eine Amazon-SQS-Warteschlange die Quelle einer Lambda-Funktion ist, muss durch einen vollständigen Test überprüft werden, ob die Lambda-Funktion erfolgreich aufgerufen wird, wenn eine Nachricht in eine Warteschlange gestellt wird.

Emulationstests und Scheintests sind in der Regel so eingerichtet, dass der Lambda-Funktionscode direkt ausgeführt und die Amazon SQS-Integration simuliert wird, indem eine JSON-Event-Nutzlast (oder ein deserialisiertes Objekt) als Eingabe für den Funktionshandler übergeben wird.

Lokale Tests, die die Amazon SQS-Integration simulieren, testen, was die Lambda-Funktion tut, wenn sie von Amazon SQS mit einer bestimmten Nutzlast aufgerufen wird. Der Test überprüft jedoch nicht, ob Amazon SQS die Lambda-Funktion erfolgreich aufruft, wenn sie in einer Cloud-Umgebung bereitgestellt wird.

Einige Beispiele für Konfigurationsprobleme, die bei Amazon SQS und Lambda auftreten können, sind die folgenden:

Wie diese Beispiele zeigen, liefern Tests, die sich mit der Geschäftslogik, aber nicht mit den Konfigurationen zwischen Cloud-Services befassen, wahrscheinlich zu unzuverlässigen Ergebnissen.

Häufig gestellte Fragen

Ich habe eine Lambda-Funktion, die Berechnungen durchführt und ein Ergebnis zurückgibt, ohne andere Dienste aufzurufen. Muss ich es wirklich in der Cloud testen?

Ja. Lambda-Funktionen haben Konfigurationsparameter, die das Testergebnis verändern könnten. Der gesamte Lambda-Funktionscode ist von Timeout- und Speichereinstellungen abhängig, was dazu führen kann, dass die Funktion fehlschlägt, wenn diese Einstellungen nicht richtig gesetzt sind.

Lambda-Richtlinien ermöglichen auch die standardmäßige Protokollierung der Ausgabe bei Amazon. CloudWatch Auch wenn Ihr Code nicht CloudWatch direkt aufgerufen wird, ist eine Genehmigung erforderlich, um die Protokollierung zu aktivieren. Diese erforderliche Erlaubnis kann nicht korrekt verspottet oder nachgeahmt werden.

Wie können Tests in der Cloud beim Einheitentest helfen? Wenn es sich in der Cloud befindet und eine Verbindung zu anderen Ressourcen herstellt, ist das nicht ein Integrationstest?

Wir definieren Komponententests als Tests, die isoliert auf Architekturkomponenten ausgeführt werden. Dies verhindert jedoch nicht, dass Tests Komponenten einbeziehen, die möglicherweise andere Dienste aufrufen oder eine gewisse Netzwerkkommunikation verwenden.

Viele Serverless-Anwendungen verfügen über Architekturkomponenten, die isoliert getestet werden können, sogar in der Cloud. Ein Beispiel ist eine Lambda-Funktion, um Eingaben entgegenzunehmen, die Daten zu verarbeiten und eine Nachricht an eine Amazon-SQS-Warteschlange zu senden. Ein Komponententest dieser Funktion würde wahrscheinlich testen, ob Eingabewerte dazu führen, dass bestimmte Werte in der Nachricht in der Warteschlange vorhanden sind.

Stellen Sie sich einen Test vor, der nach dem Muster „Arrange, Act, Assert“ geschrieben wurde:

Ein Mock-Testansatz würde das Mocking der Warteschlange mit einem prozessinternen Mock-Objekt und das Erstellen einer prozessinternen Instance der Klasse oder des Moduls, das den Lambda-Funktionscode enthält, beinhalten. Während der Assert-Phase würde die Nachricht in der Warteschlange aus dem simulierten Objekt abgerufen.

Bei einem cloud-basierten Ansatz würde der Test eine Amazon-SQS-Warteschlange für die Testzwecke erstellen und die Lambda-Funktion mit Umgebungsvariablen bereitstellen, die so konfiguriert sind, dass sie die isolierte Amazon-SQS-Warteschlange als Ausgabeziel verwenden. Nach dem Ausführen der Lambda-Funktion würde der Test die Nachricht aus der Amazon-SQS-Warteschlange abrufen.

Der cloudbasierte Test würde denselben Code ausführen, dasselbe Verhalten bestätigen und die funktionale Korrektheit der Anwendung überprüfen. Es hätte jedoch den zusätzlichen Vorteil, dass die Einstellungen der Lambda-Funktion überprüft werden könnten: die IAM-Rolle, die IAM-Richtlinien sowie die Timeout- und Speichereinstellungen der Funktion.

Nächste Schritte und Ressourcen

Verwenden Sie die folgenden Ressourcen, um weitere Informationen und praktische Testbeispiele zu erhalten.

Beispielimplementierungen

Das Serverless Test Samples Repository auf GitHub enthält konkrete Beispiele für Tests, die den in diesem Handbuch beschriebenen Mustern und bewährten Methoden folgen. Das Repository enthält Beispielcode und Anleitungen zu den Mock-, Emulations- und Cloud-Testprozessen, die in den vorherigen Abschnitten beschrieben wurden. Verwenden Sie dieses Repository, um sich über die neuesten Anleitungen für serverlose Tests von zu informieren. AWS

Weitere Informationen

Besuchen Sie Serverless Land, um auf die neuesten Blogs, Videos und Schulungen für AWS serverlose Technologien zuzugreifen.

Es wird auch empfohlen, die folgenden AWS Blogbeiträge zu lesen:

Tools