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