查看完整版本: 如何进行冒烟测试呢?

如何进行冒烟测试呢?

如何进行冒烟测试呢?
  一般是怎么做的呢?

我想做每日构建和冒烟测试, 但现在却不知道该如何进行冒烟测试,请大侠们帮忙,指点一二.

-------这个我也没有涉及过,贴一篇文章,以前保存的,呵呵,希望有点帮助
       你实施后记得来分享一下你的具体做法  :)

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

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

冒烟测试的说法据说是：

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


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


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

本人陋见，“没病的走两步”

基本是这样的

就是BT，基本功能测试

冒烟测试运用在日构建中，这个过程是测试人员手工进行的，还是用工具进行的？
一般在构建完成之后，会依据单元测试代码进行单元测试，这个过程是构建是否成功的一个确认过程，他和冒烟测试是不是没有任何关联，这个地方我有点搞晕了，请大侠指点一下

冒烟测试，它和回归测试的性质一样——只是一个测试活动，并不是一个测试阶段。也就是说，冒烟测试贯穿于测试的任何一个阶段，单元测试里会有冒烟测试、集成测试里会有冒烟测试、系统测试里也会有冒烟测试。
冒烟测试和其他所有的测试活动的目的不一样，它不是为了证明程序存在BUG，而是为了证明程序的基本功能、核心功能没有问题。

当冒烟测试发生在集成测试的子系统间集成和系统测试的时候，这个时候，人们常常把冒烟测试等同为BVT（Build Verification Testing），也就是所谓的小版本验证测试。

冒烟测试一般是由程序员来执行；冒烟测试带有一定的随机性，它不需要去设计正式的测试用例，这个活动在开发部门内开展；

了解些了