Serverlose Anwendungen testen auf AWS - AWS Präskriptive Leitlinien

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.

Serverlose Anwendungen testen auf AWS

Amazon Web Services (MitwirkendeMitwirkende)

März 2026 (Verlauf der Dokumente)

In diesem Leitfaden werden Methoden für das Testen von Serverless-Anwendungen erörtert, die Herausforderungen beschrieben, denen Sie beim Testen begegnen können, und bewährte Methoden vorgestellt. Diese Testtechniken sollen Ihnen helfen, schneller zu iterieren und Ihren Code sicherer zu veröffentlichen.

Dieses Handbuch richtet sich an Entwickler, die Teststrategien für ihre Serverless-Anwendungen entwickeln möchten. Sie können den Leitfaden als Ausgangspunkt verwenden, um mehr über Teststrategien zu erfahren. Besuchen Sie anschließend das Repository für Serverless-Testbeispiele, um Beispiele von Tests zu sehen, die den in diesem Leitfaden beschriebenen Mustern und bewährten Methoden folgen. In diesem Leitfaden werden Methoden für serverlose Tests beschrieben, die Herausforderungen beschrieben, mit denen Kunden beim Testen serverloser Anwendungen konfrontiert sind, und es werden bewährte Methoden zum Testen serverloser Anwendungen vorgestellt. Diese Techniken sollen Entwicklern helfen, schneller zu iterieren und Releases sicherer zu machen.

-Übersicht

Automatisierte Tests sind wichtige Investitionen, die dazu beitragen, die Anwendungsqualität und die Geschwindigkeit der Entwicklung sicherzustellen. Das Testen beschleunigt auch das Feedback für Entwickler. Als Entwickler möchten Sie in der Lage sein, schnell an Ihrer Anwendung zu iterieren und Feedback zur Qualität Ihres Codes zu erhalten. Viele Entwickler sind es gewohnt, Anwendungen zu schreiben, die sie in einer Umgebung auf ihrem Desktop bereitstellen, entweder direkt auf ihrem Betriebssystem oder in einer containerbasierten Umgebung. Wenn Sie in Desktop- oder Container-basierten Umgebungen arbeiten, schreiben Sie in der Regel Tests für Code, der vollständig auf Ihrem Desktop gehostet wird. In Serverless-Anwendungen können Architekturkomponenten jedoch möglicherweise nicht in einer Desktop-Umgebung bereitgestellt werden, sondern sind eventuell nur in der Cloud vorhanden. Eine cloudbasierte Architektur kann Persistenzschichten, Messaging-Systeme, Sicherheitskonstrukte und andere Komponenten APIs umfassen. Wenn Sie Anwendungscode schreiben, der auf diesen Komponenten basiert, kann es schwierig sein, die beste Methode zum Entwerfen und Ausführen von Tests zu ermitteln.

Dieser Leitfaden hilft Ihnen dabei, sich auf eine Teststrategie einzustellen, die Reibungsverluste und Verwirrung reduziert und die Codequalität verbessert.

Voraussetzungen

In diesem Leitfaden wird davon ausgegangen, dass Sie mit den Grundlagen automatisierter Tests vertraut sind, einschließlich der Art und Weise, wie automatisierte Softwaretests zur Sicherstellung der Softwarequalität eingesetzt werden. Das Handbuch bietet eine allgemeine Einführung in die Teststrategie für serverlose Anwendungen und erfordert keine praktische Erfahrung beim Schreiben von Tests.

Definitionen

In diesem Leitfaden werden die folgenden Begriffe verwendet:

  • Einheitentests sind Tests, die isoliert gegen Code für eine einzelne Architekturkomponente ausgeführt werden.

  • Integrationstests werden mit zwei oder mehr Architekturkomponenten durchgeführt, typischerweise in einer Cloud-Umgebung.

  • End-to-end Tests verifizieren das Verhalten ganzer Anwendungen oder Workflows.

  • Emulatoren sind Anwendungen (oft von Drittanbietern bereitgestellt), die darauf ausgelegt sind, einen Cloud-Dienst nachzuahmen, ohne Cloud-Ressourcen bereitzustellen oder aufzurufen.

  • Mocks(auch Fälschungen genannt) sind Implementierungen in einer Testanwendung, die eine Abhängigkeit durch eine Simulation dieser Abhängigkeit ersetzen.

