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.
Herausforderungen beim Testen von Serverless-Anwendungen
Wenn Sie Emulatoren und Mocked Calls verwenden, um Ihre Serverless-Anwendung auf Ihrem lokalen Desktop zu testen, kann es beim Testen zu Inkonsistenzen kommen, wenn Ihr Code in Ihrer CI/CD-Pipeline von einer Umgebung zur nächsten weitergegeben wird. Die Unit-Tests, die Sie auf Ihrem Desktop erstellen, um die Geschäftslogik Ihrer Anwendung zu validieren, enthalten möglicherweise keine kritischen Aspekte von Cloud-Services oder bilden diese nicht korrekt ab. Vollständige Tests können nicht lokal und isoliert 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.
Beispiel: Eine Lambda-Funktion, die einen S3-Bucket erstellt
Wenn die Logik einer Lambda-Funktion von der Erstellung eines 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 CreateBucketAPI 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 fähig ist, den Bucket unter Berücksichtigung der Konfiguration der Funktion erfolgreich zu erstellen. Diese Konfiguration wird wahrscheinlich durch Infrastructure as Code (IaC) für Produkte und Dienste wie, oder Terraform dargestellt. AWS CloudFormation AWS SAM HashiCorp Ein mögliches Problem besteht darin, dass der Rolle, die der Funktion zugewiesen ist, keine Richtlinie angehängt ist, die die s3:CreateBucket-Aktion ermöglicht, und die Funktion schlägt fehl, wenn sie in einer Cloud-Umgebung bereitgestellt wird.
Beispiel: Eine Lambda-Funktion, die Nachrichten aus einer Amazon-SQS-Warteschlange verarbeitet.
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 Mock-Tests werden in der Regel so eingerichtet, dass der Lambda-Funktionscode direkt ausgeführt wird und die Amazon-SQS-Integration simuliert wird, indem eine JSON-Event-Payload (oder ein deserialisiertes Objekt) als Eingabe des Funktions-Handlers übergeben wird.
Lokale Tests, die die Amazon-SQS-Integration simulieren, testen, was die Lambda-Funktion tun wird, 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 es nicht, Nachrichten aus der Warteschlange zu lesen (durch
sqs:ReceiveMessage,sqs:DeleteMessageodersqs: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.
