单元测试：测试类内部工作的自动测试。它应该是与其他资源无关的独立测试。集成测试：在环境中进行的自动测试，与单元测试非常相似，但使用外部资源（数据库、磁盘访问）回归测试：在实现新功能或bug修复后，您重新测试过去有效的场景。这里您将介绍新功能打破现有功能的可能性。烟雾测试：测试人员可以断定是否继续测试的第一次测试。

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

单元测试：这一点（尽可能隔离）是否有效？集成测试：这两个（或更多）组件是否一起工作？烟雾测试：整个系统（尽可能接近于一个生产系统）是否结合得很好？（即，我们有理由相信它不会产生黑洞吗？）回归测试：我们是否无意中重新引入了以前修复过的bug？

单元测试：指定并测试类的单个方法的契约的一个点。这应该有一个非常狭窄和明确的范围。复杂的依赖关系和与外部世界的交互会被破坏或嘲弄。集成测试：测试多个子系统的正确互操作。从测试两个类之间的集成，到测试与生产环境的集成，这是一个完整的过程。烟雾测试（也称为健全性检查）：一个简单的集成测试，我们只需要检查当被测试的系统被调用时，它是否正常返回并且不会崩溃。烟雾测试与电子设备都是一个类比，在电子设备中，当电路通电时会进行第一次测试（如果它冒烟，那就糟糕了！）。。。……显然，还有管道系统，管道系统被烟雾填满，然后进行目视检查。如果有任何东西冒烟，系统就会泄漏。回归测试：在修复错误时编写的测试。它可确保此特定错误不会再次发生。全名是“非回归测试”。它也可以是在更改应用程序之前进行的测试，以确保应用程序提供相同的结果。

对此，我将补充：

验收测试：测试功能或用例是否正确实现。它类似于集成测试，但侧重于要提供的用例，而不是所涉及的组件。系统测试：将系统作为黑盒进行测试。在测试过程中，对其他系统的依赖性通常会被嘲笑或清除（否则这将更像是一个集成测试）。飞行前检查：在类似生产的环境中重复进行的测试，以缓解“在我的机器上构建”综合症。这通常通过在类似生产的环境中进行验收或烟雾测试来实现。

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

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

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

单元测试测试特定的代码片段。通常是方法。集成测试测试您的新功能软件是否可以与其他所有功能集成。回归测试。这是为了确保您没有损坏任何东西而进行的测试。一切过去有效的东西都应该继续有效。烟雾测试是作为一项快速测试来完成的，以确保在您参与更激烈的测试之前一切都正常。

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

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

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

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

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

回归测试-

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

我刚刚意识到的一个新的测试类别是金丝雀测试。金丝雀测试是一种自动的、非破坏性的测试，它在实时环境中定期运行，因此如果失败了，就会发生非常糟糕的事情。

例如：

只有在开发/测试中才可用的数据是否出现了？后台进程是否无法运行？用户可以登录吗？

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

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

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

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

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

单元测试

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

集成测试：

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

烟雾测试

这种类型的测试是在系统成功集成并准备在生产服务器上运行时完成的。

这种类型的测试将确保从开始到结束的每个重要功能都能正常工作，并且系统可以部署到生产服务器上。

回归测试

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

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

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

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

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

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

烟雾测试：是一种决定是否接受构建/软件以进行进一步QA测试的测试。

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

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

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

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

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

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

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

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

因为健全性测试更深入，需要更多时间，所以在大多数情况下，自动化是非常值得的。

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

卫生测试比吸烟更详细，可能需要15分钟到一整天，具体取决于新建筑的规模。这是一种更专业的验收测试，在进展或重新测试后进行。它检查某些新功能和/或bug修复的核心特性以及与这些特性密切相关的一些特性，以便在可以更大规模地执行回归测试之前，验证它们是否按照所需的操作逻辑运行。

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

自动化测试可分为两种。

单元测试和集成测试（这是最重要的）

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

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

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

我只是想补充一下，并给出更多的背景，说明我们为什么要进行这些级别的测试，以及它们对示例的真正意义

Mike Cohn在他的《敏捷成功》一书中提出了“测试金字塔”作为一种在项目中实现自动化测试的方法。对这个模型有多种解释。该模型解释了需要创建什么样的自动化测试，他们可以以多快的速度向被测试的应用程序提供反馈，以及由谁编写这些测试。任何项目基本上都需要3个级别的自动化测试，如下所示。

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

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

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

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

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

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

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

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

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

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

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

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

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

烟雾测试

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

回归测试

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