bowen601 发表于 2008-12-4 15:52:58

我在测试中的困惑

我的测试
1:开发过来找我,A系统的B模块有些功能做了修改,你去测下,ok
等等,改成什么样子了,有相关的需求变更文档嘛?哦,文档没有,就是前天讨论的时候
说是需要改下,你过来我告诉你具体改成什么样子,于是乎,他就把他理解的需求给我
讲述了下,好了,你去测吧,回去一测,果然,和他描述的变更的需求差不多,只是
提了一些 校验和界面上的问题,功能上我没有发言权,因为他说需求是这样变更的,最后
也是这样实现的,至于用户提的怎样的变更要求,鬼知道

2: 老大发话,今天A系统的C模块,好,开测,不测不知道,一测下一跳,好多些功能都
不可用,有的甚至还影响后续的测试工作,好,和开发人员沟通,开发人员也算敬业,你

说一个问题,他给你改这个问题,改完一重新部署,重启服务,开测,一会又遇到同样的
影响后续测试的功能不可用,来来回回,反反复复的改了好多次,重启了好多次服务,算

是把第一轮测试完成了,而且在测试的过程中,开发人员的好多修改都是直接登到测试服

务器上做的修改,有的是改代码,有的是调页面,有的是数据库加字段,总之,一切是为

了测试能进行下去,至于svn或cvs代码库中改了没,不好说,但愿下次部署不会涛声依旧

,继续在服务器上改。
3:突然接到业务部门的需求,需要增加一个D功能,于是开发人员就去着手该功能的代码开发,
完了交付测试,结果由于新增了该功能,导致整个系统出现2,3十个bug,在测试出这么多bug
后还不能放心,于是整个系统反反复复测试了好几遍。   
    不知道各位测试同仁是否遇到同样的问题,是怎样解决的?

[ 本帖最后由 bowen601 于 2008-12-4 17:25 编辑 ]

creatysun 发表于 2008-12-4 16:44:38

首先我想说,这些问题肯定会出现,原因可能因为质量体系不完整造成的。

但我们可以从一条测试原则上突破,跟开发人员沟通,找测试经理协调,这个原则是:

测试需要有稳定的测试环境。

另外,在修改某些模块时,是需要评估模块的影响范围的,如果无法评估,只能对整个产品进行测试。

kiss0710 发表于 2008-12-5 08:55:09

原帖由 creatysun 于 2008-12-4 16:44 发表 http://bbs.51testing.com/images/common/back.gif
首先我想说,这些问题肯定会出现,原因可能因为质量体系不完整造成的。

但我们可以从一条测试原则上突破,跟开发人员沟通,找测试经理协调,这个原则是:

测试需要有稳定的测试环境。

另外,在修改某些模块 ...


我比较郁闷的一个是:开发发了新版本和改了某些特性后,通常不会告诉我们这个新版本跟以前那个旧版本有哪些不同,而且我们测试中途会经常有新版本发出来,我根本不知道这个新版本到底会影响哪些功能,导致一直神经紧张...

乐乐公主的弟弟 发表于 2008-12-5 10:33:49

谈一些自己的看法。
首先,对于需求方面的内容,无论是原始需求还是变更需求,开发人员和测试人员必须同时得到,而且测试人员要根据自己的理解对需求进行分析,这样才不会出现开发人员根据自己的理解编写了软件,测试人员也就只能对软件实现的功能进行测试了。
其次,开发必须有自己的开发服务器,测试也必须有自己的测试服务器,而且测试的服务器应该不止一套,因为日常的测试和最终发布版本的测试是要分开的,在日常测试中有时会对系统进行一些调整,而这些调整不一定在开发服务器上也进行了同样的调整,所以发布版本必须在一个“干净”的环境中进行测试。
第三,无论是修改功能还是增加需求,或多或少都会对其他的模块或功能产生影响,因此如果条件许可,在发布版本之前是必须对所有功能进行回归测试的,如果条件不允许,也必须对主要功能和重点功能进行回归测试。

jeladeer 发表于 2008-12-11 15:41:09

这些都是属于质量管理的问题,存在于项目的生命周期内,并不仅仅是测试部分可以解决的,多数国内公司都是这样的管理方式 呵呵 找你老大反映反映吧

qifni21 发表于 2008-12-11 17:32:37

楼主说的我也遇到了,呵呵,说下我的做法,不一定对啊,
1.这个问题对于现在的流行开发模式是肯定有的,项目肯定会在开发到一定阶段(还没有完成),拿给客户看,让客户根据现在做的业务提出自己不满的地方,然后回去开发继续修改,这个过程测试很难去参与。
这样就导致了经常出现某某模块做了修改需要测试的情况,当开发人员给你说的时候,你完全可以顺便回一句,''做了那些修改呀?",这时候不必要什么修改文档,自己要用心记下开发口述给你的修改内容,然后自己编个《某某项目模块版本修改记录文档》,
2.对于这个问题的Bug就应该划分到紧急或者非常严重的类别了.这个就是版本控制问题了,前提自己要做个《Bug管理记录文档》,你自己做好的《版本修改记录文档》更用的上了,完全可以很简单的写上一条什么时候谁修改了项目的哪个模块的什么内容,Bug编号多少,当开发人员动你的测试版本的服务器的时候,你要提前给人家打好招呼:你动我的测试环境一定要给我说下。
3.对于这个问题,感觉应该是你们的版本控制和Bug跟踪做的不太好了,把前2条做好了,这个困惑应该就不会太大了。

大家都是新人,我也才刚毕业工作了3个月,刚来公司困惑不止这些,没事多想想,做好自己的活动安排管理,说笼统了就是朝测试计划慢慢考虑,就会越来越顺手了,加油吧:)
页: [1]
查看完整版本: 我在测试中的困惑