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测试。