什么是集成测试？

集成测试的概念引发了几个问题。第一个问题是是否需要集成测试。这个问题的答案至少部分取决于相关公司。与公众互动有限的小型组织可以不进行集成测试。

然而，对于任何与公众广泛合作的公司来说，集成测试变得越来越重要。如果是一家需要发布新软件应用程序和工具的科技公司，集成测试就更为重要。

有句谚语说，一个人永远不会有第二次机会给人留下良好的第一印象。同样的理念也适用于当代公司。他们中的大多数都在拼命地吸引用户，将他们转变为常规订阅者或消费者，并与他们保持成功且有利可图的持续关系。此类公司在推出重磅新程序或应用时不能犯太多错误。

从安装到与其他程序和系统交互的方式，消费者希望相关技术能够像宣传的那样运作。因此，对于许多组织来说，集成测试是开展业务的必要步骤。

简而言之，集成测试的目标是确保各个部分和系统能够可靠地协同工作。但从公关角度来看，集成测试的另一目标在于助力维护组织在当今商业环境中作为一家有能力可靠开展业务的负责任企业的形象。

集成测试这个术语是随着时间的推移而发展的，用于描述某些瀑布式方法。早期，软件模块和相关项目是在“真空”中创建的，这样 QA 团队就需要单独测试代码库的各个组成部分，并在将其引入软件系统之前分析这些测试结果，因此需要完成大量繁琐的工作。

集成测试是通过创建和评估测试用例来完成的。第一阶段涉及成功识别集成点，即应用程序中不同模块交互的区域。当整合点建立后，测试用例就围绕它们设计。这些测试用例是为了展示整合点是如何根据各种输入场景、真实情况和预期结果运作的。

借助从测试覆盖率中收集到的数据，项目利益相关方能够对代码库（所有项目数据都存储于此）做出必要调整。

集成测试中使用的测试用例可帮助开发人员集中精力于几个特定的操作领域：

集成测试的另一个增加其整体复杂性的方面涉及依赖关系，即模块和/或组件之间存在的关系。典型的依赖关系要求一个组件要发挥作用，相关组件必须首先按需求运行。在试图理清程序执行过程中可能出现的问题时，必须考虑这些依赖关系。

执行集成测试时执行的单个测试步骤有一个标准顺序，因为这样的有序顺序为开发人员提供了一种以结构化方式系统评估不同代码片段的方法。测试顺序通常从检查最简单的单个组件开始，在低级模块中的错误对运营造成负面影响之前将之纠正。然后，测试将移动到更复杂的集成领域并评估其性能。

除了尽早发现漏洞之外，常规测试流程采用逻辑推进的方式，模拟代码的数据流，确保以正确的顺序对组件交互进行测试。此外，测试流程会为针对低层级模块、重要性较低的测试分配较低优先级，让开发人员能够将精力集中在最关键的操作上。

在传统的测试顺序中，测试格式按以下顺序检查：

1. 单元测试，它可评估单个功能。
2. 集成测试，用于观察组件之间的交互情况。
3. 系统测试，可用于确定整个系统的整体功能。
4. 验收测试，则是从用户视角对功能进行检查。

集成测试并非这一标准流程中的初始测试步骤。集成测试之所以在流程中处于当前阶段，是因为各个组件之间的交互测试已通过单元测试完成。接下来的系统测试阶段，会将测试的规模范围进一步扩大，让测试人员从更宏观的视角审视整个系统以及各部分协同工作的效果。

集成测试技术种类繁多，但以下几种是最常用于评估软件系统的。

自上而下的方法是增量集成测试的两种主要类型之一。它侧重于主模块及其工作，然后评估子模块和子例程。这种方法最强大的特性之一是它可以在流程早期使用，甚至在较低级别模块被完全识别之前。测试人员可以使用占位符（称为“桩”）来替代底层模块。

集成测试的另一个主要示例是自下而上的集成测试，它会切换集成测试序列的顺序。在自下而上的方法中，子模块和子例程是首先被评估的。然后，这种方法继续测试主模块。正如自上而下的测试在需要时使用桩作为占位符一样，自下而上的集成测试使用称为驱动模块的临时模块来替代尚未确定的高级组件。

混合集成（有时也称为“三明治集成”）结合了自顶向下和自底向上两种方法。混合集成的主要优势在于它克服了自顶向下和自底向上测试（这两种方法间接相反）所受到的强制过程顺序限制。采用混合集成时，测试可以根据用户需求，从主模块开始，也可以从子模块和子例程开始。

进行集成测试的另一个关键方法是大爆炸集成测试。在这种方法中，系统中的所有单个单元、组件和模块都会同时进行集成和测试，就好像它是一个单元一样。当系统与其所有部件一起工作时，大爆炸测试可以提供快速答案。

然而，这种测试形式存在局限性。如果测试过程显示系统未能按预期运行，大爆炸集成测试将无法揭示具体是哪些独立部分未能协同工作。

