如果测试自动化完成了预期的工作，那么当引入缺陷时，应该非常迅速地发现并修复它，希望在一个每日周期内。

如果这就是自动化套件的工作方式，那么自动化应该成为一个“障碍”，防止在已经工作和测试的代码中创建新的错误。

当你这样想的时候，一个好的自动化套件会发现很少（如果有的话）新的错误，但它应该防止新的错误被引入。

然而，间接地，自动化应该释放测试人员，以便他们可以执行其他探索性和手动测试活动，这将发现错误。

所以，测试自动化实际上确实允许发现新的错误，只是不像你期望的那样。

在 fuzzing 方面，我还没有看到这种类型的测试被广泛使用，而且我觉得它不是很有效（除了在安全测试环境中）。我认为使用测试数据生成器、使用等价方法和边界测试更有效地发现问题。

我不喜欢这种说法，因为它假定您唯一可以自动化的是回归测试。如果您将声明重写为“回归测试未发现新错误”，那么我认为它是准确的。

我经常编写发现新错误的自动化（例如性能、数据驱动或基于模型的测试）——我认为如果没有回归测试之外的某种自动化，自动化工作是不完整的。

我认为我看到其他人的回答中暗示了答案的另一部分，但没有直接指出。

通常，自动化测试的创建方式甚至是非必要的细节都被锁定并以相同的方式执行。这导致了所谓的农药悖论或雷区类比。在创建测试时会发现错误，然后发现新错误的测试效率会下降，因为测试每次都在无差异地重复完全相同的事情。在某些情况下，您可能想要这种行为 - 像 Bruce 描述的路障测试、旨在寻找某些特定数据错误的复发的回归测试等等。对于许多人来说，这似乎就是自动化，这就是传统的自动化测试“智慧”不会发现新错误的来源。在这种情况下，测试最大的错误发现效率是在创建时。在那之后，随着错误得到修复，它更多地转向“提供持续的信心”模式。它可能偶尔会发现引入的新错误，但除非对应用程序的该部分进行任何直接更改，否则它可能永远不会发现进一步的问题。

但是，可以创建测试，将它们的错误发现有效性扩展到最初创建之后。通过考虑每个测试并确定对测试至关重要的内容以及仅为方便或可重复性指定的内容，您可以利用测试的非关键方面来提供差异。

例如，我在医疗保健信息系统上工作。注册新患者的测试显然需要实际注册患者。我们可能有单独的测试，用于通过医院入院、急诊室或预先安排入院来登记患者。但是，根据测试，患者是男性还是女性，或者出生于 1930 年之前，或者我们可能会说不应该关心的所有其他方面，都可能无关紧要。我们可以创建使用给定患者记录添加的自动化，并让它每次都做同样的事情，甚至可能事先对测试数据进行了一些分析，以在整个套件中手动改变患者的某些方面，但是这个单一的测试总是可以的相同的事物具有相同的数据。然而，我们也可以将测试连接到一个假数据生成器，并在这个特定的测试场景中获得更广泛的差异，以捕捉超出我们最初识别的东西。这种方法可能需要更多的编码——除了输入的地方之外，您还需要将预期的数据值获取到进行验证的地方，处理整个代码中的差异，以及在上下文中重复性是否很重要这个测试，你 d 需要某种方法来重用特定的随机种子，或者使用带有硬编码数据的可执行测试版本或类似的东西创建一个日志文件，但测试可能会发现更多错误。在这种情况下，每次运行测试时，它都有可能发现一个新的错误，因为它在某种程度上可能是一个“新”测试。我们可能是对的，我们改变的东西真的无关紧要，在那种情况下，我们仍然不会发现任何新的错误。但是，如果我们错了，并且某些事情确实很重要，那么我们找到它的机会就比我们从不改变任何事情要好。以某种方式测试。我们可能是对的，我们改变的东西真的无关紧要，在那种情况下，我们仍然不会发现任何新的错误。但是，如果我们错了，并且某些事情确实很重要，那么我们找到它的机会就比我们从不改变任何事情要好。以某种方式测试。我们可能是对的，我们改变的东西真的无关紧要，在那种情况下，我们仍然不会发现任何新的错误。但是，如果我们错了，并且某些事情确实很重要，那么我们找到它的机会就比我们从不改变任何事情要好。

它背后的理论是自动化测试只会准确地捕捉到它测试的内容。由于有人必须手动对其进行编码，因此有人知道它将如何失败。根据这个定义，这不是一个新错误——有人在编写测试时已经知道它。

有人可能会争辩说它可以捕获新的错误，但不能捕获新的症状。其中很多取决于语义。

我还认为您关于模糊测试的观点与标准测试理念背道而驰：如果您使用相同的输入运行相同的测试，它应该具有相同的输出。模糊/随机测试将不满足此条件。这并不是说它可能不会提供有用的信息，但它不属于人们通常所说的“自动化测试”所指的范围。