it-swarm.cn

到底什么是集成测试?

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

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

我检查了Ruby上Rails)文档,以了解这些测试类型的分类,现在完全把我扔了。

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

116
Martin Blore

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

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

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

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

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

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

维基百科也有 不错的概述

预订实用的程序员 说:

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

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

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

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

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

希望这可以帮助。

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

81
KeesDijk

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

明显。

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

集成==系统整体。

接受==整个系统。

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

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

验收==测试用例,仅使用针对最终用户的功能集的80%。并非所有的Edge和Corner案例。测试用例往往是非技术性的,由最终用户编写。

31
S.Lott

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

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

16
user8685

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

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

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

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

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

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

8
Marco Ciambrone

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

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

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

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

验收测试验证产品是否适合用途。它们原则上由客户执行。以飞机为例,它们包括验证以下内容:

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

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

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

enter image description here

7
Christophe

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

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

1
Anita

集成测试的一种实用定义是:任何需要与进程外事物进行交互的测试。

例如:

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

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

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

尽管有集成测试,但此定义并未涵盖(因此,为什么我称其为实用的定义),我认为它们不那么常见/有用。

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

0
Schneider