或者也许我们实施它.我是想要完成整个过程的团队的新手,这似乎让我们的团队中的一些成员感到困惑,包括我.我们得到了我认为的用户验收测试或手动操作列表,您可以点击它们以查看是否一切正常.我认为它会比这简单得多,因为我们只是将应用程序的各个部分分开,并且通常只是查看它会发现巨大的错误.这将不涉及脚本,只需单击每个页面,可能填写东西,确保它提交确定.这让我想到了另一点,在我看来,烟雾测试基本上毫无价值.我会认为相反,你' d有单元测试甚至是自动化测试,它们会通过一个需求列表来确保这类事情正确发生.即使至少没有完成,我认为首先检查代码的开发人员至少会进行一次微型烟雾测试,以确保他们的功能首先起作用.我们在会议中提到了这一点,你可以想象出这种困惑,它让我回到了我的问题,我们将从这种类型的烟雾测试中获得什么价值？
任何测试的价值都是为了增加您对实施的信心.进行这种"冒烟测试"是为了增加它确实正确构建的可信度,并且没有重大且令人尴尬的错误,例如用户界面不会出现.所以它基本上是一种省力的测试.确认没有真正重大的问题.
它可能听起来不是很有用,但我看到经过严格测试的代码无法通过"冒烟测试",例如,由于构建中的意外故障或损坏的图像.通常在向重要客户展示时.
如果您将冒烟测试定义为"运行系统的基本功能以确保它们正常工作",那么我认为这有价值.必要时,单元测试并非全包.他们没有发现任何集成错误.至于自动化测试,我还没有看到一个可以通过自动化进行全面测试的系统,即使可以,这样的自动化也需要时间和精力来完成.
基本上,我在其中看到的值是让我们确保我们今天对代码所做的更改不会破坏昨天正常工作的任何内容.根据您的编码实践的规划程度,这并不总是给定的.
要回答"什么是烟雾测试？"这个问题,想象一下您正在测试一件电气或电子设备.
将其插入并打开电源:
你看到它开启了吗(例如屏幕或电源指示灯)？好!
你看到它冒出来了吗？坏!
就这样!"烟雾测试"是一项最低限度的测试:不是严格的测试.
"冒烟测试"的价值在于它便宜或具有成本效益:例如,对于完整测试的成本的1%,它可以捕获90%的最可能的错误.例如,在原始的烤面包机工厂,您可能会这样做:
对初始设计进行成本测试
对原型进行昂贵的测试
对批量生产线上的第一个项目进行昂贵的测试
对大规模生产线上的每个后续项目进行廉价的烟雾测试
现在自动测试变得越来越流行,我不确定这些天在软件开发中有哪些"冒烟测试".在过去,人们主张"日常建设"作为质量保证措施(具体来说,帮助"持续整合")......然后,提倡"日常建设和烟雾测试 "作为一种比每天更好的方式构建(即,每天构建并验证它是否完全运行)......但是现在,更好的是"每日构建和广泛的自动化测试套件".
京公网安备 11010802040832号 | 京ICP备19059560号-6 