Question

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

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

Answer 1

以下是实现相同目标的几种方法，但是在我们讨论解决方案之前，我们还应该讨论它将带来的问题。您正在运行E2E测试用例，如果它们在步骤10失败，则应该从头开始而不是从步骤10开始，因为您可能会错过在运行前9个步骤后执行第10个步骤时发生的重要集成缺陷。例如如果您创建了一个帐户然后立即搜索酒店，则您的应用程序可能会因为输入新创建的帐户而出错，但是如果您从尝试搜索酒店房间的步骤中重试该应用程序，则该应用程序可能会工作，因为从测试失败到重新启动测试所花费的时间，您将不会注意到此问题。

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

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

以上解决方案只是一个主意，因为我认为没有解决此问题的现有解决方案。

希望这会给您一个有关如何开始解决此问题的想法。

Answer 2

听起来您的端到端测试用例太大又太脆。在一个脚本中全部需要它的原因是什么？

您已经说过，如果预订失败，可以使用预订参考继续进行下一步，这似乎是拆分测试的合理位置。

执行第一位，将预订参考输出到文件中。阅读第二次测试的预订参考并完成旅程，如果失败，那么重试将不会花费很长时间。

如果您在构建后使用测试提供快速反馈并且测试始终失败，那么我希望将旅程分成更小的烟雾测试，并且如果需要，可以进行一整夜的端到端测试，并进行与您一样多的重试喜欢。

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

Answer 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测试成功执行。

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

3 个答案: