baizhudan 发表于 2007-6-13 22:04:49

想问老师关于版本的控制问题

如果开发那边天天或者比较高频率的推出一个又一个版本,在无法完成前一个版本的测试的情况下,下一个版本又来了,导致测也不是不测也不是,测,是继续测原来那个版本还是测新版本,测新版本的话,难不成再从头开始测?原来的版本的BUG怎么办?不从头开始测的话,由于版本的更新你不能保证更新的部分不会影响到以前测试过的那部分东西,将来开发在修复以前所报的BUG的时候有可能会出问题,如对于报BUG的那个版本的确修复了,但由于后来新版本的因素很可能整合在一起后仍然是有BUG产生,然后再发布了所谓修复了那个BUG的版本后测试有可能会发现仍然有问题,然后再REOPEN,开发再FIX,这样开发和测试都会做一些无用功,随着版本的增多这种问题或许不会少。(对于开发来说我猜想或许他们在加入某些功能后希望尽快得到结果,所以会立即推出新版本)

请问老师如何解决这种情况呢?

[ 本帖最后由 baizhudan 于 2007-6-13 22:14 编辑 ]

v_v 发表于 2007-6-13 23:09:36

我也很困惑的问题,呵呵...楼主说出心声了....

云层 发表于 2007-6-14 11:08:08

这个问题提的很好,具体工作中经常遇到这个问题,而解决的方法其实说过,只是你没意识到

回头想想测试的目的是什么?再回想回归测试的2种方式?

遇到这个问题,首先考虑的是风险,制定测试计划去评估当前版本的情况,来决定是否终止当前测试进入下一个版本。
注意:不是说开发每出一个版本都必须要测试的!!

独立的测试部门应该有自己独立的测试计划和过程,这样才能更好的保证测试的质量,而不光是数量!

那么怎么具体处理呢?
新版本和现在版本的区别?了解版本的轻重等级,如果下个版本修改不多,而且不是很重要。而现在的版本测到1半,发现问题还很多,那么应该优先测试当前版本,确保一次完整的回归。反过来,如果测的差不多,发现问题很少,可以考虑终止现在的测试进入下一个版本
其实这就是一个你选择完全回归还是部分回归测试的过程

具体情况具体分析,太多的完整回归浪费资源,太少的完整回归无法及早发现问题。

云层 发表于 2007-6-14 11:09:09

然后如果有足够的测试人员,分1个出来专门做冒烟测试也不错啊.

天网 发表于 2007-6-14 16:14:14

版本级别是不一样的,以常见的一种版本标识方式: V10 R01 B00 D0614版本为例,V后面标识的主版本号,R后面标识的是次版本号,B后面标识的是测试版本, D后面标识补丁版本。V、R、B版本号应该有严格的版本规划的,这是我们测试计划中需要考虑的测试对象,而D版本号是在测试过程中或者维护过程中出现一些缺陷修复后的临时版本,不是计划之内的。正常情况下,是不应该天天或者频频出版本的,除非B版本发布后测试时天天或者频频出现错误导致测试被堵塞,必须修复该类缺陷后在同一B版本下重新发布补丁版本,而这种情况可以通过版本发布前加入预测试环节来解决或者减少频繁发布版本的情况。

baizhudan 发表于 2007-6-15 15:18:58

谢谢!
页: [1]
查看完整版本: 想问老师关于版本的控制问题