单元测试、集成测试、冒烟测试和回归测试之间有什么区别？

• 单元测试：测试类内部工作的自动测试。它应该是一个独立的测试，与其他资源无关。
• 集成测试：在环境上完成的自动测试，类似于单元测试，但使用外部资源（数据库、磁盘访问）
• 回归测试：在实现新功能或bug修复后，您重新测试过去有效的场景。在这里，您介绍了新功能破坏现有功能的可能性。
• 冒烟测试：测试人员可以得出结论是否继续测试的第一个测试。

每个人的定义都会略有不同，经常会有灰色地带。然而：

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

• 单元测试：指定和测试类的单个方法的契约的一点。这应该有一个非常狭窄和定义良好的范围。对外部世界的复杂依赖和交互被存根或模拟

• 集成测试：测试多个子系统的正确互操作。从测试两个类之间的集成到测试与正式生产环境的集成，这是一个完整的范围。

• 冒烟测试（又名理智检查）：一个简单的联调，我们只是检查当被测系统被调用时它是否正常返回并且不会爆炸。

  • 冒烟测试与电子产品类似，第一次测试发生在为电路供电时（如果冒烟，那就不好了！）。
  • …和显然，与管道，其中管道系统实际上充满了烟雾，然后目视检查。如果有任何烟雾，系统是泄漏的。

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

对此，我将补充：

• 验收测试：测试功能或用例是否正确实现。它类似于联调，但关注要提供的用例，而不是所涉及的组件。

• 系统测试：将系统作为黑盒进行测试。在测试过程中，对其他系统的依赖通常会被模拟或存根（否则它更像是一个联调）。

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

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

单元测试是这里白盒测试的唯一形式。其他的是黑盒测试。白盒测试意味着你知道输入；你知道机制的内部工作原理，可以检查它，你知道输出。使用黑盒测试，你只知道输入是什么，输出应该是什么。

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

• 单元测试测试特定的代码片段。通常是方法。
• 集成测试测试您的新功能软件是否可以与其他所有内容集成。
• 回归测试。这是为了确保你没有破坏任何东西而做的测试。所有以前工作的东西都应该仍然工作。
• 冒烟测试是一种快速测试，以确保在您参与更激烈的测试之前一切看起来都很好。

单元测试：验证特定组件（即类）按照设计创建或修改的功能。此测试可以手动或自动进行，但不会超出组件的边界。

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

回归测试：验证没有在现有代码中引入新的缺陷。这些测试可以是手动的或自动的。

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

工具集在很大程度上依赖于代码库，但也有许多用于单元测试（JUnit）的开源工具。惠普（水星）的QTP或Borland的丝绸测试都是用于自动化集成和回归测试的工具。

回归测试-

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

我刚刚意识到的一个新的测试类别是金丝雀测试。金丝雀测试是一种自动化的、非破坏性的测试，在生活的环境中排名第一，如果它失败了，就会发生非常糟糕的事情。

例子可能是：

• 应该只在开发/测试中可用的数据是否出现了生活？
• 是否有后台进程运行失败？
• 用户可以登录吗？

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

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

在冒烟测试中，他们以浅层和广泛的方式检查应用程序。在冒烟测试中，他们检查应用程序的主要功能。如果应用程序中有任何拦截器问题，他们将向开发团队报告，开发团队将修复它并纠正缺陷，并将其返回给测试团队。现在测试团队将检查所有模块，以验证在一个模块中所做的更改是否会影响其他模块。冒烟测试测试用例是脚本化的。

回归测试重复执行相同的测试用例，以确保未更改的模块不会导致任何缺陷。回归测试属于功能测试

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

单元测试

单元测试通常由开发人员完成，而测试人员部分是在这种类型的测试中进化的，其中测试是一个单元一个单元地完成的。在JavaJUnit测试用例也可以测试编写的代码是否设计完美。

集成测试：

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

冒烟测试

这种类型的测试是在系统集成成功并准备好正式服时完成的。

这种类型的测试将确保从开始到结束的每个重要功能都正常工作，并且系统已准备好在正式服上部署。

回归测试

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

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

当您的测试调用多个类时，它是联调。

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

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

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

冒烟测试：是一种测试，用于决定是否接受构建/软件进行进一步的QA测试。

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

软件测试的类型-完整列表点击这里

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

单元测试：它总是由开发人员在开发完成后执行，以在他们为QA准备任何需求之前从测试方找出问题。

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

冒烟测试：测试人员执行以验证系统进行高级测试，并试图在更改或代码上线之前找出显示停止bug。

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

冒烟测试和健全性测试都是在软件构建后执行的，以确定是否开始测试。健全性可以在冒烟测试后执行，也可以不执行。它们可以单独执行，也可以同时执行——健全性在冒烟后立即执行。

由于完整性测试更深入，需要更多时间，因此在大多数情况下，自动化是非常值得的。

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

健全测试比冒烟详细，根据构建规模的不同，测试时间从15分钟到一整天不等。健全测试是一种更专业的验收测试，在进行或重新测试后执行。它检查某些新功能的核心特性和/或bug修复以及一些与其密切相关的特性，以验证它们是否按照所需的操作逻辑运行，然后才能大规模执行回归测试。

冒烟测试已经在这里解释过了，很简单。回归测试属于集成测试。

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

单元测试和集成测试（这就是一切）

我将使用短语“长测试”（LT）来进行所有测试，如集成测试、功能测试、回归测试、UI测试等，并将单元测试称为“短测试”。

一个LT的例子可以是，自动加载一个网页，登录到帐户并购买一本书。如果测试通过，它更有可能以同样的方式在实时站点上运行（因此是“更好的睡眠”参考）。Long=网页（开始）和数据库（结束）之间的距离。

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

我只是想补充并给出更多的背景，说明为什么我们有这些级别的测试，它们的真正含义是什么

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

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

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

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

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

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

从历史上看，开发人员或技术QA会使用各种工具编写这些测试，例如Postman、SoapUI、JMeter和其他工具，例如Testims。

这些测试比UI测试运行得更快，因为它们仍然在底层运行，但可能比单元测试消耗更多的时间，因为它必须检查系统中各个独立组件之间的通信并确保它们具有无缝集成。这应该包括超过30%的自动化测试。

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

例如-在计算器应用程序中，端到端流程可以是，打开浏览器->输入计算器应用程序url->使用用户名/密码登录->打开计算器应用程序->在计算器上执行一些操作->验证来自UI的结果->退出应用程序。这可能是一个端到端流程，是UI自动化的良好候选者。

从历史上看，技术QA或手动测试人员编写UI测试。他们使用像Selenium这样的开源框架或像Testima这样的UI测试平台来作者、执行和维护测试。这些测试提供更多的视觉反馈，因为你可以看到测试是如何运行的，通过屏幕截图、日志、测试报告看到预期结果和实际结果之间的差异。

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

接下来的两种类型的测试可以根据您的项目而有所不同，但想法是-

冒烟测试

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

回归测试

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