如何使用 github PR 工作流程更好地针对分布式系统进行端到端测试？

Question

我的团队使用内部 e2e 测试框架来测试从 http 请求到 http 响应的所有内容是否按预期工作。

由于 AWS 中跨多个地理位置的分布式架构的性质，这些测试的工作方式非常复杂且不稳定。

我们遇到的一个大问题是，当我们将功能 PR 合并到影响端点响应/行为的众多微服务/lambda 之一时，我们的 e2e 测试会失败。

我们处理这个问题的方法是接受 e2e Jenkins 作业将暂时变为红色，直到有人获得更新/添加测试的 e2e PR 合并。

由于接受 e2e 作业“暂时”呈红色，因此会导致其他可能包含或不包含 bug 的更改。

另一个问题是，如果构建失败（这很好），我们不允许合并 PR，但如果 e2e 测试由于不同服务的更改而失败，则修复 e2e 测试的人员会发现他们的功能正在进行的工作将需要修复同一 PR 中的其他故障。

所以我的问题是，我的团队可以做些什么来解决这个问题？

我希望我们保留 e2e 测试，因为它们非常有用，但由于上述原因，它们很容易被忽视。

我们能否以某种方式将 e2e 测试存储库与每个功能分支联系起来，以便当有人将代码推送到分支时，我们的 e2e 测试服务上具有相同名称的功能分支会针对它运行并阻止 PR，直到他们更新 e2e 测试为止？

任何有关如何使用 github 工作流程对 AWS 中的分布式微服务/lambda 架构进行 e2e 测试的建议/示例将非常感激。

而且，我很难相信我的团队是唯一遇到这个问题的团队。所以也许这会帮助其他人。

Answer 1

您可以采用的用于 e2e 测试的常见测试策略是拆分它们的执行：

关于您的 e2e 测试在更新时呈红色的问题，我建议更改您的交付策略：

您可以阻止功能分支的合并，直到 e2e 测试通过功能分支。例如，您可以要求 e2e 测试至少运行一次，即使手动触发作业，并且在允许合并之前必须通过电子邮件确认执行成功
您可以更改您的分支策略。例如，您将有一个开发分支、一个稳定分支和一个发布分支。您可以根据分支执行或多或少的 e2e 测试，并接受开发分支比稳定分支更频繁地变为红色

事实上，e2e 测试没有完美的解决方案，但我希望我能给你一些想法

PS：你们的内部测试框架是用Selenium构建的吗？如果是这样，我建议使用 Selenium Grid 解决方案，例如 zalenium https://opensource.zalando.com/zalenium/

还可以尝试https://playwright.dev/这个框架的目标是创建可靠的测试：D 它适用于事件。你不需要到处都放置睡眠功能