测试过程中，开发频繁给版本咋办？

miracleyaya

很多次碰到了，测试过程中，发现了BUG，开发改了一些就立马给个新版本，
拿到新版本刚开始测，发现缺这漏那的，旧的问题改的不彻底不算，还会带来不可思议的新问题，很头疼的说
最高记录，我一天能拿到6-7个版本
大家有过类似经历么？ 有啥解决方法么？

我们的爱

我们公司情况类似。但我们这边主要是因为需求变化太快，导致版本很多。现在主要采用的方式是通过统计数据来分析版本提交的合理性，最后与研发的考核挂钩，如果版本提交合理性太低，扣相应 的考核分，这样能在某种 程度上抑制住乱提版本的情况。

davy_chen

方法一：拒收新版本
方法二：版本照收，但是测试进展照旧，不是所有版本都从头完全测试，而是当前测试到哪里了，在新版本中继续，除非时间很充分，才考虑在对应版本做全测试
方法三：发现问题不急于提交bug，而是当达到一定程度后再提交，如果开发没有随时看到问题随时改，也不会随时给版本，可以控制bug每天提交一次，或者两天提交一次

方法人想的，只要能解决问题就好。

蓝色水滴

版本多，说明软件的缺陷多或者需求变更快，如果仅仅是缺陷多，可以预测试（测试软件的基本功能），预测试不通过的直接打回。如果你知道公司的需求变更很快，你可以先将测试的工作放一放。这样就不会整天完全重复测试了，搞得自己也厌烦。如果时间实在很紧，只能用楼上的方法二了。

sunfly_3333

恩，我也觉得控制BUG提交频率，会减少这种情况的发生，而且有助于减少测试与开发两个人在时间上的浪费。提高一定的效率。

miracleyaya

控制BUG的提交频率？ 不是发现BUG就放到缺陷库上的么？难道要积累到一定程度再提么？

好像没有项目时间不紧的呵，我现在基本是要求开发给版本之间提供改了哪些问题，再回归问题，可是每次回归的时候简直就是惨不忍睹，改的不彻底就算了，还会带来新问题，更夸张的是N个版本不出现的问题突然又出来了。。。。
其实开发是按各自的模块开发的，所以，各模块的功能没什么问题，但是模块之间一交互，就开了花了。再加上老大们又会改需求。。。
痛苦啊，今天就测了3个版本  救命

gseraph

恩，确实，这种情况做好预测试很重要。
最担心的是漏资源文件之类的，结果一个流程也跑不完，反复打包好多次。
这时候有必要开会整风，很多时候这是由于个别开发人员工作太多不端正引起的。

stilldeeppool

第一.提交的版本要具有一定程度的可用性.即开发人员需通过自己的测试才可以提交至测试人员处.避免因出现一些低级错误导致的测试效率下降.如果你们单位还在随意的提交版本.你有必要告诉负责的开发经理.更正此不良习惯
第二.让开发人员提交更新说明.明确指出程序的更新点.以及相应涉及模块.测试人员根据更新说明.
    一是验证其修改点的正确性.二是根据涉及模块,作一些相关性的测试(切记不要因为改了一个单元模块,就去做整套集成测试).
第三.当发布的版本未达到程序员指出的更新点.这叫"版本未达标",在BUGLIST中修改其状态
      可以直接返回此版本失效.如果产生了新的缺陷.明确指出.因某某版本的发布.引出新的缺陷.在BUGLIST中新增

第四.控制每天接收版本的数量.

如果程序员版本更新过于频繁.代码质量低下.请找项目经理反映.

[ 本帖最后由 stilldeeppool 于 2009-7-10 17:18 编辑 ]

fengyajingling

学习了···实践经验····

guofei318

支持9楼的，我们的版本现在都是项目经理在督促开发必须自检后提交测试，由于跟相应开发人员平时关系还不错，开发人员不细心导致的bug渐渐少，还有，每次我都会问他发我的版本是修改什么了，针对性的立马测试，不通过立即告诉他，原来不习惯提他许多bug，几次开会后说测试工作不好，连bug都没有怎么提交，我问清了项目经理到底对提交bug的重视度多深，之后就提交，项目经理也会督促看，这样开发不好意思不负责任的乱提交我版本。其实有时候对于一些粗心的开发，需要在你知道的地方，提醒他，减少彼此的麻烦工作，更多时候需要先表扬他的工作，后直接告诉他，他还是会好心态的接受改bug。由于我帮了不少他的忙，他也要相应的照顾我的工作嘛！呵呵

SQA_Kico

原帖由 davy_chen 于 2009-6-24 09:54 发表
方法一：拒收新版本
方法二：版本照收，但是测试进展照旧，不是所有版本都从头完全测试，而是当前测试到哪里了，在新版本中继续，除非时间很充分，才考虑在对应版本做全测试
方法三：发现问题不急于提交bug，而是当 ...

这个方法实际中我经常用到
不过其实可以根据产品的基本功能列出一个Acceptance test Plan（不要很详细，包含所有的功能测试就行），新code来后先根据这份check list验证下基本的功能，那如果连这个基本的acceptance test都不过的话就应该拒收新版本！
我们公司的流程规定通过了Acceptance test后QA才会接受code进行更详细的测试。

lyl419

方法确实不错，领教了