如何测试无服务器函数和应用程序
测试无服务器函数使用传统的测试类型和技术,但您还必须考虑对无服务器应用程序进行整体测试。基于云的测试将为您的函数和无服务器应用程序的质量提供最准确的衡量。
无服务器应用程序架构包括可通过 API 调用提供关键应用程序功能的托管服务。因此,您的开发周期应包括在函数与服务交互时验证功能的自动化测试。
如果您不创建基于云的测试,则可能会由于本地环境和已部署环境之间的差异而遇到问题。在将代码提升到下一个部署环境(例如 QA、暂存或生产)之前,您的持续集成过程应针对在云端预置的一套资源运行测试。
继续阅读本简短指南,了解无服务器应用程序的测试策略,或者访问无服务器测试示例存储库
对于无服务器测试,您仍需要编写单元、集成和端到端测试。
-
单元测试 – 针对隔离代码块运行的测试。例如,验证业务逻辑以计算给定特定项目和目的地的配送费用。
-
集成测试 – 涉及通常在云环境中交互的两个或更多组件或服务的测试。例如,验证函数是否会处理队列中的事件。
-
端到端测试 – 验证整个应用程序行为的测试。例如,确保正确设置基础设施,并确保事件在服务之间按预期流动,以记录客户的订单。
目标业务成果
测试无服务器解决方案可能需要稍多时间来设置测试,以验证服务之间的事件驱动型交互。阅读本指南时,请牢记以下实际商业原因:
-
提高应用程序的质量
-
缩短构建功能和修复错误的时间
应用程序的质量取决于测试各种场景以验证功能。仔细考虑业务场景,以及自动执行这些测试以针对云服务运行,将提高应用程序的质量。
在迭代开发周期中发现软件错误和配置问题时,对成本和计划的影响最小。如果在开发过程中始终未检测到问题,那么在生产环境中发现和修复问题时将需要更多人付出更多努力。
精心规划的无服务器测试策略将通过验证您的 Lambda 函数和应用程序是否在云环境中按预期执行来提高软件质量并缩短迭代时间。
测试内容
我们建议采用测试策略来测试托管服务行为、云配置、安全策略以及与您的代码的集成,以提高软件质量。行为测试,也称为黑盒测试,用于验证系统在不了解所有内部信息的情况下是否按预期运行。
-
运行单元测试以检查 Lambda 函数内部的业务逻辑。
-
验证是否已实际调用集成服务,输入参数是否正确。
-
检查事件是否在工作流中端到端遍历所有预期服务。
在基于服务器的传统架构中,团队通常将测试范围定义为仅包括在应用程序服务器上运行的代码。其他组件、服务或依赖项通常被认为是外部的,并且超出测试范围。
无服务器应用程序通常由小型工作单元组成,例如从数据库检索产品、处理队列中的项目或调整存储中图像大小的 Lambda 函数。每个组件均在自己的环境中运行。团队很可能会负责单个应用程序中的许多此类小型单元。
可以将某些应用程序功能完全委派给 Amazon S3 等托管服务,也可以在不使用任何内部开发代码的情况下创建。无需测试这些托管服务,但您确实需要测试与这些服务的集成。
如何测试无服务器
您可能熟悉如何测试本地部署的应用程序:编写针对完全在桌面操作系统上或容器内运行的代码运行的测试。例如,您可以使用请求调用本地 Web 服务组件,然后对响应做出断言。
无服务器解决方案通过函数代码和基于云的托管服务(如队列、数据库、事件总线和消息传送系统)而构建。这些组件均通过事件驱动型架构,其中消息(称为事件)从一个资源流向另一个资源。这些交互可以是同步操作(例如 Web 服务立即返回结果),也可以是稍后完成的异步操作(例如将项目放入队列或启动工作流步骤)。您的测试策略必须包括这两个场景并测试服务之间的交互。对于异步交互,可能需要检测下游组件中可能无法立即观察到的副作用。
复制整个云环境(包括队列、数据库表、事件总线、安全策略等)并不可行。由于本地环境与云端已部署环境之间的差异,您难免会遇到问题。不同环境之间的差异将会增加重现和修复错误的时间。
在无服务器应用程序中,架构组件通常完全存在于云端,因此必须对云端的代码和服务进行测试以开发功能和修复错误。
测试技术
实际上,您的测试策略可能包括多种可提高解决方案质量的技术。您将使用快速交互式测试来调试控制台中的函数,使用自动化单元测试来检查隔离的业务逻辑,通过 Mock 验证对外部服务的调用,以及偶尔对模仿服务的仿真器进行测试。
-
在云端进行测试 – 您可以部署基础设施和代码,使用实际服务、安全策略、配置和基础设施特定参数进行测试。基于云的测试可以最准确地衡量代码质量。
在控制台中调试函数是在云端进行测试的一种快速方法。您可以从示例测试事件库中进行选择,也可以创建自定义事件来在隔离环境中测试函数。您还可以通过控制台与您的团队共享测试事件。
要在开发和构建生命周期中自动执行测试,您需要在控制台之外进行测试。有关自动化策略和资源的更多信息,请参阅本指南中特定于语言的测试部分。
-
使用 Mock 进行测试(也称为伪件)– Mock 是代码中的对象,用于模拟和替代外部服务。Mock 提供预定义的行为来验证服务调用和参数。伪件是一种 Mock 实施,它采用捷径来简化或提高性能。例如,虚设数据访问对象可能会从内存中数据存储返回数据。Mock 可以模仿和简化复杂的依赖项,但也可以导致生成更多的 Mock,以替换嵌套依赖项。
-
使用仿真器进行测试 – 您可以设置应用程序(有时来自第三方)以在本地环境中模仿云服务。速度是其优势,但设置复杂和与生产服务的对等性较差是其缺点。请谨慎使用仿真器。
在云端进行测试
在云端进行测试对于各个阶段的测试(包括单元测试、集成测试和端到端测试)而言都很有价值。当您针对基于云的且与基于云的服务进行交互的代码运行测试时,可以最准确地衡量代码质量。
在云端运行 Lambda 函数的一种便捷方法是在 AWS Management Console 中使用测试事件。测试事件是函数的一个 JSON 输入。如果函数不需要输入,则事件可以是空 JSON 文档 ({})
。控制台为各种服务集成提供示例事件。在控制台中创建事件后,您还可以将其与团队共享,以简化测试并保持一致性。
了解如何在控制台中调试示例函数。
注意
尽管在控制台中运行函数是一种快速的调试方法,但自动执行测试周期对于提高应用程序质量和开发速度而言具有至关重要的意义。
无服务器测试示例存储库
python -m pytest -s tests/integration -v
尽管测试在本地运行,但它会与基于云的资源进行交互。这些资源使用 AWS Serverless Application Model 和 AWS SAM 命令行工具部署。测试代码首先检索已部署的堆栈输出,包括 API 端点、函数 ARN 和安全角色。接下来,测试会向 API 端点发送请求,该端点使用 Amazon S3 存储桶列表进行响应。此测试完全针对基于云的资源运行,以验证这些资源是否已部署、受到保护并按预期工作。
========================= test session starts =========================
platform darwin -- Python 3.10.10, pytest-7.3.1, pluggy-1.0.0
-- /Users/t/code/aws/serverless-test-samples/python-test-samples/apigw-lambda/venv/bin/python
cachedir: .pytest_cache
rootdir: /Users/t/code/aws/serverless-test-samples/python-test-samples/apigw-lambda
plugins: mock-3.10.0
collected 1 item
tests/integration/test_api_gateway.py::TestApiGateway::test_api_gateway
--> Stack outputs:
HelloWorldApi
= https://p7teqs3162.execute-api.us-east-2.amazonaws.com/Prod/hello/
> API Gateway endpoint URL for Prod stage for Hello World function
PythonTestDemo
= arn:aws:lambda:us-east-2:123456789012:function:testing-apigw-lambda-PythonTestDemo-iSij8evaTdxl
> Hello World Lambda Function ARN
PythonTestDemoIamRole
= arn:aws:iam::123456789012:role/testing-apigw-lambda-PythonTestDemoRole-IZELQQ9MG4HQ
> Implicit IAM Role created for Hello World function
--> Found API endpoint for "testing-apigw-lambda" stack...
--> https://p7teqs3162.execute-api.us-east-2.amazonaws.com/Prod/hello/
API Gateway response:
amplify-dev-123456789-deployment|myapp-prod-p-loggingbucket-123456|s3-java-bucket-123456789
PASSED
========================= 1 passed in 1.53s =========================
对于云原生应用程序开发,在云端进行测试具有以下优势:
-
您可以测试每个可用服务。
-
您始终使用最新的服务 API 和返回值。
-
云测试环境与您的生产环境非常相似。
-
测试可以涵盖安全策略、服务限额、配置和基础设施特定参数。
-
每个开发人员都可以在云端快速创建一个或多个测试环境。
-
云测试可增强您的信心,确保代码在生产环境中正确运行。
在云端进行测试确实有一些缺点。在云端进行测试最明显的缺点是,部署到云环境通常会比部署到本地桌面环境花费更长的时间。
所幸,如 AWS Serverless Application Model(AWS SAM)Accelerate、AWS 云开发工具包(AWS CDK)监视模式和 SST
注意
请参阅《无服务器开发人员指南》中的如何创建基础设施即代码,以了解有关 AWS Serverless Application Model、AWS CloudFormation 和 AWS Cloud Development Kit (AWS CDK) 的更多信息。
与本地测试不同,在云端进行测试需要额外的资源,这可能会产生服务成本。创建隔离的测试环境可能会增加 DevOps 团队的负担,尤其是在对账户和基础设施有严格控制的组织中更是如此。即便如此,在处理复杂的基础设施场景时,开发人员设置和维护错综复杂的本地环境所花费的时间成本可能与使用一次性测试环境(通过基础设施即代码自动化工具创建)的时间成本相似(或更昂贵)。
即使考虑到这些因素,在云端进行测试仍然是保证无服务器解决方案质量的最佳方式。
使用 Mock 进行测试
使用 Mock 进行测试是在代码中创建替换对象以模拟云服务行为的一种技术。
例如,您可以编写一个测试,该测试使用 Amazon S3 服务的 Mock,每当调用 CreateObject 方法时,其返回特定的响应。测试运行时,Mock 会返回该编程响应,而无需调用 Amazon S3 或任何其他服务端点。
Mock 对象通常由 Mock 框架生成,以减少开发工作量。一些 Mock 框架是通用的,而其他框架则是专门为 AWS SDK 设计的,例如 Moto
请注意,Mock 对象与仿真器的不同之处在于,Mock 对象通常由开发人员作为测试代码的一部分创建或配置,而仿真器是独立的应用程序,以与其模拟的系统相同的方式公开功能。
使用 Mock 的优势包括:
-
Mock 可以模拟应用程序无法控制的第三方服务,例如 API 和软件即服务(SaaS)提供程序,而无需直接访问这些服务。
-
Mock 对于测试失败条件很有用,尤其是当此类情况难以模拟时(例如服务中断)更是如此。
-
配置完成后,Mock 可以提供快速本地测试。
-
Mock 可以为几乎任何类型的对象提供替换行为,因此与仿真器相比,Mock 策略可以针对更多种类的服务创建覆盖面。
-
当新功能或行为可用时,Mock 测试可以更快地做出反应。通过使用通用 Mock 框架,您可以在更新的 AWS SDK 可用后立即模拟新功能。
Mock 测试有以下缺点:
-
Mock 通常需要极大量的设置和配置工作,特别是在尝试确定来自不同服务的返回值以正确模拟响应时更是如此。
-
Mock 由开发人员编写、配置且必须由开发人员维护,这会加重开发人员的职责。
-
您可能需要访问云才能了解服务的 API 和返回值。
-
Mock 可能很难维护。当 Mock 模拟的云 API 签名更改或返回值架构发生变化时,您需要更新 Mock。如果您扩展应用程序逻辑以调用新的 API,则还需要更新 Mock。
-
使用 Mock 的测试可能在桌面环境中通过,但在云端失败。结果可能与当前 API 不匹配。无法测试服务配置和限额。
-
Mock 框架仅限于测试或检测 AWS Identity and Access Management(IAM)policy 或限额限制。尽管 Mock 更擅长在授权失败或超过限额时进行模拟,但测试无法确定生产环境中实际会出现哪种结果。
使用仿真进行测试
仿真器通常是在本地运行的应用程序,它会模仿生产 AWS 服务。
仿真器的 API 与云对应项类似,可提供相似的返回值。它们还可以模拟由 API 调用启动的状态更改。例如,您可以借助 AWS SAM Local 使用 AWS SAM 运行函数,以仿真 Lambda 服务,从而可以快速调用函数。有关详细信息,请参阅《AWS Serverless Application Model 开发人员指南》中的 AWS SAM Local。
使用仿真器进行测试的优点包括以下几点:
-
仿真器可以促进快速本地开发迭代和测试。
-
仿真器为习惯于在本地环境中开发代码的开发人员提供熟悉的环境。例如,如果您熟悉 n 层应用程序的开发,则您可能拥有在本地计算机上运行的数据库引擎和 Web 服务器(类似于在生产环境中运行的数据库引擎和 Web 服务器),以提供快速的本地隔离测试功能。
-
仿真器不需要对云基础架构(例如开发人员云账户)进行任何更改,因此很容易使用现有的测试模式进行实施。
使用仿真器进行测试具有以下缺点:
-
仿真器可能很难设置和复制,尤其是在 CI/CD 管道中使用时更是如此。这样可能会增加管理自有软件的 IT 人员或开发人员的工作量。
-
仿真功能和 API 通常落后于服务更新。这样可能会导致发生错误,因为测试的代码与实际的 API 不匹配,并会阻碍新功能的采用。
-
仿真器需要支持、更新、错误修复和同等功能增强。这些是仿真器作者的职责,仿真器作者可以是某个第三方公司。
-
依赖于仿真器的测试可能会在本地提供成功的结果,但由于生产安全策略、服务间配置或超出 Lambda 限额,可能会在云端失败。
-
许多 AWS 服务没有可用的仿真器。如果您依赖于仿真,则部分应用程序可能无法提供令人满意的测试选项。
最佳实践
以下各节为成功测试无服务器应用程序提供了建议。
您可以在无服务器测试示例存储库
优先考虑在云端进行测试
在云端进行测试可提供最可靠、最准确和最完整的测试覆盖范围。在云环境中进行测试不仅可以全面测试业务逻辑,还可以全面测试安全策略、服务配置、限额以及最新的 API 签名和返回值。
构建代码以提高测试可行性
通过将特定于 Lambda 的代码与您的核心业务逻辑分开,从而简化您的测试和 Lambda 函数。
您的 Lambda 函数处理程序应该是一个纤薄的适配器,它接收事件数据并仅将重要的详细信息传递给您的业务逻辑方法。通过此策略,您可以围绕业务逻辑进行全面测试,而不必担心特定于 Lambda 的详细信息。您的 AWS Lambda 函数应该不需要设置复杂的环境或大量依赖项来创建并初始化所测试组件。
一般来说,您应该编写一个处理程序,用于从传入的事件和上下文对象中提取和验证数据,然后将该输入发送到执行您的业务逻辑的方法。
加速开发反馈循环
有一些工具和技术可以加速开发反馈循环。例如,AWS SAM Accelerate 和 AWS CDK 监视模式都减少了更新云环境所需的时间。
GitHub 无服务器测试示例存储库
我们还建议您在开发期间尽早创建和测试云资源,而不仅仅是在签入到源代码控制之后执行。这种做法有助于在开发解决方案时更快地进行探索和实验。此外,从开发计算机自动执行部署可以帮助您更快地发现云配置问题,并减少在更新和代码审查流程上浪费的工作量。
专注于集成测试
使用 Lambda 构建应用程序时,将组件一起测试是一项最佳实践。
针对两个或更多架构组件运行的测试称为集成测试。集成测试的目标不仅是了解您的代码将如何跨组件执行,而且要了解托管代码的环境将如何运行。端到端测试是特殊类型的集成测试,用于验证整个应用程序的行为。
要构建集成测试,请将您的应用程序部署到云环境。此操作可以在本地环境中完成,也可以通过 CI/CD 管道完成。然后,编写测试以执行被测系统(SUT)并验证预期行为。
例如,被测系统可能是使用 API Gateway、Lambda 和 DynamoDB 的应用程序。测试可以对 API Gateway 端点进行合成 HTTP 调用,并验证响应是否包含预期的负载。此测试可验证 AWS Lambda 代码是否正确,以及每项服务是否均已正确配置以处理请求,包括它们之间的 IAM 权限。此外,您可以将测试设计为写入各种大小的记录,以验证您的服务限额(例如 DynamoDB 中的最大记录大小)是否设置正确。
创建隔离的测试环境
在云端进行测试通常需要隔离的开发人员环境,这样测试、数据和事件就不会重叠。
一种方法是为每位开发人员提供一个专用 AWS 账户。这样将避免与资源命名发生冲突,而当多个开发人员在共享代码库中工作、尝试部署资源或调用 API 时,可能会发生此类冲突。
自动测试过程应为每个堆栈创建唯一命名资源。例如,您可以设置脚本或 TOML 配置文件,以便 AWS SAM CLI sam deploy 或 sam sync 命令将自动指定具有唯一前缀的堆栈。
在某些情况下,多名开发人员会共享一个 AWS 账户。这可能是由于堆栈中的资源在操作或预置和配置方面成本都很高昂。例如,可以共享数据库,以便更容易正确设置数据和为数据设定种子
如果开发人员共享账户,则应设置边界,以确定所有权并消除重叠。执行此操作的一种方法是使用开发人员用户 ID 作为堆栈名称的前缀。另一种常用方法是基于代码分支设置堆栈。借助分支边界,可实现即隔离环境,开发人员又可以共享资源,例如关系数据库。当开发人员一次处理多个分支时,这种方法就是最佳实践。
在云端进行测试对于各个阶段的测试(包括单元测试、集成测试和端到端测试)而言都很有价值。保持适当的隔离至关重要;但您的 QA 环境最好与您的生产环境尽可能相似。出于此原因,团队为 QA 环境添加了更改控制流程。
对于预生产和生产环境,通常在账户级别绘制边界,以将工作负载与嘈杂的相邻问题隔离开来,并实施最低权限安全控制来保护敏感数据。工作负载有限额。您不希望测试占用为生产分配的限额(嘈杂的相邻)或访问客户数据。负载测试是您应该与生产堆栈隔离的另一项活动。
在任何情况下,都应为环境配置警报和控件,以避免产生不必要的支出。例如,您可以限制可创建的资源的类型、层级或大小,并在估计成本超出给定阈值时设置电子邮件警报。
使用 Mock 来实现隔离的业务逻辑
Mock 框架是编写快速单元测试的重要工具。当测试涵盖复杂的内部业务逻辑(例如数学或财务计算或模拟)时,此框架尤其有用。寻找具有大量测试用例或输入变体的单元测试,其中,这些输入不会改变调用其他云服务的模式或内容。
通过 Mock 进行的单元测试所涵盖的代码也应包含在云端测试中。之所以建议这样做,是因为开发人员笔记本电脑或生成计算机环境的配置可能与云端的生产环境不同。例如,当使用某些输入参数运行时,您的 Lambda 函数使用的内存或时间可能会比分配的内存或时间多。或者您的代码可能包含没有以相同方式配置的环境变量(或者根本未配置),这些差异可能导致代码的行为不同或失败。
对于集成测试而言,Mock 的优势较少,因为实施必要 Mock 的工作量会随着连接点数量的增加而加重。端到端测试不应使用 Mock,因为这些测试通常涉及无法使用 Mock 框架轻松模拟的状态和复杂逻辑。
最后,避免使用 Mock 模拟的云服务来验证服务调用是否正确实施。反之,应在云端进行云服务调用以验证行为、配置和功能实现。
请谨慎使用仿真器
仿真器在某些使用案例中可能很方便,例如,对于互联网访问受限、不可靠或速度慢的开发团队而言,确实如此。但是,在大多数情况下,请选择谨慎使用仿真器。
通过避免使用仿真器,您将能够使用最新的服务功能和最新的 API 进行构建和创新。您不会一直等待供应商发布以实现同等功能。您将减少在多个开发系统和生成计算机上购买和配置的前期和持续费用。此外,您也不会遇到许多云服务根本没有可用仿真器的问题。依赖于仿真的测试策略会使您无法使用这些服务(这会导致需要采用潜在成本更高昂的解决方法)或生成未经全面测试的代码和配置。
当您确实使用仿真进行测试时,仍必须在云端进行测试以验证配置,并测试与只能在仿真环境中模拟或 Mock 模拟的云服务的交互。
在本地测试所面临的挑战
当您使用仿真器和 Mock 模拟的调用在本地桌面上进行测试时,随着代码在 CI/CD 管道中从一个环境进行到另一个环境,您可能会遇到测试不一致的情况。在桌面上验证应用程序业务逻辑的单元测试可能无法准确测试云服务的关键方面。
以下示例提供了当使用 Mock 和仿真器进行本地测试时需要注意的情况:
示例:Lambda 函数创建一个 S3 存储桶
如果 Lambda 函数的逻辑依赖于创建 S3 存储桶,则完整的测试应确认已调用 Amazon S3 并已成功创建相应存储桶。
-
在 Mock 测试设置中,您可以 Mock 模拟成功响应,并可能会添加一个测试用例来处理失败响应。
-
在仿真测试场景中,可能会调用 CreateBucket API,但您需要注意,进行本地调用的身份不会源自 Lambda 服务。调用身份不会像在云端那样担任安全角色,因此将改用占位符身份验证,可能使用权限更宽松的角色或用户身份,而在云端运行时会有所不同。
Mock 和仿真设置将测试 Lambda 函数在调用 Amazon S3 时会做什么;但是,这些测试不会验证所配置的 Lambda 函数是否能够成功创建 Amazon S3 存储桶。您必须确保分配给该函数的角色具有允许该函数执行 s3:CreateBucket
操作的附加安全策略。否则,该函数在部署到云环境时可能会失败。
示例:Lambda 函数处理来自某个 Amazon SQS 队列的消息
如果 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 永远无法发送这一大小的消息。
如这些示例所示,涵盖业务逻辑但不涵盖不同云服务之间配置的测试可能会提供不可靠的结果。
常见问题解答
我有一个 Lambda 函数,该函数可以在不调用任何其他服务的情况下执行计算并返回结果。我还需要在云端对其进行测试吗?
是。Lambda 函数的配置参数可能会改变测试结果。所有 Lambda 函数代码均依赖于超时和内存设置,如果这些设置不正确,这可能会导致函数失败。Lambda 策略还允许将标准输出记录到 Amazon CloudWatch
在云端进行测试如何帮助单元测试? 如果测试在云端并连接到其他资源,那不属于集成测试吗?
我们将单元测试定义为在架构组件上单独运行的测试,但这样并不能阻止测试包括可能调用其他服务或使用某些网络通信的组件。
许多无服务器应用程序都有可以单独测试的架构组件,即使在云端也是如此。一个示例为 Lambda 函数,该函数获取输入、处理数据并将消息发送到 Amazon SQS 队列。此函数的单元测试可能会测试输入值是否导致某些值出现在队列消息中。
考虑使用以“安排、执行、断言”模式编写的测试:
-
安排:分配资源(接收消息的队列和所测试的函数)。
-
执行:调用所测试的函数。
-
断言:检索函数发送的消息,并验证输出。
Mock 测试方法包括使用进行中的 Mock 对象模拟队列,以及创建包含 Lambda 函数代码的类或模块的进行中的实例。在断言阶段,将从 Mock 模拟对象中检索队列消息。
在基于云的方法中,测试将面向测试目的创建 Amazon SQS 队列,并将部署带有配置为使用隔离的 Amazon SQS 队列作为输出目标的环境变量的 Lambda 函数。运行 Lambda 函数后,测试将从 Amazon SQS 队列中检索消息。
基于云的测试将运行相同的代码,断言相同的行为,并验证应用程序的功能正确性。但是,它还有一个额外的优势,那就是能够验证 Lambda 函数的设置:IAM 角色、IAM policy 以及函数的超时和内存设置。
后续步骤和资源
使用以下资源可了解更多信息,并探索测试的实际示例。
示例实施
GitHub 上的无服务器测试示例存储库
延伸阅读
访问 Serverless Land
还建议您阅读以下 AWS 博客文章:
-
使用 AWS SAM Accelerate 加速无服务器开发
(AWS 博客文章) -
使用 CDK Watch 提高开发速度
(AWS 博客文章) -
使用 AWS Step Functions Local Mock 模拟服务集成
(AWS 博客文章) -
测试无服务器应用程序入门
(AWS 博客文章)
工具
-
AWS SAM — 测试和调试无服务器应用程序
-
AWS SAM – 与自动测试集成
-
Lambda – 在 Lambda 控制台中测试 Lambda 函数