查看完整版本: 冒烟测试讨论贴

冒烟测试讨论贴

所谓冒烟测试 就是在软件版本release 出来以后 对它的一个基本功能的检查， 不知道理解是否有误。 请发表自己的看法。。。

release指准备正式发布的版本，冒烟测试的对象应该是刚编译完准备拿来测试的版本吧

冒烟测试一般和每日构建、持续集成在一起使用。

请将每个知识点讲清楚 我想了解 谢谢各位

想听听高手的看法，请指教

WIKIPEDIA关于 smoke testing 的定义
[url]http://en.wikipedia.org/wiki/Smoke_test#Smoke_Testing_in_Software_Engineering[/url]

Smoke Testing in Software Engineering

Software smoke tests are designed to confirm that changes in the code do function as expected and do not cause failure of the rest of an entire build.

In software engineering, a smoke test generally consists of a collection of tests that can be applied to a newly created or repaired computer program. Sometimes the test is performed by the automated system that builds the final software.

In this context, the term smoke testing describes the process of validating code changes before the changes are checked into the larger product’s official source code collection. Next after code reviews, smoke testing is the most cost effective method for identifying and fixing defects in software; some even believe that it is the most effective of all.

Smoke testing also refers to the propensity for software engineers assigned to software testing activities to spend large amounts of time outside buildings, grabbing a smoke.

我象可以理解为 它是为了保证 软件 从 ”跑不动，流程走不了“ －－》 ”软件能用了“ 的一类测试。

冒烟测试是对提交的测试版本的主要功能进行比较“随机”的测试，也就是可以不按测试用例执行测试，一旦发现的bug比较多，达到一定程度，则返回给开发人员，不开始软件测试 。如果冒烟测试中发现的bug较少，再开始真正的测试，即严格按照测试用例执行。

做冒烟测试，前期写case时确认case等级很重要，关键性功能和有可能堵塞后面测试的用例占在10%左右,用于做冒烟测试

这部分用例归为一类做冒烟测试

[quote]原帖由 [i]lemonscent[/i] 于 2006-7-6 13:56 发表
冒烟测试是对提交的测试版本的主要功能进行比较“随机”的测试，也就是可以不按测试用例执行测试，一旦发现的bug比较多，达到一定程度，则返回给开发人员，不开始软件测试 。如果冒烟测试中发现的bug较少，再开始 ... [/quote]
同意！！

在正式进行测试之前,先检验软件功能是否基本完成.如果软件问题太多或者有重大功能缺陷,则不正式进行测试.

冒烟测试=预测试

摘抄

冒烟测试从操作上是一个随机的测试，操作对象通常是核心业务模块。测试员任意操作，钥匙发现多数功能走不下去，（大概20%），那么这个冒烟测试就结束了。冒烟测试一般不用参照测试用例。
执行冒烟测试的目的是对姚测试的产品进行一个大概的度量。如果冒烟测试不能通过，通常不会启动测试计划。因为软件缺陷较多的情况下，启动测试计划会浪费更多的人力物力。通俗的说，对“垃圾”产品执行测试世纪是测试人员抢了程序设计人员的工作。这些缺陷应该在开发阶段消灭，只有这样才可以真正的节约成本。

冒烟测试最早是用在硬件测试上的，主要是测试新开发的产品是否可以用，后来延伸到到软件测试上来，冒烟测试的对象是刚build 的软件，执行着是版本编译人员。冒烟测试是黑盒测试。冒烟测试关注的是系统的核心模块的功能

[[i] 本帖最后由 aifengyun 于 2006-8-2 19:04 编辑 [/i]]

[quote]原帖由 [i]liuliu022004[/i] 于 2006-7-26 14:40 发表
冒烟测试从操作上是一个随机的测试，操作对象通常是核心业务模块。测试员任意操作，钥匙发现多数功能走不下去，（大概20%），那么这个冒烟测试就结束了。冒烟测试一般不用参照测试用例。
执行冒烟测试的目的是对 ... [/quote]


严重同意
冒烟测试的目的是检查提交的程序是不是可以进行测试了。也就是检测程序员提交的程序是可以测试（通过)，还是需要的不是测试，而是调试（不通过）。

有收获

学习先

学习先

学习先

ding

不错，各有各得的好处

学习了

Smoke test verifies the major functionalities at high level in order to determine if further testing is possible.

该说的大虾们都说了，我就不增加了，相互学习下吧，哈哈。

