本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 在上测试无服务器应用程序 AWS
*亚马逊 Web Services*（[贡献者](contributors.md)贡献者）
*2026 年 3 月*（[文件历史记录](doc-history.md)）
本指南讨论了测试无服务器应用程序的方法，描述了您在测试过程中可能遇到的挑战，并介绍了最佳实践。这些测试技术旨在帮助您更快地迭代、更自信地发布代码。
本指南适用于希望为其无服务器应用程序制定测试策略的开发人员。您可以将该指南作为起点来学习测试策略，然后访问[无服务器测试样本存储库](https://github.com/aws-samples/serverless-test-samples)以查看遵循本指南中介绍的模式和最佳实践的测试示例。本指南描述了无服务器测试方法，描述了客户在测试无服务器应用程序时遇到的挑战，并介绍了测试无服务器应用程序的最佳实践。这些技术旨在帮助开发人员更快地迭代并更自信地发布。
## 概述
自动化测试是重要的投资，有助于确保应用程序质量和开发速度。测试还可以加快开发人员反馈的速度。作为一名开发人员，您一定希望能够快速迭代您的应用程序，并获得有关代码质量的反馈。许多开发人员习惯于在桌面上编写部署到环境的应用程序，然后要么直接部署到操作系统，要么部署到基于容器的环境中。在桌面或基于容器的环境中工作时，通常会针对完全托管在桌面上的代码编写测试。但是，在无服务器应用程序中，架构组件可能无法部署到桌面环境，可能仅能存在于云中。基于云的架构可能包括持久层、消息传递系统、安全结构和其他组件。 APIs在编写依赖于这些组件的应用程序代码时，可能很难确定设计和运行测试的最佳方式。
本指南可帮助您实现一致的减少摩擦和混乱并提高代码质量的测试策略。
## 先决条件
本指南假设您熟悉自动化测试的基础知识，包括如何使用自动化软件测试以确保软件质量。该指南提供了对无服务器应用程序测试策略的高级介绍，并且不需要任何编写测试的实践经验。
## 定义
本指南使用了以下术语：
+ *单元测试*，是针对单个架构组件的代码单独运行的测试。
+ *集成测试*****针对两个或多个架构组件运行，通常是在云环境中。
+ *End-to-end 测试*验证整个应用程序或工作流程中的行为。
+ *仿真器*是应用程序（通常由第三方提供），旨在模仿云服务，无需配置或调用任何云资源。
+ *Mock*（也称为*伪件*)，是测试应用程序中将依赖项替换为该依赖项的模拟的实施。
## 目标
本指南中的最佳实践旨在帮助您实现两个主要目标：
+ 提高无服务器应用程序的质量
+ 在架构边界上进行测试
+ 在代码边界上进行测试
+ 缩短实施或更改功能的时间
### 提高软件质量
应用程序的质量在很大程度上取决于开发人员测试各种场景以验证功能的能力。当您不实施自动化测试时，或者更常见的是，如果您的测试没有充分涵盖所需的场景，则无法确定或保证应用程序的质量。
在基于服务器的架构中，团队能够轻松地定义测试范围：任何在应用程序服务器上运行的代码都需要进行测试。其他服务器调用的组件或服务器调用的依赖项，通常被负责服务器上应用程序的团队视为外部组件，不在测试范围之内。
无服务器应用程序通常由较小的工作单元组成，例如 AWS Lambda 函数（在其自己的环境中运行）。团队很可能会负责单个应用程序中的许多此类较小的单元。可以将某些应用程序功能完全委托给托管服务，如 Amazon Simple Storage Service（Amazon S3）或 Amazon Simple Queue Service（Amazon SQS），无需使用内部开发的代码。传统的基于服务器的软件测试模型可能会将托管服务视为应用程序外部的托管服务，从而将其排除在外。这可能导致覆盖范围不足，在这种情况下，关键场景可能仅限于手动探索性测试或一些结果因环境而异的集成测试使用案例。因此，采用包含托管服务行为和云配置的测试策略可以提高软件质量。
#### 在架构边界上进行测试
随着无服务器应用程序的增长，它们自然会分布在多个架构组件中。虽然这使用 AWS 分布式功能，但它可能会使 end-to-end行为难以理解。
##### 识别自然界限
在按照无服务器最佳实践（一个功能 = 一项工作，解耦合）设计架构时，您会注意到子系统周围的自然界限。这些边界代表应用程序中的逻辑分隔点。
##### 边界作为测试合同
这些架构边界非常适合测试边缘。将每个边界视为合约，并验证其行为是否符合其定义的规范。可以将这些边界想象成应用程序中的*接缝*，您可以在其中插入测试验证。
##### 主要优势
以下是在架构边界上进行测试的主要好处：
+ **重点测试范围** — 无需了解整个应用程序即可独立测试子系统。
+ **合同验证** — 确保随着系统的发展，每个边界都保持其预期行为
+ **双用途仪器** — 这些相同的界限使生产中的可观察性非常出色
+ **测试工具**-允许您测试异步无服务器系统。它通过捕获和验证流经子系统的事件来帮助您测试事件驱动的架构。
#### 在代码边界上进行测试
通过将基础设施代码（例如 Lambda 代码）与核心业务逻辑分开，定义清晰的代码边界。这种分离创建了不同的测试范围，从而简化了您的测试策略。
##### 边界图案
在 Lambda 函数中建立两个明确的代码边界：
+ **外部边界（Lambda 处理程序）**— 一个超薄的适配器层，用于处理特定于的问题 AWS Lambda
+ **内部边界（业务逻辑）**— 独立于 Lambda 运行时的纯业务逻辑方法
##### 处理器作为适配器（外部作用域）
您的 Lambda 函数处理程序应该是一个薄层，该层应：
+ 从传入的`event`和`context`对象中提取数据
+ 验证提取的数据
+ 仅将相关细节传递给业务逻辑方法
+ 以 Lambda 的预期格式返回结果
##### 业务逻辑（内部范围）
你的核心业务逻辑应该：
+ 独立于 Lambda 的特定细节进行操作
+ 接受简单、经过验证的输入
+ 返回可预测的输出
+ 初始化需要最少的依赖关系
##### 按范围划分的测试优势
+ **内部边界测试** — 围绕业务逻辑进行全面的单元测试，无需复杂的 Lambda 或环境设置
+ **外部边界测试** — 重点集成测试验证适配器层的事件处理和数据提取
+ **最小的测试开销** — 大多数测试不需要复杂的环境或大量的依赖关系
这种基于边界的方法允许您将大部分代码作为纯函数进行测试，同时保持 Lambda 测试的最小化和有针对性。
### 缩短实施或更改功能的时间
通过在迭代开发周期中发现这些问题，可以最大限度地减少软件错误和配置问题对成本和进度的影响。当开发人员未能发现这些问题时，必须有更多的人投入更多精力来识别问题。
无服务器架构可能包括可通过 API 调用提供关键应用程序功能的托管服务。因此，您的开发周期应包括测试，以验证*快乐路径*（与这些服务的交互行为符合预期）和*悲伤路径*（调用失败、返回意外响应或在不同环境中表现不同）。如果没有这些测试，您可能会遇到由本地环境和已部署环境之间的差异引起的问题。发生这种情况时，你必须花更多时间尝试重现和验证修复，因为现在每次迭代都需要在不同于你首选设置的环境中验证更改。
通过为包括了调用其他服务的测试提供准确的结果，适当的无服务器测试策略得以缩短迭代时间。