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. # Bewährte Methoden zum Testen von Serverless-Anwendungen In den folgenden Abschnitten werden bewährte Methoden für die Erzielung einer effektiven Abdeckung beim Testen von Serverless-Anwendungen beschrieben. ## Priorisieren Sie Tests in der Cloud Für gut konzipierte Anwendungen können Sie eine Vielzahl von Testtechniken einsetzen, um eine Reihe von Anforderungen und Bedingungen zu erfüllen. Auf der Grundlage der aktuellen Tools empfehlen wir Ihnen jedoch, sich so weit wie möglich auf das Testen in der Cloud zu konzentrieren. Obwohl Tests in der Cloud zu Latenz für Entwickler führen, die Kosten erhöhen und manchmal Investitionen in zusätzliche DevOps Kontrollen erfordern können, bietet diese Technik die zuverlässigste, genaueste und vollständigste Testabdeckung. Sie sollten Zugriff auf isolierte Umgebungen haben, in denen Sie Tests durchführen können. Idealerweise sollte jeder Entwickler über ein eigenes Tool verfügen, AWS-Konto um Probleme mit der Benennung von Ressourcen zu vermeiden, die auftreten können, wenn mehrere Entwickler, die am selben Code arbeiten, versuchen, API-Aufrufe für Ressourcen mit identischen Namen bereitzustellen oder aufzurufen. Diese Umgebungen sollten mit den entsprechenden 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. Wenn Sie eine einzelne Ressource AWS-Konto mit anderen Entwicklern teilen müssen, sollten automatisierte Testprozesse Ressourcen so benennen, dass sie für jeden Entwickler eindeutig sind. Aktualisierungsskripts oder TOML-Konfigurationsdateien, die die AWS SAM CLI [sam deploy](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-deploy.html) - oder [sam sync-Befehle](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-sync.html) auslösen, können beispielsweise automatisch einen Stacknamen angeben, der den Benutzernamen des lokalen Entwicklers enthält. Das Testen in der Cloud ist für alle Testphasen nützlich, einschließlich Unit-Tests, Integrationstests und end-to-end Tests. ## Bei Bedarf Mocks verwenden Mock-Frameworks sind ein wertvolles Tool zum Schreiben schneller Einheitentests. Sie sind besonders wertvoll, wenn Tests komplexe interne Geschäftslogiken wie mathematische oder finanzielle Berechnungen oder Simulationen abdecken müssen. Suchen Sie nach Einheitentests, die eine große Anzahl von Testfällen oder Eingabevariationen enthalten, bei denen die Eingaben das Muster oder den Inhalt von Aufrufen an andere Cloud-Services nicht ändern. Die Erstellung von Mocktests für diese Szenarien kann die Iterationszeiten der Entwickler verbessern. Code, der durch Komponententests mit Mocks-Tests abgedeckt wird, muss auch durch Tests in der Cloud abgedeckt werden. Dies ist notwendig, da die Mocks immer noch auf dem Laptop oder der Build-Maschine eines Entwicklers laufen und die Umgebung möglicherweise anders konfiguriert ist als in der Cloud. Ihr Code könnte beispielsweise AWS Lambda Funktionen enthalten, die mehr Speicher verbrauchen oder mehr Zeit in Anspruch nehmen, als Lambda für die Zuweisung konfiguriert ist, wenn es mit bestimmten Eingabeparametern ausgeführt wird. Oder Ihr Code könnte Umgebungsvariablen enthalten, die nicht auf die gleiche Weise (oder überhaupt nicht) konfiguriert sind, und die Unterschiede können dazu führen, dass sich der Code anders verhält oder fehlschlägt. Verwenden Sie keine Modelle von Cloud-Diensten, um die korrekte Implementierung dieser Dienstintegrationen zu überprüfen. Es mag zwar akzeptabel sein, sich über einen Cloud-Dienst lustig zu machen, wenn Sie andere Funktionen testen, aber Sie sollten Cloud-Dienstaufrufe in der Cloud testen, um die korrekte Konfiguration und funktionale Implementierung zu überprüfen. Mocks können bei Komponententests einen Mehrwert bieten, vor allem, wenn Sie häufig eine große Anzahl von Fällen testen. Dieser Vorteil ist bei Integrationstests geringer, da der Aufwand für die Implementierung der erforderlichen Mocks mit der Anzahl der Verbindungspunkte zunimmt. End-to-endBeim Testen sollten keine Mocks verwendet werden, da sich diese Tests im Allgemeinen mit Zuständen und komplexer Logik befassen, die mit Schein-Frameworks nicht einfach simuliert werden können. ## Machen Sie sich mit den Kompromissen von Emulationstests vertraut Emulatoren können für bestimmte Anwendungsfälle eine praktische Wahl sein. Beispielsweise könnte ein Entwicklungsteam mit eingeschränktem, inkonsistentem oder langsamem Internetzugang feststellen, dass Emulationstests die zuverlässigste Methode sind, Code zu iterieren, bevor er in eine Cloud-Umgebung wechselt. In den meisten anderen Fällen sollten Sie Emulatoren selektiv verwenden. Wenn Sie sich stark auf einen Emulator verlassen, kann es schwierig werden, neue AWS Servicefunktionen in Ihre Tests zu integrieren, bis der Emulationsanbieter ein Update veröffentlicht, das die gleiche Funktionalität gewährleistet. Emulatoren erfordern außerdem im Voraus laufende Investitionen in die Einrichtung und Konfiguration aller Entwicklungssysteme und Build-Maschinen. Darüber hinaus sind für viele Cloud-Dienste keine Emulatoren verfügbar. Wenn Sie eine Strategie wählen, bei der die Emulation an erster Stelle steht, kann dies entweder die Nutzung dieser Dienste ausschließen oder Code und Konfigurationen erzeugen, die nicht ausreichend anhand des tatsächlichen Dienstverhaltens getestet wurden. Wenn Sie Emulationstests verwenden, sollten Sie diese so weit wie möglich durch Cloud-Tests ergänzen, um zu überprüfen, ob die richtigen Cloud-Konfigurationen vorhanden sind, und um Interaktionen mit Diensten zu testen, die nur in einer emulierten Umgebung simuliert oder simuliert werden können. Emulationstests können schnelles Feedback für Komponententests liefern und je nach den Funktionen und der Verhaltensparität der Emulationssoftware auch einige Integrationen und Tests unterstützen. end-to-end ## Durchführen von Tests anhand natürlicher Grenzen Da serverlose Anwendungen immer mehr architektonische Komponenten umfassen, entstehen natürliche Grenzen rund um Subsysteme — vor allem, wenn bewährte Verfahren wie Funktionen für einzelne Zwecke und ereignisgesteuerte Entkopplung befolgt werden. Diese Grenzen dienen als effektive Testgrenzen, an denen Sie Verträge zwischen Komponenten validieren können. ### Identifizieren Sie die Grenzen der Architektur Achten Sie in Ihrem Anwendungsdesign auf natürliche Nähte: + Zwischen Diensten, z. B. einer EventBridge Amazon-Regel, die einen Verlag mit einem Verbraucher verbindet + An API-Edges, wie z. B. Amazon API Gateway Gateway-Endpunkten, die Lambda-Funktionen unterstützen + Rund um Workflows, wie z. B. die AWS Step Functions Orchestrierung mehrerer Dienste + Auf Speicherebenen wie Amazon DynamoDB DynamoDB-Streams, die die Downstream-Verarbeitung auslösen ### Lambda-Code von Geschäftslogik trennen Vereinfachen Sie Ihre Tests, indem Sie Lambda-Code von der Kerngeschäftslogik isolieren. Ihr Lambda-Handler sollte als dünner Adapter zwischen der AWS Laufzeit und Ihrer Anwendungslogik fungieren. Es sollte Ereignisdaten extrahieren und validieren und dann an eine testbare Funktion delegieren, die keine Lambda-Abhängigkeiten hat. Dadurch ist Ihre Geschäftslogik portabel, leichter nachvollziehbar und einfach zu testen, ohne Lambda-Objekte zu verspotten oder komplexe Umgebungen einzurichten. ### Behandeln Sie Grenzen wie Verträge Testen Sie an der Grenze, nicht durch sie hindurch. Prüfen Sie, was die Grenze überschreitet, ohne dass das gesamte nachgeschaltete System erforderlich ist. Dieselben Grenzen dienen auch als Haken für die Beobachtbarkeit in der Produktion. Die architektonischen Nähte, an denen Sie testen, können mithilfe von Amazon CloudWatch Logs, AWS X-Ray Traces und EventBridge Events für die Überwachung instrumentiert werden. ## Verwenden Sie Testlösungen für asynchrone Workflows Serverlose Anwendungen basieren häufig auf asynchronen Mustern, bei denen Ereignisse die Verarbeitung auslösen, Nachrichten durch Warteschlangen fließen und Workflows sich über mehrere Dienste erstrecken, ohne dass sofort reagiert wird. Sie können nicht einfach eine Funktion aufrufen und einen Rückgabewert überprüfen. Das Ergebnis kann später in einer Datenbank, einem Protokollstream oder einem anderen Dienst erscheinen. Ein *Test-Harness* ist eine Testinfrastruktur, die Sie zusammen mit Ihrer Anwendung bereitstellen, um dieses asynchrone Verhalten zu beobachten und zu validieren. Zu den Testkabelbäumen gehören in der Regel: + Ereignis-Listener, die dieselben Ereignisse abonnieren, die Ihre Anwendung erzeugt + Speichermechanismen (wie DynamoDB-Tabellen oder Amazon S3 S3-Buckets), mit denen Testergebnisse erfasst werden können + Abfragelogik in Ihrem Testcode, die darauf wartet, dass erwartete Ergebnisse angezeigt werden Ihr Testcode löst ein Ereignis aus, wartet, bis der Workflow abgeschlossen ist, und fragt dann den Testcode ab, um zu überprüfen, ob das erwartete Ergebnis eingetreten ist. Im Folgenden finden Sie bewährte Methoden: + **Definieren Sie „Clear“ SLAs für asynchrone Operationen** — Legen Sie fest, wie lange Workflows dauern sollen, und verwenden Sie diese als Timeouts für Abfragen in Ihren Tests + **Verwenden Sie eindeutige Identifikatoren für die Testisolierung** — Generieren Sie eindeutige Dateinamen, Nachrichten- oder Korrelationstoken pro IDs Testlauf, um Interferenzen zwischen Tests zu vermeiden + **Stellen Sie die Testinfrastruktur zusammen mit Ihrer Anwendung** bereit — Nehmen Sie Test-Harness-Ressourcen in Ihre infrastructure-as-code Vorlagen auf, damit sie bei der Weiterentwicklung Ihrer Anwendung synchron bleiben + **Bereinigen Sie die Testdaten nach Testläufen** — Dadurch wird verhindert, dass sich Testartefakte in Ihrer Cloud-Umgebung ansammeln Testkabelbäume sind am wertvollsten für Integrationstests, bei denen Workflows über mehrere Services hinweg validiert werden, end-to-end Tests, die komplette Benutzererfahrung verifizieren, und ereignisgesteuerte Architekturen, bei denen Dienste über Amazon SNS EventBridge, Amazon SQS oder Amazon Kinesis kommunizieren. ## Organisieren Sie Cloud-Umgebungen zur Isolierung von Entwicklern Das Testen in der Cloud erfordert Umgebungen, die voneinander isoliert sind. Wenn sich Entwickler ein einzelnes Konto teilen AWS-Konto, z. B. ein Teamentwicklungskonto, sollten Sie erwägen, für jeden Entwickler oder jeden Feature-Branch einen separaten Anwendungsstapel zu erstellen. Dadurch werden Ressourcen isoliert, Namenskonflikte vermieden und Quotenkonflikte oder Probleme mit störenden Nachbarn beim Testen vermieden. Verwenden Sie AWS Systems Manager Parameter Store oder ähnliche Tools, um stapelspezifische Konfigurationen wie API-Endpunkte und Warteschlangennamen zu verwalten. Aus Kostengründen sollten Sie teure Ressourcen wie Amazon Relational Database Service (Amazon RDS) -Cluster auf mehrere Entwickler-Stacks verteilen und gleichzeitig leichtgewichtige serverlose Ressourcen (wie Lambda-Funktionen, API Gateway Gateway-Stufen und DynamoDB-Tabellen) pro Stack isoliert halten. In regulierten Branchen können Sicherheitsrichtlinien für Unternehmen den Zugriff von Entwicklern auf Cloud-Umgebungen einschränken, was es schwierig macht, Cloud-Tests als Teil eines lokalen Entwicklungsworkflows durchzuführen. In diesen Fällen können Emulationstests die Lücke zwischen lokalen Scheintests und vollständiger Cloud-Validierung schließen. Sie sollten jedoch durch Cloud-Tests ergänzt werden, sofern der Zugriff dies zulässt. ## Feedback-Schleifen beschleunigen Wenn Sie in der Cloud testen, verwenden Sie Tools und Techniken, um die Feedback-Schleifen zur Entwicklung zu beschleunigen. Verwenden Sie beispielsweise [AWS SAM den Beschleunigungs](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/accelerate.html) - und AWS CDK Überwachungsmodus, um die Zeit zu verkürzen, die benötigt wird, um Codeänderungen in eine Cloud-Umgebung zu übertragen. In den Beispielen im [Repository GitHub Serverless Test Samples](https://github.com/aws-samples/serverless-test-samples) werden einige dieser Techniken untersucht. Wir empfehlen Ihnen außerdem, Cloud-Ressourcen so früh wie möglich während der Entwicklung auf Ihrem lokalen Computer zu erstellen und zu testen — nicht erst, nachdem Sie sich bei der Quellcodeverwaltung angemeldet haben. Diese Praxis ermöglicht ein schnelleres Erkunden und Experimentieren bei der Entwicklung von Lösungen. Die Möglichkeit, die Bereitstellung von einem Entwicklungscomputer aus zu automatisieren, hilft Ihnen zudem, Probleme mit der Cloud-Konfiguration schneller zu erkennen und den Aufwand für die Aktualisierung und Genehmigung von Änderungen in der Versionsverwaltung zu reduzieren.