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

【问题标题】：Are regression tests the entire test suite or a sample of tests?回归测试是整个测试套件还是测试样本？
【发布时间】：2008-10-30 16:14:55
【问题描述】：

我被告知，回归测试只是整体测试的一个小样本（仅足以证明您没有因引入更改或新模块而破坏任何东西）样本。然而，Ron Morrison 和 Grady Booch 的 this article 让我有了不同的想法：

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

同一份文件还说：

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

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

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

我从未见过同时使用“广泛”和“回归测试”，也从未见过将回归测试描述为“对整个系统进行完全回归测试”。回归测试应该尽可能简单和快速。烟雾测试的定义就是我学到的回归测试。

我是否误解了我所教的内容？是不是我教错了？还是对“回归检验”有多种解释？

【问题讨论】：

标签： testing regression-testing smoke-testing

【解决方案1】：

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

“如果它可能损坏，请测试它”的经验法则在这里适用。如果 Foo 的更改可能会影响 Bar，则对两者运行回归。

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

【讨论】：

好吧，我了解到回归测试应该做两件事。 (1) 更改的组件应经过良好测试。 (2) 系统的任何关键组件，即使是未更改的组件，也应在回归测试中进行测试。
这不是一个坏规则。但是，如果每个组件突然变得“关键”，请当心。
好吧，你必须定义“关键”。但是是的。

【解决方案2】：

我一直认为回归测试是指任何旨在确保现有功能不会被新更改破坏的测试。这并不意味着对测试套件的大小有任何限制。

【讨论】：

【解决方案3】：

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

【讨论】：

您在描述系统测试或系统集成测试。回归测试只是检查之前通过的测试是否失败，并且可以随时运行。
tloach 和 Elie 描述的是同一件事，我怀疑他们在同一家公司工作。这描述了第一次运行测试的模型，然后是修复等，以及发货前的最终回归测试阶段。在这里使用“回归”这个词是完全正确的。
“回归”并不意味着整套测试。这意味着重新运行现有测试以查看新代码是否破坏了它们。这并不（必然）意味着您必须运行整个套件，但它可以。我只是指出一个细微的差别。
虽然@BilltheLizard 的描述正确，但我认为这取决于组织。在我的组织中，受影响区域通常在回归中进行测试。但是，有时上级管理层坚持要我们完全回归。

【解决方案4】：

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

但是，在我正在进行的当前项目中，回归测试更加彻底，我们注意到测试期间出现的缺陷数量有所减少。这两者不一定相关，但我们确实注意到它相当一致。

【讨论】：

这是系统（集成）测试。
不，不是。系统（集成）测试是针对新功能的。回归测试是针对我们在当前构建期间没有更改的内容。随着我们添加更多功能，我们的回归测试套件不断增长。
回归测试是为了测试新代码没有破坏之前通过的测试。您正在描述系统测试。
现在我们进入语义论证。这很愚蠢。 Elie 完全正确，这些测试在她工作的地方和我曾经工作的地方都被认为是回归测试，同样的事情。单词意味着事情，而且通常同一个单词意味着不止一件事。
回归测试的范围比单元、集成和系统测试的范围更广。它可以在任何这些级别上完成。单词确实有意义，既然这是一个公共论坛，我们应该尝试使用最广泛接受的定义。

【解决方案5】：

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

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

在实践中，最好在进行更改时始终运行所有现有的单元测试。我唯一会为测试子集烦恼的是，当完整的单元测试套件需要“太长时间”才能运行时[其中“太长”是相当主观的]

【讨论】：

【解决方案6】：

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

【讨论】：

清晰的沟通很重要。如果我们使用相同的字典会有所帮助。

【解决方案7】：

...回归测试是整体测试的一个小样本（仅足以证明您没有因引入更改或新模块而破坏任何东西）

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

【讨论】：

【解决方案8】：

一般来说，产品版本 X 中引入的新功能的功能测试子集成为版本 X+1、X+2 等回归测试的基础。随着时间的推移，您可以减少未遭受回归的稳定特征的特征/回归测试所花费的时间。如果一个特征有很多回归，那么增加对该特征的强调可能是有益的。

我认为提到“广泛回归测试”的文章意味着运行一组广泛的（个别简单的）回归测试。

【讨论】：