更多课程 选择中心

软件测试培训
达内IT学院

400-111-8989

做软件测试这么久,Bug你怎么看?


软件测试做久了,你会不会特别讨厌Bug?软件测试做了这么久,你怎么看Bug?从各种各样的Bug中你收获到了什么?

一提起测试,大多数人很容易就会联想到Bug。的确,测试的日常工作离不开Bug,测试工作很重要的一部分就是发现Bug。但是,发现Bug、解决Bug,就足够了吗?肯定不是的。

Bug是我们测试人员宝贵的财富,通过Bug我们可以获得经验,这种经验又能用在以后的测试中,帮助我们更早、更快地找到同类的Bug。

Bug最大的价值不在于找到并解决它,而在于通过对Bug的分析,使我们增加一些经验、掌握一些规律,以便更好地进行测试。

在对Bug进行分析时,一般很容易能想到的问题有:

这个Bug是什么?

为什么会出现这个Bug?

实际上,如果做Bug分析,只做到这个层次,还远远不够,上面只对Bug产生的原因进行分析,除此之外,还要更加注意:

Bug的发现阶段

Bug的产生阶段

在这方面,T-RCA缺陷根因分析法(T-RCA,Test Root Cause Analysis)很适用,主要目的是基于缺陷的过程改进(开发的改进、测试的改进、组织的改进),通过问10个问题来对Bug进行根因分析,看似很简单,实则重在引导和交流。

我在T-RCA的基础上,结合自己的理解,认为分析Bug要分为四个步骤:

第一步,认识Bug

Bug是什么?(有什么影响?)

为什么会出现Bug?(什么场景下会出现?)

第二步,Bug的发现

在哪个阶段发现的?

应该在哪个阶段发现?

为什么在这个阶段没有发现?

如何才能在这个阶段发现?

第三步,Bug的产生

在哪个阶段产生的?

为什么会在这个阶段产生?

如何避免Bug的产生?

第四步,Bug的改进

如何改进,做到Bug预防?

下面来详细说说。

1、认识Bug

在这一步骤中,要清晰全面地认识Bug,包括

通过问“这个Bug是什么”,来清楚描述这个Bug,包括向开发人员提Bug时也要用到这个描述

通过问“Bug有什么影响”,来判断这个Bug需要修复的优先级和影响的严重程度,对于优先级高的Bug要尽快上线,对于严重程度高的Bug可通过T-RCA方法进行根因分析

通过问“为什么出现这个Bug”来快速找到原因,一般我们通过询问开发人员或自己定位得到这个原因,并且这个原因大多是代码层面的原因,要知道根因分析,不能止于代码层面

通过问“什么场景下会出现”来复现Bug,并且最重要的是,可以反思自己在测试时是否遗漏了测试场景,测试覆盖是否不够

这一步可以说是测试人员的基础能力,遇到Bug后我们自然而然就能想到的问题。对于大多数的Easy Bug,做到这一步也足够了,毕竟我们的测试总是要在有限的时间和资源下做平衡,分析Bug也不例外。

Easy Bug,是指不需要精心的测试设计、不需要复杂的测试场景,就可以验证出来,随便找一个人来点点点,就可以发现的Bug。注意,验证和测试是完全不同的两个概念。但很可惜,大多数业务测试都是在做验证,而不是在做测试。

2、Bug的发现

在这一步骤中,要着重对Bug的发现进行分析,根据尽早测试原则,Bug发现越早,修复的成本也就越低,所以分析Bug的发现过程,也十分有价值。

“Bug是在哪个阶段发现的”,软件研发的阶段,不论是瀑布式开发、迭代式开发,还是敏捷开发,细分下来大体可以是需求定义阶段、需求分析阶段、开发设计/测试设计阶段、开发编码阶段、联调阶段、 测试阶段、改Bug回归阶段、预生产环境测试阶段、部署上线阶段、线上释放阶段等等,越晚发现的Bug,更应该去反思为什么没有更早地发现它

“Bug应该在哪个阶段发现”,较晚阶段的Bug应该尽早发现,早期阶段的Bug也不应该遗留到较晚阶段才发现,大多数人会认为Bug就是应该测试阶段发现的,但是如果可以做到今早发现,比如在需求分析阶段就从测试的角度提出一些风险,那规避风险的成本就会小得多