以下是一些流行的集成测试方法。由于这些方法都有可能成为软件公司根据自身需求采用的正确方法，因此以下按字母顺序列出：

• API 集成测试：应用程序编程接口 (API) 是计算的重要组成部分，它允许软件应用程序相互连接接口并成功共享数据。API 测试是一种软件测试手段，用于检查系统中的不同 API 如何协同工作。其目标是见证它们顺畅地运行，就好像这些 API 是单个有组织单元的一部分一样。API 之间的运作越顺畅，整个系统就运转得越好。

• 自动化集成测试：作为软件开发过程的重要组成部分，自动化测试是另一种评估软件组件如何协同工作的方法。该集成测试过程基于专门的测试工具和脚本运行测试用例。通过此方式，可以在部署之前发现并修复集成问题。而且，由于它是自动化的，整个系统会变得更加高效和敏捷。自动化测试是“持续集成”这一 DevOps 实践的关键要素，而持续集成依赖于共享存储库来存储不断更新的代码变更。

• 黑匣测试：“黑匣”这一比喻可以应用于任何情况，即在这些情况下，我们理解黑匣（无论涉及计算机代码还是其他操作方面，例如公司报告的盈利情况）的内部工作原理并不需要被完全理解。在黑匣集成测试的情况下，这意味着测试人员并不想深入研究不同模块内部使用的具体代码；相反，他们更希望获得一个更简单、更快速的答案，即系统、组件和模块能否和谐地协同工作。

• 端到端测试：顾名思义，端到端测试（有时也称为 E2E 测试）为测试人员提供了一种从头到尾检查整个系统功能的方法。除此之外，E2E 测试还可模拟真实测试场景，并通过合并确定要测试哪些单元的测试计划来为集成测试奠定基础。E2E 测试通常出现在集成测试过程的后期，在集成测试完成之后、用户验收测试之前。

• 功能测试：在所有软件测试类型中，最专注于了解系统纯粹功能的是功能集成测试 (FIT)。FIT 能够验证不同模块或组件能否按需交互，其价值在于能够在软件开发生命周期的早期阶段定位缺陷，从而防止这些问题演变成严重问题。测试人员通常在单元测试之后、完整系统测试开始之前进行功能测试。

• 回归测试：另一种测试框架存在于回归测试中，它提供了一个事后测试环境，用于检查在集成过程中所做的任何更改是否无意中给系统的其他部分引入了故障。当引入新功能（例如，新的在线支付渠道）时，回归测试可用于帮助确保这些新增功能不会破坏已在正常运行的系统。

• 白盒测试：与黑盒测试完全相反，白盒测试假定测试人员希望在测试过程中检查相关代码，以便找出问题所在，并对代码进行纠正性修改以调试这些问题，尽管这种方法几乎肯定会耗费更多时间。“白盒”一词反映了对系统内部工作清晰性的渴望，尽管“透明盒”一词可能是对测试人员所追求目标的更准确的描述。

同样地，这个细分市场中有众多集成测试工具和框架。以下是一些最受欢迎的：

• Citris：Citris 使用开源的 JavaTM 框架为 Java 庞大的用户群（这使其成为世界上最受欢迎的编程语言之一）提供服务。Citris 可以管理 API 使用（如交易）并生成测试消息。

• Katalon：Katalon Studio 的自动化测试软件集成了开源框架 Selenium——这是一款基于浏览器的工具，允许测试人员使用多种编程语言（包括 JavaScript、Node.js 和 Python）编写测试脚本。

• Postman：Postman 在 API 集成测试方面表现出色。该工具还擅长促进团队协作，并支持自动化测试。此外，用户无需将测试放入集合中，甚至无需保存测试，就可以直接编写测试。测试人员在 Postman 中发起请求，会收到一个对应的 URL。

• SoapUI：SoapUI 提供了一款开源工具，能够测试 Web 应用程序并执行集成测试。借助该工具，测试人员可以获得一个图形界面，以支持创建测试用例，并使用户能够轻松处理测试数据。

无论是需要进行前端还是后端的评估与修复，集成测试都提供了一种手段，用于评估当前对企业实现高效运营和最大化盈利能力至关重要的连接是否成功。

如前所述，由于软件创建者致力于为每种可能的需求和所有相关配置确定和开发集成测试方法，因此存在相当多的不同集成测试方法。它正在发挥作用，因为大多数软件开发公司都了解此类测试的必要性。据估计，约有 70% 从事 DevOps 工作的企业已经在使用某种形式的集成测试。

那么，哪种集成工具适合您的业务？多亏了一个接受度高的市场，您很可能可以找到适合您公司需求的市场。为了弄清楚这些需求是什么，我们建议大家回想一句更著名的老话：“认识你自己”。即使对于后现代世界来说，这句谚语仍然是有用的建议。