自动化测试仍然被称为烟雾测试吗？

Question

如果没有，是否仍在使用冒烟测试？

Answer 1

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

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

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

Answer 2

自动化测试可以进行烟雾测试（浅，宽），但也可以进行其他测试，如回归测试，并单元测试。基本上自动化测试可以是任何可重复的测试。

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

Answer 3

我认为烟雾测试通常不会自动化。根据我的经验，冒烟测试实际上只是一个基本的健全性测试，以确保后续测试可以实际运行，并且没有任何基本的破坏像启动代码或菜单条目。这通常可以由一个人手动完成。我想它可以自动化，但通常它涉及添加新功能，因此自动化测试也必须改变，你仍然有同样的问题，你需要一个人来验证自动化测试是修改为正确测试新功能。相比之下，自动化测试（如单元测试）代表了一个回归测试套件，用于测试成熟的功能，这些功能在发布版本之间不会有太大变化，当然您也可以添加单元测试以涵盖新功能。 / p>

Answer 4

在硬件背景下进行烟雾测试的公司可能更多。很少有人再这样称呼他们了。它通常只是较大的验收或系统测试套件的一小部分而且很宽泛。这些tets是自动化的，在提交或提交到源代码控制之前会自动针对代码运行。

Answer 5

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

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

永远不能用真正的大脑取代测试，也不能一切都是自动化的。这是一项补充测试过程的活动，而不是取代它。

由于Smoke测试可能在每个构建上运行，因此自动化它具有很好的价值。如果手动运行烟雾测试需要4个小时，并且在自动化之后需要1个小时，则您节省了3个工时*构建数量。

市场上有几种自动化测试工具 - AutoIT和SilkTest，仅举几例。

Answer 6

简单来说，我们可以说Smoke测试可以自动化，但它不像自动测试总是进行烟雾测试。

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

Answer 7

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

Answer 8

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

烟雾测试可以自动进行，但并非所有自动测试都是烟雾测试。