51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: fanli2000_0
打印 上一主题 下一主题

冒烟测试讨论贴

[复制链接]

该用户从未签到

21#
发表于 2007-1-10 13:30:42 | 只看该作者
ding
回复 支持 反对

使用道具 举报

该用户从未签到

22#
发表于 2007-1-23 14:23:57 | 只看该作者
不错,各有各得的好处
回复 支持 反对

使用道具 举报

该用户从未签到

23#
发表于 2007-1-29 18:06:48 | 只看该作者
学习了
回复 支持 反对

使用道具 举报

该用户从未签到

24#
发表于 2007-3-6 18:02:07 | 只看该作者
Smoke test verifies the major functionalities at high level in order to determine if further testing is possible.
回复 支持 反对

使用道具 举报

该用户从未签到

25#
发表于 2007-3-23 16:34:53 | 只看该作者
该说的大虾们都说了,我就不增加了,相互学习下吧,哈哈。
回复 支持 反对

使用道具 举报

该用户从未签到

26#
发表于 2007-4-2 11:44:08 | 只看该作者
大虾们! 讨论了那么长,怎么不讨论怎么实践呢?难道你们不做实践吗?
回复 支持 反对

使用道具 举报

该用户从未签到

27#
发表于 2007-4-2 15:42:45 | 只看该作者
大虾们是不是喜欢把实践放在口头交流

打字不过瘾~
回复 支持 反对

使用道具 举报

该用户从未签到

28#
发表于 2007-4-2 23:34:30 | 只看该作者

学习中
回复 支持 反对

使用道具 举报

该用户从未签到

29#
发表于 2007-4-6 15:22:38 | 只看该作者
冒烟测试一般应该是在回归测试当中出现吧。
另外请高人指点一下冒烟测试的技巧,根据什么判断针对哪里进行测试,如何来选择测试点
回复 支持 反对

使用道具 举报

该用户从未签到

30#
发表于 2007-4-23 14:36:49 | 只看该作者
应该相信哪个呢,先相信大多数人的吧!!!
回复 支持 反对

使用道具 举报

该用户从未签到

31#
发表于 2007-4-25 17:45:11 | 只看该作者
不错,学习先
回复 支持 反对

使用道具 举报

该用户从未签到

32#
发表于 2007-5-23 20:31:21 | 只看该作者

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,或者简单的脚本语言来做。
回复 支持 反对

使用道具 举报

该用户从未签到

33#
发表于 2007-10-12 20:59:34 | 只看该作者
有收货
回复 支持 反对

使用道具 举报

该用户从未签到

34#
发表于 2007-11-14 16:28:45 | 只看该作者
我也是刚从事软件测试。对于冒烟测试也是一知半解。大概的印象就是执行某个功能时软件会不会crash,功能是不是和spec上的一致。至于当bug多到什么程度才返回给开发,就不是很清楚了。比如一个软件只有10个功能,那么多少个功能有问题时冒烟测试不能通过呢?
回复 支持 反对

使用道具 举报

该用户从未签到

35#
发表于 2007-11-27 23:33:31 | 只看该作者

回复帖子

冒烟测试还应包括对系统进行安装与卸载测试
回复 支持 反对

使用道具 举报

该用户从未签到

36#
发表于 2007-11-28 10:08:04 | 只看该作者
学习一下
回复 支持 反对

使用道具 举报

该用户从未签到

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

使用道具 举报

该用户从未签到

38#
发表于 2007-12-28 09:14:11 | 只看该作者
除了学习
还是学习
回复 支持 反对

使用道具 举报

该用户从未签到

39#
发表于 2007-12-28 09:14:22 | 只看该作者
谢谢了哈1
回复 支持 反对

使用道具 举报

该用户从未签到

40#
发表于 2007-12-28 16:23:04 | 只看该作者

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

哈哈!  其实回头找找有些标准贴出来倒是不错,比如  冒烟测试结束或者暂停的标准!
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-22 06:26 , Processed in 0.075041 second(s), 21 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表