如何测试无服务器函数和应用程序
测试无服务器函数使用传统的测试类型和技术,但您还必须考虑对无服务器应用程序进行整体测试。基于云的测试将为您的函数和无服务器应用程序的质量提供最准确的衡量。
无服务器应用程序架构包括可通过 API 调用提供关键应用程序功能的托管服务。因此,您的开发周期应包括在函数与服务交互时验证功能的自动化测试。
如果您不创建基于云的测试,则可能会由于本地环境和已部署环境之间的差异而遇到问题。在将代码提升到下一个部署环境(例如 QA、暂存或生产)之前,您的持续集成过程应针对在云端预置的一套资源运行测试。
继续阅读本简短指南,了解无服务器应用程序的测试策略,或者访问无服务器测试示例存储库
对于无服务器测试,您仍需要编写单元、集成和端到端测试。
-
单元测试 – 针对隔离代码块运行的测试。例如,验证业务逻辑以计算给定特定项目和目的地的配送费用。
-
集成测试 – 涉及通常在云环境中交互的两个或更多组件或服务的测试。例如,验证函数是否会处理队列中的事件。
-
端到端测试 – 验证整个应用程序行为的测试。例如,确保正确设置基础设施,并确保事件在服务之间按预期流动,以记录客户的订单。
目标业务成果
测试无服务器解决方案可能需要更多时间来设置。您必须验证服务之间事件驱动的交互。阅读本指南时,请牢记以下实际商业原因:
-
提高应用程序的质量
-
缩短构建功能和修复错误的时间
应用程序的质量取决于对多种场景的测试。请考虑您的业务场景,并自动执行针对云服务的测试。这将提高您的应用程序质量。
在开发周期的早期发现错误和配置问题的成本会更低。在生产环境中才发现的问题需要投入更多人力和精力才能解决。
良好的无服务器测试策略可以提高软件质量并加快迭代速度。它会验证 Lambda 函数和应用程序在云端是否按预期运行。
测试内容
我们建议采用测试策略来测试托管服务行为、云配置、安全策略以及与您的代码的集成。行为测试(也称为黑箱测试)验证系统在不了解内部信息的情况下是否按预期运行。
-
运行单元测试以检查 Lambda 函数内部的业务逻辑。
-
验证是否已实际调用集成服务,输入参数是否正确。
-
检查事件是否在工作流中端到端遍历所有预期服务。
在基于服务器的传统架构中,团队通常仅测试在应用程序服务器上运行的代码。其他组件、服务或依赖项通常被认为是外部的,并且超出范围。
无服务器应用程序由小的工作单元组成。示例包括从数据库检索产品、从队列中处理项目或调整存储中图像大小的 Lambda 函数。每个组件均在自己的环境中运行。团队在单个应用程序中管理许多此类小单元。
某些功能可以完全由 Amazon S3 等托管服务处理,也可以在没有自定义代码的情况下构建。您不需要测试这些托管服务。但是,您必须测试您的代码如何与它们集成。
如何测试无服务器
您可能知道如何测试本地部署的应用程序。您可以在桌面或容器内针对代码编写测试。例如,您可以调用本地 Web 服务,然后检查响应。
无服务器解决方案使用函数代码和基于云的托管服务(如队列、数据库、事件总线和消息传送系统)。这些组件通过事件驱动型架构进行连接,其中消息(称为事件)从一个资源流向另一个资源。有些交互是同步的,例如立即返回结果的 Web 服务。
其他则是异步的,例如将项目放入队列或启动工作流步骤。测试策略必须涵盖这两种类型并测试服务之间的交互。对于异步交互,可能需要检测下游组件中不会立即看到的副作用。
您无法在本地完全复制云环境。这包括队列、数据库表、事件总线以及安全策略。本地和云环境之间的差异会导致问题。这些差异会增加重现和修复错误所需的时间。
在无服务器应用程序中,组件完全存在于云端。需要对云代码和服务进行测试,以便开发功能和修复错误。
测试技术
测试策略可能包括多种技术。您可以使用快速交互式测试来调试控制台中的函数。您可以编写自动单元测试来检查业务逻辑。您可以使用模拟来验证对外部服务的调用。您也可以针对模拟服务的仿真器进行测试。
-
在云端进行测试:部署基础设施和代码,使用实际服务、安全策略和配置进行测试。基于云的测试可以最准确地衡量代码质量。
在控制台中调试函数是在云端进行测试的一种快速方法。您可以从示例测试事件中选择,也可以创建自定义事件。您还可以通过控制台与您的团队共享测试事件。
要在开发和构建生命周期中自动执行测试,请在控制台之外进行测试。有关自动化策略,请参阅本指南中特定于语言的测试部分。
-
使用 Mock 进行测试:模拟是代码中的对象,用于模拟外部服务。它们提供预定义的行为来验证服务调用和参数。伪件是一种采用捷径来简化或加快测试速度的 mock。例如,虚设数据访问对象可能会从内存中数据存储返回数据。模拟可以简化复杂的依赖项,但可能导致生成更多的模拟以替换嵌套依赖项。
-
使用 AWS SAM CLI 进行本地测试:使用 AWS SAM CLI 在 Docker 容器中本地调用与 AWS Lambda 使用相同运行时环境的 Lambda 函数。无需部署到云端即可测试函数逻辑和事件处理。
-
使用仿真进行测试:使用 VS Code 中的 LocalStack 集成在本地模拟多个 AWS 服务以测试服务集成。
在云端进行测试
在云端进行测试对于各个阶段的测试而言都很有价值:单元测试、集成测试和端到端测试。针对基于云的代码和服务运行的测试可最准确地衡量代码质量。
在云端运行 Lambda 函数的一种简单方法是在 AWS 管理控制台 中使用测试事件。测试事件是函数的一个 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、CloudFormation 和 AWS Cloud Development Kit (AWS CDK) 的更多信息。
与本地测试不同,云测试会使用可能产生费用的资源。隔离的测试环境可能会增加 DevOps 团队的工作量,尤其是在账户控制严格的组织中。即便如此,开发人员设置复杂的本地环境所花费的时间成本可能比使用通过基础设施即代码工具构建的一次性云环境更高。
即使考虑到这些因素,在云端进行测试仍然是保证无服务器解决方案质量的最佳方式。
使用 Mock 进行测试
使用 Mock 进行测试是在代码中创建替换对象以模拟云服务行为的一种技术。
例如,您可以编写一个使用 Amazon S3 服务模拟的测试。每次调用 CreateObject 方法时,模拟都会返回一个集合响应。它不会调用 Amazon S3 或任何其他服务端点。
模拟框架通常会为您生成模拟对象。有些框架是通用的。其他框架则针对 AWS SDK,例如 Moto
模拟对象不同于仿真器。开发人员将作为测试代码的一部分创建模拟。仿真器是独立的应用程序,它们提供与所模拟的系统相同的功能。
使用 Mock 的优势包括:
-
Mock 可以模拟应用程序无法控制的第三方服务,例如 API 和软件即服务(SaaS)提供程序,而无需直接访问这些服务。
-
Mock 对于测试失败条件很有用,尤其是当此类情况难以模拟时(例如服务中断)更是如此。
-
配置完成后,Mock 可以提供快速本地测试。
-
Mock 可以为几乎任何类型的对象提供替换行为,因此与仿真器相比,Mock 策略可以针对更多种类的服务创建覆盖面。
-
当新功能或行为可用时,Mock 测试可以更快地做出反应。通过使用通用 Mock 框架,您可以在更新的 AWS SDK 可用后立即模拟新功能。
Mock 测试有以下缺点:
-
模拟通常需要大量的设置和配置工作,特别是在尝试确定来自不同服务的返回值以正确模拟响应时。
-
Mock 由开发人员编写、配置且必须由开发人员维护,这会加重开发人员的职责。
-
您可能需要访问云才能了解服务的 API 和返回值。
-
Mock 可能很难维护。当 Mock 模拟的云 API 签名更改或返回值架构发生变化时,您需要更新 Mock。如果您扩展应用程序逻辑以调用新的 API,则还需要更新 Mock。
-
使用 Mock 的测试可能在桌面环境中通过,但在云端失败。结果可能与当前 API 不匹配。无法测试服务配置和限额。
-
Mock 框架仅限于测试或检测 AWS Identity and Access Management(IAM)policy 或限额限制。尽管模拟更擅长在授权失败或超过限额时进行模拟,但测试无法确定生产环境中实际会出现哪种结果。
使用 AWS SAM CLI 进行本地测试
通过 AWS SAM CLI 在与 AWS Lambda 使用相同运行时环境的 Docker 容器中测试您的函数。您可以在本地测试函数逻辑和事件处理,而无需部署到云端。如果您的函数对其他 AWS 服务 进行 API 调用,这些调用将到达真实的 AWS 资源。
使用本地容器进行测试的优点包括:
-
使用 AWS Lambda 运行时环境进行精确测试。
-
无需云部署即可实现快速的本地开发迭代。
-
支持使用熟悉的本地开发工具进行调试。
使用本地容器进行测试具有以下限制:
-
来自您的函数的 AWS 服务 调用将与真实的 AWS 资源进行交互,这可能会产生成本并影响生产数据。
-
需要在本地安装并运行 Docker。
使用仿真进行测试
模拟器是在本地运行的应用程序,通过提供类似的 API 和返回值来模拟 AWS 服务。LocalStack 是一种流行的仿真工具,其提供用于测试服务集成的完整本地开发环境。
LocalStack 是一款 AWS Cloud 模拟器,可用于在本地测试无服务器应用程序。您可以测试与 DynamoDB、Amazon S3 和 Amazon SQS 等服务集成的 Lambda 函数,而无需连接到实际的 AWS 服务。您可以在 AWS Toolkit for VS Code 中使用 LocalStack。
使用仿真器进行测试的优点包括以下几点:
-
仿真器可帮助快速本地开发迭代和测试。
-
仿真器为习惯于在本地环境中开发代码的开发人员提供熟悉的环境。例如,如果您熟悉 n 层应用程序的开发,则您可能拥有在本地计算机上运行的数据库引擎和 Web 服务器(类似于在生产环境中运行的数据库引擎和 Web 服务器),以提供快速的本地隔离测试功能。
-
仿真器不需要对云基础设施(例如开发人员云账户)进行任何更改,因此很容易使用现有的测试模式进行实施。
-
由于模拟器不使用实际 AWS 资源,因此在启动多项服务或让某些资源长时间运行时不会产生意外费用。
使用仿真器进行测试具有以下缺点:
-
仿真器可能很难设置和复制,尤其是在 CI/CD 管道中使用时更是如此。这样可能会增加管理自有软件的 IT 人员或开发人员的工作量。
-
仿真功能和 API 通常落后于服务更新。这样可能会导致发生错误,因为测试的代码与实际的 API 不匹配,并会阻碍新功能的采用。
-
仿真器需要支持、更新、错误修复和同等功能增强。这些是仿真器作者的职责,仿真器作者可以是某个第三方公司。
-
依赖于仿真器的测试可能会在本地提供成功的结果,但由于生产安全策略、服务间配置或超出 Lambda 限额,可能会在云端失败。
最佳实践
以下各节为成功测试无服务器应用程序提供了建议。
您可以在无服务器测试示例存储库
优先考虑在云端进行测试
在云端进行测试可提供最可靠、最准确和最完整的测试覆盖范围。在云环境中进行测试不仅可以全面测试业务逻辑,还可以全面测试安全策略、服务配置、限额以及最新的 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 服务。调用身份不会像在云端那样担任安全角色,因此将改用占位符身份验证,可能使用权限更宽松的角色或用户身份,而在云端运行时会有所不同。
模拟和仿真设置将测试 Lambda 函数在调用 Amazon S3 时会做什么;但是,这些测试不会验证所配置的 Lambda 函数是否能够成功创建 Amazon S3 存储桶。您必须确保分配给该函数的角色具有允许该函数执行 s3:CreateBucket 操作的附加安全策略。否则,该函数在部署到云环境时可能会失败。
示例:Lambda 函数处理来自某个 Amazon SQS 队列的消息
如果 Amazon SQS 队列是 Lambda 函数的来源,则完整的测试应验证在将消息放入队列时是否已成功调用 Lambda 函数。
仿真测试和模拟测试通常设置为直接运行 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 函数