BVT测试介绍：

　　BVT测试也称为"冒烟测试".版本验证测试 (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测试。 

每日构建 (Daily Build)
　　每日构建要求团队成员协同工作，并激励开发人员彼此坚持同步。假如新版本的迭代被延迟，则该延迟很轻易导致具有多个依附项的产品不同步。遵守每日构建和冒烟测试的进程，任何更改过的或新的二进制文件都可确保实现高质量。将高质量的每日构建作为团队最主要的义务。如果由于签进代码未进行冒烟测试而导致版本中止，则需要开发人员和测试人员结束所有其他工作，直到问题被解决为止。对导致中止版本的人员的处分不应当很重，但这个处分必定要能强调这样一个道理：准确的每日构建是团队最主要的义务。

每日构建和BVT测试的长处重要有:
1、进度可见并可以把持到1-2天的细粒度，很轻易看到进度的偏差
2、及早的发明开发BUG和缺点并剖析解决，对开发人员的一种监视和增进，进步软件质量
3、由于将大集成分解到每日构建中的小集成，避免了传统产品集成或集成测试时候呈现的严重问题的可能。
4、在项目中宣灌质量意识，强调第一次就把事情做好，而不是等测试来帮你发明问题

每日构建和BVT存在一些风险和缺点，具体重要有:
1、给开发者太大压力，开发天天都在较紧张环境中工作
2、需要额外的测试人力资源和每日构建硬件环境的投入
3、开发职员不能专注，既要分心往修正BUG，又要开发新的功效点
4、对开发负责人要求更好，需要将功能细化到1-2天的有明白输出的功能点
5、开发须要投进额外的精神来保证逐日构建顺畅

实用场景
1、对进度偏差把持和要求很高的项目
2、开发检讨点和里程碑制订的很过细的项目
3、采取增量和迭代开发的项目,快速和迅速开发的项目

每日构建提前需要进行的筹备工作
1、对开发进度打算的请求，需要细化出每1-2天的开发进度规划，可以到一个很小的功效点。
2、对逐日构建测试规划的请求，须要依据开发进度打算来部署冒烟测试和体系测试进度方案。
3、需要提前筹备好每日构建的环境(每日构建必需是独立的环境)