无服务器测试策略(下)

2023-02-22   出处: medium  作/译者:Jérôme Van Der Linden/Yilia

更进一步

  如果不想为测试 SQS 队列而烦恼并降低基础设施部分的风险,我建议像下图一样扩展测试。 它往往会成为一个集成测试,你会在反馈中失去一些精确性,但可以保持你的基础设施代码直截了当。

  另一方面,在测试其他一些无服务器组件时,你可能需要添加更多基础设施才能执行断言。 例如,对于 SNS 和 EventBridge,无法轮询主题或总线,因此我们需要一种方法来断言消息/事件已被正确接收。 为此,我们可以添加一个测试 SQS 队列:

我的观点:

●在测试队列中将 MessageRetentionPeriod 设置为最小值(60 秒),以便自动清除超过一分钟的消息(以防测试未正确清理)。
●鼓励每位开发人员拥有一个 AWS 账户。 这样做可以降低单个帐户超出免费套餐的风险,并降低测试期间发生冲突的风险(每个人都使用相同的 SQS 队列……)。 如果不可能,请确保为每个开发人员部署一个堆栈并定义命名约定(例如“昵称-mystack”)。

选项 #3:

集成测试在之前的所有选项中,我们都缺少两个基本方面:
●函数的触发器(与上游服务集成):API 调用、DynamoDB 流、SQS 轮询。
●与下游服务交互的 Lambda 函数权限(执行角色)。

  集成测试允许涵盖这一点:不在本地调用 Lambda 函数,而是使用上游服务触发已部署的 Lambda 函数,然后该函数将与实际服务交互。 查看示例,它看起来像这样:

  我们仍然可以使用喜欢的编程语言和工具来编写这些测试,这使得编写它们非常方便。 利用 AWS SDK 来执行操作和断言,或者在 API 的情况下简单地请求端点。
  对这个选项进行评级,在准确性 (4) 上获得了在精度上失去的东西 (3):我们测试了真实的服务,完全集成并部署在 AWS 上,这提供了非常好的准确性,但是当测试失败时,它就变成了更难确定确切原因(这是否是因为Lambda 函数?)。 还有较慢的测试 (2):调用 rest api,在 DynamoDB 表中插入项目,……无疑需要更多时间并增加故障排除时间。 谈到成本,实施起来稍微复杂一些,排除故障也更耗时,这导致了 3。

我的观点 :

●没什么特别的,我真的不推荐这些测试。 它们提供了更好的准确性,但仍不是最佳选择(参见选项 #4)。

选项 #4:端到端测试

  将通过端到端测试到达最后一个选项。 顾名思义,其目的是验证整个系统是否已良好集成并在云端端到端运行。 至于集成测试,将使用 JUnit/Jest/… 和 AWS SDK 编写测试用例。 然而这一次,没有拆分工作,而是测试整个“功能”。在示例中,验证了在使用一些数据调用 API 时,最终在 RDS 数据库中获得了预期的输出:

  这些测试的主要好处是它们的准确性:可以按照与生产环境相同的方式部署所有内容,无需测试队列或专用基础设施。 如果测试在测试环境中通过,那么它在以后的生产环境中应该也能正常工作。 请注意,只有当使用基础设施即代码和框架(如 SAM、CDK 或无服务器)并在不同环境中部署相同的基础设施时,情况才会如此。 但是今天到底是谁手动部署了这个基础设施呢?
  另一方面,这些测试的大问题是测试失败时缺乏准确性。 必须对链的每个组件进行故障排除,以找出问题出在哪里。 AWS X-Ray 和 CloudWatch ServiceLens 可以提供帮助,但并非所有服务都与 X-Ray 集成。 还可以利用其他工具:用于查询日志并搜索错误或特定事件的 CloudWatch Logs Insights,或者提供无服务器应用程序指标的 CloudWatch Lambda Insights。
  这种测试的另一个缺点是它们通常很难设置。 不是因为基础设施(使用 IaC),而是因为数据。 需要获得一个干净的数据集(在我们的示例中的 RDS 中),可能会从生产环境中检索它,这意味着匿名化数据、删除 PII……测试后清理数据也可能很复杂。 对于此类测试尤其如此,因为它们通常在共享环境(集成、UAT、preprod 等)中执行。
  同样,如果可以获得一个可以执行这些测试的干净(非共享)环境,那会更好,这样就可以每次都使用全新的干净数据集填充数据库。 基础设施即代码就在这里,你使用它!
查看雷达,我们有以下图表:

●如前所述,准确性是最佳的 (5),在真实条件下进行测试(前提是拥有正确的数据集)。
●精度真的很低 (1) 并且更难排除故障。
●我们正在失去速度 (1),因为需要部署所有东西,执行测试的时间也很长,更难排除故障也意味着要花更多的时间在上面。
●时间就是金钱! 这就是我将利率降为 1 的主要原因。

我的观点:

●显然,测试金字塔和蜂窝也同意这一点,不要在这些测试上投入太多。 使用它们来验证基础架构的不同“路径”。 在示例中,主要有一条路径,即一次测试。 例如,如果在某个地方有一个 EventBridge,它具有将事件发送到不同目标的不同规则,我们将为每个规则添加一个测试。 如果有一个字符队列,我们也会想检查“错误路径”。 Step Functions 更复杂:是否必须验证所有路径和条件呢? 你必须验证状态机的所有分支,以确保它配置良好并与它调用的所有服务集成。
●这里的目标是仅验证之前无法验证的内容:每个服务和权限之间的集成。 你可以用另一种测试用例来验证某些内容。
●不要连续运行这些测试。与你希望每天运行数百次的单独和社交测试相反,这些测试运行的频率较低,并且通常不是从笔记本电脑而是从 CI/CD 流水线上运行的。 记住它们会很慢,不要等待它们运行。

结论

我们并不真正关心测试的形状,无论是三角形、蜂窝还是其他任何形状。 下面这是一朵花:

但是,我们必须关心的是为工作使用适当的测试。 我总结一下:
●对 Lambda 函数的业务逻辑使用单独测试。 尽可能尝试从处理程序中提取此业务,以避免模拟,尤其是 AWS 模拟。 六边形架构是一个加号,但不是强制性的。 这样就可以在不部署到云的情况下测试业务(如果有的话)。 如果拥有的唯一“业务”是协调其他 AWS 服务,那么 Step Functions 可能更合适,但这是另一个话题。
●不要依赖模拟 Lambda 的社交测试。
●支持社交测试:在本地调用处理程序方法,而不模拟对 AWS 服务的外部调用。 根据介绍中列出的四个标准,这些测试获得了 3.75/5 的最佳分数。
●不要依赖集成测试,更喜欢提供更高准确性的端到端测试,但不要过度投资。 只需验证基础架构路径(服务之间的集成:事件和消息、配置、权限)。


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
184° /1847 人阅读/0 条评论 发表评论

登录 后发表评论