我们正在尝试为预订应用程序自动化E2E测试用例，每个测试用例涉及大约60多个步骤。每当最后一步出现故障时，如果我们选择传统的重试选项，则非常耗时，因为测试用例将再次从步骤1开始执行。在应用程序中，我们有一些逻辑步骤可以通过某种方式标记，我们希望通过这些步骤从失败步骤之前的逻辑点恢复测试用例。例如，在60个步骤中说，每10步是一个逻辑点，其中脚本可以恢复而不是从步骤1重试。如果失败是在第43行，那么在预订参考号的帮助下测试因为验证已经完成直到步骤40（步骤40是逻辑闭合点），所以可以从步骤41恢复。您可能建议将测试用例拆分为较小的模块，这对我来说不起作用，因为它是我们希望在单个Geb规范中使用的应用程序的E2E测试用例。该框架使用Geb＆Spock构建，用于Web应用程序自动化。请分享您关于如何为此案例构建恢复方案的想法/逻辑。感谢您的支持。！
截至目前，我无法找到解决此类问题的方法。
以下是可以实现相同目标的一些事项，但在我们讨论解决方案之前，我们还应该讨论它将产生的问题。您正在运行E2E测试用例，如果它们在步骤10中失败，那么它们应该从头开始而不是从步骤10开始，因为您可能会错过在执行前9个步骤后执行第10步时发生的重要集成缺陷。对于例如如果你创建一个帐户，然后立即搜索酒店，你的应用程序可能会因为它是一个新创建的帐户而出错，但如果你从一个只是试图搜索酒店房间的步骤重试它，那么它可能会起作用，因为在测试失败和重新开始测试之间花费的时间，您将不会注意到此问题。
现在，如果你必须实现这一点
每次到达检查点时都创建一个日志，该检查点可以是一个简单的文本文件，指示测试用例名称和检查点编号，然后使用重试分析器运行失败的测试，在测试中查找带有测试用例名称的文本文件，如果它存在，那么简单地跳过代码到文本文件中提到的检查点。它可以以不同的方式使用，例如，如果您的e2e测试通过3个应用程序然后文件可以有测试用例名称和最后传递的应用程序名称，如果您已经使用了页面对象，那么您可以在文本文件中写入最后一个成功的页面对象名称并使用它来继续测试。
以上解决方案只是一个想法，因为我不认为这个问题有任何现有的解决方案。
希望这能让您了解如何开始解决此问题。
解决问题的可能方法是首先定义编写测试的方式。我建议将一个测试规范（类）作为一个包含多个功能的E2E测试。此外，建议在实施RetryOnFailure后使用GitHub上提供的opensource 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
}
所有Feature块（方法）的传递将表示E2E测试执行成功。
听起来你的端到端测试用例太大太脆了。在一个脚本中需要它的原因是什么？
您已经声明如果失败，您可以使用预订参考继续以后的步骤，这似乎是分割您的测试的合理位置。
执行第一位，将预订参考输出到文件。阅读第二次测试的预订参考并完成旅程，如果失败，则重试不会接近任何时间。
如果您在构建之后使用测试来提供快速反馈并且测试仍然失败，那么我会将旅程分成更小的冒烟测试，如果需要，可以使用尽可能多的重试进行一夜之间的端到端测试。
它一直失败的事实表明你的测试，环境或构建是脆弱的。