测试无服务器应用程序时面临的挑战

当您使用仿真器和 Mock 模拟的调用在本地桌面上测试无服务器应用程序时，随着代码在 CI/CD 管道中从一个环境进行到另一个环境，您可能会遇到测试不一致的情况。您在桌面上创建的、用以验证应用程序业务逻辑的单元测试可能不包含或无法准确表示云服务的关键方面。无法在本地隔离环境中执行完整的测试。它们需要在多个服务之间验证权限和配置。

以下各节概述了您在实施云测试策略时可能遇到的挑战。

示例：创建了一个 S3 存储桶的 Lambda 函数

如果 Lambda 函数的逻辑依赖于创建 S3 存储桶，则完整的测试应确认已成功调用 Amazon S3 并已成功创建相应存储桶。在 Mock 测试设置中，您可以 Mock 一次成功的响应，还可以添加一个测试用例来处理失败响应。在仿真测试场景中，可能会调用 CreateBucketAPI，但进行调用的身份不会来自担任角色的 Lambda 服务，而是使用占位符身份验证——这通常是你更宽松的角色或用户身份。

前文讨论的 Mock 和仿真设置很可能会测试 Lambda 函数将执行什么操作（如果它调用 Amazon S3 成功（或失败））。但是，这些测试将无法捕获到 Lambda 函数是否有能力根据函数的配置，成功创建存储桶的结果。这种配置可能由 AWS CloudFormation、 AWS SAM或 HashiCorp Terraform 等产品和服务的基础设施即代码 (IaC) 表示。一个可能的问题是，分配给该函数的角色没有允许执行 s3:CreateBucket 操作的附加策略，进而导致该函数在部署到云环境时总是失败。

示例：处理来自 Amazon SQS 队列的消息的 Lambda 函数

如果 Amazon SQS 队列是 Lambda 函数的来源，则完整的测试应验证在将消息放入队列时是否已成功调用 Lambda 函数。仿真测试和 Mock 测试通常设置为直接运行 Lambda 函数代码，并通过传递 JSON 事件负载（或反序列化对象）作为函数处理程序的输入来模拟 Amazon SQS 集成。

模拟 Amazon SQS 集成的本地测试将测试 Amazon SQS 使用给定负载调用 Lambda 函数时，该函数将执行什么操作，但测试不能确保 Amazon SQS 在部署到云环境时能否成功调用 Lambda 函数。

您在使用 Amazon SQS 和 Lambda 时可能会遇到的一些配置问题示例包括：

• Amazon SQS 可见性超时设置过低，从而导致在仅打算调用一次的情况下进行多次调用。

• Lambda 函数的执行角色不允许从队列读取消息（通过 sqs:ReceiveMessage、sqs:DeleteMessage 或 sqs:GetQueueAttributes）。

• 传递给 Lambda 函数的示例事件超出了 Amazon SQS 消息大小限额。因此，该测试无效，因为 Amazon SQS 永远无法发送这一大小的消息。

如这些示例所示，涵盖业务逻辑但不涵盖不同云服务之间配置的测试可能会提供不可靠的结果。