testing - 自动化测试是否仍称为冒烟测试？

Question

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

Answer 1

这有点像维恩图。一些自动化测试是冒烟测试，而一些冒烟测试是自动化的（因为它们是由计算机程序运行的）。烟雾测试（如果我没记错的话）是对“有烟的地方，通常会有火”这一术语的起飞（如果我没记错的话）。这是程序必须通过的一组初步测试，才能考虑进行“真实”（即火灾）测试。

冒烟测试可以是手动的，因为测试人员有一个他遵循的步骤列表，但这些不是通过计算机程序自动化的。

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

Answer 2

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

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

Answer 3

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

Answer 4

可能更多来自硬件背景的公司，其中烟雾测试是按字面意思进行的。很少有人这样称呼他们了。它通常只是一个较大的验收或系统测试套件的一个小而广泛的子集。这些 tet 是自动化的，并在代码提交之前或提交到源代码控制时自动针对代码运行。

Answer 5

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

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

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

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

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

Answer 6

简单来说，我们可以说冒烟测试可以自动化，但自动化测试并不总是冒烟测试。

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

Answer 7

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

Answer 8

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

冒烟测试可以自动化，但并非所有自动化测试都是冒烟测试。