烟雾测试和健全测试有什么区别?

时间:2015-02-19 11:44:06

标签: testing manual-testing smoke-testing sanity-testing

烟雾测试和健全测试有什么区别?什么时候进行烟雾测试?什么时候进行健全性测试?

10 个答案:

答案 0 :(得分:35)

完整性测试

完整性测试是回归测试的子集,当我们没有足够的时间进行测试时,它就会执行。

完整性测试是表面级测试,QA工程师验证产品和项目中可用的所有菜单,功能,命令是否正常工作。


实施例

例如,在一个项目中有5个模块:登录页面主页用户的详细信息页面,< em>新用户创建和任务创建

假设我们在登录页面中有一个错误:登录页面的用户名字段接受的用户名短于6个字母数字字符,这符合要求,因为在规定的用户名应该是是至少6个字母数字字符。

现在,测试团队将错误报告给开发团队以修复它。在开发团队修复错误并将应用程序传递给测试团队之后,测试团队还会检查应用程序的其他模块,以验证错误修复是否不会影响其他模块的功能。 但请记住一点:测试团队只检查模块的极端功能,因为时间短,所以不会深入测试细节。


在构建清除烟雾测试后进行完整性测试,并且QA团队已接受进行​​进一步测试。完整性测试用更精细的细节检查主要功能。

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


烟雾测试

在构建软件之后执行Smoke测试,以确定程序的关键功能正常工作。它被执行&#34;之前&#34;在软件构建上执行任何详细的功能或回归测试。

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

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

  
      
  • 验证应用程序是否成功启动,
  •   
  • 检查GUI是否有响应
  •   

答案 1 :(得分:12)

烟雾测试

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

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

完整性测试

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

烟雾测试与健全测试之间的区别

烟雾测试

  • 烟雾测试用于测试应用程序的所有区域,而不会过深。

  • 烟雾测试始终使用自动测试或一组书面测试。它始终是脚本化的。

  • 烟雾测试旨在以不彻底或详细的方式包含应用程序的每个部分。

  • 烟雾测试总能确保程序最关键的功能是否正常工作,但不会因细节问题而烦恼。

完整性测试

  • 完整性测试是一项狭隘的测试,主要关注一个或几个功能领域,但不是彻底或深入。

  • 完整性测试通常没有脚本。

  • 完整性测试用于确保在稍作更改后,应用程序的一小部分仍然有效。

  • 完整性测试是一种粗略的测试,用于证明应用程序根据规范运行。此级别的测试是回归测试的一个子集。

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

参考

答案 2 :(得分:4)

尝试通过这个例子理解两者。

假设您是否从展厅购买汽车。

你要检查汽车的第一件事是,例如它是四个轮胎,一个盯着,大灯还是所有其他基本的东西。这称为冒烟测试

如果您要检查汽车的行驶里程或最大速度是多少,则称为完整性测试

答案 3 :(得分:4)

烟雾和健康测试

一般来说,烟雾和健康测试似乎与刚刚开始的许多测试人员非常相似,因为在我们谈论 build 时,我们谈论功能并且我们谈论关于拒绝构建,如果构建的健康状况不利于可行的测试。

经历了几个项目,从初创公司到产品基础公司,我发现了烟雾和健康测试之间的基本区别。

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

烟雾测试

  • 进行烟雾测试以测试健康构建

  • 它也被称为浅和宽测试,因为我们通常包括那些可以涵盖产品所有功能的测试用例。

  • 我们可以说这是测试的第一步,在此之后,我们通常会进行其他类型的功能和系统测试,包括回归测试。

  • 通常由开发人员在某些脚本或某些工具的帮助下完成,但在某些情况下,它也可以由测试人员执行。

  • 它对构建确认的初始阶段有效。例如,假设我们已经开始开发某种产品,并且我们是第一次生产构建,那么烟雾测试就成了产品的必需品。

