从 E2E 自动化的逻辑点重试失败的自动化测试用例

Question

我们正在尝试为预订应用程序自动化 E2E 测试用例，每个测试用例涉及大约 60 多个步骤。每当最后步骤出现故障时，如果我们选择传统的重试选项，将会非常耗时，因为测试用例将再次从步骤 1 执行。在应用程序上，我们有一些逻辑步骤，可以通过它们以某种方式标记，我们希望通过这些步骤来实现从失败步骤之前的逻辑点恢复测试用例。例如，在 60 个步骤中，假设每第 10 步是一个逻辑点，在该点可以恢复脚本，而不是从第 1 步重试。假设失败出现在第 43 行，那么在预订参考号的帮助下进行测试可以从第 41 步恢复，因为验证已经完成直到第 40 步（第 40 步是一个逻辑结束点）。您可能会建议将测试用例拆分为更小的模块，这对我不起作用，因为它是我们希望在单个 Geb Spec 中拥有的应用程序的 E2E 测试用例。该框架是使用 Geb & Spock 构建的，用于 Web 应用程序自动化。请分享您对我们如何为这种情况构建恢复方案的想法/逻辑。感谢您的支持！

到目前为止，我无法找到解决此类问题的任何方法。

Answer 1

以下是可以做的几件事，但在我们讨论解决方案之前，我们还应该讨论它会产生的问题。您正在运行 E2E 测试用例，如果它们在第 10 步失败，那么它们应该从头开始，而不是从第 10 步开始，因为您可能会错过在运行前 9 步后执行第 10 步时发生的重要集成缺陷。例如如果您创建一个帐户然后立即搜索酒店，您的应用程序可能会出错，因为它是一个新创建的帐户，但是如果您从尝试搜索酒店房间的步骤重试它，那么它可能会起作用，因为测试失败和重新开始测试之间花费的时间，您不会注意到这个问题。

现在如果你必须做到这一点，那么

每次到达检查点时创建一个日志，可以是一个简单的文本文件，指示测试用例名称和检查点编号，然后使用重试分析器运行失败的测试，在测试中查找带有测试的文本文件案例名称，如果存在则简单地跳过代码到文本文件中提到的检查点。它可以以不同的方式使用，例如如果您的 e2e 测试通过 3 个应用程序，则文件可以包含测试用例名称和最后通过的应用程序名称，如果您使用了页面对象，那么您可以在文本文件中写入最后成功的页面对象名称并使用它来继续测试。

以上解决方案只是一个想法，因为我认为这个问题没有任何现有的解决方案。

希望这能让您了解如何着手解决这个问题。

Answer 2

您的问题的可能解决方案是首先定义您想要编写测试的方式。 我建议将一项测试规范（类）视为一项包含多个功能的 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
}

所有功能块（方法）的通过将意味着成功的端到端测试执行。

Answer 3

听起来您的端到端测试用例太大太脆弱。在一个脚本中需要所有内容的原因是什么。

您已经说过，如果失败，您可以使用预订参考在稍后的步骤继续，这似乎是拆分测试的合乎逻辑的地方。

首先，将预订参考输出到文件。阅读第二次测试的预订参考并完成旅程，如果失败，那么重试不会花费任何时间。

如果您在构建后使用测试来提供快速反馈并且您的测试一直失败，那么我希望将整个旅程分成较小的冒烟测试，如果需要，运行一些通宵的端到端测试，重试次数尽可能多随你喜欢。

它不断失败的事实表明您的测试、环境或构建很脆弱。