什么是单元测试，集成测试，冒烟测试和回归测试？

什么是单元测试，集成测试，冒烟测试和回归测试？它们之间有什么区别，我可以为每个工具使用哪些工具？

例如，我将JUnit和NUnit用于单元测试和集成测试。对于后两个（烟度测试或回归测试）是否有任何工具？

• 单元测试：指定并测试一个类的单一方法合约的一点。这应该具有非常狭窄且定义明确的范围。对外部世界的复杂依赖关系和交互行为是存根或嘲笑的。

• 集成测试：测试多个子系统之间的正确互操作。从两类之间的测试集成，到与生产环境的测试集成，整个过程都有。

• 冒烟测试（也称为 健全性 检查）：一种简单的集成测试，我们只检查被测系统被调用时，它会正常返回并且不会崩溃。

  • 冒烟测试与电子设备都类似，在首次通电时会为电路加电（如果冒烟，那就很糟糕！）。
  • ...，而且显然是水暖管道，管道系统实际上是由烟雾填充的，然后进行目视检查。如果有任何冒烟，则表明系统泄漏。

• 回归测试：修复错误后编写的测试。它确保不会再次发生此特定的错误。全名是“非回归测试”。也可以是在更改应用程序之前进行的测试，以确保应用程序提供相同的结果。

为此，我将添加：

• 验收测试：测试功能或用例是否正确实现。它类似于集成测试，但侧重于提供的用例，而不是所涉及的组件。

• 系统测试：将系统测试为黑匣子。在测试过程中，通常会嘲笑或打断对其他系统的依赖关系（否则，它更像是一个集成测试）。

• 飞行前检查：在类似于生产的环境中重复进行的测试，以减轻“在我的机器上构建”综合症。通常，这是通过在类似生产的环境中进行验收或冒烟测试来实现的。

• 单元测试：一种自动测试，用于测试课程的内部运作。它应该是与其他资源无关的独立测试。
• 集成测试：在环境上完成的自动测试，与单元测试类似，但是具有外部资源（数据库，磁盘访问）
• 回归测试：实施新功能或错误修复后，您将重新测试过去有效的方案。在这里，您将探讨新功能破坏现有功能的可能性。
• 冒烟测试：测试人员可以决定是否继续测试的第一个测试。

每个人的定义都会略有不同，并且通常会有灰色区域。然而：

• 单元测试：这一点点（尽可能孤立）是否起作用？
• 集成测试：这两个（或更多）组件可以一起工作吗？
• 冒烟测试：整个系统（尽可能接近生产系统）是否可以合理地相互连接？（即我们是否有理由相信它不会造成黑洞？）
• 回归测试：我们是否无意中重新引入了先前修复的错误？

我刚刚意识到的一种新的测试类别是canary测试。金丝雀测试是一种自动化的，无损的测试，它在实时环境中定期运行，因此，如果测试失败，则确实发生了一些不好的事情。

示例可能是：

• 有应该永远只能是在开发/易怒的可用数据出现活？
• 后台进程是否无法运行？
• 用户可以登录吗？

关于软件测试技术的最佳网站之一的答案：

软件测试的类型–完整列表，请单击此处

这是一个很长的描述，我不会在这里粘贴：但是对于想要了解所有测试技术的人来说可能会有所帮助。

单元测试：验证特定组件（即类）是否按设计创建或修改了功能。该测试可以是手动的也可以是自动化的，但不会超出组件的范围。

集成测试：验证特定组件的交互是否按设计起作用。集成测试可以在单元级别或系统级别执行。这些测试可以是手动的也可以是自动化的。

回归测试：验证新缺陷是否未引入现有代码中。这些测试可以是手动的也可以是自动化的。

根据您的SDLC（瀑布，RUP，敏捷等），特定的测试可以分阶段进行，也可以全部或多或少地同时进行。例如，单元测试可能仅限于开发人员，然后开发人员将代码移交给测试人员进行集成和回归测试。但是，另一种方法可能是让开发人员进行单元测试以及某种程度的集成和回归测试（将TDD方法与持续集成以及自动化的单元和回归测试一起使用）。

该工具集将在很大程度上取决于代码库，但是有许多用于单元测试（JUnit）的开源工具。HP（Mercury）QTP或Borland的Silk Test都是用于自动集成和回归测试的工具。

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

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

