组件vs集成vs功能测试

Question

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

例如，单元测试是对一个单元的测试，其中与其他单元的交互基于模拟（假冒，存根）。因此，无需与文件系统，线程，时间交互...

对我而言，组件测试是围绕一个组件（更多单元）进行的测试，在该组件中我同时使用了模拟和“实际”资源。我都将它们都用于输入仿真和输出测试。似乎更合适的东西。例如，我在嘲笑当前仲裁状态的更改，但是我断言事件存储在RTDB中。

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

我认为功能测试围绕生产环境中运行的应用程序（exe）进行（黑盒）测试。

好吧，这是真的吗？组件测试是否仅基于模拟？如果是，为什么？我如何确定模拟足够好？我们是否应该通过功能测试运行应用程序？为什么与线程中的应用程序主例程的引导不同？什么是集成测试？

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

干杯!

Answer 1

您的问题有些侧重，但我仍将尝试给出答案。

这里已经讨论了各种测试：什么是单元测试，集成测试，冒烟测试，回归测试？

但是，并不是主要使用双打（例如模拟，存根等）来区分不同类型的测试。您通过不同测试所追求的目标将它们与众不同。

在单元测试中，目标是测试所编写的代码段是否按预期运行。也就是说，您正在根据对代码行为的假设进行测试。加倍（模拟）只是实现此目标的一种手段，同时确保a）测试所有场景（包括错误情况）b）确定性测试结果（独立于时间/计划/环境条件）c）快速测试建立和执行d）简便的测试设置e）独立于库问题（不完整，有故障的...）。如果您可以通过使用实际库满足所有这些条件，则不必将库加倍。例如，在大多数情况下，您不会为容器库（列表，集合，地图等）创建双打，而容器库是编程语言的标准库的一部分-通常，仅需达到所有单元测试目标使用图书馆。

识别关于如何与其他软件部件交互的误解不是单元测试的目标。并且，由于不是强制性的，而是将与您的单元交互的软件部分加倍，因此在这种情况下，您甚至将无法识别这样的误解：每当将一个依赖项加倍时，您将根据自己的理解来实现加倍（以及您可能的误解）。因此，识别关于如何与其他组件交互的误解是集成测试的目标。在集成测试中，您将那些组件（要测试的组件之间的交互）组合在一起。同样，可以根据与单元测试类似的标准，将其他组件链接或加倍。

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

然后，（子系统）测试再次带来不同的目标，例如测试一组组件是否一起真正实现了该（子）系统的必需功能。一个例子可能是组件A和B在一个结构列表上运行，并且除其他外，最终列表应进行排序。现在，A和B的开发人员可能会假设另一个将进行排序。并且，如果它们都不要求对数据进行排序以用于其自己的代码，则a）两个组件都将具有不测试正在排序的输出的单元测试套件，并且b）将进行集成测试，以测试之间的交互A和B不一定测试来自另一个的输入是否已排序。但是，通过（子系统）测试，将测试所有必需功能的存在，并检测缺失的类别。再次，

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