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

Question

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

例如，我使用JUnit和NUnit进行单元测试和集成测试。有没有烟雾测试或回归测试工具？

Answer 1

• 单元测试：指定并测试一个类的单个方法的合同的一个点。这应该有一个非常狭窄和明确的范围。复杂的依赖关系和与外界的互动是stubbed or mocked。

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

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

  • 烟雾测试与电子产品类似，第一次测试是在给电路加电时（如果它抽烟，那就太糟糕了！）......
  • ...和apparently，plumbing，其中管道系统实际上是由烟雾填充，然后在视觉上进行检查。如果有什么东西抽烟，系统就会漏水。

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

对此，我将添加：

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

• 系统测试：将系统测试为黑匣子。其他系统的依赖性通常在测试期间被模拟或存根（否则它将更多地是集成测试）。

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

Answer 2

• 单元测试：自动测试以测试类的内部工作方式。它应该是一个独立的测试，与其他资源无关。
• 集成测试：在环境中完成的自动测试，类似于单元测试，但具有外部资源（数据库，磁盘访问）
• 回归测试：在实施新功能或错误修复后，您将重新测试过去有效的方案。在这里，您将了解新功能是否会破坏现有功能。
• 冒烟测试：首先测试哪些测试人员可以继续测试。

Answer 3

每个人的定义都会略有不同，并且通常会出现灰色区域。但是：

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

Answer 4

我刚刚意识到的新测试类别是：

Canary测试

A Canary测试是一种自动化的非破坏性测试，它是在 LIVE 环境中定期运行，这样如果它失败了，就会发生一些非常糟糕的事情。

示例可能是：

• 是否只有DEV / TEST中可用的数据出现在 LIVE。
• 后台进程无法运行
• 用户可以登录

Answer 5

伪造的历史琐事：“烟雾测试”来自潜艇工程（继承自管道），在那里将字面的烟雾泵入船体，看它是否有任何一次出现，这对于潜艇而言将是一次戏剧性的失败！

Answer 6

从最好的软件测试技术网站之一回答：

软件测试类型 - 完整列表Click Here

  

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

希望它会有所帮助：）

Answer 7

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

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

回归测试：验证新缺陷未引入现有代码。这些测试可以手动或自动进行。

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

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

Answer 8

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

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

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

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

Answer 9

回归测试 -

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

Answer 10

单元测试针对可能的最小部分实施。在java中，这意味着您正在测试单个类。如果该类依赖于其他类，则这些都是伪造的。

当您的测试调用多个类时，其集成测试。

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

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

Answer 11

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

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

回归测试：验证新缺陷未引入现有代码。这些测试可以手动或自动进行。

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

Answer 12

在这个帖子中似乎值得一提的一种测试是压力/性能/负载测试，可以简单地找出某个软件破坏的限制。 请注意，在工具方面，必须从系统角度精确确定建议强调测试的范围。 例如，在“Web应用程序”的情况下，压力测试可以在其范围内包括Web服务器应用程序本身，因此工具可以干预该目的。 这是关于http load testing

的好文章

Answer 13

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

Answer 14

在软件构建之后执行烟雾和健全性测试以确定是否开始测试。在进行烟雾测试后，可能会或可能不会执行理智。它们可以单独执行或同时执行 - 在冒烟后立即执行。

因为完整性测试更加深入并需要更多时间，所以在大多数情况下，它都可以实现自动化。

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

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

Answer 15

单元测试： - 单元测试通常由开发人员方完成，其中测试人员在这种类型的测试中部分演变，其中测试是逐个单元完成的。 在java Junit测试用例中也可以测试编写的代码是否完美设计。

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

烟雾测试： - 当系统成功集成并准备好进入生产服务器时，最后完成此类测试。 这种类型的测试将确保从头到尾的每个重要功能都能正常工作，并且系统已准备好在生产服务器上部署。

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

Answer 16

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

Smoke测试：是否进行了一种测试，以决定是否接受Build / Software以进行进一步的QA测试。

Answer 17

单元测试：开发人员在开发完成后始终执行它，以便在他们为QA做出任何准备之前从他们的测试方面找出问题。

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

Smoke测试：执行测试程序以验证系统是否进行高级测试，并尝试在更改或代码生效之前找出显示停止错误。

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

Answer 18

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

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

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

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

Answer 19

  

单元测试单元测试的级别很低，接近您的来源   应用。它们在于测试各个方法和功能   您的软件使用的类，组件或模块。单元   测试通常自动化起来非常便宜，并且可以非常运行   连续集成服务器可以快速完成

。      

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

     

功能测试：功能测试关注业务需求   应用程序。他们仅验证动作的输出，而不验证   执行该操作时检查系统的中间状态   行动。

     

有时集成测试与   功能测试，因为它们都需要多个组件进行交互   彼此。区别在于集成测试可能只是   验证您可以在功能测试期间查询数据库   期望从数据库中获取特定的值，如   产品要求。

     

端到端测试端到端测试可以复制用户行为   完整的应用程序环境中的软件。它验证   各种用户流程都能按预期工作，就像加载一个   网页或登录或更复杂的场景来验证电子邮件   通知，在线付款等...

     

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

     

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

     

性能测试：性能测试可检查   负载很大的系统。这些测试是   非功能性的，可以有多种形式来理解   平台的可靠性，稳定性和可用性。对于   例如，执行高   请求数，或查看系统如何与   重要的数据。

     

性能测试就其性质而言，实施和实施的成本很高   运行，但是它们可以帮助您了解是否要进行新的更改   降级您的系统。

     

烟雾测试烟雾测试是用于检查基本情况的基本测试   应用程序的功能。他们注定要快   执行，他们的目标是给您保证   系统的功能正在按预期运行。

     

在做出新的构建决定之后，烟雾测试可能会很有用   您是否可以运行更昂​​贵的测试，还是在   部署以确保其应用程序在   新部署的环境。

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

Answer 20

以一种简化的方式。

单元测试：测试单个代码，算法，类或系统。该测试应该是独立的，并且应该对依赖项进行模拟或存根。

集成测试：应该测试组件，算法，类或系统是否被其他组件使用时工作正常，集成测试不是用于测试系统的工作方式（行为），而是应该测试系统运行良好。

烟雾测试：这是一整套很小的测试，应该首先运行它们进行大量测试，这将确保即使升级后系统的最关键功能也可以正常工作。< / p>

回归测试：是对计算机程序所做的更改进行测试的过程，以确保较旧的程序仍然可以与新更改一起使用。比烟雾测试要复杂得多。

如果您想了解有关集成测试的更多信息，可以在Udemy上这门课程，它的折扣很大。

https://www.udemy.com/testes-de-integracao-com-spring-boot/?couponCode=TISB_ODESC2019

Answer 21

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

自动测试可分为2个。

单元测试和集成测试。（这一切都很重要）

对于所有测试，例如集成测试，功能测试，回归测试，UI测试等，我会使用短语“long test”（LT）。单元测试为“短测试”。

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

这是一篇很好的文章，讨论integration testing(long test) over unit testing

的好处

Answer 22

我只想添加并提供更多背景信息，说明为什么我们要进行这些测试，这些测试对示例的真正意义

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

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

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

从历史上看，开发人员通常以与软件应用程序相同的编程语言来编写这些测试。为此，使用了单元测试框架，例如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分钟才能获得有关故障的更快反馈

回归测试

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

希望这会有所帮助

-Raj

Testim

My Website