Monthly Archives: 十一月 2013

现实过程中，经常提到冒烟测试与BVT测试，许多人经常并且将其等同，在实际操作应用中，这样做并没有太大问题，而实际两者间是存在区别的。最近反反复复遇到人提问这个问题，在此就该问题发表一下自己的看法，供大家参考：

冒烟测试

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

　　冒烟测试一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。类似的如果冒烟测试没有通过，那么这个build也会返回给开发队伍进行修正，测试人员测试的版本必须首先通过冒烟测试的考验。

　　冒烟测试：

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

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

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

BVT测试

BVT(Build Verification Testing)，验证一个软件版本是否符合最基本的要求，是否存在重大问题。

在项目过程中，会产生很多个版本（每天都产生版本），测试组需要对每一个版本都进行一个最简单的验证，以确认u重大的问题，这就是BVT。

如：冒烟测试通过，该版本能够安装运行，但是其中主要功能在该版本中出现了问题，则视为BVT失败。这个时候因与冒烟测试相同的处理方式，尽快反馈给开发组，让其修改，避免因为代码量增多，不容易定位问题。

做BVT可以从如下几方面入手：

1、只验证最主要的功能；

2、提取的测试用例，优先级一定搞，数量一定少，执行时间要短；

BVT的测试用例的数量及筛选可以由整个项目组确定。

对比冒烟测试与BVT测试：

冒烟测试相当于，验证汽车的发动机是否能够发动，而BVT则是在发动机能够发动的基础上，验证是否能跑动、是否能够刹车、能否换挡等基本功能。

所以冒烟测试与BVT本质上还是有差别的，而现实许多项目组操作过程中也没必要区分这么细，可以把二者合二为一，都成为BVT或冒烟。

以上仅本人愚见，希望大家多多交流。

本文出自 “探索之家” 博客，请务必保留此出处http://starpoint.blog.51cto.com/968349/642122
Continue reading →