回归测试是整个测试套件还是测试样本？

Question

我被告知回归测试是整体测试的一个小样本（仅足以证明引入更改或新模块时没有破坏任何内容）。然而， 本文 罗恩·莫里森和格雷迪·布奇的著作让我有不同的想法：

理想的策略是一次引入每个单元，执行广泛的回归测试，纠正任何缺陷，然后继续进行下一个单元。

同一份文件还说：

一旦添加少量单元，就会生成测试版本并进行“冒烟测试”，其中运行少量测试以获得集成产品将按预期运行的信心。目的既不是彻底测试新单元，也不是对整个系统进行完全回归测试。

在描述烟雾测试时，作者是这样说的：

同样重要的是，冒烟测试对整个系统进行快速检查，而不仅仅是新组件。

我从未见过“广泛”和“回归测试”一起使用，也从未见过被描述为“对整个系统进行完全回归测试”的回归测试。回归测试应该尽可能轻松、快速。冒烟测试的定义就是我学到的回归测试的定义。

我是否误解了我所教的内容？难道是我教错了？或者说“回归测试”有多种解释？

Answer 1

有多种解释。如果您只修复影响系统一小部分的错误，那么回归测试可能只包含一小部分测试，可以运行相关的类或包。如果您正在修复错误或添加范围更广的功能，那么您的回归测试也应具有更广泛的范围。

“如果它可能破裂，测试它”经验法则适用于此。如果 Foo 中的更改可能会影响 Bar ，则运行两者的回归。

回归测试只是检查更改是否导致先前通过的测试失败。它们可以在任何级别（单元，集成，系统）运行。 参考。

Answer 2

我总是采用回归测试来表示任何测试，其目的是确保现有功能不会被新的更改破坏。这并不意味着对测试套件的大小有任何限制。

Answer 3

回归通常用于指整套测试。这是QA在发布之前做的最后一件事。它用于表明过去工作的所有东西仍然可以工作，达到可以显示的程度。根据我的经验，它通常是系统范围的测试集，无论变化有多小（尽管小的变化可能不会触发回归测试）。

Answer 4

在我工作的地方，每个版本在每个版本结束时对每个应用程序进行标准化。它们旨在测试所有功能，但它们并非旨在捕获微妙的错误。因此，如果您有一个对其进行了各种验证的表单，例如，该表单的回归套件将确认每种类型的验证都已完成（字段级别和表单级别），并且可以提交正确的信息。它的设计并不是为了涵盖每一个案例（例如，如果我将字段A留空，怎么办？字段B如何？它只测试其中一个并假设其他工作）。

然而，在我正在进行的当前项目中，回归测试更加彻底，我们注意到测试期间引发的缺陷数量减少了。这两者并不一定相关，但我们确实相当一致。

Answer 5

我对“回归测试”一词的理解是：

• 单元测试是在系统创建时编写的，用于测试功能
• 当发现错误时，会编写更多的单元测试来重现错误并验证它是否已得到纠正
• 回归测试运行整套测试，证明一切仍然有效，包括没有再次出现旧的错误[即证明代码没有“回归”]

在实践中，最好在发生更改时始终运行所有现有的单元测试。我唯一会费心测试子集的时候是完整的单元测试套件运行“太长”的时间[其中“太长”是相当主观的]

Answer 6

从你想要完成的事情开始。然后做你需要做的事来实现这个目标。然后使用流行语宾果为你实际做的事情分配一个词。就像其他人一样:-)准确性并不是那么重要。

Answer 7

  

...回归测试很小（仅足以证明你没有通过引入变更或新模块来破坏任何东西）整体测试样本

如果一小部分测试样本足以证明系统有效，为什么其他测试甚至存在呢？如果您认为您知道您的更改只影响了一部分功能，那么为什么在进行更改后需要测试任何内容？人类是错误的，没有人真正知道改变某些东西会破坏其他东西。 IMO，如果您的测试是自动化的，请重新运行它们。如果它们不是自动化的，则自动化它们。与此同时，重新运行任何自动化的东西。

Answer 8

通常，产品版本X中引入的新功能的一部分功能测试成为版本X + 1，X + 2等的回归测试的基础。随着时间的推移，您可以减少功能/回归测试对没有退回的稳定特征所花费的时间。如果某个功能遭受大量回归，那么增加对功能的重视可能会有所帮助。

我认为引用“广泛回归测试”的文章意味着进行一系列（单独简单的）回归测试。