我被告知回归测试只是整体测试的一个小样本（仅足以证明您没有通过引入更改或新模块而破坏任何东西）样本。然而， Ron Morrison 和 Grady Booch 的这篇文章让我有不同的想法：
理想的策略是一次将每个单元纳入一个单元，执行广泛的回归测试，纠正任何缺陷，然后继续下一个单元。
同一份文件还说：
一旦添加了少量单元，就会生成测试版本并进行“冒烟测试”，其中运行少量测试以获得集成产品将按预期运行的信心。目的既不是彻底测试新单元，也不是完全回归测试整个系统。
在描述冒烟测试时，作者是这样说的：
同样重要的是，烟雾测试对整个系统进行快速检查，而不仅仅是新组件。
我从未见过一起使用“广泛”和“回归测试”，也从未见过被描述为“对整个系统进行完全回归测试”的回归测试。回归测试应该尽可能简单和快速。烟雾测试的定义是我学到的回归测试。
我误解了我所教的内容吗？是不是我教错了？还是对“回归测试”有多种解释？
有多种解释。如果您只修复影响系统一小部分的错误，那么回归测试可能只包括一小套测试相关类或包的测试。如果您要修复错误或添加范围更广的功能，那么您的回归测试也应该有更广泛的范围。
“如果它可能会损坏，请测试它”的经验法则适用于此。如果变化Foo可能影响Bar，则对两者运行回归。
回归测试只是检查更改是否导致先前通过的测试失败。它们可以在任何级别（单元、集成、系统）运行。 参考。
我一直认为回归测试是指任何旨在确保现有功能不会被新更改破坏的测试。这并不意味着对测试套件的大小有任何限制。
回归通常用于指代整套测试。这是 QA 在发布之前所做的最后一件事。它用于表明曾经有效的一切仍然有效，在可以显示的范围内。以我的经验，它通常是一组系统范围的测试，无论变化有多大（尽管小的变化可能不会触发回归测试）。
在我工作的地方，在每个版本结束时，每个应用程序的回归测试都是标准化的。它们旨在测试所有功能，但并非旨在捕获细微的错误。因此，例如，如果您有一个对其进行了各种验证的表单，则该表单的回归套件将确认每种类型的验证都已完成（字段级别和表单级别）并且可以提交正确的信息. 它并非旨在涵盖每一种情况（即，如果我将字段 A 留空怎么办？字段 B 怎么样？它只会测试其中一个并假设其他情况有效）。
但是，在我正在进行的当前项目中，回归测试更加彻底，我们注意到测试期间出现的缺陷数量有所减少。这两者不一定相关，但我们确实注意到它相当一致。
我对“回归测试”一词的理解是：
在实践中，最好在进行更改时始终运行所有现有的单元测试。我唯一会打扰测试子集的时间是完整的单元测试套件需要“太长时间”才能运行[其中“太长”是相当主观的]
从你想要完成的事情开始。然后做你需要做的事情来实现这个目标。然后使用流行语宾果游戏来给你实际做的事情分配一个词。就像其他人一样:-) 准确性并不是那么重要。
...回归测试是整体测试的一个小样本（仅足以证明您没有通过引入更改或新模块而破坏任何东西）样本
如果一小部分测试就足以证明系统有效，那为什么剩下的测试还存在呢？如果您认为您知道您的更改只影响了一部分功能，那么为什么您需要在进行更改后测试任何内容？人类是容易犯错的，没有人真正知道改变某些东西是否会破坏其他东西。IMO，如果您的测试是自动化的，请重新运行它们。如果它们不是自动化的，就将它们自动化。同时，重新运行自动化的任何内容。
通常，针对产品版本 X 中引入的新功能的一部分功能测试成为版本 X+1、X+2 等回归测试的基础。随着时间的推移，您可以减少未遭受回归的稳定特征的特征/回归测试所花费的时间。如果一个特征遭受大量回归，那么增加对该特征的强调可能是有益的。
我认为提到“广泛回归测试”的文章意味着运行一组广泛的（个别简单的）回归测试。