到底什么是集成测试？

#1 楼

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

您确实需要与谈论测试的人们一起指出您打算测试的内容。

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

对于测试人员，荷兰普遍接受的测试方法是TMap。 TMap具有以下区别。


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

它们可以在上述测试中进行更具体的测试。查看此词doc以获得概述。

维基百科也有很好的概述。 >单元测试是对模块进行测试的测试
集成测试表明，系统的主要部分可以很好地协同工作

看看这些不同的来源并总结我自己的经验和意见首先，我将按三个类别进行区分


谁进行一般测试
要测试的内容

测试的目标是什么



单元测试：程序员在类中测试逻辑以显示代码级正确性。它们应该快速并且不依赖于您不打算测试的系统的其他部分

功能接受测试：测试用例场景基于测试完成的有限（专门创建的）数据集

用户接受测试：测试用例场景在生产中的使用，就像由用户代表所做的数据一样，以使其正式接受应用程序。

集成测试：由测试部门或开发人员测试模块不同部分之间的通信路径，以显示所有模块可以正常工作。



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

希望有帮助。

26-10-2016编辑：最近，在YouTube单元测试与集成测试之间进行了非常不错的介绍-MPJ的Musings-FunFunFunction＃55

#2 楼

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


很明显。

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

集成==整个系统。

验收==整个系统。

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

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

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

#3 楼

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

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

#4 楼

集成测试可验证复杂系统的组件（例如软件，飞机，发电厂）是否按设计协同工作。

让我们想象一下，我们正在谈论一架飞机（使用软件可以使飞机更抽象，并且很难有所作为）。集成测试包括验证以下内容：


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

集成测试解决了一个技术问题，即，即使将系统细分为多个组件，系统仍可正常运行。在软件中，组件可以是用例，模块，功能，接口，库等。

验收测试可以验证产品是否适合用途。它们原则上由客户执行。以飞机为例，它们包括验证：



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

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

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

#5 楼

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

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


我使用单元测试来识别，记录并强调所有行为
我正在测试的类负责
完成。
我正在系统中进行集成测试
，只要我的系统中有一个组件（也许是多个组件）
与另一个组件进行对话
系统。 （继续下面的...）
我实施了验收测试，以定义，记录和强调
系统期望的某些工作流程。
/>
在集成测试定义中，外部是指超出我的开发范围的系统：出于任何原因，我都无法立即更改其行为方式。它可能是一个库，一个无法更改的系统组件（即与公司中的其他项目共享），一个dbms等。对于这些测试，我需要设置与真实环境非常相似的东西将在以下环境中工作：必须初始化外部系统并将其设置为特定状态；真实数据必须在数据库中注册；等。

相反，当我在进行验收测试时，我会假货：我正在从事不同的工作，我正在研究系统的规范，而不是与外部协作的能力。实体。

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

#6 楼

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

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

#7 楼

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

例如：


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

您的流程与外部世界之间存在某种合同，并且最小程度地验证该合同应该是一个目标集成测试。也就是说，它只需要验证合同即可。如果可以，那么您就朝着系统/端对端的方向发展。

单元测试能够测试过程边界内的所有逻辑，并且由于缺少这些功能，它们可以轻松地精确地实现。慢/脆弱/复杂的“外部世界”的依赖关系。

尽管有集成测试，但该定义并未涵盖（因此，我称其为实际定义），我认为它们不那么常见/有用。

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