51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: 默默巫
打印 上一主题 下一主题

[你问我来答第8期]:软件缺陷管理交流(已结束)

[复制链接]

该用户从未签到

41#
发表于 2011-1-21 14:55:49 | 只看该作者
好面熟呀
回复 支持 反对

使用道具 举报

该用户从未签到

42#
发表于 2011-1-21 15:03:10 | 只看该作者
支持!文采不错哦!
回复 支持 反对

使用道具 举报

该用户从未签到

43#
发表于 2011-1-22 00:31:11 | 只看该作者
支持千里~   从我注册51testing 就看到千里    应该蛮牛的
回复 支持 反对

使用道具 举报

该用户从未签到

44#
发表于 2011-1-22 18:11:28 | 只看该作者
回复 37# 江潭素月

(1)测试流程存在的风险
没有版本管理,会导致其他工作会很乱,另外会增加测试人员工作量,测试人员的工作变成没计划,没管理。比如新发现的BUG,无法去分析,是不是修改带来的,还是这BUG是原来就有,只是没测试到。为什么会增加测试人员工作量呢,开发人员只要改代码,就会提交到SVN中,频繁的这么更改,测试轮次就会乱,且容易助长发人员,自己修改后不测试,就扔到测试人员手中,在我们公司这就private build ,测试人员不能没完没了的给开发人员帮private build测试,只有特殊情况下才用,在你们这,感觉就是在做private build的测试,不是系统测试。
(2)不写测试用例,想到哪测到哪,测试很难将功能点覆盖全面
      先做好测试需求分解,细化到每个功能点。可以一边测试一边补充测试用例,具做法是,每写一个BUG,就现写一个用例并与这BUG关联。另外最后是,写BUG时,BUG要和测试需求关联。
(3)测试、修改Bug、复测的时间混在一块,分不清是谁的效率低
根源还是没有版本管理,有了版本管理,从BUG的发现版本和修复版本,就可以看出来了,有了版本管理,开发人员也不可以改一个BUG就发一个新版本。发版本最多一周发一次;关于存在分歧的BUG,一定是要由开发经理来仲裁的。
   另外,还可以从测试管理工具中,统计分析提交BUG曲线,和未修复的BUG曲线中,分析效率,如果说发现的BUG越来越少,但未修复的BUG越来越多,说明是开发人员修复BUG太慢。
(4) 关于什么样的问题该提交bug
我的意见是,测试时你要有测试策略,针对系统的不同阶段,要有不同的测试重点。系统功能都还没稳定时,不要去做可用性测试,这时你提交那些,可用性问题,开发人员会有情绪的。在实现要求的功能后,再考虑,非功能性需求。比如还在集成测试时,你提校验的问题,开发人员会认为你尽提些无关重要的BUG 。

我的一些笨见,详聊加我QQ 31931880
回复 支持 反对

使用道具 举报

该用户从未签到

45#
发表于 2011-1-25 09:11:52 | 只看该作者
回复 44# liuygneusoft

首先,谢谢您的指点,仔细分析了我们工作中的问题。但问题是我们该如何改进呢?

(1)没有版本控制
之前给公司提过建议,让开发人员打包,将包部署到测试环境下测试不同版本的包。但是这样会增加开发人员的工作量,所以建议没有被采纳。我用什么来说服他们呢,因为做这个工作主要是对我们测试人员有帮助的,而我们测试人员地位很低,所以这样的建议很难被采纳
(2)关于写测试用例
首先我们公司没有需求分析这回事。都是在一个系统的基础上进行修改。客户首先拿到我们已经有的系统,然后指出哪里不合适,开发人员就改,改完再让客户看,再提哪里不合适。这样,需求变更很多次,开发人员做完一部分,想给客户更新了,然后就让我们测测,我们无法预知他们什么时候要测试,要测试什么样的功能
(3)关于bug的提交
您说开始测试时,对于像可用性、易用性这样的Bug暂时不要提交。难道发现问题先记到本子上吗?我们是不管发现什么bug都提,怕以后忘记,然后把这些不重要的bug优先级设置为低
回复 支持 反对

使用道具 举报

该用户从未签到

46#
发表于 2011-1-25 09:43:27 | 只看该作者
支持一下千里 !
回复 支持 反对

