我们正在尝试为预订应用程序自动化E2E测试用例，每个测试用例涉及大约60+步骤。每当最后步骤出现故障时，如果我们采用传统的重试选项，则会非常耗时，因为测试用例将再次从步骤 1 开始执行。在应用程序上，我们有一些逻辑步骤，可以以某种方式标记这些步骤，我们希望通过这些步骤从失败步骤之前的逻辑点恢复测试用例。例如，在 60 个步骤中，假设每 10 步是一个逻辑点，在该逻辑点中可以恢复脚本，而不是从步骤 1 重试。假设失败在第 43 行，那么在预订参考号的帮助下，测试可以从步骤 41 恢复，因为验证已经完成到步骤 40(步骤 40 是逻辑闭包点)。您可能建议有一个选项将测试用例拆分为较小的模块，这对我不起作用，因为它是我们希望在单个 Geb 规范中拥有的应用程序的 E2E 测试用例。该框架是使用Geb&Spock构建的，用于Web应用程序自动化。请分享您对如何为此案例构建恢复方案的想法/逻辑。感谢您的支持。！
到目前为止，我无法找到此类问题的任何解决方案。
以下是可以实现相同目标的一些事情，但在我们谈论解决方案之前，我们还应该讨论它将产生的问题。您正在运行 E2E 测试用例，如果它们在步骤 10 失败，则应从头开始而不是从步骤 10 开始，因为您可能会错过在运行前 9 步后执行第 10 步时发生的重要集成缺陷。例如，如果您创建一个帐户，然后立即搜索酒店，您的应用程序可能会出错，因为它是新创建的帐户，但是如果您从只是尝试搜索酒店房间的步骤重试它，那么它可能会起作用，因为测试失败和重新启动测试之间花费了时间， 你不会注意到这个问题。
现在，如果您必须实现这一目标，那么
每次到达检查点时创建一个日志，该日志可以是指示测试用例名称和检查点编号的简单文本文件，然后使用重试分析器运行失败的测试，在测试中查找带有测试用例名称的文本文件，如果存在，则只需将代码跳到文本文件中提到的检查点。它可以以不同的方式使用，例如，如果您的 e2e 测试如果经过 3 个应用程序，则文件可以具有测试用例名称和上次传递的应用程序名称，如果您使用了页面对象，那么您可以在文本文件中写入最后一个成功的页面对象名称并使用它继续测试。
上面的解决方案只是一个想法，因为我认为这个问题没有任何现有的解决方案。
希望这能让您了解如何开始解决此问题。
问题的可能解决方案是首先定义编写测试的方式。 我建议将一个测试规范(类)视为一个包含多个功能的 E2E 测试。 此外，建议在实现RetryOnFailure后，使用GitHub上可用的开源Spock Retry项目。
最终代码应如下所示：
@RetryOnFailure(times= 2) // times parameter is for retry attempts, default= 0
class MyEndtoEndTest1 extends GebReportingSpec {
def bookingRefNumber
def "First Feature block which cover the Test till a logical step"()
{
// your test steps here
bookingRefNumber = //assign your booking Ref here
}
def "Second Feature which covers a set of subsequent logical steps "()
{
//use the bookingRefNumber generated in the First Feature block
}
def "Third set of Logical Steps"()
{ // your test steps here
}
def "End of the E2E test "()
{ // Your final Test steps here
}
所有功能块(方法)的传递将表示 E2E 测试执行成功。
听起来您的端到端测试用例太大且太脆。 在一个脚本中需要它背后的原因是什么。
您已经说过，如果失败，您可以使用预订参考在后面的步骤中继续，这似乎是拆分测试的合乎逻辑的地方。
执行第一位，将预订参考输出到文件。 阅读第二次测试的预订参考并完成旅程，如果失败，则重试不会花费很长时间。
如果您使用测试在构建后提供快速反馈，并且测试一直失败，那么我希望将旅程拆分为较小的冒烟测试，如果需要，可以运行一些通宵端到端测试，
并根据需要重试次数。它不断失败的事实表明您的测试、环境或构建很脆弱。