51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 6261|回复: 11
打印 上一主题 下一主题

[转贴] 测试过程中,开发频繁给版本咋办?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2009-6-23 23:53:46 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
很多次碰到了,测试过程中,发现了BUG,开发改了一些就立马给个新版本,
拿到新版本刚开始测,发现缺这漏那的,旧的问题改的不彻底不算,还会带来不可思议的新问题,很头疼的说
最高记录,我一天能拿到6-7个版本
大家有过类似经历么? 有啥解决方法么?
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2009-6-24 09:40:22 | 只看该作者
我们公司情况类似。但我们这边主要是因为需求变化太快,导致版本很多。现在主要采用的方式是通过统计数据来分析版本提交的合理性,最后与研发的考核挂钩,如果版本提交合理性太低,扣相应 的考核分,这样能在某种 程度上抑制住乱提版本的情况。
回复 支持 反对

使用道具 举报

该用户从未签到

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

方法人想的,只要能解决问题就好。
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2009-6-24 10:58:08 | 只看该作者
版本多,说明软件的缺陷多或者需求变更快,如果仅仅是缺陷多,可以预测试(测试软件的基本功能),预测试不通过的直接打回。如果你知道公司的需求变更很快,你可以先将测试的工作放一放。这样就不会整天完全重复测试了,搞得自己也厌烦。如果时间实在很紧,只能用楼上的方法二了。
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2009-6-24 12:02:46 | 只看该作者
恩,我也觉得控制BUG提交频率,会减少这种情况的发生,而且有助于减少测试与开发两个人在时间上的浪费。提高一定的效率。
回复 支持 反对

使用道具 举报

该用户从未签到

6#
 楼主| 发表于 2009-6-26 23:20:52 | 只看该作者
控制BUG的提交频率? 不是发现BUG就放到缺陷库上的么?难道要积累到一定程度再提么?

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

使用道具 举报

该用户从未签到

7#
发表于 2009-7-2 16:12:54 | 只看该作者
恩,确实,这种情况做好预测试很重要。
最担心的是漏资源文件之类的,结果一个流程也跑不完,反复打包好多次。
这时候有必要开会整风,很多时候这是由于个别开发人员工作太多不端正引起的。
回复 支持 反对

使用道具 举报

该用户从未签到

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

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

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

[ 本帖最后由 stilldeeppool 于 2009-7-10 17:18 编辑 ]
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2009-7-14 18:35:03 | 只看该作者
学习了···实践经验····
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2009-7-19 14:17:56 | 只看该作者

回复 9# 的帖子

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

使用道具 举报

该用户从未签到

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


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

使用道具 举报

该用户从未签到

12#
发表于 2009-8-25 13:20:48 | 只看该作者
方法确实不错,领教了
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-23 08:13 , Processed in 0.081338 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表