如何避免遗漏bug

发表于:2007-9-06 14:53

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:龚亮    来源:龚亮的测试专栏

分享:
        bug遗漏,我想这个是很多公司很多人头痛的一个问题。众所周知,bug是不可能被完全消灭的,当然也就意味着在发布前不能被全部找出来。于是乎当项目发布后,或多或少都会出现bug遗漏的现象,即使发布初期没有发现,随着时间的流逝,一些隐藏的bug也会慢慢浮现出来。那么对于遗漏的bug,我们该怎么去做?

        古时云:亡羊补牢,为时未晚也。对于遗漏的bug,我们应该去透彻的分析它产生的原因,然后吸取教训,防止再次出现。这样遗漏bug的数量就会越来越少,趋于0。那么怎样的分析才是透彻的呢?我发表一下自己的观点。

        根据我的经验,总结下来有以下几点,首先从根源上说,需求的问题。需求是一切的根本,我们所做的一切都是在需求的基础上进行的,那么需求会不会有问题?当然有啦,否则要需求评审干嘛,每次需求评审,或多或少都能发现一些需求的问题,在还没有开始编码之前就把需求的bug找出来,这个是最理想的状态。显然这个不现实,但是能多发现一个不合理的地方,那就能减少很多风险。因此需求关要把好。当然要求测试人员在需求评审时就要找出需求的bug,这个是要求比较高的,需要对业务的熟悉以及对相似产品的认识。需求关把好了,那么就算踏出了成功的第一步。

        其次,要尽早与开发人员进行测试设计评审,统一对需求的认识(开发测试人员都可能存在对需求的认识不正确)。越早进行,越能够避免出现因为对需求的认识不同而导致出现的问题(最可怕的是因此产生的隐性bug),这样也能减少后期很多不必要的资源浪费。

        接下来,就是用例设计了,这方面体现了一个测试人员的真实地能力。考虑的面要广,包括:使用不同的测试方案,不同的测试数据的类型(要齐全),正常流与异常流等来覆盖所有的需求。

        然后就开始执行测试,要全面地执行测试用例,并且在测试过程中不断的添加遗漏的用例。在时间允许下,尽可能的执行。

        回归阶段,除了要回归前面发现的bug,还要重视回归那些bug相关的模块,这个教训是很多的,所以千万不能忽视。一个小小的小小的参数变动可能引起一个比较远的功能点的大bug,继而引发遗漏。所以这个是需要开发人员与测试人员去识别的。开发人员熟知代码,知道改动的地方会被哪些模块调用或者会引起哪些变化,因此开发人员需要通知测试人员测试关注点以及加强自测。在开发人员与测试人员无间隔的合作下,这种bug的遗漏会减少很多。

        发布前期,应该在保证所有的bug都fixed的前提下,把所有用例都回归一下,以免遗漏。

        最后终于发布了,发布好就可去FB了,^o^。不要在开心的情况下放松神经,所谓行百里,半九十,不能倒在最后的冲刺关头。细心细心再细心。只要一步步走下来,那么就可以把遗漏的bug数量减到最低。

        当然最好做自动化脚本,方便以后的回归。这就是我想说的,大家有意见可以跟着,共同进步。



《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • zhangshouju
    2008-7-18 08:47:55

    拉走了~~嘎嘎

  • sdxyyouyou
    2007-9-13 11:27:40

    有启示

  • zhangj8826
    2007-9-07 11:55:14

    不错,写的很好

  • morose81
    2007-9-07 11:24:35

    很好,但是我想说一下,自动化测试有的时候在回归测试中也不是很好用,因为有些时候产品需要有一些改动,这样就导致脚本不可用,还需要修改,有的时候真的很麻烦.

  • liujihui226
    2007-9-07 11:08:14

    学习中好东西

  • yanghuimin
    2007-9-06 16:28:53

    讲的很好,学习了,谢谢

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号