Ziele

Die bewährten Methoden in diesem Leitfaden sollen Ihnen helfen, zwei Hauptziele zu erreichen:

  • Steigerung der Qualität von Serverless-Anwendungen

    • Testen an Architekturgrenzen

    • Testen an Codegrenzen

  • Verkürzung des Zeitaufwands für die Implementierung oder Änderung von Features

Erhöhung der Softwarequalität

Die Qualität einer Anwendung hängt in hohem Maße von der Fähigkeit der Entwickler ab, eine Vielzahl von Szenarien zu testen, um die Funktionalität zu überprüfen. Wenn Sie keine automatisierten Tests implementieren oder, was noch typischer ist, wenn Ihre Tests die erforderlichen Szenarien nicht angemessen abdecken, kann die Qualität Ihrer Anwendung weder bestimmt noch garantiert werden.

In einer serverbasierten Architektur können Teams den Testumfang leicht definieren: Jeder Code, der auf dem Anwendungsserver läuft, muss getestet werden. Andere Komponenten, die den Server aufrufen, oder Abhängigkeiten, die der Server aufruft, werden von dem Team, das für die Anwendung auf dem Server verantwortlich ist, häufig als extern betrachtet und können daher nicht getestet werden.

Serverless-Anwendungen bestehen häufig aus kleineren Arbeitseinheiten, wie AWS Lambda -Funktionen, die in ihrer eigenen Umgebung laufen. Teams werden wahrscheinlich für mehrere dieser kleineren Einheiten innerhalb einer einzigen Anwendung zuständig sein. Einige Anwendungsfunktionalitäten können vollständig an verwaltete Services wie Amazon Simple Storage Service (Amazon S3) oder Amazon Simple Queue Service (Amazon SQS) delegiert werden, ohne dass intern entwickelter Code verwendet wird. Herkömmliche serverbasierte Modelle für Softwaretests schließen verwaltete Services möglicherweise aus, da sie als außerhalb der Anwendung betrachtet werden. Dies kann zu einer unzureichenden Abdeckung führen, sodass kritische Szenarien möglicherweise auf manuelle Sondierungstests oder auf einige wenige Integrationstestfälle beschränkt sind, bei denen das Ergebnis je nach Umgebung unterschiedlich ist. Daher kann die Softwarequalität durch die Einführung von Teststrategien, die das Verhalten von verwalteten Services und Cloud-Konfigurationen umfassen, verbessert werden.

Testen an Architekturgrenzen

Wenn serverlose Anwendungen wachsen, verteilen sie sich naturgemäß auf mehrere Architekturkomponenten. Dabei werden zwar AWS verteilte Funktionen verwendet, das end-to-end Verhalten kann jedoch schwer verständlich sein.

Identifizierung natürlicher Grenzen

Wenn Sie Ihre Architektur nach bewährten Methoden für serverlose Systeme entwerfen (eine Funktion = ein Job, Entkopplung), werden Sie natürliche Grenzen rund um Subsysteme feststellen. Diese Grenzen stellen logische Trennpunkte in Ihrer Anwendung dar.

Grenzen als Testverträge

Diese architektonischen Grenzen eignen sich hervorragend zum Testen von Kanten. Behandeln Sie jede Grenze als Vertrag und überprüfen Sie, ob sie sich gemäß der definierten Spezifikation verhält. Stellen Sie sich diese Grenzen als Nähte in Ihrer Anwendung vor, in die Sie eine Testvalidierung einfügen können.

Wichtigste Vorteile

Im Folgenden sind die wichtigsten Vorteile von Tests an Architekturgrenzen aufgeführt:

  • Fokussierter Testumfang — Testen Sie Subsysteme unabhängig voneinander, ohne die gesamte Anwendung verstehen zu müssen.

  • Vertragsvalidierung — Stellen Sie sicher, dass jede Grenze ihr erwartetes Verhalten beibehält, während sich das System weiterentwickelt

  • Instrumentierung mit doppeltem Verwendungszweck — Dieselben Grenzen bieten hervorragende Beobachtungsmöglichkeiten in der Produktion

  • Test Harness — Ermöglicht das Testen asynchroner serverloser Systeme. Es hilft Ihnen beim Testen ereignisgesteuerter Architekturen, indem es Ereignisse erfasst und validiert, während sie Ihr Subsystem durchlaufen.