使用道具 举报

  • TA的每日心情
    开心
    2021-6-9 14:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    47#
    发表于 2011-1-25 13:36:24 | 只看该作者
    原来你就是千里啊,之前接到过宇信易诚的面试通知呢?后来接到offer了就没去!要知道应该去试试的,呵呵
    hvein 发表于 2011-1-19 15:48



        幸好你没来,这个公司加班很严重,非常辛苦。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2021-6-9 14:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    48#
    发表于 2011-1-25 13:51:03 | 只看该作者
    回复 45# 江潭素月


    (1)没有版本控制
    之前给公司提过建议,让开发人员打包,将包部署到测试环境下测试不同版本的包。但是这样会增加开发人员的工作量,所以建议没有被采纳。我用什么来说服他们呢,因为做这个工作主要是对我们测试人员有帮助的,而我们测试人员地位很低,所以这样的建议很难被采纳
    --如果你了解配置管理的话,你应该会知道这是项目管理的工作,也就是说这是项目经理的活儿。不过这部分工作量确实非常大,我上一家公司也曾碰到了版本控制的麻烦,项目经理也在考虑版本管理,最终因为没人可做这部分工作而一直搁置着
    (2)关于写测试用例
    首先我们公司没有需求分析这回事。都是在一个系统的基础上进行修改。客户首先拿到我们已经有的系统,然后指出哪里不合适,开发人员就改,改完再让客户看,再提哪里不合适。这样,需求变更很多次,开发人员做完一部分,想给客户更新了,然后就让我们测测,我们无法预知他们什么时候要测试,要测试什么样的功能
    --这部分工作首先要认可是测试员本份的工作,如果是不会做可以理解。这里提到的需求分析是将用户需求抽出成功能点,然后再将功能点具体实现为用例。当然你的问题也存在一定程度上面的需求环节不规范性,只要对客户意见和测试员bug进行了统一管理,情况会相对好一点。
    (3)关于bug的提交
    您说开始测试时,对于像可用性、易用性这样的Bug暂时不要提交。难道发现问题先记到本子上吗?我们是不管发现什么bug都提,怕以后忘记,然后把这些不重要的bug优先级设置为低
    --这里涉及到一个缺陷不修复的问题,哪些缺陷可以不修复呢?其实还是能够找到相关答案的:1.确实不是bug的;2.修复的代价太大;3.缺陷本身并不严重,但修复需要很长时间;4.缺陷被暴露的概率非常小,就算被暴露了影响也不是致命的。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    49#
    发表于 2011-1-25 15:01:27 | 只看该作者
    回复 48# 千里


        我们往往在这样的bug上存在争议:出现频率很高,只要运行程序就出现。但不是致命的bug,不影响功能,修改起来也很比较容易。不属于你说的那几种不修改Bug中的任何一种

    例如打开一个页面时,只是在左下角报脚本错误,功能照样用。像这样的Bug,开发人员心情好就改,心情不好就不改。

    我们测试人员对于这种bug是倾向于修改的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    50#
    发表于 2011-1-25 15:03:18 | 只看该作者
    回复 48# 千里


      关于写测试用例,你说“对客户意见和测试员bug进行了统一管理,情况会好一点”,没有听明白,在我们这种情况下,该如何做测试用例的工作
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    51#
    发表于 2011-1-25 16:00:17 | 只看该作者
    你这张照片貌似还是我们一起去陈家祠的时候照的。。。哈哈。。。占个位置好好听讲
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2021-6-9 14:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    52#
    发表于 2011-1-25 20:10:56 | 只看该作者
    你这张照片貌似还是我们一起去陈家祠的时候照的。。。哈哈。。。占个位置好好听讲
    medoraemon 发表于 2011-1-25 16:00



        这都被你看出来了,好神奇啊。测试的眼力真是不错,佩服之。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2021-6-9 14:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    53#
    发表于 2011-1-25 20:13:29 | 只看该作者
    回复 49# 江潭素月


        对于问题较严重,开发都很随意的,领导也不管的。我的做法是把问题以邮件的形式反馈给开发并邮件抄送一份给领导。同时把要不要修改的权力交给领导并暗示他,如果是谁说的不改以后出了问题谁来承担责任。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2021-6-9 14:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    54#
    发表于 2011-1-25 20:18:22 | 只看该作者
    回复  千里


      关于写测试用例,你说“对客户意见和测试员bug进行了统一管理,情况会好一点”,没有听 ...
    江潭素月 发表于 2011-1-25 15:03


    你跟我上一份工作的情况相同,最明显的区别是我有一个好的项目经理。我是说客户意见也是bug,和你在实际测试过程发现的bug是相同的,可以统一管理。
    我们公司也是开发更新程序,但我们建立了一个群。凡是开发有任何更新必须发群消息出来,测试员对更新情况做出记录。这样在一定程度上做到了版本控制,另外程序能不能提交给客户由测试员说了算(尽可能的)。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    55#
    发表于 2011-1-25 22:11:01 | 只看该作者
    本帖最后由 liuygneusoft 于 2011-1-25 22:27 编辑

    回复 45# 江潭素月

    千里的回答很好,很明确,我再补充一点
    (1)没有版本控制
    之前给公司提过建议,让开发人员打包,将包部署到测试环境下测试不同版本的包。但是这样会增加开发人员的工作量,所以建议没有被采纳。我用什么来说服他们呢,因为做这个工作主要是对我们测试人员有帮助的,而我们测试人员地位很低,所以这样的建议很难被采纳
      
      是如千里所说,这工是配置管理员的专职工作,当前公司没配备,那我们只能从己有人员中想办法,谁最合适呢,当然是研发经理,也不要求正经八百的做配置管理,只是控制一下,什么时候发布下一个版本到测试人员那,或是定在每周五(多长时间,可以视情况定)发布一个新版本测试,这样也促使开发人员尽量在下一版本前修改优先级高的BUG,这对开发经理的要求也不高,我原来就这么做过,我来发布版本,连测试服务环境都是我来配置,我们是分布式环境。那测试人员如何去说服呢,首先不要让人地位
    低,其次要和经研发经理讲清当前做法产生的严重后果,你可以发邮件建议,并抄送他的领导,我上面的改进办法也不复杂吧,只是控制一下发布时间,把时间点当成版本。
    当然我这是权宜之计,不过比没有强。
      
      心态上也不要自认为
    测试人员地位很低当然要证明测试人员存在的价值,就是用业绩和专业来反映;按我的理解,测试比开发人员更操心,开发人员,只管实现自己的业务,而不用向测试人员那样,通盘考虑。开发除了复杂系统外,MIS系统都是增删改查,很简单的。

    (2)关于写测试用例
    首先我们公司没有需求分析这回事。都是在一个系统的基础上进行修改。客户首先拿到我们已经有的系统,然后指出哪里不合适,开发人员就改,改完再让客户看,再提哪里不合适。这样,需求变更很多次,开发人员做完一部分,想给客户更新了,然后就让我们测测,我们无法预知他们什么时候要测试,要测试什么样的功能
    这时候不要再强调需求分析了,因为没有。我上一回贴说的测试需求分解,和开发的需求分析并不是一个东西,它只是定义了要测试的功能点有哪些。在没需求分析的情况下,你甚至可以,按功能菜单划化测试需求,并细化到增删改查功能点,这么做是为了好理清功能点,然后再这个测试需求分解的基本上来组纷测试,为什么我说要写用例呢,且是一边测试一边写,既然进入测试了,系统也有了,随着测试的深入,测试人员头脑中一定有业务,那为什么不一边测试一边补充呢,且有了那个测试需求分解,写用例时也能把握住,而不是随意的。这么做的好处是,可以慢慢积累用例,如中间有测试人员离职,也还有用例在.呵呵这是也是在做MYPM时加入BUG和用例关联功能的初衷。在测试期间,有空时(如,等待开发人员提交下一版本),也可以安排一定的时间写用例。

    (3)关于bug的提交
    您说开始测试时,对于像可用性、易用性这样的Bug暂时不要提交。难道发现问题先记到本子上吗?我们是不管发现什么bug都提,怕以后忘记,然后把这些不重要的bug优先级设置为低

      关于这个,我前面没讲清,不同的时间段内,测试肯定是要有侧重点的,可用性的BUG不是说不能提,如果不经意发现的当然要提,我是想表达,不要有意去执行可用性测试,在功能没实现前。要不开发的会误认为,你发现不了什么BUG,尽提些不重要的。目标是把有限的时间,用到当前紧要的事情上。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    56#
    发表于 2011-1-26 11:35:48 | 只看该作者
    谢谢千里和liuygneusoft ,帮我分析了问题还提供了解决方案。我已经将问题和改进办法进行了归纳,写了2010年测试总结。再次谢谢你们
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    57#
    发表于 2011-1-26 15:37:50 | 只看该作者
    我来捧场的,千里,进步很快,我的进步比较小了,以后要以你为榜样!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    58#
    发表于 2011-1-26 21:28:09 | 只看该作者
    老师,你好!
    请问如何保证测试达到要求的需求覆盖率? 谢谢。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2018-2-13 11:02
  • 签到天数: 55 天

    连续签到: 1 天

    [LV.5]测试团长

    59#
    发表于 2011-1-27 11:02:29 | 只看该作者
    终于见到了千里的真面目了。支持支持。。。


    我想问几个问题:
    1.在做提取测试功能点时,在只有需求分析文档时,我们怎样提取测试功能点,然后怎样进行根据功能点写测试用例?我正在做的这个cmmb项目时,写出的测试用例完全不能测开发出来的系统,有很大的偏差。不知道这个在前期怎么做比较好,才会减少这样的偏差,不造成测试用例不可用。
    2.关于职业发展方面的问题,我想以后向测试管理方面发展,如测试组长或测试主管经理什么的,但是现在我存在一个问题,我说话什么的缺少一种气势,我想改变这种现状,不知道如何改变。我如果向测试管理方面发展,需要做学习哪些东西,需要做好哪些工作,然后我个人的素质需要达到什么要求。
    请千里兄给点意见
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    60#
    发表于 2011-1-27 15:33:54 | 只看该作者
    问一个问题:
    如果你到一个公司做测试经理,你的下属中80%的人压根就不适合做软件测试,你会怎么处理?公司考虑所谓成本,你不能开除不合适的人。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-23 19:49 , Processed in 0.086006 second(s), 21 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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