冒烟测试

gzj_06

忘了到底什么是冒烟测试了，这个“冒烟”到底指的是什么呢？谢谢！

Kel'Thuzad

从硬件测试借鉴过来的．．．．
让硬件冒烟然后罢工说不给加工钱还让干那么多老子不干了的测试．冒烟就是让测试对象说老子不干了．．
想起来了吧＞？呵呵，不用继续说下去了吧

[ 本帖最后由 Kel'Thuzad 于 2007-4-22 22:46 编辑 ]

齐鲁亚

论坛里有蛮多帖子关于冒烟测试的呢
http://bbs.51testing.com/viewthread.php?tid=584
http://bbs.51testing.com/viewthread.php?tid=33234

songfun

新手上路精华区有专门的介绍。
建议我们的同学养成勤逛精华区的好习惯。sdlkfj2

gzj_06

谢谢宋老师的提醒，不瞒您说，我还真没养成这个习惯，也常常上网，可就是瞎浏览，时间很快就过去了，然后感觉什么正事也没干似的。sdlkfj1

晓诺

冒烟测试是从硬件方面引申过来的！例:对电脑一块主版进行测试..首先对被测主版进行通电.要是发现主版有冒烟现象话话那么就不用再进行下一轮的测试..可以先将主版返还直接Pass掉..
对于软件来说冒烟测试应该是在进行系统测试前进行的..首先看看在被测的平台下要是软件无法运行（或是没有响应）就无需进行之后的测试..可将软件提交给程序员进行修改..
以上都是学弟个人的理解！还请老师和学长多多指教！

wangxiu836

恩,是从硬件测试借鉴过来的.老师讲的例子是楼上说的,对主板测试,首先给它通电,如果冒烟的话当然通不过了,就不必再往下测试了.
对于软件,我的理解是在IT后在ST前进行,主要是看它的最基本的功能是否实现,如果有错误的话,当然也无需再往下继续了.
都是自己的想法,若有不对的地方,请大家指出.

keenling

其实就是粗略地测一下最重要、最基本的用例，如果这些都失败就说明程序根本没做完，如：根本不能运行，就有权打回去，让他重新做好。
    这个名次来源于硬件开发，就是在完成的电路板做正式测试前，先通一下电，如果冒烟了说明完全坏了，根本不用继续测。

sindybi

软件基本实现后，还要经常修改，有可能会改出问题来，影响其它功能，
因此每天都用一些基本的测试用例去跑一遍，以保证软件是基本正常、可运行的，

v_v

这名字看了就应该感觉到它的涵义了，只是个大概的测试....很实在

aileen2008

从硬件引申过来的一个测试方面的术语.而从软件方面来说,冒烟测试就是对系统的基本功能进行检查，很通俗的说，就是先保证系统能跑的起来，不至于让测试工作做到一半突然出现错误导致整个测试工作无法进行.目的就是先通过最基本的测试，如果最基本的测试都有问题，就直接打回开发部了，以减少测试部门时间的浪费。

candy_83

冒烟测试是对软件基本功能地测试，如果软件地基本功能都失效的话，后续测试根本无法展开了

gzj_06

请教诸位，根据你们所说，我感觉冒烟测试与系统测试预测试有点像了，那么这个冒烟测试与系统测试预测试有什么区别呢

yufan1997

呵呵，2楼的回答我比较喜欢。。。。

zhang_jun_

留一半清醒留一半醉

walkman2508

是不是每个软件都要进行冒烟测试呢？

red-hat

冒烟测试（smoke testing）,据说是微软起的名字。在《微软项目求生法则》一书第14章“构建过程”关于冒烟测试，就是开发人员在个人版本的软件上执行目前的冒烟测试项目，确定新的程序代码不出故障。

冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板功基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。

冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。

在一般软件公司，软件在编写过程中，内部需要编译多个版本(Builds)，但是只有有限的几个版本需要执行正式测试（根据项目开发计划），这些需要执行的中间测试版本，在刚刚编译出来后，软件编译人员需要进行基本性能确认测试，例如是否可以正确安装/卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等Bug。如果通过了该测试，则可以根据正式测试文档进行正式测试。否则，就需要重新编译版本，再次执行版本可接收确认测试，直到成功。

新版本的基本功能确认检查的测试，有的公司成为版本健康检查(Build Sanity Check)。对于编译的本地化软件新版本，除了进行上面提到的各种测试检查，还要检查是否在新的本地化版本中正确包含了全部应该本地化的文件。可以通过采用文件和目录结构比较工具，首先比较源语言版本和本地化版本的文件和目录中的文件数目、文件名称和文件日期等，这个过程称为版本镜像检查(Build Image Check)。其次，分别安装源语言版本和本地化版本，比较安装后的文件和目录结构中的文件数目、文件名称和文件日期等，这个过程称为版本安装检查(Build Installing Check)。

red-hat

　　关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说，冒烟测试就是在每日build建立后，对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。从这一点看和所谓的“接受性（验收）测试（Acceptance Test）”非常相似。不同之处就在于他们执行的频率和被测的版本不同。

　　至于冒烟测试这个名称的来历，大概是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟在进行其它测试，否则就必须重新来过。类似的如果冒烟测试没有通过，那么这个build也会返回给开发队伍进行修正，测试人员测试的版本必须首先通过冒烟测试的考验。

　　冒烟测试的说法据说是：

　　就象生产汽车一样，汽车生产出来以后，首先发动汽车，看汽车能否冒烟，如果能，证明汽车最起码可以开动了。说明完成了最基本的功能。

　　冒烟测试一般用于每日构建(Nightly build)，构建服务器首先从CVS服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执行最基本的功能，则认为通过了冒烟测试，这时，构建服务器会把程序打包成安装文件，然后上传到内部网站，第二天一早，测试人员来了以后，会收到构建服务器发来的邮件提示昨晚是否构建成功。若构建成功，则测试人员进行相关的功能测试。所有这些功能的完成，一般是靠编写脚本完成的，目前比较常用的脚本有TCL，Perl，Python及功能弱弱的批处理。用这些可以完成系统的每日构建。

　　简单的说，就是先保证系统能跑的起来，不至于让测试工作做到一半突然出现错误导致业务中断。目的就是先通过最基本的测试，如果最基本的测试都有问题，就直接打回开发部了，减少测试部门时间的浪费。