版本验证测试 (BVT) 也称为"冒烟测试"，通常由一组广泛的测试组成，这些测试用于验证特定版本的总体质量。 BVT 通常根据设定的计划自动运行，经常在夜间进行。也可以手动运行，例如自动运行失败后。如果 BVT 中的所有测试均已通过，则认为该版本成功。就是拿到一个软件，首先不急于完全测试，而是在很短的时候内把软件的基本功能走一遍，看有没有什么大的问题，如果存在大的问题，就没有必要再进一步测试了。可以节约时间，提高测试效率。

冒烟测试，也有称作烟雾测试（smoke Test):一种用于验证系统基本功能的实现并达到一定程度的稳定性的测试。这种测试经常用作进入下一个等级的测试的入口准则的一部分。关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说冒烟测试就是在每日build建立后对系统的基本功能进行简单的测试，这种测试强调功能的覆盖率，而不对功能的正确性进行验证。从这一点看和所谓的“接受性（验收）测试（Acceptance Test）”非常相似。不同之处就在于他们执行的频率和被测的版本不同。 至于冒烟测试这个名称的来历，大概是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟在进行其它测试，否则就必须重新来过。类似的如果冒烟测试没有通过，那么这个build也会返回给开发队伍进行修正，测试人员测试的版本必须首先通过冒烟测试的考验。冒烟测试应该是对整个系统流程从输入到输出的完整测试。测试不必是面面俱到的，但是应该能够发现系统中较大的问题。冒烟测试应该是足够充分的，通过了冒烟测试的build就可以认为是经过充分测试、足够稳定的。不进行冒烟测试的build是没有太大价值的。冒烟测试就像一个哨兵，在阻止着产品质量恶化和集成问题的产生，不进行冒烟测试，每日构造可能会变成浪费时间的练习。冒烟测试必须随着系统的扩充而扩充。最初，冒烟测试可能是非常简单的，比如验证系统是否会打印“Hello World”，随着系统功能的扩充，冒烟测试需要越来越充分。最初的冒烟测试也许只需要几秒钟来执行，逐渐地，测试可能会花费30分钟，1小时，甚至更长。

BVT测试内容：

单元测试，使用白盒测试，设计用例是针对详细设计文档产生的。

集成测试，设计用例是针对概要设计说明书产生的。

系统测试，设计用例是针对软件需求规格说明书产生的。

验收测试，测试用例正常情况下应该由客户给出，由客户进行验证，以便下结论是否可交付。

BVT测试的特点：主要是针对主体功能及各入口点，时间短，测试用例也只有正面的，负责人一般式项目经理或者技术经理。

何时应该进行BVT测试：从上面的BVT测试介绍中可以看出来，bvt测试当然是测试的次数越多越好，但是针对现实情况，测试部要求在送测之前，程序在vss上打了基线，然后项目经理或者技术经理从vss上拿下最新的版本，然后做bvt测试，如果测试通过，则才可以填写送测单，并将bvt测试情况写在其中，如果vbt测试没通过，则需要修改bug，然后重新打基线，从新做bvt测试。bvt通过的要求并不是说所有的bug全部都改掉，而是没有重大的bug，允许有小bug的存在。

bvt测试，以及测试用例的编写，都是需要时间成本的，故在最初制作项目计划时，就应该识别该任务，并充分考虑其工作量。

bvt测试用例，应该随着系统的不断扩展而不断扩展，它不应该是一成不变的。

bvt测试应该包含的内容：

1、业务流的测试，保证正常业务链路的通畅。

2、工作流的测试，主要是测试流程流转是否正常，至于流程步骤的表单内容是否正确则不关注。

3、关键功能的测试，至少要保证系统运转所需的启动数据，以及一些开关控制正常。

4、重要基本功能的测试，比如对核心业务有影响的一些增删改等。

bvt测试的过程：

1、各单元测试通过

2、打版本

3、拿最新版本

4、根据部署文档部署，尽量与用户环境一致

5、执行bvt测试用例

6、bvt测试结束后，如果成功，则填写送测单，并在送测单种写明bvt测试结果；如果不成功，则修改bug，重新进行bvt测试。