BVT测试与冒烟测试

版权申明：文章转自51CTO博客，

链接：http://starpoint.blog.51cto.com/968349/642122 感谢作者
软件测试的管理中，通常将BVT测试与冒烟测试作用等同，二者的执行过程是常常在一起的，功能也很相近，但还是有区别的，博主找到一篇讲解BVT与冒烟非常好的文章，分享给大家。同时自己也提出一番自己的看法：

 冒烟测试

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

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

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

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

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

BVT测试

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

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

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

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

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

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

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

总结看法：

BVT测试，叫编译检查测试，

就是检查源代码是否能编译成一个新的、完整可用的版本。

BVT只验证build构建的成功与失败，不深入测试构建好的build的功能、性能等等。

BVT是在所有开发工程师都已经检入自己的代码，项目组编译生成当天的版本之后进行，主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确。如果BVT测试不通过，测试人员拿不到新的版本进行测试。

冒烟测试：一个编译版本出来，先检验基本功能是否通过，例如：启动、登录与退出，才有资格进行下一步测试。通常随着开发的深入而不断推进，关注新的功能点是否正常。
由此可看出，BVT和冒烟测试的目的是检查程序是否完整，基本功能点是否能满足，是否实现最基本的可测试性能要求。 BVT和冒烟测试是测试执行前的第一步骤。