自动化测试仍称为烟雾测试？

Question

如果不是，是smoke testing仍然使用？

Answer 1

这是一种维恩图。一些自动化测试是烟雾测试，一些烟雾测试是自动化的（因为它们是由计算机程序运行的）。烟测试是一个起飞（如果我没有记错的话）术语“哪里有烟，通常有火。”这是一套初步测试，程序必须通过考虑“真实”（即火灾）测试。

烟雾测试可以手动完成，因为测试人员有一系列他所遵循的步骤，但这些步骤并非通过计算机程序自动执行。

烟雾测试仍在使用 - 在我工作的地方，通常是自动化的。

Answer 2

我对“烟雾测试”的理解与维基百科文章不同。我了解冒烟测试是开发应用程序和测试基本功能的开发人员，以验证应用程序看起来正确&正在做基础。所以我一直认为这是一个手动过程，而不是自动化过程。

Answer 3

我不认为烟雾测试通常是自动的。我的经历中的烟雾测试实际上只是一个基本的理性测试，以确保后续测试可以真正运行，并且没有像启动代码或菜单条目那样基本被破解。这通常会由一个人手动完成。我想这可能是自动化的，但通常它会涉及到添加新功能，所以自动化测试也必须进行更改，而且您仍然有同样的问题，您需要一个人来验证自动化测试是修改为正确测试新功能。相比之下，自动化测试（比如单元测试）代表了一个回归测试套件，用于测试从发布到发布的变化不大的完善功能，尽管您当然也会添加单元测试来涵盖新功能。

Answer 4

可能更多的公司是从硬件背景中抽烟测试的字面上。很少有人再这样称呼他们。它通常只是一个较大的验收或系统测试套件的一小部分而广泛的子集。这些脚本是自动的，并在提交之前或提交给源代码控制之前自动针对代码运行。

Answer 5

自动化测试可以进行烟雾测试（浅，宽），但它也可以执行其他测试，如regression testing和unit testing。基本上自动化测试可以是任何可重复的测试。

是的，烟雾测试仍在使用中。我通常看到两种情况。首先是确定软件是否准备好进行更深入的测试。第二种和IMO更常见的是撇弃不应该受到新版本更改影响的全面测试功能。

Answer 6

我不确定我们可以比较烟雾和自动化测试。烟雾测试是一种在构建上运行一系列基本测试的方法，涵盖了所有基本功能，但不能深入研究。目的是确定构建是否可用于更详细的测试。这也是一组步骤，即使在开发人员构建中也可以快速运行，以确定是否存在因构建中即将进行的重要或核心更改而导致的任何问题。我们认为Smoke测试是我们的“测试计划”之一，但是每个构建都会运行一次。

自动化测试不是特定于烟雾测试，但也可以在那里应用。这样做是为了“自动化”冗余或重复的步骤，测试人员总是这样做以节省时间。这是自动化的主要目的。允许测试人员花更多时间做其他测试。

它永远不能用真正的大脑替代测试，也不能使所有的东西都自动化。这是一项补充测试过程的活动，而不是替代它。

由于烟雾测试可能在每个版本上运行，因此在自动化测试中有很好的价值。如果手动进行烟雾测试需要4个小时，并且自动化后需要1个小时，那么您已经节省了3个工时*的构建数量。

自动化测试市场上有几种工具--AutoIT和SilkTest等等。

Answer 7

用非常简单的话来说，烟雾测试可以是自动化的，但它不像自动化测试总是冒烟测试。

是的，烟雾测试是测试任何应用程序/软件的流行方式。

Answer 8

测试自动化套件包含各种级别，如烟雾测试，验收测试，每晚构建等。它由测试人员决定哪个测试用例需要在每个级别运行。每个测试用例都根据应该运行的级别进行编号。假设有2个测试用例是自动的，分别用1和2编号以指示级别，并且在配置文件中将测试级别定义为2，则它只运行第二个测试用例并给出结果。与验收测试相比，烟雾测试通常具有较少的测试案例数量。

烟雾测试可以自动进行，但不是所有的自动化测试都是烟雾测试。