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

Question

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

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

Answer 1

• 单元测试:指定并测试一个类的单个方法的合同的一个点.这应该有一个非常狭窄和明确的范围.复杂的依赖关系和与外部世界的交互被扼杀或嘲笑.

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

• Smoke测试(又名Sanity检查):一个简单的集成测试,我们只是检查当被测系统被调用时它会正常返回并且不会爆炸.

  • 烟雾测试与电子设备类似,第一次测试是在给电路加电时(如果它抽烟,那就太糟糕了!)......
  • ...... 显然,还有管道,管道系统实际上是由烟雾填充,然后用肉眼检查.如果有什么东西抽烟,系统就会漏水.

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

对此,我将补充:

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

• 系统测试:将系统测试为黑盒子.在测试期间,通常会对其他系统的依赖性进行模拟或存根(否则它将更多地是集成测试).

• 飞行前检查:在生产环境中重复的测试,以减轻"我的机器上的建立"综合症.通常,这是通过在生产环境中进行验收或烟雾测试来实现的.

Answer 2

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

Answer 3

每个人的定义都会略有不同,通常都有灰色区域.然而:

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

Answer 4

我刚刚意识到的一个新的测试类别是:

金丝雀测试

一个金丝雀测试是一个自动化的,非破坏性测试定期运行在LIVE的环境,这样,如果它没有成功,一些真正糟糕的事情.

例子可能是:

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

Answer 5

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

Answer 6

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

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

这是一个很长的描述,我不会在这里粘贴它:但它可能对想要了解所有测试技术的人有所帮助.

希望它会有所帮助:)

Answer 7

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

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

回归测试:验证新缺陷未引入现有代码.这些测试可以是手动或自动的.

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

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

Answer 8

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

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

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

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

Answer 9

我只是想补充并提供更多关于为什么我们有这些级别的测试的背景，它们在示例中的真正含义

Mike Cohn 在他的《Succeeding with Agile》一书中提出了“测试金字塔”作为在项目中进行自动化测试的一种方法。对该模型有多种解释。该模型解释了需要创建什么样的自动化测试，他们可以多快地对被测应用程序提供反馈，以及谁编写这些测试。任何项目基本上都需要 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 分钟才能获得更快的故障反馈

回归测试

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

Answer 10

回归测试-

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

Answer 11

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

Answer 12

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

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

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

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