详细介绍一下 BVT

a21th

详细介绍一下 BVT

　　BVT 在成熟的软件研发过程中是很普及的一项测试，也是不可或缺的一项测试。然而在实际中，尤其是国内一些软件企业的实际工作中，却因为配置管理的缺乏而根本没有 BVT，甚至很多人至今还不清楚 BVT 究竟是做什么。
【误区】
　　如果没有接触过具体的实践，单单看一些名词的定义，有时候会产生一些错误的理解。

• 很多人误认为软件集成以后所做的一系列测试就是 BVT。这可以说对 BVT 是毫无概念了。
  
• 更多人认为 BVT 就是 Smoke Testing（冒烟测试）。这是基于对 Smoke Testing 概念的片面理解，这一点我在《详细介绍一下 Smoke Testing（冒烟测试）》一文中已经有所解释，本文中会有更详细的叙述。
  
• 不少人认为 BVT 只是基于每日构建（daily build）的。其实，对于每一个版本、微版本，都要执行 BVT。
  

【BVT 释义】
　　BVT 的全称是 Build Verification Test。可以说这个全称就是 BVT 的定义了。
　　BVT 只验证 build 构建的成功与失败，不深入测试构建好的 build 的功能、性能等等。
【BVT 的执行】
　　在每日构建的环境里，每个 daily build 构建完成时都要执行 BVT。对于 daily build 以外的每个版本和微版本，构建完成时也要执行 BVT。
　　BVT  可以手动执行。版本的构建是相对稳定的过程，因此 BVT 基本上是软件测试中最早实现全面自动化的测试。现在绝大多数版本构建工具都附带 BVT 功能。
　　BVT 最基础的任务是进行文件版本的比对。伴随开发进程，软件功能越来越固化，BVT 有时会在不影响最基本功能的基础上加入一些成熟的自动化测试脚本。
【BVT 对后续测试工作的影响】
　　BVT 是集成测试的一道门槛，只有通过了 BVT 的 build 才可以进入后面的集成测试过程。

• BVT 结果成功的 build —— 表明该 build 构建成功，交付集成测试，但不一定被测试。
  
• BVT 结果失败的 build —— 表明该 build 构建失败，不交付集成测试；提交 BVT Bug，并按照 Bug 流程解决此 Bug。
  
• 未经 BVT 的 build —— 不得提交集成测试。
  

【BVT 不同于 Smoke Testing】
　　BVT 所做的测试内容很浅，这一特征似乎符合 Smoke Testing 的定义；但是 BVT 只验证 build 的构建情况，这一点与 Smoke Testing 截然不同，因此二者是完全不同的测试。另外：

• BVT 只在 build 构建完成时进行；Smoke Testing 是各个阶段都有的测试。
  
• 尽管 BVT 可以加入自动测试脚本并执行少量固定的自动化测试，但 Smoke Testing 与 build 的验证无关。
  
• BVT 的结果直接决定新构建的 build 是否交付后续测试；Smoke Testing 不影响其他日常测试工作。
  

（2010.5.11）

zoeli1

你说的BVT是在怎样的开发模式中用的呢，是敏捷开发么？

a21th

BVT 是一项测试，不局限于某种开发模式，应该说只要有集成的软件产品就应该有 BVT。敏捷开发也应该有 BVT。

张志英

意思就是说，BVT就是集成测试？

a21th

毫无此意！

deter

下面的话也说得挺实在的~~放到这里大家学习一下，补充一下我是转帖，里面的内容也是我学习之一

BVT作为Build的一部分，主要是通过对基本功能、特别是关键功能的测试，保证新增代码没有导致功能失效，保证版本的持续稳定。


1、测试人员手工验证关键功能实现的正确性。
特点：这是传统开发方法中，通常采用的方式。无需维护测试脚本的成本，在测试人力资源充足，测试人员熟悉业务、并对系统操作熟练情况下效率很高，比较灵活快速。
缺点：人力成本较高；对测试人员能力有一定要求；测试人员面对重复的工作，容易产生疲倦懈怠，从而影响测试质量。

2、借助基于GUI的自动化功能测试工具来完成，将各基本功能操作录制成测试脚本，每次回放测试脚本验证功能实现的正确性。
特点：能够模拟用户操作完成自动的测试，从UI入口到业务实现，每一层的代码实现都经过验证；节约人力成本；降低测试人员重复劳动的工作量，机器不会疲倦；
缺点：对于UI变动比较频繁的系统来说，这种方式的维护成本很高，实施起来非常困难。另外，在项目周期较短且后续无延续性或继承的情况下，也不推荐使用此方式。

3、由开发人员通过自动化测试工具完成业务层的BVT测试。
特点：通过对业务层关键功能的持续集成测试，保证系统功能的持续稳定。可以结合Daily Build，做为Build的一部分，自动实现并输入BVT报告。
缺点：仅对业务规则实现的正确性进行了测试，对表现层无法测试到，对于诸如：前台页面控件各种事件响应、页面元素变化等方面的问题无法保证。



本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/ivalen/archive/2007/06/07/1641876.aspx

a21th

这个写得不错，但不完全赞同，最主要就是第二点。BVT 的目的很明确，就是验证 build 的构造，其它附带的测试内容都是在此基础之上附带的，因此它通常是跟版本工具捆绑在一起，而不会借助其他的自动化测试工具，尤其不该依赖于 UI 自动测试工具，也就不存在 UI 变动对 BVT 的影响。

[ 本帖最后由 a21th 于 2010-5-26 15:23 编辑 ]

a21th

daily build 和 BVT 是完全不同的工作——daily build 是版本构建工作，BVT 是测试工作。二者不存在类似性。

要说先后，二者有工序上的先后，但没有目的上的先后。一方面，每一个 daily build 都应该进行 BVT；另一方面，即使没有 daily build，也应该对每一个 build 做 BVT。

yzwangxf

我们一直在做BVT测试，效果很好。

在对比以前的一般测试时，缺陷密度减少很多。

canterer

目前，我们也在做类BVT方面的工作，但是目前遇到的问题是，BVT的自动化测试用例不是太稳定，导致一些误判，因此在想着采取一定的策略来实现相关的应对：
很赞同6楼的兄弟的表述，尤其对
由开发人员通过自动化测试工具完成业务层的BVT测试。
特点：通过对业务层关键功能的持续集成测试，保证系统功能的持续稳定。可以结合Daily Build，做为Build的一部分，自动实现并输入BVT报告。
缺点：仅对业务规则实现的正确性进行了测试，对表现层无法测试到，对于诸如：前台页面控件各种事件响应、页面元素变化等方面的问题无法保证。
特别感兴趣，希望能有所交流