BVT (Build Verification Test)

landizlan 2010-05-18

转载自http://hi.baidu.com/rebeccage/blog/item/647eb03ab024bbe614cecbe1.html

     BVT是在所有开发工程师都已经检入自己的代码,项目组编译生成当天的版本之后进行,主要目的是验证最新生成的软件版本在功能上是否完整,主要的软件特性是否正确。如无大的问题,就可以进行相应的功能测试。BVT优点是时间短,验证了软件的基本功能。缺点是该种测试的覆盖率很低。因为运行时间短,不可能把所有的情况都测试到。

BVT测试介绍:   BVT测试也称为"冒烟测试".版本验证测试 (BVT) 通常由一组广泛的测试组成,这些测试用于验证特定版本的总体质量。BVT通常根据设定的计划自动运行,经常在夜间进行。也可以手动运行,例如自动运行失败后。如果 BVT中的所有测试均已通过,则认为该版本成功。就是拿到一个软件,首先不急于完全测试,而是在很短的时候内把软件的基本功能走一遍,看有没有什么大的问题,如果存在大的问题,就没有必要再进一步测试了。可以节约时间,提高测试效率。冒烟测试,也有称作烟雾测试(smokeTest):一种用于验证系统基本功能的实现并达到一定程度的稳定性的测试。这种测试经常用作进入下一个等级的测试的入口准则的一部分。关于冒烟测试,应该是微软首先提出来的一个概念,和微软一直提倡的每日build有很密切的联系。具体说冒烟测试就是在每日build建立后对系统的基本功能进行简单的测试,这种测试强调功能的覆盖率,而不对功能的正确性进行验证。从这一点看和所谓的“接受性(验收)测试(AcceptanceTest)”非常相似。不同之处就在于他们执行的频率和被测的版本不同。至于冒烟测试这个名称的来历,大概是从电路板测试得来的。因为当电路板做好以后,首先会加电测试,如果板子没有冒烟在进行其它测试,否则就必须重新来过。类似的如果冒烟测试没有通过,那么这个build也会返回给开发队伍进行修正,测试人员测试的版本必须首先通过冒烟测试的考验。冒烟测试应该是对整个系统流程从输入到输出的完整测试。测试不必是面面俱到的,但是应该能够发现系统中较大的问题。冒烟测试应该是足够充分的,通过了冒烟测试的build就可以认为是经过充分测试、足够稳定的。不进行冒烟测试的build是没有太大价值的。冒烟测试就像一个哨兵,在阻止着产品质量恶化和集成问题的产生,不进行冒烟测试,每日构造可能会变成浪费时间的练习。冒烟测试必须随着系统的扩充而扩充。最初,冒烟测试可能是非常简单的,比如验证系统是否会打印“HelloWorld”,随着系统功能的扩充,冒烟测试需要越来越充分。最初的冒烟测试也许只需要几秒钟来执行,逐渐地,测试可能会花费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测试。

相关推荐