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

Question

我被告知，回归测试很小（仅足以证明你没有通过引入变更或新模块来破坏任何东西）整体测试的样本。然而，Ron Morrison和Grady Booch的this article让我有不同的想法：

  

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

同一份文件也说：

  

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

在描述烟雾测试时，作者说：

  

烟雾测试对整个系统进行快速检查也很重要，而不仅仅是新组件。

我从未见过一起使用“广泛”和“回归测试”，也没有将回归测试描述为“完全回归测试整个系统”。回归测试应该尽可能轻松快速。烟雾测试的定义是我学到的一种回归测试。

我是否误解了我的教学内容？我教的不正确吗？或者对“回归测试”有多种解释？

Answer 1

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Answer 5

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

• 在创建系统时将单元测试写入测试功能
• 发现错误时，会编写更多单元测试来重现错误并验证错误已被更正
• 回归测试运行整套测试证明一切仍然有效，包括没有旧错误再次出现[即证明代码没有“退化”]

实际上，最好在进行更改时始终运行所有现有的单元测试。唯一一次我打扰测试子集的时候是完整的单元测试套件需要“太长时间”来运行[其中“太长”是相当主观的]

Answer 6

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

Answer 7

  

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

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

Answer 8

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

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