详细介绍一下 BVT
查看( 2515 ) /
评论( 8 )
相关阅读:
- BVT 不等同于 Smoke Test (a21th, 2010-4-28)
TAG: BVT
- zoeli1发布于2010-05-11 18:30:03
-
你说的BVT是在怎样的开发模式中用的呢,是敏捷开发么?
- a21th 发布于2010-05-12 08:57:47
-
回复 2# 的帖子
BVT 是一项测试,不局限于某种开发模式,应该说只要有集成的软件产品就应该有 BVT。敏捷开发也应该有 BVT。
- 张志英 发布于2010-05-17 09:50:31
-
BVT就是集成测试
意思就是说,BVT就是集成测试?
- a21th 发布于2010-05-18 21:39:44
-
回复 4# 的帖子
毫无此意!
- deter 发布于2010-05-19 16:47:04
-
下面的话也说得挺实在的~~放到这里大家学习一下,补充一下我是转帖,里面的内容也是我学习之一
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 发布于2010-05-26 15:21:49
-
回复 6# 的帖子
这个写得不错,但不完全赞同,最主要就是第二点。BVT 的目的很明确,就是验证 build 的构造,其它附带的测试内容都是在此基础之上附带的,因此它通常是跟版本工具捆绑在一起,而不会借助其他的自动化测试工具,尤其不该依赖于 UI 自动测试工具,也就不存在 UI 变动对 BVT 的影响。
[ 本帖最后由 a21th 于 2010-5-26 15:23 编辑 ]
- a21th 发布于2010-05-31 11:27:13
-
回复 8# 的帖子
daily build 和 BVT 是完全不同的工作——daily build 是版本构建工作,BVT 是测试工作。二者不存在类似性。
要说先后,二者有工序上的先后,但没有目的上的先后。一方面,每一个 daily build 都应该进行 BVT;另一方面,即使没有 daily build,也应该对每一个 build 做 BVT。
- yzwangxf 发布于2010-10-26 16:11:27
-
我们一直在做BVT测试,效果很好。
在对比以前的一般测试时,缺陷密度减少很多。