Herausforderungen beim Testen von Serverless-Anwendungen

Wenn Sie Emulatoren und simulierte Aufrufe verwenden, um Ihre serverlose Anwendung auf Ihrem lokalen Desktop zu testen, kann es zu Testinkonsistenzen kommen, wenn Ihr Code in Ihrer Pipeline von Umgebung zu Umgebung fortschreitet. CI/CD Die Komponententests, die Sie auf Ihrem Desktop erstellen, um die Geschäftslogik Ihrer Anwendung zu überprüfen, beinhalten möglicherweise wichtige Aspekte von Cloud-Diensten nicht oder stellen diese nicht korrekt dar. Vollständige Tests können nicht isoliert lokal durchgeführt werden. Sie erfordern die Überprüfung der Berechtigungen und Konfigurationen mehrerer Services.

In den folgenden Abschnitten werden die Herausforderungen beschrieben, auf die Sie bei der Implementierung einer Cloud-Teststrategie stoßen könnten. In den folgenden Abschnitten werden die Herausforderungen beschrieben, mit denen Kunden bei der Implementierung einer Cloud-Teststrategie konfrontiert sind, sowie unsere Empfehlungen zu bewährten Verfahren für eine effektive Testabdeckung.

Beispiel: Eine Lambda-Funktion, die einen Amazon S3 S3-Bucket erstellt

Wenn die Logik einer Lambda-Funktion von der Erstellung eines Amazon S3-Buckets abhängt, sollte ein vollständiger Test bestätigen, dass Amazon S3 erfolgreich aufgerufen und der Bucket erfolgreich erstellt wurde. In einem Test-Setup können Sie eine Erfolgsreaktion simulieren und möglicherweise einen Testfall hinzufügen, um eine Fehlerreaktion zu behandeln. In einem Emulationstestszenario könnte die CreateBucket API zwar aufgerufen werden, aber die Identität, die den Aufruf tätigt, stammt nicht von der Übernahme einer Rolle durch den Lambda-Service, sondern es wird stattdessen eine Platzhalterauthentifizierung verwendet — dies ist oft Ihre tolerantere Rollen- oder Benutzeridentität.

Die zuvor besprochenen Mock- und Emulations-Setups werden höchstwahrscheinlich testen, was die Lambda-Funktion tun wird, wenn sie erfolgreich (oder erfolglos) Amazon S3 aufruft. Diese Tests können jedoch nicht erfassen, ob die Lambda-Funktion den Bucket aufgrund der Konfiguration der Funktion erfolgreich erstellen kann. Diese Konfiguration wird wahrscheinlich durch Infrastructure as Code (IaC) für Produkte und Dienste wie AWS CloudFormation AWS SAM, oder HashiCorp Terraform dargestellt. Ein mögliches Problem besteht darin, dass der Rolle, die der Funktion zugewiesen ist, keine Richtlinie angehängt ist, die die s3:CreateBucket Aktion zulässt. Daher schlägt die Funktion immer fehl, wenn sie in einer Cloud-Umgebung bereitgestellt wird.

Beispiel: Eine Lambda-Funktion, die Nachrichten von Amazon SQS verarbeitet

Wenn eine Amazon Simple Queue Service (Amazon SQS) -Warteschlange die Quelle einer Lambda-Funktion ist, sollte ein vollständiger Test sicherstellen, dass die Lambda-Funktion erfolgreich aufgerufen wurde, wenn eine Nachricht in eine Warteschlange gestellt wird. Emulationstests und Scheintests sind im Allgemeinen so eingerichtet, dass der Lambda-Funktionscode direkt ausgeführt wird und die Amazon SQS SQS-Integration simuliert wird, indem eine JSON-Ereignisnutzlast (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, aber sie stellen nicht sicher, dass 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:

• Das Amazon-SQS-Sichtbarkeits-Timeout ist zu niedrig, was zu mehreren Aufrufen führt, obwohl nur einer vorgesehen war.

• Die Ausführungsrolle der Lambda-Funktion erlaubt nicht das Lesen von Nachrichten aus der Warteschlange (durch sqs:ReceiveMessagesqs:DeleteMessage, odersqs:GetQueueAttributes).

• Das Beispielereignis, das an die Lambda-Funktion übergeben wird, überschreitet das Amazon-SQS-Nachrichtengrößenkontingent. Daher ist der Test ungültig, da Amazon SQS niemals in der Lage wäre, eine Nachricht dieser Größe zu senden.

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.