详细介绍一下 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）

a21th

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

a21th

毫无此意！

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。