组件测试

软件是借助多个模块或组件开发的。在这里，我们将探讨和讨论与 组件测试 相关的以下主题，这有助于我们理解软件测试中组件测试和产品可靠性的要求。

• 什么是组件测试？
• 组件测试的目标
• 谁执行组件测试？
• 组件测试过程
• 我们何时需要执行组件测试？
• 为什么组件测试必不可少？
• 组件测试的不同测试策略
• 组件测试示例

在深入探讨上述所有主题之前，我们非常清楚，无论如何，所有测试方法都有一个目标，因此所有这些都应该准确地执行。

什么是组件测试？

另一种软件测试类型是 组件测试。它用于单独测试所有组件以及可用性测试；还对每个特定组件进行交互式评估。它进一步被称为 模块测试或程序测试和单元测试。

为了实现组件测试，所有组件或模块都需要处于独立且可管理的状态。并且软件的所有相关组件都应该是用户可理解的。

这种类型的测试提供了一种发现所有模块中出现的缺陷的方法。并且还有助于验证软件每个组件的工作。

组件测试是 质量保证团队 执行的最常见的 黑盒测试 类型之一。

它可以单独执行，即与系统的其余部分分离。但是，它依赖于首选生命周期模型。

调试 或 测试结构工具 可用于组件测试。

在组件测试中，一旦发现错误，就可以尽快修复，而无需保留任何记录。

简单来说，我们可以说执行组件测试可确保所有应用程序组件正常工作并符合要求。组件测试在进行 集成测试 之前执行。

组件测试的目标

执行组件测试的主要目的是验证测试对象的输入/输出性能。并确保指定测试对象的功能按照所需的要求或规范正常工作。

让我们看看组件测试的一些其他重要目标

• 降低风险
• 识别组件中的缺陷/错误
• 验证组件的功能和非功能性能是否符合预期
• 建立对组件质量的信心
• 阻止缺陷逃逸到更高的测试级别

• 降低风险

组件测试的实施验证了应用程序的每个单元。并帮助开发人员识别代码中的错误并修复它们。因此，我们可以说组件测试从根本层面降低了风险的可能性。

• 识别组件中的缺陷/错误

执行组件测试的另一个重要目的是 识别源代码中的错误。此外，它还验证程序中使用的 控制流、函数、数据结构等。

• 验证组件的功能和非功能性能是否符合预期

执行组件测试的目的是验证组件的功能和非功能特性是否正常运行。

换句话说，我们可以描述为执行组件测试可确保其设计和规范按预期执行。

它可能涉及功能特性，例如 计算的正确性 和 非功能 特性，例如 探索内存泄漏。

• 建立对组件质量的信心

正如我们从组件测试的定义中理解的，它发生在单元级别，并且大多数错误在编码时就被识别和修复。

组件测试在建立对组件的信心方面起着至关重要的作用，这意味着在额外测试中更少的错误或缺陷。

• 阻止缺陷逃逸到更高的测试级别

总而言之，在组件测试中，编码错误由开发人员识别和修复。因此，组件测试减少了在更高层次测试中出现错误的可能性。

谁执行组件测试？

组件测试由 测试工程师或开发人员 在 IDE 的帮助下编写代码来执行。正如我们已经知道的，单元测试 由开发人员执行，以对特定功能或方法进行测试。

组件测试过程

组件测试过程可以通过以下七个步骤完成，如下图所示

为了更好地理解，让我们逐一讨论它们

步骤 1：需求分析

组件测试的第一步是 需求分析，其中检测与每个组件相关的用户需求。

步骤 2：测试计划

完成 需求分析 阶段后，我们将进入组件测试过程的下一步，即 测试计划。在此阶段，设计测试以评估用户/客户给出的要求。

步骤 3：测试规范

完成 测试计划阶段 后，我们将进入下一个阶段，称为 测试规范。 在这里，我们将识别需要执行和遗漏的测试用例。

步骤 4：测试实施

组件测试过程的第四步是 测试实施。 当测试用例根据用户要求或规范确定后，我们才能实施测试用例。

步骤 5：测试记录

成功完成上述所有步骤后，我们将进入下一步，即 测试记录。 在组件测试过程的此步骤中，我们有在组件测试实施期间发现的缺陷/错误的记录。

步骤 6：测试验证

成功记录错误或缺陷后，我们将进入 测试验证 阶段。它是验证产品是否符合规范的过程。

步骤 7：完成

成功完成上述所有步骤后，我们将进入组件测试过程的最后一步。在此特定步骤中，将评估结果，以交付高质量的产品。

我们何时需要执行组件测试？

当对特定应用程序进行单元测试时，我们可以进行组件测试。组件一旦开发就进行测试；因此，从被测组件中检索到的输出取决于尚未创建的其他组件。

根据 开发生命周期模型，组件测试可以与其他系统组件分离执行。

