到底什么是集成测试？

我和我的朋友一直在努力准确地对什么是集成测试进行分类。

现在，在回家的路上，我才意识到，每当我尝试给出一个真实的集成测试示例时，它实际上就是一个验收测试，即。业务人员会大声说出要指定系统应该提供的内容。

我检查了Ruby on Rails文档中对这些测试类型的分类，现在完全把我扔了。

您能否以一个真实的例子为我提供关于集成测试的简短学术描述？

目前，我喜欢这样的说法：Gojko Adzic在本文中提出的“它的重要性并不重要，但它的作用” 。

您确实需要与谈论测试的人员一起指定要测试的内容。

根据角色的不同，很多人有不同的看法。

对于测试人员，TMap是荷兰公认的测试方法。TMap有以下区别。

• 单元测试
• 单元集成测试
• 系统测试
• 系统集成测试
• 验收测试（各种/级别）
• 功能验收测试
• 用户验收测试
• 生产验收测试

他们具有可以在上述测试中执行的更具体的测试类型。查看此Word文档以获取概述。

维基百科也有很好的概述。

在本书的务实程序员说：

• 单元测试是行使模块的测试
• 集成测试表明，系统的主要部分可以很好地协同工作

着眼于这些不同的来源，并提出一些自己的经验和观点，我将首先按三个类别进行区分

• 谁通常进行测试
• 测试什么

• 测试的目的是什么

  • 单元测试：程序员在类中测试逻辑以显示代码级正确性。它们应该快速，并且不依赖于您不打算测试的系统其他部分
  • 功能接受测试：测试用例场景是由测试部门完成的有限（特殊创建的）数据集，用于显示每个指定的场景均按指定的方式工作。
  • 用户接受测试：测试用例场景在生产中的使用情况，例如由用户代表完成的数据，以使他们正式接受应用程序
  • 集成测试：测试部门或开发人员完成的模块不同部分之间的通信路径，以显示所有模块可以正常工作。

我上面的列表只是一个开始和建议，但我确实认为：“您所说的并不重要，但它的作用”

希望这可以帮助。

2016年10月26日编辑：最近在YouTube 单元测试与集成测试上做了一个非常不错的介绍-MPJ的Musings-FunFunFunction＃55

集成测试，结果证明是验收测试

明显。

这两个几乎是同一回事。但是测试定义的维度有些不同。

集成==系统整体。

接受==整个系统。

唯一的区别-这是微妙的-是测试用例的定义。

集成==测试用例，用于测试集成的深度和程度。它适用于所有边缘情况和拐角情况吗？测试用例往往是技术性的，由设计师和编码人员编写。

验收==测试用例仅使用针对最终用户的功能集的80％。并非所有的边缘和角落情况。测试用例往往是非技术性的，由最终用户编写。

当系统的每个组件都是真实的，没有模拟对象时，我个人喜欢将集成测试视为功能测试。

真实的存储库，真实的数据库，真实的UI。在系统完全组装好之后，就像在部署时一样，您应该测试特定的功能。

在我（我承认）的一点经验中，我了解到集成一词确实会造成误解：确实，很难在系统中找到完全孤立的事物，某些元素肯定需要进行集成。

因此，我习惯于进行以下区分：

• 我使用单元测试来识别，记录和强调我正在测试的类负责完成的所有行为。
• 每当我的系统中有一个组件（可能不止一个）与另一个“ 外部 ”系统进行对话时，我都会进行集成测试。（下面继续...）
• 我实施验收测试以定义，记录和强调系统期望的某些工作流程。

在集成测试定义中，外部是指超出我的开发范围的系统：出于任何原因，我都无法立即更改它们的行为方式。它可能是一个库，一个无法更改的系统组件（即与公司中的其他项目共享），一个dbms等。对于这些测试，我需要设置与实际环境非常相似的东西将在以下环境中工作：必须初始化外部系统并将其设置为特定状态；真实数据必须在数据库中注册；等等

相反，当我进行验收测试时，我会伪造一些东西：我在做不同的事情，我在研究系统的规格，而不是它与外部实体协作的能力。

与KeesDijk先前描述的相比，这实际上是一个狭窄的视图，但是我认为到目前为止我从事的项目很小，足以让我简化。

一个集成测试验证一个复杂的系统（如软件，飞机，动力装置）的组件一起工作的设计。

假设我们正在谈论一架飞机（使用软件则更加抽象，并且很难有所作为）。集成测试包括：

• 某些组件之间的正确交互。示例：按下启动按钮时，发动机启动并且螺旋桨达到预期转速（飞机仍停留在地面上）
• 与外部组件的正确交互。示例：检查嵌入式无线电是否可以与固定无线电通信（飞机仍在地面上）
• 正确处理所有相关组件之间的交互，以使整个系统按预期工作。示例：一组测试飞行员和工程师启动飞机，然后乘飞机飞行（他们全都穿着降落伞...）。

在集成测试解决一个技术问题，即该系统工作，尽管其细分成组件。在软件中，组件可以是用例，模块，功能，接口，库等。

在验收试验证明产品是符合目的。它们原则上由客户执行。以飞机为例，它们包括验证以下内容：

• 设想的业务场景在几乎真实的情况下会导致预期的结果。例如：与试乘乘客一起排练登机，以检查工作人员是否可以按照操作程序的要求监视登机。有些情况可能是如此简单，以至于它们看起来像是单元测试，但它们是由用户执行的（例如，尝试使用公司设备的电插头）。
• 该系统可以在几乎真实的业务情况下工作。例如：在两个真实的目的地之间进行空试飞行，并由航空公司的新培训飞行员检查燃油消耗是否达到了承诺。

在验收测试解决更多的是责任问题。在客户/供应商关系中，这可能是合同责任（符合所有要求）。但是在任何情况下，使用组织都有责任确保他们的职责可以在系统中继续执行，并审慎地防止任何不可预见的问题（例如，像这家铁路公司在验收测试中发现他们必须缩短准点，因为新的旅行车太大了5厘米-别开玩笑了！）。

结论：集成和验收测试是重叠的。他们俩都打算表明该系统作为一个整体起作用。但是，“整体”对于客户而言可能更大（因为该系统本身可能是更大的组织系统的一部分），而对于系统集成商而言，则更具技术性：

集成测试不过是检查两个或更多模块之间数据流的连接和正确性。

例如：当我们编写一个邮件（一个模块）并将其发送给某个有效的用户ID（第二个模块）时，集成测试将检查已发送邮件中是否存在已发送邮件。

集成测试的一个实际定义是：任何需要与进程外交互的测试。

例如：

• 文件系统
• 网络
• 数据库
• 外部API

您的流程与外部世界之间存在某种合同，并且最小程度地验证该合同应该是集成测试的目标。也就是说，它只需要验证合同即可。如果是这样，那么您正在朝系统/端对端空间移动。

单元测试能够测试过程边界内的所有逻辑，并且由于不依赖于慢速/脆弱/复杂的“外部世界” ，因此它们可以轻松地精确地进行测试。

尽管有集成测试，但此定义并未涵盖（因此，为什么将其称为实际定义），我认为它们的通用性/实用性要差得多。

注意严格来说，是的，该定义也将涵盖系统/端对端测试。在我的哲学中，它们是“极限”集成测试的一种形式，因此，为什么它们的名称强调另一个方面。在另一个方向上，单元测试可以视为零组件的集成测试，即所有测试都可以视为位于积分谱中的某个位置，在0-n个组件之间进行积分 :-)