完整性测试

  • 这是次级回归

  • 对于那些经历过许多回归测试并且代码发生微小变化的构建版本,已经完成了理智。在这种情况下,我们通常会对发生这种变化或可能已经发生变化的功能进行密集测试。

    • 由于这个原因,它也被称为“狭窄”和“深度”测试
  • 由测试人员执行

  • 这对于成熟版本已经完成,就像那些刚刚投入生产的版本一样,并且经历了多个回归过程。

  • 如果已经进行回归,可以从测试过程中删除。

  • 如果任何构建没有通过完整性测试,那么它将被抛给开发人员以修正构建。

答案 4 :(得分:4)

烟雾测试

  1. 烟雾测试是一种广泛的方法,可以测试软件应用程序的所有区域而不会进入太深的

  2. 软件烟雾测试的测试用例可以手动或自动

  3. 进行烟雾测试以确保软件应用程序的主要功能是否有效。在对软件进行烟雾测试期间,我们不会详细介绍。

  4. 完成软件应用程序的烟雾测试以检查是否可以通过软件测试接受构建

  5. 此测试由开发人员或测试人员执行

  6. 烟雾测试从头到尾练习整个系统

  7. 烟雾测试就像一般健康检查

  8. 通常记录或编写烟雾测试

  9. Santy测试

    1. Sanity软件测试是一项狭隘的回归测试,主要关注软件应用程序的一个或一小部分功能。

    2. 完整性测试通常没有测试脚本或测试用例。

    3. 完整性测试是一种粗略的软件测试类型。只要快速的软件测试可以证明软件应用程序根据业务/功能要求运行,就可以完成。

    4. 软件的完整性测试是为了确保是否符合要求。

    5. 完整性测试通常由测试人员执行

    6. 完整性测试仅执行整个系统的特定组件

    7. 完整性测试就像专业的健康检查一样

    8. 通常没有记录完整性测试并且没有脚本

    9. 更多访问Link

答案 5 :(得分:1)

冒烟测试是关于检查是否满足要求。 烟雾测试是一般健康检查

完整性测试是关于检查特定模块是否完全正常工作。完整性测试专门用于健康检查

答案 6 :(得分:0)

烟雾测试

假设从开发阶段开始准备新的应用程序版本。

我们检查是否能够在没有崩溃的情况下打开应用程序。我们登录到该应用程序。我们检查用户是否被重定向到正确的URL并且环境是否稳定。如果该应用程序的主要目的是提供&#34;购买&#34;对用户的功能,检查用户的ID是否被重定向到购买页面。

冒烟测试之后,我们确认构建是可测试的形式,并准备好进行完整性测试。

完整性测试

在此阶段,我们会检查基本功能,例如

  1. 使用有效凭据登录
  2. 使用无效凭据登录
  3. 登录后
  4. 用户的信息正确显示
  5. 使用特定用户的身份
  6. 制作采购订单
  7. &#34;谢谢你&#34;购买后显示页面

答案 7 :(得分:0)

冒烟测试是旨在检查所有内容是否构建正确的测试。我的意思是集成,连接。因此,从技术角度检查是否可以进行更广泛的测试。您必须执行一些测试用例并检查结果是否为正。

完整性测试通常具有相同的目标 - 检查我们是否可以进行进一步的测试。但是在完整性测试中,您将重点放在业务价值上,以便执行一些测试用例,但是检查逻辑。

一般来说,人们都会说上面的烟雾测试,因为它们是在同一时间执行的(烟雾测试后的健全性),并且它们的目标是相似的。

答案 8 :(得分:-1)

根据ISTQB,烟雾与健康之间没有区别。

理智是烟的代名词。

在此处检查:https://glossary.istqb.org/en/search/sanity

答案 9 :(得分:-3)

烟雾测试: -

冒烟测试是编写脚本的,即您可以使用手动测试用例或自动脚本。

完整性测试: -

完整性测试大多没有编写脚本。