“为什么在这个阶段没有发现”,对于线上Bug很容易理解,为什么这些Bug会被遗漏到线上,而不是在测试阶段就发现呢?通过问这个问题,我们能很好地反思我们的测试,究竟是在测试设计的时候没有考虑到这种场景,还是测试的时候巧合地漏掉了Bug,还是修改Bug时影响到了其他的业务逻辑而没有回归

“如何才能在这个阶段发现?”,针对上面的问题,继续刨根问底,我们的测试永远有可以优化的地方

3、Bug的产生

这一步骤中是对Bug的产生进行分析,之所以把产生放到了发现的后面,是因为我认为Bug的发现相比于Bug的产生来说更重要。作为测试人员,你对发现Bug的控制,要更强于产生Bug,也就是说,预防Bug是很难做到的,而尽早发现Bug,却是我们都应该做到的。

“在哪个阶段产生的”,有人会认为,Bug都是开发写出来的呀,自然就是开发阶段产生的,这就陷入了一个误区,我们做根因分析,就不能这么粗放地想当然,开发也不是拿到一个需求后上来就写代码的,也是需要分析、设计、code、review等几个阶段的,不同的开发人员之间还要经历联调阶段,所以搞清楚Bug的产生阶段,可以帮助我们更有针对性地注意在这个阶段做一些事情,来及时发现Bug

“为什么会在这个阶段产生”,如果这个Bug不是代码Bug,而是开发从头就把需求理解错了,就要反思一下是不是我们需求细审时做得不够,是产品讲得不清楚, 还是测试没有提出一些有价值的风险?其他阶段如是,这也能帮助我们有针对性地改进

“如何避免Bug的产生”,其实有不少的Bug都是可以避免的,比如作为测试在需求阶段从测试角度想到一些容易出Bug的风险或场景,作为开发在编码之后的自测做得更好等等

4、Bug的改进

在这一步中要考虑的就是通过分析了Bug的根因,认识到了我们测试的不足之后,就要想办法如何改进我们的测试过程,以帮助我们在以后的测试工作。比如是我们的需求阶段没有真正地理解需求,还是测试设计阶段遗漏了一些测试场景,还是测试阶段由于测试环境、测试数据等因素没有发现Bug,还是Bug回归阶段没有回归其他收到影响的模块等等。

5、总结

Bug根因分析法是很有价值的,但并不是每一个Bug都需要这样刨根问底的分析,也没有这样的精力和时间允许我们这样做。要选取那些有价值的Bug,分析完后真正能帮助我们思考和改进,比如我们公司,就会有分析线上Bug的这一环节,是因为线上Bug毕竟是遗留到了线上,普遍会具有一些价值。

除了线上Bug,我们在测试中发现的Bug,如果比较有价值,能带给我们经验的提升,也是应该做根因分析的。所以,在进行Bug根因分析时,要以Bug的价值作为选取标准。

作为测试人员,一直是在有限的时间和资源下进行平衡,不存在零Bug的软件,测试也是无穷无尽的,所以平衡资源一直是测试人员应该掌握的技巧,分析Bug也不例外,我们的最终目的不在于把Bug根因分析流程化,比如迭代开发中每个迭代都做一次,作为工作流程中的一环,而在于从Bug中进行反思、总结、学习、改进,以便更好地改进我们以后的测试工作。

感谢您的阅读,以上就是我们对软件测试中Bug的解读,还记得我们生活中常说的一句宽慰自己的话吗?敌人、对手使我强大,这不正如软件测试中的Bug吗?好了,更多软件测试相关的内容尽在达内软件测试培训机构官网,敬请关注!

免责声明:内容和图片源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。

预约申请免费试听课

填写下面表单即可预约申请免费试听! 怕学不会?助教全程陪读,随时解惑!担心就业?一地学习,可全国推荐就业!

上一篇:做软件测试会用到哪些工具?
下一篇:我想从功能测试转向自动化测试,怎么办?

你知道吗?做软件测试不一定需要精通代码!

软件测试人员不需要懂代码,这是一个伪命题!

如何设计登录测试的设计用例?

软件测试必备的数据库知识有哪些?(终)

  • 扫码领取资料

    回复关键字:视频资料

    免费领取 达内课程视频学习资料

Copyright © 2023 Tedu.cn All Rights Reserved 京ICP备08000853号-56 京公网安备 11010802029508号 达内时代科技集团有限公司 版权所有

选择城市和中心
黑龙江省

吉林省

河北省

陕西省

湖南省

贵州省

云南省

广西省

海南省