到底什么是集成测试?


110

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

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

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

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


76
顺便说一句,当您使用名词短语(“我和一些朋友”)时,需要注意使用的第一人称单数。这是测试。放下朋友,看看它是否仍然有效。“我一直在挣扎” “我一直在挣扎”。此测试告诉您它是“我和我的朋友...”而且-出于礼貌-我们将其他人列在第一位。“我和我的朋友们”。测试很重要。
S.Lott

58
我认为S.Lott刚刚给您提供了语法->社会融合测试。
乔丹

Answers:


78

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

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

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

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

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

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

维基百科也有很好的概述

本书的务实程序员说:

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

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

  • 谁通常进行测试
  • 测试什么
  • 测试的目的是什么

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

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

希望这可以帮助。

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


3
+1表示“不管您叫什么”。可悲的是,没有任何测试的通用定义。即使是良好的ol单元测试,也有点可变。将Web应用程序的DOM测试视为单元测试吗?有人说是,有人说不。
Laurent Bourgault-Roy 2014年

2
单词doc的链接不可用。
Paul Rougieux 2015年

6
“这并不重要”适用于所有计算机科学,实际上适用于几乎所有领域。我发现人们陷入的许多激烈争论都可以归结为“我们正在争论任意短语的定义”。
Gardenhead '16

+1同意定义:我去过一个地方,在“单元测试”中,程序员使用至少一个示例输入来尝试系统...手动...并目视检查输出是否“看起来正确”。 。没有关于预期的合同,没有受控的投入等
Newtopian

指向Gojko的链接返回的是404。您可以在此处访问档案:web.archive.org/web/20150104002755/http
//gojko.net/2011/01/12/…– Eduardo Copat

32

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

明显。

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

集成==系统整体。

接受==整个系统。

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

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

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


7
我要补充的是,集成测试也可以只测试系统的一部分,但一次只能测试多个。每当您寻找由系统的两个或多个部分协同工作(集成在一起)而导致的错误时,您就是在进行集成测试。集成从实际的两个组件以及其他所有可模拟的组件运行到整个应用程序套件一起工作,甚至可以检查与其他应用程序的集成(例如,“ MS Office如何与Internet Explorer一起工作?”)。
Ethel Evans

1
@Ethel Evans:好点。即使只涉及系统的一部分,测试在集成和验收之间仍将是模糊的。测试在足够高的水平上进行,以使接受和集成感觉相似。
S.Lott

3
集成测试当然不会(也可能不会)测试“整个系统”。在将两个或多个组件一起测试的任何地方,特别是在针对外部组件(数据库,网络等)进行测试时,您都在进行集成测试。由于“整个系统”测试的高昂成本,因此您希望尽可能避免这种情况,而希望进行更多的部分系统集成测试(请参阅测试金字塔
Schneider

1
@Schneider说得很好,集成测试不应测试“整个系统”。根据您在项目中考虑的范围,此类测试将被视为“端到端测试”或“系统测试”。端到端测试可能涵盖通过多个系统运行的“整体”数据流,而系统测试仅“整个系统”。
RoyB

这是我如何定义它们,以避免在“集成”测试的广泛使用方面造成混淆。单元测试->测试最小的工作单元,即类中的一种方法,该方法不会调用该方法之外的任何其他代码(如果需要,可以模拟依赖项)集成测试->从单元测试中测试范围更大的单元并且应该测试可以协同工作的应用程序层,但不能测试整个应用程序部署在某个地方。)功能测试/验收测试->测试应用程序已部署版本的测试
Kevin M

16

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

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


4
我同意,只是不需要“完全组装”系统。您可以(并且应该)对整个系统的子集进行集成测试,因为这通常更便宜/更容易。
施耐德2014年

2个单元/组件之间的集成也可以进行“集成测试”,而其余的仍然可以模拟。因此,许多集成测试框架都允许
模拟

1
我在Spring Boot应用程序中进行了测试,该应用程序测试Spring容器内的前端(API合约),但模拟了存储库/数据层。因此,它使用的是模拟的存储库/数据,但合并了控制器层并进行了杰克逊编组等操作。集成测试。
凯文M

8

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

因此,我习惯于进行以下区分:

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

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

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

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


6

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

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

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

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

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

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

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

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

在此处输入图片说明


1

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

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


3
欢迎来到程序员。现有答案还没有提供您的答案?Programmers.SE与传统论坛不同。它专注于高质量的问答,而不是大量的讨论。请查看游览页面,以获取有关网站运行方式的更多信息。

0

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

例如:

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

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

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

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

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


如果有两个单元,则使用单元测试对每个单元进行测试。当这两个单元相互集成时,可以使用集成测试来测试集成。它们不一定非要“脱离过程”,并且这类测试非常普遍。
布莱恩·奥克利

您是完全正确的-集成测试不一定非要进行。这就是为什么我试图弄清楚我的回答更像是一个“经验法则”(但可能失败了)。我不同意单元之间的集成测试是“极其普遍的”。在我的经验中,流程外的集成测试更为常见,并且通常非常有价值,因此为什么我的答案强调集成测试的这一方面。
施耐德
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.