冒烟测试 在冒烟测试中，他们以浅而宽的方式检查应用程序。在烟雾测试中，他们检查应用程序的主要功能。如果应用程序中存在任何阻止程序问题，他们将向开发人员团队报告，开发团队将对其进行修复并纠正缺陷，然后将其返回给测试团队。现在，测试团队将检查所有模块，以验证在一个模块中所做的更改是否会影响另一个模块。在冒烟测试中，对测试用例进行了脚本编写。

重复执行相同测试用例的回归测试，以确保未更改的模块不会造成任何缺陷。回归测试正在进行功能测试

回归测试-

“回归测试针对更改后的软件重新运行先前的测试，以确保对当前软件所做的更改不会影响现有软件的功能。”

我只是想添加并提供更多背景信息，说明为什么我们要进行这些级别的测试，它们对示例的实际含义

迈克·科恩（Mike Cohn）在其著作《敏捷的成功》中提出了“测试金字塔”，作为在项目中进行自动化测试的一种方法。此模型有多种解释。该模型说明了需要创建哪种自动测试，它们可以在多长时间内就被测应用程序提供反馈，以及由谁编写这些测试。任何项目基本上都需要3个级别的自动化测试，它们分别如下。

单元测试- 这些测试用于测试软件应用程序的最小组成部分。从字面上看，这可能是代码中的一个函数，该代码根据某些输入来计算值。此功能是构成应用程序的硬件/软件代码库的其他几个功能的一部分。

例如-让我们以基于Web的计算器应用程序为例。该应用程序中需要进行单元测试的最小组件可能是执行加法的功能，另一个执行减法的功能，依此类推。所有这些小的功能加在一起构成了计算器应用程序。

从历史上看，开发人员编写这些测试的原因是它们通常使用与软件应用程序相同的编程语言编写。为此，使用了JUnit和NUnit（对于Java），MSTest（对于C＃和.NET）和Jasmine / Mocha（对于JavaScript）等单元测试框架。

单元测试的最大优点是，它们在UI下运行得非常快，我们可以快速获得有关应用程序的反馈。这应该占您自动化测试的50％以上。

API /集成测试- 这些测试一起测试软件系统的各个组件。这些组件可能包括测试数据库，API（应用程序编程接口），第三方工具和服务以及应用程序。

例如-在上面的计算器示例中，Web应用程序可以使用数据库来存储值，使用API​​进行一些服务器端验证，并且可以使用第三方工具/服务将结果发布到云中以使其可在不同的情况下使用平台。

从历史上看，开发人员或技术质量检查人员会使用各种工具（例如Postman，SoapUI，JMeter和其他工具（如Testim））编写这些测试。

它们的运行速度比UI测试要快得多，因为它们仍在引擎盖下运行，但可能要比单元测试花费更多的时间，因为它必须检查系统各个独立组件之间的通信并确保它们无缝集成。这应该占自动化测试的30％以上。

UI测试- 最后，我们有一些测试可以验证应用程序的UI。通常将这些测试编写为测试通过应用程序的端到端流程。

例如-在计算器应用程序中，端到端流程可能是，打开浏览器->输入计算器应用程序url->使用用户名/密码登录->打开计算器应用程序->在计算器上执行一些操作->从UI验证这些结果->注销应用程序。这可能是一个端到端的流程，将是UI自动化的一个不错的选择。

过去，技术质量检查人员或手动测试人员会编写UI测试。他们使用诸如Selenium之类的开源框架或诸如Testim之类的UI测试平台来编写，执行和维护测试。通过查看屏幕截图，日志和测试报告，您可以查看测试的运行方式，预期结果与实际结果之间的差异，这些测试提供了更多的视觉反馈。

UI测试的最大限制是，与单元和API级别的测试相比，它们相对较慢。因此，它应该只占整个自动化测试的10-20％。

接下来的两种测试类型可能会因您的项目而异，但是想法是-

烟雾测试

这可以是上述3个测试级别的组合。这个想法是在每次代码检入期间运行它，并确保系统的关键功能仍按预期运行。新代码更改合并后。他们通常需要运行5-10分钟才能获得有关故障的更快反馈

回归测试

它们通常至少每天运行一次，并涵盖系统的各种功能。他们确保应用程序仍按预期运行。它们比烟雾测试更为详细，并且涵盖了应用程序的更多场景，包括非关键场景。

