关闭

如何避免遗漏bug

标签: 测试testing脚本产品
466人阅读 评论(0) 收藏 举报

转载自:51Testing,原作者:龚亮
转载地址:http://www.51testing.com/?action_viewnews_itemid_20096.html

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

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

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

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

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

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

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

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

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

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

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:86716次
    • 积分:1404
    • 等级:
    • 排名:千里之外
    • 原创:48篇
    • 转载:29篇
    • 译文:0篇
    • 评论:37条