单元测试、功能测试、验收测试和集成测试有什么区别？ [关闭]答案

【问题标题】：What's the difference between unit, functional, acceptance, and integration tests? [closed]单元测试、功能测试、验收测试和集成测试有什么区别？ [关闭]
【发布时间】：2011-06-21 16:54:57
【问题描述】：

单元测试、功能测试、验收测试和集成测试（以及我没有提到的任何其他类型的测试）之间有什么区别？

【问题讨论】：

另见sqa.stackexchange.com/a/23396/8992
我想你忘了包括负载测试！
根据您正在测试的目标（测试设置），您还可以将测试分类为 HIL（硬件）、MIL（机器）、SIL（软件）（IN Loop）。

标签： testing terminology definition

【解决方案1】：

根据您查看的位置，您会得到略有不同的答案。我已经阅读了很多关于这个主题的内容，这是我的提炼；同样，这些有点毛茸茸，其他人可能不同意。

单元测试

测试最小的功能单元，通常是一个方法/函数（例如，给定一个具有特定状态的类，在该类上调用 x 方法应该会导致 y 发生）。单元测试应该专注于一个特定的特性（例如，当堆栈为空时调用 pop 方法应该抛出一个InvalidOperationException）。它所触及的一切都应该在内存中完成；这意味着测试代码和被测代码不应该：

呼唤（重要的）合作者
访问网络
点击数据库
使用文件系统
启动线程
等

任何一种缓慢/难以理解/初始化/操作的依赖项都应该使用适当的技术进行存根/模拟/任何操作，这样您就可以专注于代码单元正在做什么，而不是它的依赖项做什么。

简而言之，单元测试尽可能简单、易于调试、可靠（由于减少了外部因素）、执行速度快，并有助于证明您的程序的最小构建块在放入之前按预期运行一起。需要注意的是，尽管您可以证明它们在孤立的情况下完美工作，但代码单元在组合时可能会爆炸，这使我们...

集成测试

集成测试以单元测试为基础，通过组合代码单元并测试生成的组合是否正确运行。这可以是一个系统的内部，也可以将多个系统组合在一起做一些有用的事情。此外，将集成测试与单元测试区分开来的另一件事是环境。集成测试可以并且将使用线程、访问数据库或执行任何所需的操作以确保所有代码和不同的环境更改都能正常工作。

如果您构建了一些序列化代码并在不接触磁盘的情况下对其内部进行了单元测试，那么您如何知道在加载和保存到磁盘时它会工作？也许您忘记了刷新和处理文件流。也许您的文件权限不正确，并且您已经在内存流中测试了内部使用。唯一确定的方法是使用最接近生产环境的环境“真实地”测试它。

主要优点是他们会发现单元测试无法发现的错误，例如接线错误（例如 A 类的实例意外收到 B 的空实例）和环境错误（它在我的单 CPU 机器上运行良好，但我同事的4核机测试不通过）。主要缺点是集成测试涉及更多代码，可靠性较低，故障更难诊断，测试更难维护。

此外，集成测试不一定能证明完整的功能有效。用户可能不关心我程序的内部细节，但我关心！

功能测试

功能测试通过将给定输入的结果与规范进行比较来检查特定功能的正确性。功能测试不关心中间结果或副作用，只关心结果（他们不关心在做 x 之后对象 y 有状态 z）。编写它们是为了测试规范的一部分，例如“使用参数 2 调用函数 Square(x) 返回 4”。

验收测试

验收测试似乎分为两种：

标准验收测试涉及对整个系统执行测试（例如，通过网络浏览器使用您的网页）以查看应用程序的功能是否满足规范。例如。 “单击缩放图标应将文档视图放大 25%。”没有真正连续的结果，只有通过或失败的结果。

优点是测试以简单的英语描述，并确保软件作为一个整体功能完整。缺点是您已经将测试金字塔向上移动了一个级别。验收测试涉及大量代码，因此追踪失败可能很棘手。

此外，在敏捷软件开发中，用户验收测试涉及创建测试以反映开发期间由/为软件客户创建的用户故事。如果测试通过，则意味着软件应该满足客户的要求，并且故事可以被认为是完整的。验收测试套件基本上是用特定领域语言编写的可执行规范，它以系统用户使用的语言描述测试。

结论

它们都是互补的。有时专注于一种类型或完全避开它们是有利的。对我而言，主要区别在于，一些测试从程序员的角度看待事物，而另一些则以客户/最终用户为中心。

【讨论】：