并且执行分离以阻止外部影响。因此，我们将使用 桩和驱动器 来模拟软件组件之间的接口，以测试该组件。

注意：集成测试仅在组件测试执行后进行。

组件测试中测试所有模块的主要功能，例如

为什么组件测试必不可少？

在软件测试中，组件测试起着至关重要的作用。让我们借助以下几点来理解这一点

允许详细检查

组件测试的执行允许在获取每个模块或组件后进行详细检查。

它可以完全或彻底地在实际 Web 服务器上测试所有可能的错误或缺陷。与单元测试相比，这是一个完全独特的 组件测试 事实，因为单元测试中不是每个单元都在实时服务器上测试。

早期错误检测

正如我们从上面对组件测试的解释中理解的，它可以在任何阶段实施，这有助于我们相对较早地识别和修复这些错误，因此，我们节省了金钱和大量时间。

开发团队可以在将其交给质量评估团队之前，测试组件是否存在所有可预防的错误或缺陷。

验证合同

组件测试的实施将帮助我们 验证合同，这意味着组件测试是可重复的。

所以，我们可以说组件测试是验证我们模块的最佳方式，它兑现了所有承诺。因此，任何与给定软件的集成都可以毫无不确定和疑问地执行。

组件测试的不同测试策略

根据测试级别的复杂性，组件测试分为以下两种类型。

1. 小规模组件测试 (CTIS)
2. 大规模组件测试 (CTIL)

为了更好地理解，让我们逐一讨论它们

1. 小规模组件测试 (CTIS)

一些组件测试可以在被测应用程序或软件中与其他模块一起或不与其他模块一起执行。如果组件测试与除其他模块之外的模块隔离执行，则表示为 小规模组件测试， 也表示为 CTIS。

让我们看一个示例，我们可以清楚地了解小规模组件测试的工作原理。

例如：假设我们有一个包含五个不同网页的网站。因此，单独测试每个网页并与其他组件隔离测试表示为 小规模组件测试。

2. 大规模组件测试 (CTIL)

大规模组件测试 是指我们在不与其他软件模块隔离的情况下执行组件测试。

当模块的性能流存在依赖关系时，就会发生这种类型的测试，因此，我们无法将它们分开。我们有依赖关系的那些组件尚未创建，然后我们使用复制模块而不是实际模块或组件。

注意：这些复制模块被称为桩（被调用函数）和驱动器（调用函数）。

为了更好地理解，让我们看一个 大规模组件测试 的示例。

例如

让我们假设我们有一个包含三个不同模块的 Web 应用程序：模块 P、模块 Q 和 模块 R。

在这里，开发人员创建了 模块 Q，需要对其进行测试。

但是，要完全测试 模块 Q，它的一些功能依赖于 模块 P，它的一些功能依赖于 模块 R。

因此，特定模块的性能流如下

模块 P → 模块 Q → 模块 R

此性能流意味着 模块 Q 依赖于 模块 P 和模块 R。正如我们在下图中看到的，我们有桩和驱动器，其中桩被称为 被调用函数， 驱动器被称为 调用函数。

但 模块 P 和模块 R 尚未建立。因此，在这种情况下，如果我们想完全测试 模块 Q。

因此，我们可以根据需要借助 桩和驱动器 来互换 模块 P 和 模块 R。

因此，模块 P 和模块 R 主要由 桩和驱动器 更改，它们在创建之前充当副本对象。

注意
桩：桩是从需要测试的软件模块或组件中调用的；正如我们在上图中看到的，桩由模块 P 调用。
驱动器：驱动器调用需要测试的模块/组件，正如我们在上图中看到的，驱动器调用模块 Q。

组件测试示例

假设我们有一个包含三个不同模块的 Web 应用程序，分别为 登录、主页和用户。

第一个模块（登录）已安装在测试环境中，但其他两个模块 主页和用户 需要由尚未完成的 登录模块 调用。

出于测试目的，开发人员将添加一段代码，该代码复制其余模块的调用方法。这段特定的代码称为 桩，被认为是 自顶向下方法。

如果 第二个模块（主页） 和 第三个模块（用户） 已准备就绪，但 登录 模块尚未开发，并且两个组件都从登录模块获取返回值，则开发人员将添加一段复制登录模块的代码。

这段特定的代码称为 驱动器，被认为是 自底向上方法。

结论

在本节中，我们深入讨论了 组件测试。而且，我们可以得出结论，它是一种精确估算任何模块在开发任何阶段功能的准确方法。

在软件开发中，组件测试是节省成本的，并且通过消除所有可避免的错误，避免了未来阶段不必要的麻烦。

最后，我们可以说 单元测试和组件测试 同时执行。与开发团队执行的单元测试相反，组件/模块测试由测试团队执行。

始终建议在开始 集成测试 之前完成组件测试。因为如果组件测试准确，我们将在集成测试期间发现更少的缺陷。