如何识别回归测试？

Question

当我们收到新的构建时，我们如何在整个测试套件中检测到合适的回归测试用例？

对于这样的选择，有什么有用的策略？

Answer 1

这没有一个答案；它取决于代码的状态和测试的级别。

在较高的层次上，回归测试是针对目前在产品中工作的东西而进行的测试，并且应该在将来继续以同样的方式工作。因此，为了识别回归测试，您需要识别程序中不需要更改的部分。

对于我测试的大部分内容来说，这很容易，因为我的公司承诺，任何针对支持的接口编写的代码都会正常工作。因此，我们的回归桶至少由所有测试用例组成，测试对象被指定为受支持的接口。如果您正在测试某个公开API或以某种方式可调用的产品，则应该能够执行类似的操作，如果这些接口应该是稳定的。

然而，并不是所有的公司/项目/产品都做出同样的承诺，在这种情况下，您不一定可以使用以前测试过接口的测试用例作为回归套件(虽然理想情况下，如果有API，应该提供文档说明您可以使用的/尚未更改的接口，而不是改变现有的接口，而是创建新的接口/扩展现有的接口)。

根据您对外部库的使用，您还可以考虑为这些库将回归测试用例放在一起，以防它们进行某种不兼容的更改，而这些更改没有文档化。

Answer 2

那得看情况。

每个应用程序都是不同的。每个组织都是不同的。每个组织和应用程序都有不同的风险承受能力，这决定了您的测试用例中有多少需要成为回归套件的一部分。

在一个极端，任何没有被应用程序更改所反对的测试用例都是回归测试套件的一部分。当软件/组织的风险承受能力很低时(例如医疗设备软件、财务软件等)，就会发生这种情况。

在另一个极端，如果有任何倒退发生，这充其量是一个烟雾测试。

根据我的经验，大多数地方都在中间，对应用程序中最关键、影响最大的部分执行回归。它们到底走得多远，取决于组织、所使用的工具以及应用程序的性质。

Answer 3

找到一组好的回归测试用例可能需要对一个领域有很好的理解。您可能不希望为回归选择任意数量的测试用例，这在生产中可能不是很常见的场景。您可能希望得到BA或解决方案设计团队的帮助，以了解最重要和最常见的场景。许多项目遵循RBT (基于风险的测试)方法来确定测试用例的优先级。RBT定义了失败的可能性和失败的影响。这两个参数可以为团队找到最重要的场景提供良好的起点。

以下标准(但不限于)可用于选择回归测试用例。

1. 触及AUT的大部分功能点的场景
2. 在生产中更常见的情景(基于数量或市场数据)
3. 验证应用程序或产品的核心特性的方案
4. 可能会失败的复杂场景
5. 与最近发生变化的功能有关的情景