Testen an Codegrenzen

Definieren Sie klare Codegrenzen, indem Sie Infrastrukturcode wie Lambda-Code von Ihrer Kerngeschäftslogik trennen. Durch diese Trennung entstehen unterschiedliche Testbereiche, die Ihre Teststrategie vereinfachen.

Das Grenzmuster

Richten Sie in Ihren Lambda-Funktionen zwei klare Codegrenzen ein:

  • Äußere Grenze (Lambda-Handler) — Eine schlanke Adapterschicht, die spezifische Probleme behandelt AWS Lambda

  • Innere Grenze (Geschäftslogik) — Reine Geschäftslogikmethoden unabhängig von der Lambda-Laufzeit

Handler als Adapter (äußerer Geltungsbereich)

Ihr Lambda-Funktionshandler sollte eine dünne Schicht sein, die:

  • Extrahiert Daten aus den eingehenden event Objekten context

  • Validiert die extrahierten Daten

  • Übergibt nur relevante Details an Methoden der Geschäftslogik

  • Gibt Ergebnisse im erwarteten Format für Lambda zurück

Geschäftslogik (innerer Geltungsbereich)

Ihre Kerngeschäftslogik sollte:

  • Funktioniert unabhängig von Lambda-spezifischen Details

  • Akzeptieren Sie einfache, validierte Eingaben

  • Gibt vorhersehbare Ergebnisse zurück

  • Erfordern minimale Abhängigkeiten für die Initialisierung

Vorteile des Testens nach Umfang
  • Tests innerer Grenzen — Umfassende Komponententests rund um Geschäftslogik ohne Lambda-Komplexität oder Umgebungskonfiguration

  • Tests an äußeren Grenzen — Gezielte Integrationstests zur Validierung der Ereignisbehandlung und Datenextraktion auf der Adapterebene

  • Minimaler Testaufwand — Für die meisten Ihrer Tests sind keine komplexen Umgebungen oder umfangreichen Abhängigkeiten erforderlich

Dieser grenzenbasierte Ansatz ermöglicht es Ihnen, den größten Teil Ihres Codes als reine Funktionen zu testen und gleichzeitig die Lambda-Tests minimal und zielgerichtet zu halten.

Verkürzung des Zeitaufwands für die Implementierung oder Änderung von Features

Sie können die Auswirkungen von Softwarefehlern und Konfigurationsproblemen auf Kosten und Zeitpläne minimieren, indem Sie diese Probleme in einem iterativen Entwicklungszyklus beheben. Wenn ein Entwickler diese Probleme nicht erkennt, müssen mehr Mitarbeiter zusätzliche Anstrengungen unternehmen, um die Probleme zu identifizieren.

Eine Serverless-Architektur kann verwaltete Services umfassen, die wichtige Anwendungsfunktionen über API-Aufrufe bereitstellen. Aus diesem Grund sollte Ihr Entwicklungszyklus Tests beinhalten, die sowohl den glücklichen Weg (bei dem sich Interaktionen mit diesen Diensten erwartungsgemäß verhalten) als auch den traurigen Pfad (bei dem Anrufe fehlschlagen, unerwartete Antworten zurückgeben oder sich in den Umgebungen unterschiedlich verhalten) validieren. Ohne diese Tests können Probleme auftreten, die auf Unterschiede zwischen Ihrer lokalen Umgebung und der bereitgestellten Umgebung zurückzuführen sind. In diesem Fall müssen Sie zusätzliche Zeit damit verbringen, einen Fix zu reproduzieren und zu verifizieren, da jetzt bei jeder Iteration Änderungen anhand einer Umgebung validiert werden müssen, die sich von Ihrer bevorzugten Konfiguration unterscheidet.

Eine geeignete Serverless-Teststrategie verbessert Ihre Iterationszeit, indem sie genaue Ergebnisse für Tests liefert, die Aufrufe anderer Services beinhalten.