51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 6222|回复: 18
打印 上一主题 下一主题

[原创] 怎样能在短时间内发现更多的Bug!新手上路

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2009-8-12 23:50:40 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
大家好,我是一个刚进公司一个星期的新员工!以前不是学的测试,进公司主要是做的是别人测过的功能复测!测的是媒资系统。老大说,我上了一个星期的班没发现过有价值的Bug  ,发现的都是一些小问题 。因为我的考核期很短,又是一个新手,所以急需求助,希望大家给我一些快速发现Bug的方法,以及系统中那些部分最可能发现Bug!谢谢大家了!
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2009-8-13 10:03:20 | 只看该作者
这个貌似很难。。
回复 支持 反对

使用道具 举报

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

    连续签到: 1 天

    [LV.1]测试小兵

    3#
    发表于 2009-8-13 10:23:01 | 只看该作者
    没有捷径可以走
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2009-8-13 10:23:05 | 只看该作者
    了解系统/软件肯定需要时间的
    急不来

    和你领导好好沟通一下
    自己再努力努力
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2015-6-25 18:04
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    5#
    发表于 2009-8-13 10:53:02 | 只看该作者
    有一个建议,不过想要发现更多bug,肯定要经过努力,这世界上不劳而获的事儿还是较少的。

    建议你多测试一下已发现bug的地方,多多检查bug修复时受到影响的功能或模块。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2009-8-13 14:46:37 | 只看该作者
    1.在不是十分熟悉详细的功能需求时,可以模拟用户做任何操作,甚至破坏性的操作也可以,这样有时能发现一些意想不到的bug。但这样做的弊端是会浪费别人的时间,比如你发现的问题根本不是bug,产品设计的需求就是那个样子的,这样无疑会增加开发人员给你解释需求或者复现的时间。
    2.熟悉需求的确需要一段时间的。只有把需求都弄清楚了,你才能更快的发现更多的bug。这需要自己多下功夫去熟悉你负责测试的那部分功能。虽不赞成占用自己的时间去做工作,但作为新人,工作初期还是要多努力的。
    3.跑一遍别人已写好的case,前提是如果写的比较好的话。受项目的特殊性和公司对case的重视程度影响,有些case是写的不规范或不完整。这样的case看了也费时费力,莫不如自己多分析需求。但是如果写的很好的话,跑一遍case,也会发现一些bug,就同一个bug而言,“改完再犯,犯完再改”的事情也是时有发生的。
    4.参看别人已报过的bug,既可以学习报bug的格式,也可以把握到你们这个产品bug通常聚集的地方。而且开发人员在改掉这个bug时,滋生出其他bug的情况也是时有发生的。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2009-8-13 15:04:12 | 只看该作者
    你们老大,怎么说他好呢,做别人测过的功能的复测,还能发现多少bug啊,要是真发现多了,原来测的人估计要走路了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2009-8-13 15:38:38 | 只看该作者
    好找的错误第一遍就找完了!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2009-8-13 16:17:49 | 只看该作者
    新的员工一下子上手,是有点让人为难的。
    一般一个新员工,做测试的时候,最开始是写测试用例,熟悉功能及流程。
    如果在短时间内,发现重大问题,那就要做破坏性测试。
    测试经验要靠不断积累。
    有了经验,在短时间内才能高效的发bug。
    经验,不是说自己发现的bug是经验,别人发现的bug也是经验。
    经验不断总结自己,也总结别人的。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2009-8-13 18:12:30 | 只看该作者
    每个星期结束时问他,这一周里你放过了多少个bug。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
     楼主| 发表于 2009-8-13 23:44:44 | 只看该作者
    谢谢上面的各位朋友给的意见,这些对我很有帮助。我明白了我应该增加更多的沟通和更努力的学习,我会尽我最大努力把这份工作做好的 !希望大家以后,有些什么学习的好的建议多多给我说一下!谢咯!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2009-8-14 09:54:22 | 只看该作者
    门没有就走窗嘛  拉你同事出去吃顿饭 让他给你留个大BUG
    呵呵 说笑的
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2017-9-20 12:50
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    13#
    发表于 2009-8-14 11:32:27 | 只看该作者
    不要按常规出牌,比如,打比方啊,你关机时不要按顺序去关了所有的开的程序,窗口,直接去拔电源,意思就是破坏性的,因为你是功能复测吗,别人肯定按正常步骤测完了,这时候很难找到bug,所以你只有不要按正常步骤走才会发现问题,把自己当做电脑小白,大胆去使用认识他
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2016-5-18 09:09
  • 签到天数: 19 天

    连续签到: 1 天

    [LV.4]测试营长

    14#
    发表于 2009-8-14 14:54:24 | 只看该作者
    破坏性测试是最容易发现Bug的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2009-8-19 16:24:45 | 只看该作者
    1.精通该被测软件
       ->如果连功能都不知道,有些缺陷即使测到了,也未必知道是缺陷
    2.多看缺陷库
       ->一般缺陷都是集中的,除非软件做的真的很烂,才会到处都有缺陷
    3.测试时间越长,单功能缺陷越容易被发现,所以你要测组合功能,组合测试时让它人为发生异常,看其处理情况,再回复正常,再异常,  一般这样bug比较多
    4.人为让单功能失效时,检查其功能是否正常
    .
    .
    .
    .
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2009-8-19 16:28:46 | 只看该作者
    你可以先深刻理解用户需求和软件的各个模块之间的关系和功能。不要急于测试,要有目标性。你是新手,强烈建议你在测试之前先构思写个你自己看的懂的测试用例。
    还有一个办法就是,看看其他软件一般出现问题多的地方在哪里,前提是:这个 公司的产品基本上是用一个框架做的。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2009-10-18 21:00:26 | 只看该作者
    都是值得学习的。看完有启发啊
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2009-10-19 11:26:07 | 只看该作者

    回复 7# 的帖子

    这话说得好~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2009-11-15 22:11:54 | 只看该作者
    严重同意15#的
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-25 12:40 , Processed in 0.080130 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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