什么是单元测试、集成测试、冒烟测试和回归测试？它们之间有什么区别，我可以为它们使用哪些工具？
【问题讨论】：
标签： unit-testing testing definition
单元测试：指定并测试一个类的单个方法的契约点。这应该有一个非常狭窄和明确定义的范围。与外界的复杂依赖和交互是stubbed or mocked。
集成测试：测试多个子系统的正确互操作。从测试两个类之间的集成到测试与生产环境的集成，有整个范围。
冒烟测试（又名 健全性 检查）：一个简单的集成测试，我们只检查当被测系统被调用，正常返回，不会崩溃。
回归测试：在修复错误时编写的测试。它确保此特定错误不会再次发生。全称是“非回归测试”。它也可以是在更改应用程序之前进行的测试，以确保应用程序提供相同的结果。
对此，我将补充：
验收测试：测试功能或用例是否正确实现。它类似于集成测试，但侧重于要提供的用例，而不是涉及的组件。
系统测试：将系统作为黑盒进行测试。对其他系统的依赖关系通常在测试期间被模拟或存根（否则它更像是一个集成测试）。
飞行前检查：在类生产环境中重复进行的测试，以缓解“在我的机器上构建”综合症。这通常是通过在类似生产环境中进行验收或冒烟测试来实现的。
【讨论】：
【讨论】：
每个人的定义都会略有不同，而且往往存在灰色地带。然而：
【讨论】：
myprj 是主项目目录，mypkg 位于myprj 下，我的单元测试位于myprj/tests/test_module1.py 下，我的包位于myprj/mypkg 下。这对单元测试很有用，但我想知道是否有任何约定，我应该遵循集成测试应该驻留在哪里？
我刚刚意识到的一个新测试类别是canary test。金丝雀测试是在实时环境中定期运行的自动化、非破坏性测试，因此如果它失败了，那就是真的很糟糕的事情发生了。
示例可能是：
【讨论】：
【讨论】：
单元测试：验证特定组件（即类）是否按设计创建或修改了功能。此测试可以手动或自动进行，但不会超出组件的边界。
集成测试：验证特定组件的交互是否按设计运行。集成测试可以在单元级别或系统级别执行。这些测试可以是手动的也可以是自动的。
回归测试：验证现有代码中没有引入新缺陷。这些测试可以是手动的也可以是自动的。
根据您的SDLC（waterfall、RUP、agile 等），特定的测试可以分“阶段”执行，也可以或多或少同时执行。例如，单元测试可能仅限于开发人员，然后他们将代码交给测试人员进行集成和回归测试。但是，另一种方法可能会让开发人员进行单元测试以及某种程度的集成和回归测试（使用TDD 方法以及持续集成和自动化单元和回归测试）。
工具集在很大程度上取决于代码库，但有许多用于单元测试 (JUnit) 的开源工具。 HP (Mercury) QTP 或 Borland 的 Silk Test 都是自动化集成和回归测试的工具。
【讨论】：
单元测试：测试应用程序中的单个模块或独立组件被称为单元测试。单元测试将由开发人员完成。
集成测试：结合所有模块，测试应用程序，验证模块之间的通信和数据流是否正常。此测试也由开发人员执行。
冒烟测试 在冒烟测试中，他们以浅而宽的方式检查应用程序。在冒烟测试中，他们检查应用程序的主要功能。如果应用程序中有任何阻塞问题，他们将向开发团队报告，开发团队将修复并纠正缺陷，并将其返回给测试团队。现在测试团队将检查所有模块，以验证在一个模块中所做的更改是否会影响另一个模块。 在冒烟测试中测试用例是脚本化的。
回归测试重复执行相同的测试用例以确保未更改的模块不会导致任何缺陷。回归测试属于功能测试
【讨论】：
“回归测试针对更改的软件重新运行以前的测试，以确保在当前软件中所做的更改不会影响现有软件的功能。”
【讨论】：
"regression test" 和"non-regression test" 的结果列表中的文本 sn-ps。都是一样的。
我只是想补充并提供更多背景信息，说明我们为什么要进行这些级别的测试，它们对示例的真正含义
Mike Cohn 在他的《敏捷成功》一书中提出了“测试金字塔”作为在项目中进行自动化测试的一种方法。这个模型有多种解释。该模型解释了需要创建什么样的自动化测试、他们可以多快地对被测应用程序提供反馈以及谁编写这些测试。 基本上任何项目都需要 3 个级别的自动化测试，它们如下所示。
单元测试- 这些测试您的软件应用程序的最小组件。这实际上可能是代码中的一个函数，它根据一些输入计算一个值。此功能是构成应用程序的硬件/软件代码库的其他几个功能的一部分。
例如 - 让我们以基于 Web 的计算器应用程序为例。该应用程序中需要进行单元测试的最小组件可能是一个执行加法的函数，另一个执行减法的函数等等。所有这些小功能组合在一起就构成了计算器应用程序。
过去，开发人员编写这些测试，因为它们通常使用与软件应用程序相同的编程语言编写。诸如 JUnit 和 NUnit（用于 java）、MSTest（用于 C# 和 .NET）和 Jasmine/Mocha（用于 JavaScript）等单元测试框架用于此目的。
单元测试的最大优势在于，它们在 UI 下运行得非常快，我们可以快速获得有关应用程序的反馈。这应该包含超过 50% 的自动化测试。
API/集成测试- 它们一起测试软件系统的各个组件。这些组件可能包括测试数据库、API（应用程序编程接口）、第三方工具和服务以及应用程序。
例如 - 在我们上面的计算器示例中，Web 应用程序可能使用数据库来存储值，使用 API 进行一些服务器端验证，并且它可能使用第 3 方工具/服务将结果发布到云端以实现可在不同平台上使用。
过去，开发人员或技术 QA 会使用各种工具（例如 Postman、SoapUI、JMeter 和 Testim 等其他工具）编写这些测试。
这些运行速度比 UI 测试快得多，因为它们仍然在后台运行，但可能比单元测试消耗更多时间，因为它必须检查系统各个独立组件之间的通信并确保它们具有无缝集成。这应该包含超过 30% 的自动化测试。
UI 测试- 最后，我们有验证应用程序 UI 的测试。这些测试通常用于测试通过应用程序的端到端流程。
例如 - 在计算器应用程序中，端到端流程可以是，打开浏览器 -> 输入计算器应用程序 url -> 使用用户名/密码登录 -> 打开计算器应用程序 -> 执行一些操作在计算器上 -> 从 UI 验证这些结果 -> 注销应用程序。这可能是一个端到端的流程，非常适合 UI 自动化。
从历史上看，技术 QA 或手动测试人员会编写 UI 测试。他们使用像 Selenium 这样的开源框架或像 Testim 这样的 UI 测试平台来编写、执行和维护测试。这些测试提供了更多的视觉反馈，因为您可以通过屏幕截图、日志、测试报告查看测试的运行方式、预期结果与实际结果之间的差异。
UI 测试的最大限制是，与单元和 API 级别的测试相比，它们相对较慢。因此，它应该只占整个自动化测试的 10-20%。
接下来的两种类型的测试可以根据您的项目而有所不同，但想法是-
烟雾测试
这可以是上述 3 个测试级别的组合。这个想法是在每次代码签入期间运行它，并确保系统的关键功能仍然按预期工作；合并新代码更改后。他们通常需要运行 5 到 10 分钟才能更快地获得故障反馈
回归测试
它们通常至少每天运行一次，涵盖系统的各种功能。他们确保应用程序仍按预期工作。它们比冒烟测试更详细，涵盖了应用程序的更多场景，包括非关键场景。
【讨论】：
单元测试是针对实现的最小部分。在 Java 中，这意味着您正在测试单个类。如果该类依赖于其他类，则这些是伪造的。
当您的测试调用多个类时，它是一个集成测试。
完整的测试套件可能需要很长时间才能运行，因此在进行更改后，许多团队会运行一些快速完成的测试来检测重大损坏。例如，您已将 URI 分解为基本资源。这些是烟雾测试。
回归测试在每个构建上运行，并允许您通过捕获中断的内容来有效地重构。任何类型的测试都可以是回归测试，但我发现单元测试最有助于找出故障源。
【讨论】：
【讨论】：
单元测试：它总是由开发人员在开发完成后执行，以便在他们为 QA 准备好任何需求之前从测试方面找出问题。
集成测试：当某些数据/功能输出驱动到一个模块到另一个模块时，测试人员必须验证模块到子模块的验证。或者在您的系统中，如果使用使用您的系统数据进行集成的第三方工具。
冒烟测试：测试人员执行以验证系统以进行高级测试，并试图在更改或代码上线之前找出显示阻止错误。
回归测试：测试人员执行回归以验证现有功能由于系统中实施的更改以进行新增强或系统更改。
【讨论】：
单元测试通常由开发人员完成，而测试人员在这种类型的测试中部分进化，测试是逐个单元完成的。 在Java中JUnit测试用例也可以用来测试写出来的代码是否设计完美。
这种类型的测试在单元测试之后当所有/部分组件被集成时是可能的。这种类型的测试将确保当组件被集成时，它们是否会影响彼此的工作能力或功能？
这种类型的测试最后在系统集成成功并准备在生产服务器上进行时完成。
这种类型的测试将确保从头到尾的每个重要功能都运行良好，并且系统已准备好部署到生产服务器上。
这种类型的测试对于测试开发人员修复某些问题时系统中是否不存在意外/不需要的缺陷非常重要。 此测试还确保所有错误都已成功解决，因此不会出现其他问题。
【讨论】：
冒烟和健全性测试均在软件构建后执行，以确定是否开始测试。在烟雾测试后可能会或可能不会执行理智。它们可以单独执行，也可以同时执行 - 理智是在烟雾之后立即执行的。
由于健全性测试更深入且需要更多时间，因此在大多数情况下，自动化是非常值得的。
烟雾测试的执行时间通常不超过 5-30 分钟。它更通用：它检查整个系统的少量核心功能，以验证软件的稳定性是否足以进行进一步测试并且没有问题，从而阻止计划的测试用例的运行。
健全性测试比烟雾更详细，可能需要 15 分钟到一整天，具体取决于新构建的规模。它是一种更专业的验收测试，在进展或重新测试之后执行。它检查某些新功能和/或错误修复的核心功能以及一些与其密切相关的功能，以便在更大规模地执行回归测试之前验证它们是否按照所需的操作逻辑运行。
【讨论】：
已经有一些很好的答案，但我想进一步完善它们：
单元测试是这里唯一的白盒测试形式。其他的是黑盒测试。白盒测试意味着你知道输入；您知道该机制的内部工作原理并且可以检查它并且您知道输出。通过黑盒测试，您只知道输入是什么以及输出应该是什么。
很明显，单元测试是这里唯一的白盒测试。
【讨论】：
烟雾测试已经在这里进行了解释并且很简单。回归测试属于集成测试。
自动化测试可以分为两种。
单元测试和集成测试（这才是最重要的）
对于所有测试，如集成测试、功能测试、回归测试、UI 测试等，我会称使用短语“长测试”(LT)。将单元测试称为“短测试”。
LT 示例可以是自动加载网页、登录帐户并购买书籍。如果测试通过，则更有可能以相同的方式在现场运行（因此有“更好的睡眠”参考）。 Long = 网页（开始）和数据库（结束）之间的距离。
这是一篇很棒的文章，讨论了integration testing (long test) over unit testing 的好处。
【讨论】：
回归测试 - 是一种软件测试，我们试图覆盖或检查错误修复。围绕错误修复的功能不应因提供的修复而改变或改变。在此过程中发现的问题称为回归问题。
冒烟测试：是一种测试，用于决定是否接受构建/软件进行进一步的 QA 测试。
【讨论】：