本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 测试无服务器应用程序时面临的挑战
<a name="challenges"></a>

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

以下各节概述了您在实施云测试策略时可能遇到的挑战。以下各节概述了客户在尝试实施云测试策略时遇到的挑战，以及我们关于实现有效测试覆盖率的最佳实践指南。

## 示例：用于创建 Amazon S3 存储桶的 Lambda 函数
<a name="example-1"></a>

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

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

## 示例：处理来自亚马逊 SQS 的消息的 Lambda 函数
<a name="example-2"></a>

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

模拟 Amazon SQS 集成的本地*测试将测试 Amazon SQS 使用给定有效负载调用 Lambda 函数时会*做什么，但它并不能确保亚马逊 SQS 在*将 Lambda 函数部署到云环境时成功调用 Lambda* 函数。

您在使用 Amazon SQS 和 Lambda 时可能会遇到的一些配置问题示例包括：
+ Amazon SQS 可见性超时设置过低，从而导致在仅打算调用一次的情况下进行多次调用。
+ Lambda 函数的执行角色不允许读取队列中的消息（通过`sqs:ReceiveMessage``sqs:DeleteMessage`、或`sqs:GetQueueAttributes`）。
+ 传递给 Lambda 函数的示例事件超出了 Amazon SQS 消息大小限额。因此，该测试无效，因为 Amazon SQS 永远无法发送这一大小的消息。

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