无服务器应用程序测试技术 - AWS 规范性指导
Mock 测试在云端进行测试仿真测试

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

无服务器应用程序测试技术

针对无服务器应用程序代码有三种主要运行测试方法：Mock 测试、云端测试和仿真测试。通常，您可以在单个项目内混合使用这些方法。例如，在本地开发代码时，您可能会使用 Mock 测试，但作为每日持续集成和持续交付（CI/CD）流程的一部分，您的代码可能会在云端进行测试。

Mock 测试

Mock 测试是在代码中创建模拟云服务行为的替换对象的一种技术。例如，您可以编写一个使用 Amazon S3 服务模拟的测试，并且可以将该模拟配置为在调用该CreateObject方法时返回特定的响应对象。测试运行时，Mock 会返回响应，而无需调用 Amazon S3 或任何其他服务端点。

这些替换对象通常由 Mock 框架生成，以减少给定测试所需的实施量。有些模拟框架是通用的，而另一些则是专门为之设计的 AWS SDKs。

Mock 和存根属于更广泛类别的伪件。模拟器与仿真器（将在本节后面讨论）的不同之处在于，模拟通常由开发人员作为测试代码的一部分创建或配置，而仿真器是独立的应用程序，其公开方式 APIs （例如REST APIs）与它们所模拟的系统相同。

使用 Mock 的优势包括：

  • Mocks 可以模拟应用程序无法控制的第三方服务，例如 APIs 软件即服务 (SaaS) 提供商，而无需直接访问这些服务。

  • Mock 对于测试失败条件很有用，尤其是当此类情况难以模拟时（例如服务中断）。

  • 与仿真器一样，Mock 框架可以在配置后提供快速的本地开发。

  • Mock 可以为几乎任何类型的对象提供替换行为，因此与仿真器相比，Mock 策略可以针对更多种类的服务创建覆盖面。

  • 当有新功能或行为可用时，模拟测试可以通过使用（或回退到）通用的模拟框架来更快地做出反应，该框架可以在更新后的 AWS SDK 可用后立即模拟新功能。

Mock 测试有以下缺点：

  • Mock 通常需要极大量的设置和配置工作，特别是在尝试确定来自不同服务的返回值以正确模拟响应时更是如此。

  • 由于 Mock 是由编写测试的开发人员编写或配置的，因此这一职责需要由开发人员承担。

  • 您可能需要访问云才能了解服务的价值 APIs 和返回值。

  • 模拟也可能难以维护，因为每当模拟的云 API 签名发生变化、返回值架构演变或扩展测试的应用程序逻辑以调用 new 时，它们都需要更新。 APIs这些更改为开发人员造成了额外的测试开发工作负载。

  • Mock 测试可能在桌面环境中可行，但在云端失败。

  • 模拟框架（如仿真器）在测试或检测 AWS Identity and Access Management (IAM) 策略或配额限制方面受到限制。

  • 尽管 Mock 更擅长在授权失败或超过限额时模拟应用程序会执行什么操作，但 Mock 测试无法确定当代码部署在生产环境中时实际会出现哪种结果。

在云端进行测试

云端测试是针对部署到云环境而不是桌面环境的代码运行测试的过程。云端测试的价值随着云原生应用程序的开发而增加。例如：

  • 您可以在云端针对最新的值 APIs 和返回值运行测试。

  • 您的测试可能包括 IAM policy、服务限额、配置和所有服务。

  • 您的云测试环境与生产运行时系统环境最为相似，因此您在云端运行的测试通过环境进行时，可能会获得最一致的结果。

在云端进行测试通常包括以下几个缺点：

  • 部署到云环境通常比部署到桌面环境更花费时间。一些工具能帮助减少云部署迭代所涉及的延迟，如 AWS Serverless Application Model （AWS SAM）Accelerate、AWS Cloud Development Kit (AWS CDK) 监视模式，和 SST。

  • 与使用本地开发环境的本地测试不同，云测试可能会产生额外的服务成本。

  • 如果您没有高速的互联网访问，那么在云端进行测试可能就不那么可行了。

  • 在云端进行测试通常需要相互隔离的云环境。环境边界通常是在用于开发者环境的共享账户中在堆栈级别绘制的，有时是通过使用命名空间类型策略（例如使用前缀来标识所有权）来划定的。对于预生产和生产环境，边界通常是在账户级别绘制的，以将工作负载与嘈杂的相邻问题隔离开来，支持最低权限安全控制并保护敏感数据。创建隔离环境的要求可能会给 DevOps团队带来额外的负担，特别是如果他们所在的企业对账户和基础设施有严格控制。

仿真测试

仿真测试由本地运行的应用程序（称为仿真器）启用，这些应用程序类似 AWS 于服务。仿真器与 APIs 云端仿真器类似，并提供相似的返回值。它们还可以模拟由 API 调用启动的状态更改。例如，调用该PutObject方法时，Amazon S3 模拟器可能会将对象存储在本地磁盘上。GetObject当使用相同的密钥调用时，模拟器会从磁盘读取相同的对象并将其返回。

仿真测试的优点包括以下几点：

  • 为习惯于在本地环境中开发代码的开发人员提供熟悉的环境。例如，如果您熟悉 n 层应用程序的开发，则您可能拥有在本地计算机上运行的数据库引擎和 Web 服务器（类似于在生产环境中运行的数据库引擎和 Web 服务器），以提供快速的本地隔离测试功能。

  • 不需要对云基础设施（例如开发人员云账户）进行任何更改，因此很容易使用现有的测试模式进行实施。仿真测试展现了快速的本地开发迭代的好处。

但是，仿真器有几个缺点：

  • 它们通常难以设置和复制，尤其是当被用作 CI/CD 管道的一部分时。这可能会增加 IT 人员或管理自己的软件安装的开发人员的工作负载和维护量。

  • 模拟功能， APIs 通常会落后于服务变更，在添加支持之前，可能会阻碍新功能的采用。

  • 仿真器可能需要支持、更新、错误修复或同等功能增强，这些都由仿真器作者（通常是第三方公司）负责。

  • 依赖模拟器的测试可以在本地提供成功的结果，但由于与 IAM 策略和配额 AWS 等其他方面的交互，它们可能会在云中失败，而这些方面通常不会被模拟。

  • 有些 AWS 服务没有可用的仿真器，因此，如果您只依赖仿真，则可能无法为应用程序的某些部分提供令人满意的测试选项。