+1。 @Mark Simpson 功能和验收测试可以概括为“系统测试”吗？端到端测试在哪里适合？（我的口味太多不同的词汇）
@Franz 我说的是您可以通过隔离代码单元并对其进行测试来降低风险的能力和轻松程度。不过你是对的，我使用的语言有点松散，因为测试不能证明代码没有错误。
尽管投票赞成，但这是完全错误的。单元测试甚至不会测试“微不足道”的合作者；必须模拟任何注入的依赖项。功能测试不测试“行为”；他们只测试“函数”，即“f(A) 返回 B”。如果副作用很重要，那就是“行为”。如果这些包括系统调用，它们也是“系统”测试，如“行为系统测试”。（参见下面的 testerab@。）“验收”测试是“行为系统测试”的一个子集，涵盖了整个堆栈。 “集成”测试向上，模拟实际使用；它测试所有依赖项都可以在实践中集成。
@cdunn2001：别担心，建设性的批评总是好的 :) 你的评论教会了我一些我不知道的事情，并且稍微清理了我的术语。我总是热衷于向热衷于测试的开发人员学习新事物。我记得我第一次发现 Miško Hevery 的博客时——它就像一个宝库 :)
@MarkSimpson 虽然您的回答非常好，但我想了解更多有关功能测试的详细信息。我的意思是在你的回答中，对我来说，很难区分功能测试和单元测试。我希望你有时间，继续努力！

【解决方案2】：

重要的是您知道这些术语对您的同事意味着什么。例如，当他们说“完整的端到端”测试时，不同的群体对他们的含义的定义会略有不同。

我最近遇到了 Google 的测试命名系统，我很喜欢它 - 他们通过使用 Small、Medium 和 Large 来绕过这些参数。为了确定测试适合哪个类别，他们会考虑几个因素 - 运行需要多长时间，是否访问网络、数据库、文件系统、外部系统等等。

http://googletesting.blogspot.com/2010/12/test-sizes.html

我想您当前工作场所的小型、中型和大型之间的区别可能与 Google 不同。

但是，这不仅与范围有关，还与目的有关。 Mark 关于测试的不同观点的观点，例如程序员与客户/最终用户，真的很重要。

【讨论】：

+1 用于 google 测试命名，因为它有助于了解为什么不同的组织/人员对测试有不同的定义。
这也是一篇很好的文章，介绍了为什么要使用不同级别的测试以及从中得到什么：kentcdodds.com/blog/unit-vs-integration-vs-e2e-tests

【解决方案3】：

一些（相对）最近反对过度模拟和纯单元测试的想法：

【讨论】：

我是测试代码的新手。单元测试似乎大多是在浪费时间。我以为我在做单元测试，但我在做集成测试，然后我读到了单元测试，这似乎很愚蠢，也许对于经验很少的人来说？我有可能遗漏了一些要点。
如果 Unit 的定义很宽泛，那么您就是在进行正确的单元测试。我反对测试实现细节。私有类不应进行“单元测试”。但是，如果您有多个公共课程，您可能会想在测试另一个时模拟其中一个。这才是真正的辩论。 Unit (a) 是您的整个图书馆吗？ (b) 图书馆内的每个公共班级？或者（c），每个类中的每个公共方法？我更喜欢将给定的库作为集成组件进行测试，但要模拟或伪造外部依赖项（除非它们快速且可靠）。所以我想我和你在一起。
@PixMach：实际上是相反的。如果您（或其他人）将来必须更改该代码，则没有（好的）单元测试会浪费您的大量时间。如果您有使用和不使用单元测试来维护代码的经验，您就会知道其中的区别。这个想法是，如果单元测试中断，您应该确切地知道必须修复代码的哪一部分。未能通过大规模验收/集成测试通常只会告诉您：它不起作用。然后你必须开始老式的调试......
@Goodsquirrel，这取决于你所说的“单位”。那就是问题所在。重构期间将删除不良测试。好的测试仍然会有所帮助。糟糕的测试不会增加任何价值并且会阻碍。好的测试是自我记录的，非常感谢。让我们具体一点。如果另一个值为 True，我有一个私有方法来返回一个值，否则为默认值。（遗留代码。）应该测试该方法吗？我拒绝。另一个私有方法返回第 n 个斐波那契数。应该测试吗？我说是的。
最小的暴露代码。大不同。

【解决方案4】：

单元测试：对应用程序中单个模块或独立组件的测试称为单元测试，单元测试将由开发人员完成。

集成测试：结合所有模块，测试应用程序，以验证模块之间的通信和数据流是否正常工作，该测试也由开发人员进行。

功能测试检查应用程序的单个功能意味着功能测试

验收测试此测试由最终用户或客户完成，无论构建应用程序是否符合客户要求，以及客户规范，这被称为验收测试

【讨论】：

【解决方案5】：

我会用一个实际的例子来解释你，而不是理论的东西：

开发人员编写代码。还没有实现 GUI。此级别的测试验证功能是否正常工作以及数据类型是否正确。这一阶段的测试称为单元测试。

在开发 GUI 并将应用程序分配给测试人员时，他会与客户一起验证业务需求并执行不同的场景。这称为功能测试。在这里，我们将客户需求与应用程序流进行映射。

