问冒烟测试和健全测试的区别是什么？

EN

健全性测试

健全性测试是回归测试的子集，它是在我们没有足够的时间进行测试时执行的。

健全性测试是表面级别的测试，其中QA工程师验证产品和项目中所有可用的菜单、功能和命令是否正常工作。

示例

例如，在一个项目中有5个模块:登录页面、主页、用户详细信息页面、新用户创建和任务创建。

假设我们在登录页面中有一个bug :登录页面的username字段接受少于6个字母数字字符的用户名，这违反了要求，因为在要求中规定用户名应该至少是6个字母数字字符。

现在，测试团队将该错误报告给开发团队进行修复。在开发团队修复错误并将应用程序传递给测试团队后，测试团队还会检查应用程序的其他模块，以验证修复的错误不会影响其他模块的功能。但请记住一点:测试团队只检查模块的极端功能，由于时间较短，不会深入测试细节。

健全性测试是在构建通过冒烟测试并接受QA团队进行进一步测试后执行的。健全性测试以更详细的细节检查主要功能。

当开发团队需要在代码中进行更改后快速了解产品的状态，或者在功能中有一些受控制的代码更改以修复任何关键问题时，就会执行健全性测试，而严格的发布时间框架不允许进行完整的回归测试。

烟雾测试

冒烟测试在软件构建后执行，以确定程序的关键功能运行良好。它是在软件构建上执行任何详细的功能或回归测试之前执行的。

其目的是拒绝严重损坏的应用程序，以便QA团队不会浪费时间安装和测试软件应用程序。

在烟雾测试中，选择的测试用例涵盖了系统中最重要的功能或组件。目标不是执行详尽的测试，而是验证系统的关键功能是否正常工作。例如，典型的烟雾测试将是：

• 验证应用程序启动是否成功，
• 检查图形用户界面是否响应

烟雾测试

冒烟测试来自硬件环境，在硬件环境中应该进行测试，以检查新硬件的开发是否第一次没有起火和冒烟。

在软件环境中，进行冒烟测试，以验证是否可以考虑对新构建的功能进行进一步测试。

健全性测试

在接收到功能或代码中具有小的或小的改变的功能或代码之后，执行回归测试用例的子集，以检查它是否解决了问题或软件错误，并且新的改变没有引入其他软件错误。

冒烟测试与健全性测试的区别

烟雾测试

• Smoke testing用于测试应用程序的所有区域，而无需深入测试。
• smoke测试始终使用自动测试或一组书面测试。scripted.
• Smoke测试旨在以不彻底或不详细的方式包含应用程序的每个部分。
• Smoke测试始终确保程序的最关键功能是否正常工作，但不会为更详细的细节而烦恼。

健全性测试

• 健全性测试是一种范围很窄的测试，它侧重于一个或几个功能领域，但不是彻底或深入的。健全性测试通常是一种粗略测试( working.
• Sanity
• )，用于确保在发生微小更改后，应用程序的一小部分仍为粗略测试，以证明应用程序是按照规范运行的。这一级别的测试是回归测试的子集。

希望这些要点能帮助您理解冒烟测试和健全测试之间的区别。

参考文献

• http://www.softwaretestinghelp.com/smoke-testing-and-sanity-testing-difference/
• https://www.guru99.com/smoke-sanity-testing.html

烟雾和健全性测试

一般来说，冒烟和健全性测试似乎与许多刚刚开始的测试人员非常相似，因为在我们讨论构建时，我们都讨论功能，如果构建的健康状况不利于可行的测试，我们就会讨论拒绝构建。

在经历了几个项目后，从初创公司到产品基础公司，我弄清楚了冒烟测试和理智测试之间的基本区别。

我在这里写了烟雾测试和理智测试之间的区别，以帮助您回答通常所有测试人员在面试中都会被问到的至少一个问题。

烟雾测试

• Smoke测试是为了测试构建的健康状况。
• 它也被称为浅层和广度测试，因为我们通常包括那些可以覆盖产品所有功能的测试用例。
• 我们可以说这是测试的第一步，在此之后，我们通常会进行其他类型的功能和系统测试，包括回归测试。
• 通常由开发人员在某些脚本或某些工具的帮助下完成。但在某些情况下，它也可以由测试人员执行。
• ，它对构建确认的初始阶段有效。例如，假设我们已经开始了某个产品的开发，并且我们是第一次生产一个构建，那么冒烟测试就成为该产品的必需品。

健全性测试

对于那些已经经历了许多回归测试并且代码发生了微小变化的构建，sub-regression

• Sanity is
• 是这样做的。在这种情况下，我们通常在发生或可能影响此更改的情况下对功能进行密集测试。

- Due to this, it is also known as "narrow" and "deep" testing

​

这是由测试人员执行的，对于成熟的构建是这样做的，比如那些刚刚投产的构建，并且已经经历了多次回归processes.

• It可以从测试过程中删除，如果回归已经在performed.

• If
• 未通过健全性测试，则将其抛回给开发人员以进行构建的更正。