如果没有，是否仍在使用烟雾测试？
它有点像维恩图。有些自动测试是烟雾测试，有些烟雾测试是自动的（只要它们是由计算机程序运行的）。烟雾测试是对"有烟的地方通常会有火"这一术语的一种模仿（如果我没有记错的话）。这是一组程序必须通过的初步测试，才能被视为"真正的"（即火灾）测试。
烟雾测试可以是手动的，因为测试人员有一系列他要遵循的步骤，但这些步骤并不是用计算机程序自动完成的。
烟雾测试仍然在使用——在我工作过的地方，它通常是自动化的。
自动化测试可以进行烟雾测试（浅层、宽层），但也可以进行其他测试，如回归测试和单元测试。基本上自动化测试可以是任何可重复的测试。
是的，烟雾测试仍在使用中。我大致见过两种情况。第一个是确定软件是否准备好进行更深入的测试。第二种，也是国际海事组织更常见的一种，是对不应该受到新版本变化影响的功能进行全面测试。
我不认为烟雾测试通常是自动化的。根据我的经验，烟雾测试实际上只是一个基本的健全性测试，以确保后续测试能够真正运行，并且没有任何基本的东西像启动代码或菜单项那样被破坏。这通常是由一个人手动完成的。我想它可以是自动化的，但通常它涉及到添加新功能，所以自动化测试也必须更改，而且你仍然会遇到同样的问题，你需要一个人来验证自动化测试是否经过了修改，以正确测试新功能。相比之下，自动化测试（如单元测试）代表了一个回归测试套件，其创建目的是测试成熟的功能，这些功能在不同版本之间不会有太大变化，当然您也会添加单元测试来覆盖新功能。
可能更多的是在硬件背景的公司中进行烟雾测试。很少有人再这样称呼他们了。它通常只是一个较大的验收或系统测试套件的一个小而广泛的子集。这些tet是自动化的，在提交代码之前或提交给源代码控制时，它们会自动针对代码运行。
我不确定我们能否比较Smoke和Automated测试。烟雾测试是在构建中运行一组基本测试的一种方式，涵盖了所有基本功能，但没有深入到任何功能。目的是确定构建是否可以用于更详细的测试。这也是一组步骤，即使在开发人员构建中也可以快速运行，以确定是否由于构建中即将进行的一些重大或核心更改而出现任何问题。我们认为Smoke测试是我们的"测试计划"之一，但它在每个构建中都会运行。
自动测试并不适用于烟雾测试，但也可以应用于烟雾测试。这样做是为了"自动化"冗余或重复的步骤，而测试人员总是这样做以节省时间。这是自动化的主要目的。它允许测试人员花更多的时间进行其他测试。
它永远不可能取代真正的大脑进行测试，也不可能实现一切自动化。这是一项补充现有测试过程的活动，而不是取代它
由于烟雾测试可能在每个构建上运行，因此自动化它有很好的价值。如果手动运行烟雾测试需要4个小时，而自动化后需要1个小时，那么您就节省了3个工时*构建数量。
市场上有几种自动化测试工具，例如AutoIT和SilkTest。
简单地说，烟雾测试可以是自动化的，但自动化测试并不总是烟雾测试。
是的，烟雾测试是测试任何应用程序/软件的一种流行方式。
我对"烟雾测试"的理解与维基百科文章不同。我理解烟雾测试是开发人员打开应用程序并测试基本功能，以验证应用程序是否正确&正在做基础工作。所以我一直认为这是一个手动过程，而不是自动过程。
测试自动化套件包含各种级别，如烟雾测试、验收测试、夜间构建等。由测试人员决定需要在每个级别中运行哪个测试用例。每个测试用例的编号取决于它们应该运行的级别。假设有两个测试用例是自动的，分别用1和2来表示级别，并且您在配置文件中将测试级别定义为2，它将只运行第二个测试用例并给出结果。与验收测试相比，烟雾测试的测试用例数量通常较少。
烟雾测试可以是自动化的，但并非所有的自动化测试都是烟雾测试。