大虾们! 讨论了那么长,怎么不讨论怎么实践呢?难道你们不做实践吗?

大虾们是不是喜欢把实践放在口头交流

打字不过瘾~

顶

学习中

冒烟测试一般应该是在回归测试当中出现吧。
另外请高人指点一下冒烟测试的技巧，根据什么判断针对哪里进行测试，如何来选择测试点

应该相信哪个呢，先相信大多数人的吧！！！

不错，学习先

smoke testing

概念上面已经有人讲了，我来讲讲实际情况

一般来说冒烟测试就是实际中的build测试，不一定需要测试用例组成，但是整个一个测试计划来划定最初的覆盖是需要的。以后可以不断往里面添加，这个不能算回归测试，但是考虑到是增长性的，也可以认为有回归的性质。

这个测试一般QA负责写，builder负责执行，builder可以是QA,开发，或者是技术支持，各公司不同了，只有通过这个测试的版本才可以交到QA部门来系统测试。

更广义一些的话，交付QA后，如果执行下基本的package testing（一般也是有个计划，顺序执行各种操作，看看是不是都能完成）,那也可以算做冒烟测试。

我还是举实际例子：
这次用个购物网站好了，night build完成，开始冒烟测试，这个测试可以是很低级别的测试，比如
对于数据库直接的测试，简历数据库，批量增加，删除，查询，增加用户，销毁数据库；
对于服务的测试，服务启动，服务的各种功能；
对于ejb的测试，各个接口的测试；
安装脚本的测试，各个环境变量是否设置正确，系统路径是否设置正确；
。。。。。。。

这个smoke testing要经可能覆盖的广，确保这些底层功能完全无误。就好比管子里装满烟，烟不冒出来说明管子不漏，然后我们再说别的，就这个意思。

然后我后面提到的那个package testing,好比下面这个流程：
QA拿到通过build测试的版本，开始安装，然后按照测试计划执行一遍，比如打开localhost:8080/index.htm,点击注册，观察是否符合计划，然后点击。。。。。

这两个测试都比较适合自动化测试的，冒烟测试的量非常大，而且每个build都要经过的，一个晚上上万次（这个次指单个操作）的量也不算很大，常常会涉及到专门编程来测试。package testing，一般只做主要版本，不需要每个版本做了，可以手工，也可以用shell script,或者简单的脚本语言来做。

有收货

我也是刚从事软件测试。对于冒烟测试也是一知半解。大概的印象就是执行某个功能时软件会不会crash，功能是不是和spec上的一致。至于当bug多到什么程度才返回给开发，就不是很清楚了。比如一个软件只有10个功能，那么多少个功能有问题时冒烟测试不能通过呢？

回复帖子

冒烟测试还应包括对系统进行安装与卸载测试

学习一下

冒烟测试
冒烟测试（smoke testing）,据说是微软起的名字。在《微软项目求生法则》一书第14章“构建过程”关于冒烟测试，就是开发人员在个人版本的软件上执行目前的冒烟测试项目，确定新的程序代码不出故障。
冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板功基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。
在一般软件公司，软件在编写过程中，内部需要编译多个版本(Builds)，但是只有有限的几个版本需要执行正式测试（根据项目开发计划），这些需要执行的中间测试版本，在刚刚编译出来后，软件编译人员需要进行基本性能确认测试，例如是否可以正确安装/卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等Bug。如果通过了该测试，则可以根据正式测试文档进行正式测试。否则，就需要重新编译版本，再次执行版本可接收确认测试，直到成功。
新版本的基本功能确认检查的测试，有的公司成为版本健康检查(Build Sanity Check)。对于编译的本地化软件新版本，除了进行上面提到的各种测试检查，还要检查是否在新的本地化版本中正确包含了全部应该本地化的文件。可以通过采用文件和目录结构比较工具，首先比较源语言版本和本地化版本的文件和目录中的文件数目、文件名称和文件日期等，这个过程称为版本镜像检查(Build Image Check)。其次，分别安装源语言版本和本地化版本，比较安装后的文件和目录结构中的文件数目、文件名称和文件日期等，这个过程称为版本安装检查(Build Installing Check)。

除了学习
还是学习

谢谢了哈1

不错，大家都讲的不错，我就随便发几个字凑个热闹

哈哈！　　其实回头找找有些标准贴出来倒是不错，比如　　冒烟测试结束或者暂停的标准！