Vas*_*tha 27 testing manual-testing smoke-testing sanity-testing
烟雾测试和健全测试有什么区别？什么时候进行烟雾测试？什么时候进行健全性测试？
小智 36
完整性测试是回归测试的子集,它是在我们没有足够的时间进行测试时执行的.
完整性测试是表面级测试,QA工程师验证产品和项目中可用的所有菜单,功能,命令是否正常工作.
例如,在一个项目中有5个模块:登录页面,主页,用户详细信息页面,新用户创建和任务创建.
假设我们在登录页面中有一个错误:登录页面的用户名字段接受短于6个字母数字字符的用户名,这符合要求,因为在规定用户名应至少为6个字母数字字符的要求中.
现在,测试团队将错误报告给开发人员团队以修复它.在开发团队修复错误并将应用程序传递给测试团队之后,测试团队还会检查应用程序的其他模块,以验证错误修复是否不会影响其他模块的功能.但请始终牢记一点:测试团队只检查模块的极端功能,因为时间短,所以不会深入测试细节.
在构建清除了烟雾测试之后执行完整性测试,并且QA团队已接受进行进一步测试.完整性测试用更精细的细节检查主要功能.
当开发团队需要在代码中进行更改后快速了解产品状态,或者在功能中更改某些受控代码以修复任何关键问题时,执行完整性测试,并且严格的发布时间框架不会允许完整的回归测试.
在软件构建之后执行烟雾测试,以确定程序的关键功能正常工作.它在"之前"执行,在软件构建上执行任何详细的功能或回归测试.
目的是拒绝严重破坏的应用程序,以便QA团队不会浪费时间安装和测试软件应用程序.
在烟雾测试中,所选的测试用例涵盖了系统中最重要的功能或组件.目标不是进行详尽的测试,而是要验证系统的关键功能是否正常工作.例如,典型的烟雾测试将是:
- 验证应用程序是否成功启动,
- 检查GUI是否响应
小智 15
烟雾测试来自硬件环境,在那里应该进行测试以检查新硬件的开发是否第一次没有引起火灾和冒烟.
在软件环境中,进行烟雾测试以验证我们是否可以考虑进一步测试新构建的功能.
回归测试用例的一个子集在接收到功能或代码中的细微或微小变化的功能或代码后执行,以检查它是否解决了问题或软件错误,并且新更改没有引入其他软件错误.
烟雾测试用于测试应用程序的所有区域,而不会太深入.
烟雾测试总是使用自动测试或一组书面测试.它始终是脚本化的.
烟雾测试旨在以不彻底或详细的方式包含应用程序的每个部分.
烟雾测试始终确保程序最关键的功能是否正常工作,但不会打扰更精细的细节.
理智测试是一项狭隘的测试,侧重于一个或几个功能领域,但不是彻底或深入.
完整性测试通常没有脚本.
完整性测试用于确保在稍作更改后,应用程序的一小部分仍在工作.
健全性测试是一种粗略的测试,用于证明应用程序根据规范运行.此级别的测试是回归测试的子集.
希望这些要点可以帮助您了解烟雾测试和健全测试之间的区别.
小智 5
一般来说，冒烟和健全性测试似乎与许多刚开始的测试人员非常相似，因为在我们谈论构建、功能和拒绝构建时，如果构建的健康状况不利于可行的测试。
在经历了几个项目之后，从初创公司到产品基地公司，我弄清楚了冒烟测试和健全性测试之间的基本区别。
我在这里写了冒烟测试和健全性测试之间的区别，以帮助您回答至少一个通常所有测试人员在面试中都会被问到的问题。
进行冒烟测试是为了测试构建的健康状况。
它也被称为浅测试和宽测试，因为我们通常包括那些可以覆盖产品所有功能的测试用例。
我们可以说这是测试的第一步，在此之后，我们通常会进行其他类型的功能和系统测试，包括回归测试。
它通常由开发人员在某些脚本或某些工具的帮助下完成，但在某些情况下，它也可以由测试人员执行。
它对构建确认的初始阶段有效。例如，假设我们已经开始开发某个产品，并且我们是第一次生产构建版本，那么烟雾测试就成为该产品的必要条件。
这是子回归
对那些经过多次回归测试并且代码发生了微小变化的构建完成了理智。在这种情况下，我们通常会对已发生或可能影响此更改的功能进行密集测试。
它由测试人员执行
它是为成熟的构建完成的，比如那些即将投入生产并经过多次回归过程的构建。
如果已经在执行回归，则可以将其从测试过程中删除。
如果任何构建未通过健全性测试，则会将其返回给开发人员以进行构建的更正。