烟雾测试的附加值是多少？

Question

或者也许我们实施它。我是想要完成整个过程的团队的新手，这似乎让我们的团队中的一些成员感到困惑，包括我。我们得到了我认为的用户验收测试或手动操作列表，您可以点击它们以查看是否一切正常。我认为它会比这简单得多，因为我们只是将应用程序的各个部分分开，并且通常只是查看它会发现巨大的错误。这将不涉及脚本，只需单击每个页面，可能填写东西，确保它提交确定。这让我想到了另一点，在我看来，烟雾测试基本上毫无价值。我认为相反，你会进行单元测试甚至是自动化测试，这些测试会通过一个需求列表来确保这种事情能够正确地发生。即使至少没有完成，我认为首先检查代码的开发人员至少会进行一次微型烟雾测试，以确保他们的功能首先起作用。我们在会议中提到了这一点，你可以想象出这种困惑，这让我回到了我的问题，我们将从这种类型的烟雾测试中获得什么价值呢？

Answer 1

任何测试的价值在于增加您对实施的信心。进行这种“冒烟测试”是为了增加它确实正确构建的可信度，并且没有重大且令人尴尬的错误，例如用户界面不会出现。所以它基本上是一种省力的测试。确认没有什么真正的重大问题。

这听起来可能听起来不太有用，但我看到经过严格测试的代码无法通过“冒烟测试”，因为例如构建中的意外故障或图像损坏。通常在向重要客户展示时。

Answer 2

如果您将冒烟测试定义为“运行系统的基本功能以确保它们正常工作”，那么我认为这有价值。必要时，单元测试并非全包。他们没有发现任何集成错误。至于自动化测试，我还没有看到一个可以通过自动化进行全面测试的系统，即使你可以，这样的自动化也需要时间和精力来完成。

基本上，我在其中看到的价值是让我们确保我们今天对代码所做的更改不会破坏昨天正在运行的任何内容。根据您的编码实践的规划程度，这并不总是给定的。

Answer 3

要回答“什么是烟雾测试？”这个问题，请想象您正在测试一件电气或电子设备。

将其插入并打开电源：

• 您是否看到它开启（例如屏幕或电源指示灯）？好！
• 你看到任何冒烟吗？糟糕！

就是这样！ “冒烟测试”是最小测试：不是严格的测试。

“冒烟测试”的价值在于它便宜，或具有成本效益：例如，对于完整测试的成本的1％，它可以捕获90％的最可能的错误。例如，在原始的烤面包机工厂中，您可能会这样做：

• 初步设计的成本测试
• 原型的成本测试
• 大规模生产线上第一个项目的成本测试
• 对大规模生产线上的每个后续项目进行廉价的烟雾测试

我不确定这些天在软件开发中有哪些“冒烟测试”，现在自动化测试变得越来越流行。在过去，人们主张“日常建设”作为QA措施（具体来说，帮助“持续整合”）......然后，提倡“每日构建和冒烟测试”作为一种方式比每日构建做得更好（即，每天构建和验证它是否完全运行）......但是现在，比这更好的是“每日构建和广泛的自动化测试套件”。

Answer 4

我在工作的地方进行这种类型的烟雾测试。

最重要的是，我们可以确保所有部分在将其转交给用户进行用户验收测试之前将所有部分组合在一起。我正在考虑的应用程序存在于三台服务器上，以及与遗留系统的对话。确保我们能够完成并且每件作品都可以与其他所需的部件进行对话，这是一项简单而重要的测试。

Answer 5

我会假设你的“冒烟测试”的含义与我的相同 - 即尝试以任何方式吹制程序。

我了解了20多年前我刚刚完成（或者我认为）WYSIWYG编辑器的主要代码时的价值。我自豪地向我的同事（嘿Dbell！）表明，“整洁！”。他立即创建了一个包含大约1000个字符的段落，复制了数千次，并创建了大约32MB的文档，删除了所有内容，解除了它，并且程序绝对爆炸。

我完全惊恐地说，“你做不到！”。他咧嘴笑着说：“为什么不呢？”

找到并修复问题（一旦你知道阈值事件是什么样的，结果很容易复制）在内存管理中发现了一个微妙而严重的错误。简单的点击按钮测试从未发现它。

与现代相当的是Fuzz测试（http://en.wikipedia.org/wiki/Fuzz_testing）。它不能替代逐步的需求测试，但它经常会暴露出其他方法无法解决的问题。

Answer 6

冒烟测试是因为将破碎的软件放在用户手中可能会非常昂贵：它可能浪费很多人的时间，可能需要管理，会议等等来修复。因此，值得为每次构建花费一点的时间，以确保它没有被破坏，如果出现问题，可以节省很多时间。

一般规则是：总是总是更早地找到问题 。

而且，除非你像用户那样尝试 ，否则你无法确定它将完全像它应该的那样工作。总有意想不到的问题只有人才可以捕获，例如视觉问题，安装问题......

因此，在将工作交给用户之前，应始终通过（小）手动测试来补充自动化测试。

Answer 7

烟雾测试绝对是值得的。

这是Steve McConnell撰写的一篇名为“Daily Build and Smoke Test”的优秀文章。这就是我的想法。

有关持续集成和每日构建的更多信息，请查看Martin Fowler对该主题的出色intro。

HTH

欢呼声，

罗布

Answer 8

在我看来，在最终发布之前的“冒烟测试”，无论是发布给用户还是QA团队，都是必不可少的。自动化测试只能在编写脚本时进行测试，并且总有可能会遗漏某些内容。

一个简单的界面缺陷可能会污染您的应用程序对QA或用户的感知，并导致他们怀疑或质疑基本的基本组件。如果没有一次性发布之前你就会因为一些小的界面错误而让你自己认为你的软件质量很差。

Answer 9

像任何最佳实践一样，你真的需要相信它才能完成它的回报。每次构建时，至少每天都要进行一次冒烟测试或构建验证测试，或者如果您没有每日构建，那么每天都要检查您的环境是否正常运行。

了解您的测试周期中每天的能力是多少。如果您每天都没有运行冒烟测试来测试基本连接或功能，那么您将无法报告您在测试时被阻止，并且开发团队将无法确定哪些是优先级最高的错误。固定。

与阻止缺陷和测试执行率相比，我建议您记录烟雾测试的时间线指标。这可能会阻止你看起来像瓶颈，如果有人认真对待你，可以挽救你的工作。