单元测试针对实现的最小部分。在Java中，这意味着您正在测试一个类。如果该类依赖于其他类，则将其伪造。

当您的测试调用多个类时，这就是集成测试。

完整的测试套件可能需要很长时间才能运行，因此在进行更改后，许多团队会快速运行一些完成测试以检测重大损坏。例如，您已将URI分解为基本资源。这些是烟雾测试。

回归测试在每个构建上运行，并允许您通过捕获破坏的内容来有效地进行重构。任何类型的测试都可以是回归测试，但是我发现单元测试最有助于发现故障源。

• 集成测试：集成测试是集成的另一个要素
• 冒烟测试：冒烟测试也称为生成版本测试。冒烟测试是用来检查被测软件是否准备就绪/稳定以进行进一步测试的初始测试过程。
• 回归测试：回归测试是重复测试。新软件是否在另一个模块中生效。
• 单元测试：这是一个白盒测试。只有开发者参与其中

单元测试：验证特定组件（即类）是否按设计创建或修改了功能。该测试可以是手动的也可以是自动化的，但不会超出组件的范围。

集成测试：验证特定组件的交互是否按设计起作用。集成测试可以在单元级别或系统级别执行。这些测试可以是手动的也可以是自动化的。

回归测试：验证新缺陷是否未引入现有代码中。这些测试可以是手动的也可以是自动化的。

根据您的SDLC（瀑布，卢布，敏捷等），特定的测试可以分阶段进行，也可以全部或多或少地同时进行。例如，单元测试可能仅限于开发人员，然后开发人员将代码移交给测试人员进行集成和回归测试。但是，另一种方法可能是让开发人员进行单元测试以及某种程度的集成和回归测试（使用TDD方法以及持续集成以及自动化的单元和回归测试）。

在该线程中似乎值得一提的测试类型是压力/性能/负载测试，可以将其简单地视为找出某个软件中断的极限。请注意，就工具而言，从系统的角度精确确定建议进行压力测试的范围至关重要。例如，在“ Web应用程序”的情况下，压力测试可以在其范围内包括Web服务器应用程序本身，因此该工具可以为此目的进行干预。这是一篇有关http负载测试的好文章

单元测试单元测试是非常低的级别，与您的应用程序源非常接近。它们包括测试软件使用的类，组件或模块的各个方法和功能。通常，单元测试的自动化成本非常低，并且可以由连续集成服务器非常快速地运行。

集成测试集成测试可以验证您的应用程序使用的不同模块或服务可以很好地协同工作。例如，它可以测试与数据库的交互，或者确保微服务按预期方式协同工作。这些类型的测试运行起来比较昂贵，因为它们需要启动和运行应用程序的多个部分。

功能测试功能测试专注于应用程序的业务需求。它们仅验证动作的输出，并且在执行该动作时不检查系统的中间状态。

集成测试和功能测试之间有时会混淆，因为它们都需要多个组件才能相互交互。区别在于，集成测试可以仅验证您可以查询数据库，而功能测试可以期望从数据库中获得产品要求所定义的特定值。

端到端测试端到端测试在完整的应用程序环境中使用软件复制用户行为。它可以验证各种用户流是否按预期工作，并且可以像加载网页或登录一样简单，也可以像验证电子邮件通知，在线付款等更复杂的场景一样简单。

端到端测试非常有用，但是执行起来很昂贵，并且自动化时很难维护。建议进行一些关键的端到端测试，并更多地依赖较低级别的测试类型（单元测试和集成测试），以便能够快速识别出重大变化。

验收测试验收测试是执行的正式测试，用于验证系统是否满足其业务需求。他们需要启动并运行整个应用程序，并专注于复制用户行为。但是他们也可以走得更远，衡量系统的性能，如果未达到某些目标，则拒绝更改。

性能测试性能测试用于检查系统在负载较大时的行为。这些测试无法正常运行，并且可以采用各种形式来了解平台的可靠性，稳定性和可用性。例如，它可以观察执行大量请求时的响应时间，或者查看系统如何处理大量数据。

从本质上来说，性能测试的实施和运行成本很高，但是它们可以帮助您了解新的更改是否会使系统性能下降。

冒烟测试冒烟测试是检查应用程序基本功能的基本测试。它们旨在快速执行，并且它们的目标是向您保证系统的主要功能可以按预期运行。

