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

Question

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

由于AWS中多个地区的分布式体系结构的性质，这些测试的工作方式非常复杂和脆弱。

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

[我们如何通过接受e2e Jenkins作业将暂时变成红色直到有人获得合并以更新/添加测试的e2e PR来解决这个问题。

由于接受e2e作业是“暂时的”红色，因此可能导致其他更改可能包含也可能不包含错误。

另一个问题是，如果构建失败（这很棒），我们不允许PR合并，但是如果e2e测试由于其他服务的更改而失败，那么修复e2e测试的人员他们正在使用的功能将需要修复同一PR中的其他故障。

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

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

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

• 这需要以某种方式链接e2e测试存储库，以便在代码PR中出现相关服务/ lambda的代码更改。不知道是否可能。

对于在AWS中为分布式微服务/ lambda架构使用github工作流进行e2e测试的任何建议/示例，将非常感谢。

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

Answer 1

您可以用于端到端测试的通用测试策略是拆分执行：

• 用于拉取请求：隔离一些快速且稳定的e2e测试，并将其包含在您的主管道中
• 对于主分支（或根据您的策略发布版本）：隔离一些更耗时的非易碎e2e测试。与PR一起执行的e2e测试一起执行]
• 安排一项工作以每天或每天两次执行所有e2e测试

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

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

  实际上，对于端到端测试没有完美的解决方案，但我希望我能给您一些想法

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