科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道[龚亮]如何避免遗漏bug

[龚亮]如何避免遗漏bug

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

众所周知,bug是不可能被完全消灭的,当然也就意味着在发布前不能被全部找出来。

作者:龚亮 来源:CSDN 2007年10月8日

关键字: 龚亮 测试 遗漏bug

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

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

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

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

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

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

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

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

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

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



Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1772079

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章