在进行新的构建以决定您是否可以运行更昂​​贵的测试之后，或者在进行部署以确保它们的应用程序在新部署的环境中正常运行之后，冒烟测试可能非常有用。

资料来源：https : //www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing

单元测试：它总是由开发人员在完成开发工作后执行，以从测试方面发现问题，然后再为质量保证准备好任何要求。

集成测试：这意味着当某些数据/功能输出驱动到一个模块到另一个模块时，测试人员必须验证模块到子模块的验证。或者在您的系统中（如果使用第三方工具），该第三方工具使用您的系统数据进行集成。

冒烟测试：测试人员执行了验证系统以进行高级测试，并试图在更改或代码生效之前找出显示阻止程序的错误。

回归测试：由于系统中为新增强功能或系统更改而实施的更改，测试人员执行了回归以验证现有功能。

单元测试

单元测试通常由开发人员完成，而测试人员在这种类型的测试中得到了部分发展，其中测试是逐个单元进行的。在Java JUnit中，也可以使用测试用例来测试编写的代码是否经过完美设计。

集成测试：

集成所有/某些组件的单元测试后，可以进行此类测试。这种类型的测试将确保在集成组件时，它们是否会影响彼此的工作能力或功能？

烟雾测试

当系统成功集成并准备好在生产服务器上运行时，最后才进行此类测试。

这种类型的测试将确保从头到尾的所有重要功能都可以正常工作，并且系统已准备好在生产服务器上进行部署。

回归测试

当开发人员修复某些问题时，这种类型的测试对于测试系统中是否存在意外/不必要的缺陷很重要。此测试还确保所有错误均已成功解决，并且不会发生其他问题。

烟熏和健康测试均在构建软件后执行，以识别是否开始测试。进行烟雾测试后，可能会或可能不会执行理智检查。它们可以单独执行，也可以同时执行-吸烟后应立即戒备。

由于健全性测试更加深入并且需要更多时间，因此在大多数情况下，值得进行自动化。

进行烟雾测试通常不会超过5-30分钟。更为笼统：它检查整个系统的少量核心功能，以验证软件的稳定性足以进行进一步的测试，并且没有问题，从而阻止了计划中的测试用例的运行。

理智测试比烟雾测试更详细，可能需要15分钟到一天的时间，具体取决于新建筑的规模。它是一种更专业的验收测试，在进行或重新测试后执行。它可以检查某些新功能和/或错误修复的核心功能，以及与它们密切相关的功能，以便在可以大规模执行回归测试之前，验证它们是否在根据所需的操作逻辑运行。

已经有一些好的答案，但我想进一步完善它们：

单元测试是此处白盒测试的唯一形式。其他的都是黑匣子测试。白盒测试意味着您知道输入。您知道该机制的内部工作原理并可以对其进行检查，并且您知道输出。使用黑匣子测试，您只知道输入是什么，输出应该是什么。

显然，单元测试是这里唯一的白盒测试。

• 单元测试测试特定的代码段。通常是方法。
• 集成测试测试您的新功能软件是否可以与其他所有产品集成。
• 回归测试。已经完成测试以确保您没有损坏任何东西。以前可以正常工作的所有内容仍然可以正常工作。
• 冒烟测试是一种快速测试，可以确保您参与更严格的测试之前一切正常。

烟雾测试已经在这里进行了说明，并且很简单。回归测试属于集成测试。

自动化测试可以分为两种。

单元测试和集成测试（这很重要）

我将在集成测试，功能测试，回归测试，UI测试等所有测试中使用短语“长期测试”（LT）。单元测试称为“短期测试”。

LT的示例可能是自动加载网页，登录帐户并购买书籍。如果测试通过，则更有可能以相同的方式在实时站点上运行（因此称为“更好的睡眠”参考）。长=网页（开始）与数据库（结束）之间的距离。

这是一篇很棒的文章，讨论了集成测试（长期测试）相对于单元测试的好处。

回归测试-是一种软件测试，我们尝试覆盖或检查该错误修复程序。由于提供了此修复程序，因此错误修复程序周围的功能不应更改或更改。在此过程中发现的问题称为回归问题。

冒烟测试：是一种用来决定是否接受内部版本/软件进行进一步质量检查的测试。