.net - 组件 vs 集成 vs 功能测试

Question

最近我发现我对不同类型的测试的理解可能并不完全正确。

例如。 单元测试 正在测试一个单元，其中与其他单元的交互基于模拟(假冒、 stub )。所以，没有与文件系统、线程、时间的交互......

组件测试 ，对我来说，是围绕一个组件(更多单元)进行的测试，我同时使用了模拟和“真实”资源。我将它们都用于输入模拟和输出测试。什么似乎更合适。例如。我在 mock 当前仲裁状态的变化，但我断言事件存储在 RTDB 中。

对我来说，这些组件通常是一个应用程序的一部分。

功能测试 我考虑了在生产环境中运行的应用程序 (exe) 周围的(黑盒)测试。

嗯，这是真的还是假的？
组件测试是否仅基于模拟？如果是，为什么？我如何确定模拟足够好？
我们是否应该从功能测试中运行应用程序？为什么它与线程中应用程序主例程的 bootstrap 不同？
什么是集成测试？

我想听听其他意见，以及你是如何做到的。你有哪些测试，你如何维护它们以及你的团队中谁负责它们？

干杯!

Answer 1

你的问题有点没有重点，但我还是会尽力给出答案。

这里已经讨论了各种测试:What is Unit test, Integration Test, Smoke test, Regression Test?

然而，区分不同类型测试的主要不是 double (如模拟、 stub 等)的使用。通过不同的测试来区分它们是您追求的目标。

在 单元测试 ，目标是测试您编写的代码片段的行为是否符合您的预期。也就是说，您正在根据您对代码应该如何表现的假设来测试您的代码。加倍(模拟)只是实现这一目标的一种手段，同时确保 a) 测试所有场景(包括错误情况) b) 确定性测试结果(独立于时间/调度/环境条件) c) 快速测试构建和执行 d) 简单的测试设置 e) 不受库问题的影响(不完整、有问题，...)。如果您可以通过使用真实库来实现所有这些标准，则不必将库加倍。例如，在大多数情况下，您不会为属于您的编程语言标准库的容器库(列表、集合、映射等)创建 double 值 - 您通常只需通过使用图书馆。

识别关于如何与其他软件部分交互的误解并不是单元测试的目标。而且，由于将与您的单元交互的软件部分加倍不是强制性的但完全没问题，因此在这种情况下，您甚至无法识别此类误解:每当您将依赖项加倍时，就是根据您的理解实现加倍(可能还有你的误解)另一个组件。因此，识别关于如何与其他组件交互的误解是 的目标。集成测试 .在集成测试中，您将要测试的这些组件以及它们之间的交互组合在一起。同样，附加组件可以链接或加倍，这取决于与单元测试类似的标准。

一旦您意识到单元测试和集成测试的不同目标，您也会意识到不同的目标将导致构建不同的测试用例集。因此，单元测试套件仍然是单元测试套件，无论您是否能够接受链接真实库而不是使用 double 。

然后， (子)系统测试再次引入不同的目标，例如测试一组组件实际上是否实现了该(子)系统所需的功能。一个例子可能是组件 A 和 B 对结构列表进行操作，并且除其他外，最终列表应进行排序。现在，A 和 B 的开发人员可能会假设另一个会进行排序。并且，如果它们都不需要为自己的代码对数据进行排序，a) 两个组件都将具有单元测试套件，不测试排序的输出，并且 b) 将集成测试之间的交互A 和 B 不一定测试来自另一个的输入是否已排序。但是，通过(子)系统测试，将测试所有必需功能的存在并检测丢失的排序。同样，(子系统)测试环境中的其他组件可以链接或加倍——这两种情况都是可能的。

但是，您正在询问 组件测试 ，这很可能是(子)系统测试的同义词，或者是描述(子)系统测试和构成此(子)系统的组件的集成测试的组合的术语。而且，功能测试您提到的最有可能是在您的软件系统级别上的(子)系统测试(因此，不是子，而只是系统测试)。并且，最后按照我的理解回答这个问题，现在应该已经清楚了， double 的使用不是对测试套件进行分类的可靠标准，但测试的各自目标是。