我们正在尝试为预订应用程序自动化端到端测试用例，每个测试用例涉及大约 60 多个步骤。每当最后步骤出现故障时，如果我们选择传统的重试选项，就会非常耗时，因为测试用例将再次从步骤 1 开始执行。在应用程序上，我们有一些可以以某种方式标记的逻辑步骤，我们希望通过这些步骤从失败步骤之前的逻辑点恢复测试用例。例如，在 60 个步骤中，每第 10 个步骤是一个逻辑点，在该点可以恢复脚本，而不是从第 1 步重试。如果失败在第 43 行，则在预订引用号的帮助下进行测试可以从第 41 步继续，因为验证已经完成，直到第 40 步(第 40 步是一个逻辑关闭点)。您可能会建议将测试用例拆分为更小的模块，这对我来说不起作用，因为它是我们希望在单个 Geb 规范中拥有的应用程序的 E2E 测试用例。该框架是使用 Geb & Spock 构建的，用于 Web 应用程序自动化。请就我们如何为这种情况构建恢复方案分享您的想法/逻辑。感谢您的支持!
到目前为止，我还没有找到解决此类问题的方法。
最佳答案
以下是可以实现相同目标的几件事，但在我们讨论解决方案之前，我们还应该讨论它将产生的问题。您正在运行 E2E 测试用例，如果它们在第 10 步失败，那么它们应该从头开始而不是从第 10 步开始，因为您可能会错过重要的集成缺陷，这些缺陷在运行前 9 步后执行第 10 步时发生。例如如果您创建一个帐户然后立即搜索酒店，您的应用程序可能会出错，因为它是一个新创建的帐户，但如果您从您只是尝试搜索酒店房间的步骤重试它，那么它可能会工作，因为从测试失败到重新开始测试所花费的时间，您不会注意到这个问题。
现在如果你必须实现这个那么
每次到达检查点时创建一个日志，它可以是一个简单的文本文件，指示测试用例名称和检查点编号，然后使用重试分析器运行失败的测试，在测试中查找带有测试的文本文件案例名称，如果存在则简单地将代码跳到文本文件中提到的检查点。它可以以不同的方式使用，例如如果您的 e2e 测试通过 3 个应用程序，那么文件可以包含测试用例名称和最后通过的应用程序名称，如果您使用了页面对象，那么您可以在文本文件中写入最后成功的页面对象名称，并使用它来继续测试。
以上解决方案只是一个想法，因为我认为没有任何现成的解决方案可以解决这个问题。
希望这能让您了解如何着手解决这个问题。
关于testing - 从 E2E 自动化的逻辑点重试失败的自动化测试用例，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55480109/