集成测试：假设我们的应用程序有两个模块：人力资源和财务。 HR 模块之前已交付和测试。现在 Finance 已开发并可供测试。相互依赖的功能现在也可用，因此在此阶段，您将测试两者之间的通信点，并验证它们是否按要求工作。

回归测试是另一个重要阶段，在任何新的开发或错误修复之后完成。其目的是验证以前的工作功能。

【讨论】：

"开发人员编写代码。还没有实现GUI。这个级别的测试验证功能是否正确，数据类型是否正确。这个阶段的测试称为单元测试"这是不对。 GUI 实际上只是一个“插件”。您已经可以将 E2E 测试写入您的 API 输出。（或您生成的任何响应对象）

【解决方案6】：

http://martinfowler.com/articles/microservice-testing/

Martin Fowler 的博客文章谈到了测试代码的策略（尤其是在微服务架构中），但其中大部分内容适用于任何应用程序。

我将引用他的摘要幻灯片：

单元测试 - 运行应用程序中最小的可测试软件，以确定它们是否按预期运行。

集成测试 - 验证组件之间的通信路径和交互以检测接口缺陷。

组件测试 - 将运行软件的范围限制在被测系统的一部分，通过以下方式操作系统内部代码接口并使用测试替身来隔离代码正在接受其他组件的测试。

合同测试 - 验证外部服务边界的交互，断言它符合消费者期望的合同服务。

端到端测试 - 验证系统是否满足外部要求并实现其目标，测试整个系统，从端到端。

【讨论】：

顺便说一句，这是一篇很棒的文章。但是我不完全理解合同测试的用途。鉴于组件和集成测试，它们不是多余的吗？
在某些语言（Fowler 先生使用）中，您可以实现一个在使用类的标准定义时未公开的接口，例如无效 IMyInterface.MyMethod()。这反过来又会在逻辑上拥有自己的测试。虽然那时你正朝着 BDD 方向前进。具有讽刺意味的是，福勒先生也抢占了土地。
顺便说一句，这不是福勒的文章，只是张贴在那里。合同测试是在客户开始使用您的服务后进行的测试，然后您编写测试来检查您是否没有为该特定客户破坏某些东西，即更改服务 api。
@wheleph 单元、集成和组件测试主要针对开发人员高度可控的软件内部。前三个中的问题意味着更改您的来源以解决问题。 -- 合约测试触及功能上向您承诺的内容，但面对缺陷您可能无法直接更改。这需要添加支持代码来解决这些可能的问题，而不仅仅是修复缺陷。 -- 因此，即使合同规范告诉您它具有某种结构，您也可以解决返回格式错误的 json 的 Web 服务。

【解决方案7】：

这很简单。

单元测试：这是由具有编码知识的开发人员实际完成的测试。此测试在编码阶段完成，是白盒测试的一部分。当一个软件来进行开发时，它被开发成一段代码或一段代码，称为一个单元。这些单元的单独测试称为单元测试，由开发人员完成，以找出某种人为错误，例如缺少语句覆盖率等。
功能测试：此测试在测试 (QA) 阶段完成，它是黑盒测试的一部分。先前编写的测试用例的实际执行。此测试实际上是由测试人员完成的，他们找到站点中任何功能的实际结果，并将此结果与预期结果进行比较。如果他们发现任何差异，那么这是一个错误。
验收测试：称为 UAT。这实际上是由测试人员以及开发人员、管理团队、作者、作家和所有参与这个项目的人完成的。以确保项目最终准备好交付，并且没有错误。
集成测试：代码单元（在第 1 点中解释）相互集成以完成项目。这些代码单元可能是用不同的编码技术编写的，也可能是不同的版本，因此此测试由开发人员完成，以确保所有代码单元与其他代码单元兼容并且不存在任何集成问题。

【讨论】：

@OlegTsyba 问题得到解答 4 年后才得到答案。
我们永远不应该以“这很简单”作为答案，尤其是当它是一个复杂的话题时。

【解决方案8】：

单元测试 - 顾名思义，此方法在对象级别进行测试。测试各个软件组件是否有任何错误。此测试需要程序知识，并创建测试代码以检查软件是否按预期运行。

功能测试- 在不了解系统内部工作的情况下进行。测试人员将尝试按照要求使用系统，提供不同的输入并测试生成的输出。此测试也称为闭盒测试或黑盒测试。

验收测试- 这是软件交付给客户之前进行的最后一次测试。执行它以确保开发的软件满足所有客户要求。验收测试有两种类型 - 一种由开发团队成员执行，称为内部验收测试（Alpha 测试），另一种由客户或最终用户执行，称为（Beta 测试）

集成测试- 已经过单元测试的各个模块相互集成。通常遵循这两种方法：

1) 自上而下
2) 自下而上

【讨论】：

自上而下和自下而上是什么意思？集成测试与端到端测试相同吗？