IT干货网

如何避免遗漏bug

luoye 2022年03月04日 编程设计 231 0

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

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

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

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

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

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

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

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

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

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

软件测试干了几年,项目一个接着一个,一路从一个坑跳入另一个坑,有些是开发问题,一些是测试本人问题,大家在测试过程中踩过哪些坑尼?

1.自以为了解业务逻辑,实际浮于表面

这是个深坑,产品迭代跟的久了,功能上闭着眼睛都能说清楚就自以为很了解,实际上连该功能使用的协议,调用的接口都不知道,所以看到问题都是表面的问题。

你只看到了两个操作的入口不一样,提示信息不一样,你就以为是两个问题,而这两个问题都是调同一个接口引起的,但你分析不出来。。

这样导致的问题有:

①修改bug后对影响范围评估不够

②提相同的bug,碰上特别注重bug数量的开发,真是揪心。。

我们公司对于bug定期要做bug根因分析,这在一定程度上也是帮助测试更深入的了解产品,因为每次bug单上开发写的产生原因和解决方案,真是言简意赅。。

2.思维定死,不会向前多走一步

比如同一个账号添加之后删除再添加,同一份文档导入之后导出再导入,密码修改成功之后再修改,等等,向前多走一步,就可能有意外收获。
3.忽略偶现的问题
测试要记住:所有偶现的问题,都只是没有找到必现的规律!
不要以为偶现的问题,没有出现,就不提出来,等上线后用户发现这个问题,你再说曾经遇到过,只是没有提出来,那测试不背锅还有谁背??

提出问题但不解决,测试就可以甩锅给产品,给开发,完美!(这个真是从踩过的坑里得出血淋淋的教训)
这里有个好的习惯:遇到问题先截图!!!先录视频!!!再分析原因,再提交给开发,最怕偶现的问题口说无凭,又没有证据证明,开发说你逗我呢???
4.避免随机测试
避免没有用例而进行的随机测试,虽然随机测试能发现一些问题,但是它的特点是我们测试人员想到什么就测试什么,这样就会导致有些功能点重复测试,而有的业务流程却没有覆盖到,出现漏测,一旦上线后出现Bug,就不好说了。

5.Bug的复现步骤描述必须要详细
这个其实算不上坑,只是个人总结。之前提交过一个Bug,Bug描述非常简单,在后期给开发复现的时候,费了很大的劲儿,如果我们能在Bug描述中,准确描述Bug的复现步骤,就可以明显缩短开发分析问题、定位问题的时间。
6.不要 “动” 之前的业务逻辑,因为会 “牵一发而动全身”
要 “遵守” 之前的业务逻辑,现有的业务逻辑尽量不要和之前的冲突,为啥呢?
因为啊,一旦按照现在业务逻辑的话,就得把之前的改了,改之前的业务逻辑会非常的复杂,不仅开发需要改代码,而且我们测试要重新再测,所以,不要动之前的业务逻辑。


评论关闭
IT干货网

微信公众号号:IT虾米 (左侧二维码扫一扫)欢迎添加!

软件测试转型之路--革新全程软件测试